You are not logged in.
Hi, I am looking for some advice on troubleshooting or repair steps after a recent system crash.
Today after an unexpected crash the system rebooted to bios (instead of GRUB) and no boot devices were listed. The system is UEFI with GRUB2 installed under /boot, the mount point of an ESP partition /dev/nvme0n1p1 (FAT32).
Booted from a live USB was fine (i.e. BIOS detected it as a bootable drive). Mounting the ESP partition I can see /boot/EFI/GRUB/grubx64.efi and GRUB files under /mnt/boot/grub as I would expect. However efibootmgr -v does not register this boot partition.
Does anyone have any advice on how to proceed? My thoughts are regenerating GRUB config, reinstalling grub and/or regenerating initramfs may be required.
The system is 6.5.5.arch1-1 and the last system update two days ago did not report any errors. For reference I attach the output os lsblk -f (nvme0n1 is the main boot device). Do let me know if other information may be helpful.
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0 squashfs 4.0 0 100% /run/archiso/airootfs
sda iso9660 Joliet Extension ARCH_202209 2022-09-03-05-06-12-00
├─sda1 iso9660 Joliet Extension ARCH_202209 2022-09-03-05-06-12-00 0 100% /run/archiso/bootmnt
└─sda2 vfat FAT16 ARCHISO_EFI 11C8-A028
sdb
└─sdb1 ext4 1.0 c9e70a78-f5a0-47c4-bdcd-dbc0f56230a9 13.1G 2% /mnt2
nvme1n1
├─nvme1n1p1
└─nvme1n1p2 ntfs 362CA6462CA6014B
nvme0n1
├─nvme0n1p1 vfat FAT32 551D-4A66 889.6M 13% /mnt/boot
│ /mnt
├─nvme0n1p2 swap 1 a71b6678-3f34-46c0-964c-dfacb53f357f
├─nvme0n1p3 btrfs archroot fe23bb23-4b77-42ef-88ae-38ebe66cec86 163.2G 18% /mnt
└─nvme0n1p4 btrfs archhome 04da4b4d-b346-45a8-9efe-18bb8d0e90f2 639.9G 11% /mnt/home
nvme2n1
└─nvme2n1p1 btrfs archdata a57d76c3-c978-42fd-8d86-62403422d20e Last edited by piperfw (2023-10-03 06:04:46)
Offline
An update with a few more things I have checked:
- the physical drive nvme0n1 is detected by BIOS (UEFI), just not listed as a bootable drive
- secure boot is off and the BIOS is in UEFI not legacy mode (as has always been)
- I tried turning off the 'fast boot' option but this did not change the outcome
The moterboard is ASUS B650-PLUS Wifi. I am going to put in a ticket with ASUS support to see if they have suggestions. Other things I might look to try: testing the drive with SMART, installing an OS on a spare harddrive and connecting that to the system (but presumably that would work, since I could boot from the USB device). Other suggestions welcome.
Offline
reinstalling grub and/or regenerating initramfs may be required
But I'd start w/ an fsck on nvme0n1p1 and, though I doubt that happened, "fdisk -l /dev/nvme0n1" to see whether its still typed "EFI System"
https://wiki.archlinux.org/title/EFI_system_partition
Offline
Thanks seth, I can confirm that the partition is still listed as EFI correctly on the GPT table as I originally setup during installation:
fdisk -l /dev/nvme0n1
---------------------
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WD_BLACK SN850X 1000GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 83E393C3-26CD-E649-8B8A-3883F7DDB226
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 2099199 2097152 1G EFI System
/dev/nvme0n1p2 2099200 18876415 16777216 8G Linux swap
/dev/nvme0n1p3 18876416 438306815 419430400 200G Linux filesystem
/dev/nvme0n1p4 438306816 1953523711 1515216896 722.5G Linux filesystemOffline
Reinstalling GRUB and regenerating grub.cfg fixed the issue. I did not have to regenerate initramfs.
I'm not sure how the system crash damaged the bootloader.
Commands for reference (after mounting the ESP partition to /mnt/boot and arch-chroot /mnt):
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
# grub-mkconfig -o /boot/grub/grub.cfg
# efibootmgr -v # GRUB now recognisedOffline
I'm not sure how the system crash damaged the bootloader.
Filesystem corruption.
You can somewhat protect the boot partition/ESP itr by only mounting it on demand and unmounting it asap to get the FS synced and inert.
But if the automount-on-demand fails or is too eager or you forget to manually mount it on need, the next (kernel) update will break your boot for sure.
And it doesn't help when the system crashes at the wrong moment either ![]()
Offline
You can somewhat protect the boot partition/ESP itr by only mounting it on demand and unmounting it asap to get the FS synced and inert.
Interesting, given this has only happened once in 6-7 years of using arch/GRUB I will leave it for now. That being said, events are rarely independent - so the crash may well occur again next week (:
Offline
And here is a humorous follow-up courtesy of ASUS Support [off-topic]:
Kindly be advised that the software for this motherboard and all the documentation was intended for Windows usage only.
We do not have any troubleshooting steps or advices for Linux OS. If you can format the drive and run Windows OS from the same drive, this indicates that there is no issue with the motherboard itself.Thank you.
Offline