this post was submitted on 10 Jul 2025
6 points (100.0% liked)

Arch Linux

8888 readers
9 users here now

The beloved lightweight distro

founded 5 years ago
MODERATORS
 

Sorry for making a post for such a basic question but I wasn't able to figure out my own so I'm come here as last resort.

I bought a new CPU, RAM, and motherboard combo and I migrated all my non-conflicting parts from my previous machine, which had a Linux install and a Windows install.

When I booted into the PC, I did not see an option in the boot menu or in the boot order for Linux whatsoever. Only my windows 11 IoT install and my new nanokvm.

I had a asrock x570 extreme4 and switch to a Msi Pro x870E-P WiFi. I have updated to the newest BIOS.

I was previously using systemd as my boot manager until I tried switching over to grub but neither trying to fix system D or installing grub seemed to work for me.

So I was hoping that I could delete my boot partition or somehow start from scratch without deleting any data in my root partition (Btrfs sub volumes) . and get a step-by-step installation guide for me since I can't seem to understand the arch wiki at my current state.

I would like to give you guys more information about the scenario and more context of what I've done, but i'm sadly not capable.

/dev/nvme0n1 is my linux install while /dev/nvme1n1 is Windows 11 IoT

top 11 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 1 day ago (1 children)

You can fix this, and this certainly isn't "basic".

I figure you didn't see your Linux option, because your EFI boot variables (boot order and boot loader locations) are stored "on the mainboard", and you didn't manage to reset those on the new board according to your current layout. Windows still boots, as it installs its bootloader in a generic location intended for removable devices, instead of properly registering itself with EFI boot variables. Because of course they do.

To fix this, I'd recommend a deep breath first, and then set BIOS to UEFI boot only, no CSM/legacy at all for now, no even as fallback. If you're lucky, you can boot into your Linux system from the BIOS boot menu right now, and skip the archiso boot and chroot shenanigans. Have a look. Otherwise boot into the archiso as you did before.

Identify your EFI system partition(s) (ESP) Run sfdisk -l /dev/nvme0n1 and sfdisk -l /dev/nvme1n1, note the "EFI System" type partitions. Ideally, there's only one at nvme1n1p3. Multiple ESPs would be trickier, but let's assume your singular ESP is nvme1n1p3. Have a look at the ESP, to understand its layout and confirm this is really what you're looking for: mkdir /esp, mount /dev/nvme1n1p3 /esp, find /esp. You should find the Windows bootloader at EFI/Boot/bootx64.efi and EFI/Microsoft/Boot/bootmgfw.efi.

You might also find your grub bootloader in a subdirectory like EFI/arch/grubx64.efi. Find all of your instances with find /esp -iname grubx64.efi, and note the paths. If you find multiple grubx64.efi, I'd recommend to pick only the newest file, unless you know for a fact which one is supposed to be the one you want to use. A ls -l <file> gives you the date of the file to check. If you don't have any grub bootloader installed, yet, that's fine, too.

Create a boot entry with grub in a chrooted system If you can arch-chroot into your Linux system, make sure your ESP is mounted in your chroot as well, let's say at /esp again, and your /boot directory must be mounted, too, otherwise grub-install will fail. Then grub-install --efi-directory=/esp should do its magic just fine. Use efibootmgr to display/edit the EFI boot variables, and check if the entries in there look correct. The ESP will be referenced by UUID, and the list will look pretty busy, but you should recognize the EFI paths, and your arch entry should be the BootCurrent value. Make sure you've got a /boot/grub/grub.cfg in place, otherwise grub won't do you much good! Create one with grub-mkconfig -o /boot/grub/grub.cfg from within your chroot, after editing /etc/default/grub if you need to add any kernel arguments for your system. Usually you do not, so fire away.

If chrooting doesn't work for you, btrfs can be a little tricky, you should be able to install grub with the ESP and boot partition mounted alone in the archiso. nvme0n1p1 looks like your boot partition, so it'd go down like this:

mkdir /esp /linuxboot
mount /dev/nvme1n1p3 /esp
mount /dev/nvme0n1p1 /linuxboot
grub-install --efi-directory=/esp --boot-directory=/linuxboot

