I have a fedora system which, for the sake of brevity, got borked.
I have a bootable partition where I have moved grub.cfg because it does not boot.
The system has one hard disk : /dev/sda ; I wish to install BIOS grub2 boot on /dev/sda booting to /sda3 where I have a rootfs and /boot on the same partition.
Seems trivial situation. How can I boot from a live image , like a fed31 install iso and repair this without going through an entire installation process to a bogus partition just to get it to install grub and create a valid /boot/grub2/grub.cfg ?
Thanks, I probably should have poked about and guessed that was “near enough” the thing to use but my patience with this mess if very short now.
This is exactly what I meant by such a complex recovery method being fragile to the slightest change making a robust solution impossible.
Despite all the funky new features and pretty, pretty graphical backgrounds, the basic requirement of a solid and robust low level boot mechanism seems to have gone out of the window.
Having to do a chroot just to recover grub.cfg is insane.
In fact those instructions are very confusing, sections 3 seems to be referring to both the live boot and the on-disc installation at the same time. I’ve read this several times and I still don’t know what it is supposed to mean.
As I asked above, is anyone able to suggest a minimal grub.cfg which I can enter by hand, if I know all the relevant partitions etc. ?
Indeed, it would be great to have a more easy way to recover the boot. If you have a free partition, doing a minimal install is one to get at least the system up and running.
Chroot is insane, but you’re sure that the generated grub.cfg, grub modules and boot block are consistent with the installation to boot before ending up again with a non-booting system.
Why did mount /dev/mapper/fedora-root /mnt/root fail? Are you sure you have LVM?
First thing is to investigate with e.g. “lsblk” or “blkid” what the available partitions, lvm’s, encrypted devices, raid’s are. If there is a file system on it, you can mount it in order to look what is there.
Then there are two possibilities: you have a boot partition or a boot directory containing the kernel.
If you have a boot directory, you can just mount the partition,dev,sys… and chroot into it. If you have a boot partition with vmlinuz and initramfs in the root, then you have to mount it’s parent and then mount the boot partition into the parent’s boot folder. So there is no standard receipt, the article refers to a standard Fedora installation with LVM and separate boot partition. Other configurations need different receipts. In all cases, after the chroot you should have a /usr /var… and /boot with kernel, ramdisk and grub.
Why did mount /dev/mapper/fedora-root /mnt/root fail?
Because it did not exist. As above there is nothing that fits. The instructions are quite explicit but do not correspond to current LXDE live iso on this system. Though presumably the DVD is running LVM. The two /dev/mapper entries I posted were symlinks to dm-1 and dm-0 whatever that’s about.
Maybe all this mapper stuff is a total red-herring on a non LVM system. Can I just mount the device with my root fs by its /dev/sd*X name or LABEL ?
As stated before, it depends on your disk layout configuration. As stated in the linked doc, /dev/mapper/fedora-root is part of the default disk layout created during the installation of the system. So, if you have installed the system on a custom layout, as you can guess in the same doc, you should use the lsblk command in order to identify the various partitions/filesystems/volumes on the hard disk (root, /boot, etc.) and mount them accordingly.
Just mount the partition as /dev/sda2 or by label, as e.g. /mnt/sysimage but check that the label is unique, by dd’-ing a partition you run into the duplicate label problem. Check that /mnt/sysimage has a boot containing kernel and grub. Mount dev,sys and proc onto the /mnt/sysimage, otherwise the chroot lacks the system information for grub; grub2-mkimage grabs it’s info from the /dev/disk folder which is empty if you only chroot. Chroot /mnt/sysimage and type grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sda and you should be able to boot. Whether you have a living system or an emergeny depends on the /etc/fstab on /dev/sda2, this should be correct for the new situation.
Thanks, I changed both the UUID and LABEL after dd-ing to avoid dupes and updated the fstab on the clone. I’ll check all that again attempt another chroot.
OK, I’ve wasted a huge amount of time on what should be trivial thing to fix: restoring grub.cfg.
Even my technical curiosity has died a death at this point. I’ve installed Ubuntu. This fixed grub and gave me a Fedora grub entry. This still gets stuck before even getting an emergency console so Fedora is off this box.
I still have my desktop running Fed31 but that got a dualboot *ubuntu since I needed to follow the process while doing remote support of the other one. I’ll assess whether that works any better than Fedora.
30 I think, this is the