Gentlemen, help me sort out my Linux install, please! Systemd-boot issues.

[auntjemima]

I bought a new nvme and I am running it externally in a usb c enclosure. This is the second time I have done this because I want it separate from Windows entirely. I don't want them sharing a bootloader or efi partition.

Because my main drive is not removable, I disable it in the BIOS while using my Linux drives. This has always worked for me with my Mint install on my other USBC nvme and the windows/Linux efi partitions don't know each other exist. Yay!

With the new drive I am running endeavour OS. Love this, btw! Installing games, even BattleNet, was smooth. I followed the same steps, disabled the internal drive, installed the OS, rebooted, no issues. But then I needed some save files from Windows and I was unable to mount the windows drive in Linux, kept getting permission issues.

So I logged into windows but I forgot to disconnect my external drive! That said, before loading windows I went into the BIOS and made sure my windows boot manager was selected on the internal drive, not really thinking about the EnOS drive.

Boots into windows, copy the files I need to a usb stick and reboot, follow the same steps of disabling the internal drive. But now under boot options I only have Windows Boot Manager.. on my external drive. Oddly enough, it seems that windows has its EFI files on both drives, internal and external. So I can select either and still boot into windows.

I booted from a liveusb and ran the following...

sudo su
mkdir /mnt; mkdir /mnt/EFI
mount /devlsda4 /mnt
mount /dev/sda1 /mnt/EFI
arch-chroot /mnt
bootctl install
reinstall-kernels

This is the direction from everywhere I can find. The files it creates are definitely there. A new kernel, proper EFI files, folder structure, etc...

Yet on reboot I never get any option on this drive besides Windows. I am sure my drive is /EFI and not /boot/EFI. Verified many times. Bootctl by itself shows my EnOS boot but the ESP flag at the end has an X..

Thoughts?

 

[CrimsonKnight13]

EFI folder shouldn't be made before mounting since it'll be already on the rootfs of EndeavourOS. Any Live OS will already have /mnt as well.

EFI will be within /efi or /boot/efi as /efi/EFI or /boot/efi/EFI

What is your filesystem for /? If btrfs, it'll have subvolumes for /, /var/cache, /var/log, & /home (if /home isn't a different partition on its own).

With EXT4 or other filesystems without subvolumes

sudo -s
mount /devlsda4 /mnt
mount /dev/sda1 /mnt/efi
arch-chroot /mnt
bootctl install
reinstall-kernels

With BTRFS

sudo -s
mount -o subvol=@ /dev/sda4 /mnt
mount -o subvol=@cache /dev/sda4 /mnt/var/cache
mount -o subvol=@log /dev/sda4 /mnt/var/log
mount -o subvol=@home /dev/sda4 /mnt/home
mount /dev/sda1 /mnt/efi
arch-chroot /mnt
bootctl install
reinstall-kernels

 

[auntjemima]

EFI folder shouldn't be made before mounting since it'll be already on the rootfs of EndeavourOS. Any Live OS will already have /mnt as well.

EFI will be within /efi or /boot/efi as /efi/EFI or /boot/efi/EFI

What is your filesystem for /? If btrfs, it'll have subvolumes for /, /var/cache, /var/log, & /home (if /home isn't a different partition on its own).

With EXT4 or other filesystems without subvolumes


With BTRFS

My file system is ext4 for all partitions except EFI, which is FAT32.

What's the harm by creating the EFI folder to mount in to? If it's already created on a liveUSB I assume no change would be made? I guess I'm not sure the relevance you are getting at. I'm new to arch, would this cause an issue during the rest of the steps?

 

[CrimsonKnight13]

EFI is already inside of /boot/efi or /efi under the root filesystem of your installation.

bootctl install will do the rest for you w/o the need to create EFI.

Please test the EXT4 command list if possible.

 

[auntjemima]

EFI is already inside of /boot/efi or /efi under the root filesystem of your installation.

bootctl install will do the rest for you w/o the need to create EFI.

Please test the EXT4 command list if possible.

I have run that command 40 times hoping for a different outcome and nothing changes.

 

[CrimsonKnight13]

What does "bootctl status" show?

 

[Nobu]

The arch wiki has a few troubleshooting entries for windows dual-boot issues: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Windows_changes_boot_order

 

[auntjemima]

What does "bootctl status" show?

Let me get onto my PC instead of my phone and give you a snip.

The arch wiki has a few troubleshooting entries for windows dual-boot issues: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Windows_changes_boot_order

I've done that as well. No luck.

 

[auntjemima]

What does "bootctl status" show?

This was after running the above commands..

 

