You are not logged in.
Pages: 1
Yesterday I turned on my laptop and I got stuck on a UEFI menu loop where I couldn't boot my arch. I found someone in this forum who had a similar problem and fixed it by running mkinitcpio -P from a live usb. I did that and it didn't work. Then I saw on some other forums that it was GRUB working weirdly so I decided to switch over to systemd-boot but after the install it's not booting either. I might have done stuff wrong so please, any help is appreciated.
Lmk if I need to post any logs or whatever.
Offline
How exactly did you run mkinitcpio -P? You booted the live disk and then ran which commands? For this to work properly, assuming it's even the actual issue, you'd have to mount all relevant partitions, chroot, then run mkinitcpio -P, did you do that in that order?
Anyway, boot the live disk, mount all the partitions like you think they are correct so a proper chroot is possible, chroot, then post the outputs of
fdisk -l
lsblk -f
df -h
efibootmgr -v
ls -lR /boot
Offline
I booted the usb then ran:
mount /dev/nvme0n1p3 /mnt
mount /dev/nvme0p1p1 /mnt/boot
arch-chroot /mnt
mkinitcpio -P
Here are the outputs:
https://imgur.com/a/slZdkuV
Thanks for the help
Offline
Your boot order is Boot0000, Boot0001, Boot0002. The second two appear to be a USB drive.
Boot0000 tells the firmware to look for an EFI binary at /boot/EFI/systemd/systemd-bootx64.efi. Given that you just installed systemd-boot, that looks correct.
The output of ls -lR /boot is truncated by the window size. It's unlikely that there any missing files, but critically you need to make sure /boot/EFI/systemd/systemd-bootx64.efi does indeed exist.
This may or may not help, but in my most recent build the firmware would not load the proper binary unless I set it with the bcfg command from the UEFI shell. Now that I'm thinking about it this may be some bug involving NVME drives, because I never had that issue before and you are also using an NVME.
Offline
Then I saw on some other forums that it was GRUB working weirdly
the more plausible cause is likely the specific uefi implementation of your motherboard is what's behaving weird
unfortunately this seems to be a trend with recent hardware, mostly laptops, to have all kinds of issues as soon as one present them with anything else than windows
another user reported that, although they had secure boot turned off, a solution with thier system was to register the hash of the bootloader with the system anyway - although to this one I think it was just a symptom along the actual root issue
by spec any uefi should be able to load any arbitrary uefi binary from a drive it can see and from a filesystem it has drivers for - with fat32 as requirement - so as long as the firmware can read the fat32 it shoukd be able to boot from it - but, as many topics reveal: it seems like most oem only design and test thier implemdntations with windows and as soon as the user tries anything else it breaks in many ways
you can try to use the fallback path for remivable media ESP/efi/boot/bootx64.efi - but there is a chance it might also not work properly
Offline
The output of ls -lR /boot is truncated by the window size. It's unlikely that there any missing files, but critically you need to make sure /boot/EFI/systemd/systemd-bootx64.efi does indeed exist.
It does indeed exist, what do I do? ;-;
Offline
Pages: 1