You are not logged in.
I am running a headless server, mostly a nextcloud instance. Seemingly out of the blue, the EFISTUB-based boot has stopped working, and the machine goes straight to the UEFI/BIOS setup screen (ASUS, Z87-PRO, BIOS Version 2103).
I can boot using an USB drive and the Arch installation media. I can mount and arch-chroot into my installation, which looks and behaves (mostly) as normal then. I have then basically repeated the steps of my original setup procedure, reinstalled efibootmgr, updated the kernel and run mkinitcpio -P, checked that the files in /boot looked fine, and recreated the boot entry with efibootmgr. In the UEFI/BIOS boot menu, the new label I have assigned shows up, but when I select the entry, I go straight back to the UEFI/BIOS setup screen, so I assume the BIOS does not find a valid bootloader. I am totally at a loss what has changed to break my setup.
Some more details: My root file system is btrfs, and I am using subvolume @.
This is the current recommendation from the ArchWiki:
efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "EFISTUB Arch" --loader /vmlinuz-linux-lts --unicode 'root=UUID=01a40dd8-28f0-4636-be1e-aeed60c98095 resume=UUID=2d877d5d-4ca1-4d46-a3d6-b6ee94cbbd78 rw rootflags=subvol=@ loglevel=3 quiet initrd=\initramfs-linux-lts.img'
This is what I successfully used before, based on the ArchWiki entry then:
efibootmgr --disk /dev/sda --part 1 --create --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=UUID=91824ea9-6fab-4793-8f01-e461ff81ded2 rootfstype=btrfs rootflags=subvolid=261 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img' --verbose
I remember that I first tried subvol=@, but for some reason that did not work until I found the recommendation to use the subvolid instead. Maybe that indicates a problem that now has come back to bite me? The subvolid cannot change, can it?
Apart from the resume= parameter and using the LTS image, I can see no significant difference.
In the days before, I did experience some issues which are probably unrelated, but I am including them here just to be sure:
- nextcloud was reporting that uploading files had failed, even though the files were in fact uploaded.
- the /tmp drive had run out of inodes and was full for some reason. I think the nextcloud behavior may have been due to that
- I updated openssh and issued the try-restart command as recommended in the news item, but the restart failed (with the 'too soon' error)
- in my arch-chroot environment, snapper is not working properly, so when I used pacman to reinstall certain packages, I always got an error message when snapper tries to create the snapshot - but which does not cancel the pacman operation, so I suppose this is not a major issue.
I will re-verify the GUID and ID and try a few more times, but am otherwise out of ideas. Of course, I can always try installing GRUB, systemd-stub or rEFind, but I do not understand why this should suddenly be necessary.
Any hints or ideas would be appreciated!
Last edited by infinite-recursion (2024-07-05 07:29:54)
Offline
OK, the solution was very simple: for some reason, initramfs-linux.img had been deleted from /boot, and running mkinitcpio -P rather than mkinitcpio -P linux did not recreate it. For some reason I did not realize it should have been there, perhaps because I also have intel-ucode.img in there and so saw an .img file...
subvol=@ is now also working. And snapper also works again now that I have properly booted into my system.
Offline