[Nobu]

I've done that as well. No luck.

So you tried adding an entry which points to Arch directly instead of the default (BOOTx64.EFI)?

If your motherboard is booting the default boot path (\EFI\BOOT\BOOTx64.EFI), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using efibootmgr.

For systemd-boot, the command would be this:

efibootmgr --create --disk /dev/sdX --part Y --loader '\EFI\systemd\systemd-bootx64.efi' --label "Linux Boot Manager" --unicode

Or, from windows:

bcdedit /copy {bootmgr} /d "Linux Boot Manager"
bcdedit /set {guid} path \EFI\systemd\systemd-bootx64.efi

If you do this, is your Arch drive available there? If so, can you boot arch from there and try fixing the efi entries from there?

 

[Nobu]

Oh, make sure you replace sdX and Y with you esp drive and partition, guid with the value returned by bcdedit.

Also, the motherboard may ignore the ESP on your non-windows disk, so you might have to copy/install the systemd-boot manager to the other disk.

 

[auntjemima]

Oh, make sure you replace sdX and Y with you esp drive and partition, guid with the value returned by bcdedit.

Also, the motherboard may ignore the ESP on your non-windows disk, so you might have to copy/install the systemd-boot manager to the other disk.

I ran it within windows, which is what I meant by your first link as it went right to that location. I just ran the other suggestion

efibootmgr --create --disk /dev/sdX --part Y --loader '\EFI\systemd\systemd-bootx64.efi' --label "Linux Boot Manager" --unicode

and it worked! Thank you so much!

 

[auntjemima]

You have both been great! Always learning new little tools with Linux and since this is my first Arch install, it takes some getting used to over debian/Ubuntu builds. Still unsure of all of the reasons for using pacman vs yay and the -Syu. Some day I'll look it up.

 

[CrimsonKnight13]

I'm glad Nobu was able to help out further. I forgot about efibootmgr not necessarily playing nice with dual boot at times, which I've had such happen myself.

As far as pacman AUR wrappers go, I recommend paru over yay & others.

 

[Nobu]

No problem! Glad it worked. To be honest, it's been a while since I had a windows disk in mine with linux, so I wasn't sure it would, but I did remember having the problem before, and fixing it somehow.

 

[uOpt]

Can somebody clarify what exactly happened here in technical terms?

Did Windows just go out and murder this install on a second disk unrelated to the Windows install?

 

[Nobu]

Can somebody clarify what exactly happened here in technical terms?

Did Windows just go out and murder this install on a second disk unrelated to the Windows install?

I could be wrong, but I think what happened is windows' boot manager cleared all the efi boot entries, and replaced the default boot manager with it's own, although it may have only replaced the default.

What the command auntjemima used did, was add a non-default efi boot entry for systemd-boot, which allows it to be added to the list of boot devices in the bios in whichever order you like. Ideally, Windows would import the boot entries to its own bootloader and let you choose at system startup, but that adds complexity...and it's windows. You can add linux to windows boot options btw, but I don't know how and it could disappear just the same, not really worth it to me.

 

[auntjemima]

I could be wrong, but I think what happened is windows' boot manager cleared all the efi boot entries, and replaced the default boot manager with it's own, although it may have only replaced the default.

What the command auntjemima used did, was add a non-default efi boot entry for systemd-boot, which allows it to be added to the list of boot devices in the bios in whichever order you like. Ideally, Windows would import the boot entries to its own bootloader and let you choose at system startup, but that adds complexity...and it's windows. You can add linux to windows boot options btw, but I don't know how and it could disappear just the same, not really worth it to me.

It was definitely the first part. Without running the initial set of commands near the beginning of this thread I would not have had any of my kernels or file structure at all. When looking in the EFI drive initially, nothing Linux was there at all until I ran those commands.

 

[auntjemima]

What kills me the most is windows already had its own EFI partition on the internal drive... Yet for some reason it decided it also needed an EFI partition on my external drive as well, just because I booted into it.

 

[CrimsonKnight13]

What kills me the most is windows already had its own EFI partition on the internal drive... Yet for some reason it decided it also needed an EFI partition on my external drive as well, just because I booted into it.

Did you happen to upgrade or update Windows while the external drive was connected? That's the fastest way to see something go poof unless both OSes are on their own dedicated internal drives.

 

[auntjemima]

Did you happen to upgrade or update Windows while the external drive was connected? That's the fastest way to see something go poof unless both OSes are on their own dedicated internal drives.

I didn't see anything install and my shutdown and reboot options in windows did not say "Shut down and update" or "restart and update" which it does when there are updates to install.

But who knows.