You are not logged in.
I made the following post a little while ago: https://bbs.archlinux.org/viewtopic.php?id=300156
The problem was that Arch couldn't boot and it was eventually solved by reinstalling GRUB by arch-chroot from an install USB. But the same problem was re-occurring each time I boot the system. And I thought that too was solved by using the --removable option when reinstalling GRUB. Afterwards, rebooting the system did not require reinstalling GRUB. But now, again, I updated my system and once more, when rebooting, I couldn't boot without reinstalling GRUB. And I think that's the pattern. Updating the system seems to break something which is fixed by reinstalling GRUB.
Last edited by shayan99999 (2024-10-24 15:31:00)
Offline
as already mentioned: this seems to be an issue specific to your hardware and its uefi implementation
anyway - to give it another try:
what exactly happens after the system uodate (likely specifically a kernel udate)?
doesn't grub show up anymore?
does it show up but the boot itself fails?
if so: at what point does it fail (what's the last message you see)?
from other posts I suspect that when you update the kernel the new version and the new initramfs doesn't end up where they belong and hence grub tries to boot the old kernel which fails at pivot_root as the booted kernel is the old one and doesn't match the modules of the new one installed by the update - which in turn hints towards som issue with /boot (not mounted / wrong mountpoint) and fstab
have you any partition more than once in fstab (i.e. by executing genfstab from arch install)?
Offline
After the system update, I usually immediately restart my laptop. After which (and all the times this happened, I do think it was a kernel update), it boots through to GRUB and it works properly. Then, for some reason, it fails and tries to start an emergency shell. It fails to start an emergency shell because I don't have a root user set up. So I can't really do anything. So I go about using an install USB to arch-chroot into my system and reinstall, which inexplicably fixes everything.
As for the kernel update being the potential issue, something else might be relevant. When I reinstall GRUB from arch-chroot, I also reinstall the kernel as well each time. I don't think that could cause a problem but I thought I should mention it regardless.
I've never edited my fstab. But here it is:
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p3 UUID=792fa735-46c5-4c22-a00d-06c66fb41eb2
LABEL=ROOT / ext4 rw,relatime 0 1
# /dev/nvme0n1p2 UUID=A7FD-2842
LABEL=EFIBOOT /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
Offline
When you reinstall from the ISO, are you mounting the ESP? If not, GRUB is likely loading the kernel from the wrong place, the /boot dir of the root partition. If you want the ESP at /boot, you need to install grub while it's mounted there.
Offline
When you reinstall from the ISO, are you mounting the ESP? If not, GRUB is likely loading the kernel from the wrong place, the /boot dir of the root partition. If you want the ESP at /boot, you need to install grub while it's mounted there.
From the ISO, I mount the root partition to /mnt. Then I arch-chroot into the system. Then I mount the boot partition to /boot/efi
Offline
Why are you mounting it to /boot/efi? Your fstab is mounting it to /boot, so the new kernel is getting installed to the ESP, but grub is not looking for it there because you're doing it differently when you chroot. Make a choice on how you want it set up and stick with it.
Offline
# Static information about the filesystems. # See fstab(5) for details. # <file system> <dir> <type> <options> <dump> <pass> # /dev/nvme0n1p3 UUID=792fa735-46c5-4c22-a00d-06c66fb41eb2 LABEL=ROOT / ext4 rw,relatime 0 1 # /dev/nvme0n1p2 UUID=A7FD-2842 LABEL=EFIBOOT /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
From the ISO, I mount the root partition to /mnt. Then I arch-chroot into the system. Then I mount the boot partition to /boot/efi
and here we go again - passing left on "things that make you GRR" and jumping right off the cliff ...
why - just why I somewhat knew this or something very similar is the acutal cause of your issues?
sorry for drifting a bit sarcastic here - but, well, here you go: as predicted: the root issue is a wrong mountpoint
so here's what happens:
- arch-chroot
- mount ESP to <chroot>/boot/efi
- install kernel to <chroot>/boot
- install grub to <chroot>/boot/efi
- reboot
- in normal system
- have ESP mount to /boot instead of /boot/efi - thereby shadowing what's inside /boot: the kernel and initrd
- kernel update / mkinitcpio - new kernel and initrd gets installed to ESP mounted at /boot
- reboot
- grub tries to to load the kernel from /boot - which still has the old kernel and initrd as it was shadowed by the mount
- the boot fails due to kernel and initrd no longer matching what's install on root
- arch-chroot - start from top and you "magically" fix the wrong mountpoint issue
solution: either change fstab to mount ESP to /boot/efi - or mount ESP to /boot during arch-chroot
Offline
Next time it breaks, I'll mount it to /boot instead and see if that fixes it. Thanks for the suggestion!
Offline
Or just set it up like you want now, and reinstall and reconfigure grub and avoid the problem altogether.
Offline
I edited fstab and it seems to have fixed it as the system booted properly even after a system update.
Offline