You can pacman -S grub if grub-install isn't available on archiso, yet. Make sure you've got a /linuxboot/grub/grub.cfg in place here as well. Unfortunately you cannot use grub-mkconfig effectively without the chroot, but if you are at this point, and you're dropped into the grub rescue shell, you can try a minimal, lovingly handcrafted grub.cfg: You need to obtain the UUIDs of your ESP, boot and root partition for the menuentries, and replace the placeholders with your values. You can get those values with lsblk -oNAME,UUID /dev/nvme1n1p3 /dev/nvme0n1p1 /dev/nvme0n1p2, in this order (ESP, BOOTPART, ROOTPART UUID). I assume your root subvolume is named root, and your kernel is named vmlinuz-linux on the boot partition, with a vmlinuz-linux.img initfs. You should adapt these filenames in the grub.cfg if they are different, of course, but I think this is a pretty good guess. :)

insmod part_gpt
insmod part_msdos
set default="0"
if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi
export menuentry_id_option
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}
terminal_input console
terminal_output console
set timeout=5
menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root <BOOTPART UUID>
        echo    'Loading Linux linux ...'
        linux   /vmlinuz-linux root=UUID=<ROOTPART UUID> rw  rootflags=subvol=root
        echo    'Loading initial ramdisk ...'
        initrd  /initramfs-linux.img
}
if [ "$grub_platform" = "efi" ]; then
  insmod bli
fi
if [ "$grub_platform" = "efi" ]; then
menuentry 'Windows Boot Manager --class windows --class os $menuentry_id_option 'osprober-efi' {
        insmod part_gpt
        insmod fat
        search --no-floppy --fs-uuid --set=root <ESP UUID>
        chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
fi

Let's see how this goes.

[–] [email protected] 1 points 1 day ago
[–] [email protected] 6 points 1 day ago* (last edited 1 day ago) (2 children)

Switch from bios to uefi boot mode (or vice versa)?

Sometimes called legacy bios or something? From a quick google, might be called CSM

[–] [email protected] 4 points 1 day ago

This is most likely it. Seems some newer boards don't just nicely support both UEFI and legacy booting and will straight up only do one or the other

[–] [email protected] 2 points 1 day ago (1 children)

By default my motherboard came in with UEFI and I switched it to CMS and I did see more boot options they are USB Key,USB Floppy, and Network. I'm going to get a random 128gb SSD and use archinstall on it to see if show up on my system.

[–] [email protected] 1 points 1 day ago

Odd that the disk didn't show up in the list there. If there are other options near CMS maybe have a play with them?

Another option to checkout is to disable secure boot?

[–] [email protected] 1 points 1 day ago* (last edited 1 day ago)

What files do you have in /dev/nvme0n1p1?

From the looks of it, that should be your linux boot partition.

If you can, just remove every other drive temporarily while you focus on that specific drive. This will help avoid making changes to the windows bootloader.

From there, boot into an arch iso, mount your btrfs subvolumes (i.e. /mnt and /mnt/home and /mnt/var/logs and whatever other subvolumes you have), mount your boot partition into your btrfs mount point (i.e /mnt/boot), and then arch-chroot into your system (/mnt).

From there you'll be in your actual system. If you're using systemd-boot, run the bootctl install command. This will copy the systemd-boot UEFI boot manager to the ESP, create a UEFI boot entry for it and set it as the first in the UEFI boot order.

If you are using grub, follow the grub guidelines for installing their bootloader (im not familiar with grub commands).

Once that is done, go ahead and run mkinitcpio -P to make sure your kernel images are bootable options for your bootloader.

After that, exit and unmount the boot and BTRFS subvolumes and reboot.

That should get you back into your system.

[–] [email protected] 2 points 1 day ago

Something to try:

Boot into a Linux liveUSB environment. Then, chroot into your Linux partition (you can use Gentoo's chroot instructions from their handbook).

Once inside the chroot, reinstall your boot loader (grub or systemd).

I have a suspicion that Windows had its way with your boot partition.

[–] [email protected] 1 points 1 day ago

New motherboard with new boot options, and possibly an incompatible partition scheme.

Pull up the boot menu during POST and force it to boot the partition. That usually works depending on the manufacturer.

Otherwise, get a LiveUSB and make sure your drive is actually showing up post-boot.

[–] phucyall 1 points 1 day ago (1 children)

How many hard drives do you have in your machine?

[–] [email protected] 1 points 1 day ago* (last edited 1 day ago)

I have one HDD /dev/sda. Two SDD. /dev/nvme0n1 is my linux install while /dev/nvme1n1 is Windows 11 IoT. and I have a pcie card that has a micro sd card (nanokvm).