Arch Linux
I’ve kept my arch updated about every 2 weeks. I had recently switched to using btrfs with snapper a few months ago on my arch linux on a fresh install. Things were fine until a recent update. Now I go straight to grub rescue and none of the filesystems can be found with ls. After having booted into arch linux on a live cd, i still run into issues trying to create a new grub-install after mounting and arch-chroot. To make matters worse, I get even more issues trying to run snapper while in arch-chroot. I’ve spent hours at each one of these fixes going through the forums and google. Something that was supposed to help resolved system crashes may have been the culprit. As I said though snapper and btrfs were fine for quite some time.
#2 2022-09-09 07:47:52
Re: Updated Arch / Grub Rescue
There’s nothing that can be used to help in your post. What issues do you have when trying grub-install? How exactly are you mounting your partitions? Go through the steps you think are correct, post the commands you are executing and the outputs they are generating, as long as you have internet on the ISO you can post your outputs: https://wiki.archlinux.org/title/List_o … n_services
At the very least after the chroot, in addition to the steps you are trying to execute, post
#3 2022-09-09 11:59:11
Re: Updated Arch / Grub Rescue
That’s fair. I think I’ve just been so frustrated that Arch broke again for just a simple update a couple months after I did a fresh install with btrfs and migrated everything over. Bootup the machine and I’m greeted with grub rescue. Error: unknown filesystem. If i type ls i get (hd0) (hd1) (hd1,gpt1) and if I’m to set boot I have to have a filesystem. I go through each one with > ls (hd1,gpt1) get get back «:Filesystem is unknown» on each one of the filesystems.
That’s where I boot with a live USB into arch, connect to the internet. then > mount /dev/nvme0n1p5 /mnt as that is my arch location according to fdisk -l
Now if i > arch-chroot /mnt it gives me «mount point does not exists. dmesg(1) may have more information after failed mount system.
I search and find that it’s actually at /mnt/@ likely due to this system being on btrfs and how its setup.
>arch-chroot /mnt/@ «Warning: /mnt/@ is not a mountpoint. This may have undesirable side effects.»
Inside arch-chroot I try >snapper list (or any other snapper command besides —help) and get «Failure (org.freedesktop.Dbus.Error.ServiceUnknown)»
> mount /dev/nvme0n1p1 /boot/efi
> lsblk -l (efi boot is where i want it)
> grub-install —target=x86_64-efi —efi-directory=/boot/efi —bootloader-id=GRUB
«grub-install: error: cannot find a device for /boot/grub (is /dev mounted?). Well, I check inside /mnt/@ and sure enough boot/grub is there and it looks like the original files?
edit:
journalctl -b
Outputs: http://ix.io/4a5X
Last edited by Rabid3east (2022-09-10 06:02:10)
Arch Linux
I had a problem with GRUB2, and I couldn’t find an answer anywhere. Eventually, me and my Gentoo using friend found the solution.
Since I thought it would be useful for many users, I decided to write a guide describing how to deal with such situations. I wanted to add it to the wiki but I don’t know how to edit wiki pages.
I would appreciate opinions and corrections and if someone could convert it to wiki format it would be great.
Since the MBR is too small for all of GRUB2 modules, just the menu and a few basic capabilities truly reside there. Most of GRUB2 stays on the partition it was installed from. The «MBR part» keeps a variable — «prefix» — which points to the partition and folder containing the rest of the program.
Sometimes, when you change the partition layout of your HD, the number of the partition which contains GRUB2 changes. Let’s assume we installed GRUB2 from (hd0,7) or /dev/sda7, which is a logical partition inside an extended partition. Then we deleted /dev/sda5 and /dev/sda6, our /dev/sda7 became /dev/sda5. Now when the «MBR part» is looking for the rest of the program, it can’t find it in (hd0,7) since such partition doesn’t exist anymore. In this case, instead of showing the usual GRUB2 menu, you are being dropped to some sort of command line which is called GRUB rescue.
The easies way to fix this situation is to use another boot disk of some sort and reinstall GRUB2 again from the right partition. Such a boot disk is not always available so here is how to do it from GRUB rescue.
The number of available commands in GRUB rescue is really minimal. The only useful ones are «set» and «insmod». «set» sets variables, and «insmod» inserts new modules to expand GRUB rescue’s capabilities.
Before we can start, we have to know the right number of the partition which contains GRUB2 in order to inform the «MBR part».
Assuming GRUB2 is installed in it’s default location «/boot/grub», type
where x is the physical HD number and y is the partition number.
Note: If (hdx,y) is a boot partition, you have to omit the /boot part from the path, ie type «set prefix=(hdx,y)/grub».
Now we want to expand the console capabilities so we insert a useful module. Type
insmod (hdx,y)/boot/grub/linux.modwhere, again, (hdx,y) is the right partition where GRUB2 was installed from and «/boot/grub» is the path to the installation directory.
This will hopefully bring you back to the standad (?) GRUB2 console.
Now in order to boot your OS, we have to type the regular GRUB2 command.
Here is an example of how to boot Arch Linux:
set root=(hd0,5) linux /boot/vmlinuz26 root=/dev/sda5 initrd /boot/kernel26.img bootwhere (hd0,5) is the partition of your Arch Linux installation (not necessarily the same partition as above and it is probably different in your case).
If you have a boot partition, change the lines accordigly to something like that:
set root=(hd0,5) linux /vmlinuz26 root=/dev/sda6 initrd /kernel26.img bootand again, change the numbers to fit your layout.
After successfully booting your Arch Linux installation, you must fix grub.cfg to the new partition numbers and then run
or /dev/sdb or whatever fits your layout to reinstall GRUB2 and fix the problem completely.
Last edited by SoleSoul (2009-12-04 12:49:00)