You are not logged in.
This morning while under pressure, I ran
sudo grub-mkconfig -o /boot/grub/grub.cfgafter a minor edit in the former grub configuration. That put the grub config file in the wrong place. Now the laptop only boots to the BIOS setup screen.
To recover the former UEFI-only boot, i guess i will have to boot from usb with a rescue pendrive and chroot, before locating the right location ( which i should have checked before messing up ) and rebuilding grub.cfg there. i want to make sure i am not going to make a stupid mistake worse.
(I am busy with reading the grub wiki as i write.)
EDIT: Where I am at:
- booted to root prompt from 2017 Archlinux ISO pendrive
# mkdir -p /mnt/vfat
# mount /dev/nvme0n1p1 /mnt/vfat
# ls -AF /mnt/vfat
EFI/
# ls -AF /mnt/vfat/EFI
BOOT/ Dell/ GRUB/ arch/ arch-grub/ ubuntu/
#
# ls -AF BOOT
BOOTX64.EFI*
# ls -AF Dell
Bios/ logs/
# ls -AF GRUB
grubx64.efi*
# ls -AF arch
fw/ fwupdx64.efi* grubx64.efi*
# ls -AF arch-grub
grubx64.efi*
# ls -AF ubuntu
fw/, fwupdx64.efi*, grub.cfg*, grubx64.efi*, mmx64.efi*, shimx64.efi*I gather from here that during the early boot sequence, the firmware reads NVRAM and determines which EFI application to launch and from where. So in my case I kinda groked that the firmware tries to find an EFI application in the fallback boot path \EFI\BOOT\BOOTx64.EFI .
So which does that single boot system need GRUB/, arch-grub/ and/or ubuntu/ ? .... Part of those seem to be multiple remnants of (old?) installs. ubuntu is nowhere to be seen on that laptop and arch and arch-grub probably point to several attempts at re-installs.
I don't know how to clean that up to get rid of superfluous directories . Any pointer welcome.
# mkdir -p /mnt/boot
# mount /dev/nvme0n1p5 /mnt/boot
# ls -AF /mnt/boot
efi/ grub/ initramfs-linux.img initramfs-linux-fallback.img intel-ucode.img lost+found/ vmlinuz-linux/mnt/boot/efi/ is empty.
As expected I found the file /mnt/boot/grub/grub.cfg with the datestamp that immortalizes my mistake.
How do I take it from there ?
Last edited by Cbhihe (2022-09-14 19:12:05)
I like strawberries, therefore I'm not a bot.
Offline
Rebuilding the grub.cfg at the wrong location would have no effect. Rebuilding grub.cfg at the correct location, but not seeing the current news and also not rerunning the corresponding grub-install command will currently generate a config that crashes the old GRUB.
So from the bits and pieces we have. mounting /dev/nvme0n1p5 to /boot is correct and where GRUB is looking for it's configuration, and your ESP (nvme0n1p1 ) was either not mounted after initial grub-install, or maybe mounted to /boot/efi. That there are Ubuntu remnants there can be normal if you didn't clean house here) You might be able to make more telling inferences by looking at your /etc/fstab.
From the bits we have the progression should be
mount $yourroot$ /mnt
mount /dev/nvme0n1p5 /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot/efi
arch-chroot /mnt
pacman -Syu #Make sure we are up to date and havve the latest GRUB
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
#Shouldn't be necessary but do it for good measure
grub-mkconfig -o /boot/grub/grub.cfgreboot and recheck, if anything fails, post the error message and
cat /etc/fstab
lsblk -f
mountOffline
Sorry for the long edit that became visible after you completed your reply.
On your fourth line:
# arch-chroot /mnt
==> WARNING: /mnt is not a mountpoint. This may have undesirable side effects.
mount: /mnt/proc: mount point does not exist.
==> ERROR: failed to setup chroot /mntDo I need to issue the intermediate cmds for /proc and /sys
# mkdir -p /mnt/proc
# mount -t proc proc /mnt/procbefore proceeding with line 4 ?
If I do ...
# mkdir -p /mnt/{proc,sys}
# mount --bind /proc /mnt/proc
# mount --bind /sys /mnt/sys
# arch-chroot /mnt
==> WARNING: /mnt is not a mountpoint. This may have undesirable side effects.
mount: /mnt/proc: proc already mounted on /proc.
==> ERROR: failed to setup chroot /mntLast edited by Cbhihe (2022-09-14 17:54:48)
I like strawberries, therefore I'm not a bot.
Offline
No, you need to replace the $yourroot$ with the partition for your root drive, the name/device node of which you haven't disclosed yet.
Last edited by V1del (2022-09-14 18:02:40)
Offline
Yes (the host root is /dev/nvme0n1p8), thank you. With that I can advance to the pacman update, but:
# pacman -Syu
error: failed to initialize alpm library
(root: /, dbpath: /var/lib/pacman/)
could not find or read directorySo should I use the --sysroot /mnt long option for pacman when issuing the cmd from the chroot context ? (At least that's my take from the pacman's man page.) but then, when trying that, host complains with:
error: config file /etc/pacman.conf could not be read: No such file or directory.which kinda makes sense since I issue the cmd from chroot context.
So maybe adding --config /mnt/etc/pacman.conf ?
Last edited by Cbhihe (2022-09-14 18:44:37)
I like strawberries, therefore I'm not a bot.
Offline
You can also skip the pacman update. Though I'm not sure what your partition setup is if none of these normally essential paths are not available. Is this BTRFS with multiple subvolumes? Mount your stuff correctly.
No after the chroot all your logical paths should be under / so /boot will be /dev/nvme0n1p5 and /boot/efi will be /dev/nvme0n1p1 and so fort. If you are still unsure please post the "in case of failure" outputs I asked for.
Offline
ok. I skipped pacman -Syu and everything went smoothly. I thank you for your help.
I had not touched that laptop before this morning and I am still curious about the structure of /dev/nvme0n1p1 as described in my top message:
EFI
| __ BOOT/
| __ Dell/
| __ GRUB/
| __ arch/
| __ arch-grub/
| __ ubuntu/
with:
# ls -AF BOOT
BOOTX64.EFI*
# ls -AF Dell
Bios/ logs/
# ls -AF GRUB
grubx64.efi*
# ls -AF arch
fw/ fwupdx64.efi* grubx64.efi*
# ls -AF arch-grub
grubx64.efi*
# ls -AF ubuntu
fw/, fwupdx64.efi*, grub.cfg*, grubx64.efi*, mmx64.efi*, shimx64.efi*The only file modified by this fix is GRUB/grubx64.efi Does that mean that I can get rid of at least some of the others safely ? I'm thinking ubuntu, arch-grub, maybe arch...
Last edited by Cbhihe (2022-09-14 19:23:11)
I like strawberries, therefore I'm not a bot.
Offline
The --bootloader-id=GRUB should've defined the install dir for GRUB as GRUB so you should be able to remove the two arch attempts as well as the ubuntu dir. Leave GRUB/BOOT (that's the fallback path) and Dell in case they store something essential/necessary there.
Offline