Can´t boot SystemD-Boot after System Upgrade

Hey,
I used to have an old mainboard with an i7-6700.
Today was major upgrade day and I switched to an MSI MAG B550 Tomahawk Max board and installed a Ryzen 5 3600.

I used to have Windows ages ago. Apparently, something of that still lingers, because the UEFI only shows the Windows loader. No Systemd-Boot or anything that looks like Endeavour OS.
So far, I’ve tried:

  • Switching from AHCI to RAID
  • Changing Secure Boot options in every possible way
  • Trying to boot generic entries like “USB hard drive”, “Hard Disk Drive”, etc.
  • Rebuilding the boot setup using chroot and bootctl install
  • Turn UEFI into CSM

Nothing helped. I just can’t get this M.2 SSD to boot, which means I currently have no working system. I’d rather not reinstall because there’s too much stuff on that system I want to keep.

Anyone got any advice on what else I can try?
The partition layout is:

SDD1 – vFAT FAT32 EFI
SDD2 – SWAP
SDD3 – EXT4 Endeavour OS

Should be AHCI

Should be disabled

CSM should be disabled

With the above settings, you should be able to boot the default entry.

Yeah, I actually know that. But out of desperation I tried all those options, toggled them back and forth, and tested every possible combination.
But it’s just no use. All I ever get to see is a Windows bootloader that seems to be hidden on my storage SSD (even though Windows hasn’t been on there for a loooong time).

But there’s no trace of the Endeavour SSD or systemd-boot.
I really don’t know that much about this stuff, maybe what I’m thinking is dumb.
But I just think: when I installed the new motherboard, I didn’t pay attention to where I plugged in the SATA cables. I just stuck them into the SATA ports randomly. That probably messed up the drive order. And systemd-boot might still have old IDs or device orders or whatever saved somewhere.
Like I said… I don’t know too much. And maybe I’m talking nonsense.

If I chroot into the system now and replace systemd-boot with GRUB — could that straighten things out again? Or would the problem just stay the same, and I’d just be swapping out one source of trouble for another?

No, what happens is that the UEFI entries are stored in the nvram of your MB. So the new board doesn’t have the entries you need.

You should be able to boot the fallback, but if you can’t you need to recreate the entry. You can do this manually using efibootmgr but it is probably easier to chroot in and run bootctl install. I know you said you tried that already but are you sure that the chroot was setup properly? Be sure to use mount the EFI partition at the right location and use arch-chroot to setup the chroot.

That would be more work than it is worth.

Hey, thanks a lot for trying to help. I tried it again, but it didn’t change anything. However, I did notice something:

When I chroot into the system and the live console switches into my system’s environment, I get the neofetch output. And that output says I’m running the Arch kernel.
But my installed system only has the Zen kernel (no other one, neither mainline nor Arch).
Could that be part of the problem? Like, could the EFI be pointing to a kernel that doesn’t even exist or something like that?

You appear to mounting the ESP at the wrong location. It should be mounted at /efi for systemd-boot EOS install.

The running kernel is the one from the ISO, not the one in the installed system.

The problem has been solved.
Daltos’ help was crucial for that—thanks again!
Without the hint that I had been chrooting into /boot the whole time instead of /efi, I never would’ve been able to fix it. After over 10 hours of tinkering, I was just totally blind to the obvious.

Anyway,
bootctl install
followed by
efibootmgr --create --disk /dev/sdd --part 1 --label "EndeavourOS" --loader '\EFI\systemd\systemd-bootx64.efi'
ultimately made it possible to select Endeavour OS in the boot priority. Now it’s running again, and my issues are history.

So once more—thanks a lot!

1 Like