2

My grub broke, I don't know what caused it, it happened after I booted off a usb live image of a linux distro I was going to try to install, but I was only in the anaconda setup menu, the installation itself had not started yet. he installer froze out of the blue before I could start the installation, and I had to reboot the system. After I did somehow my grub installation on /dev/sdb broke and I can't boot into my existing OSes.

My setup is as follows: /dev/sdb1 (Boot), /dev/sdb3 (Arch Linux Root) /dev/sdb2 (Windows boot) /dev/sdb4 (Empty partition, reserved to be used as an LVM for other linux distros I intend to install).

The grub prefix should be (hd1,msdos1)/grub, but when I try to reinstall grub and fix it, it for some reason always wants to put (hd1,msdos3)/boot/grub as the prefix and root.

When I try to boot it gives me the typical error: file '/grub/i386-pc/normal.mod' not found, and I'm a little bit confused since the grub-install command runs fine on arch reporting no errors, but still doesn't install grub correctly.

This is what I do to boot from grub rescue:

set prefix=(hd1,msdos1)/grub
insmod normal
normal

When I do that it loads correctly, now I only need a way to define this manually when grub is installed. Also, just to be clear, running grub-install again does not fix the problem, only repeats it. Grub seems to expect me to have it installed on /boot/grub on /dev/sdb3 when it is in fact installed on /grub on /dev/sdb1

1

E.G.: grub-install --boot-directory=/media/USERNAME/Mounted_BootVolume/ --force /dev/sda3

where /dev/sda3 is the "Patch-Core-Onto-Partition" and may be (but doesnt have to be) the same as Mounted_BootVolume.

".../grub" as the trailing-target-dir obviously cannot be changed

taken from manpage: --boot-directory=... install GRUB images under the directory DIR/grub instead of the boot/grub dir

P.S.: the new custom-dir is implicitly reflected by any boot-up of the grub-shell (i.e. grub.cfg needs no added prefix= lines) AFAIK

1

I spent a few hours here banging my head against the wall, the missing piece of the puzzle is that grup-install does not regenerate your grub.cfg file, you need to run update-grub or the equivalent grub-mkconfig -o /boot/grub/grub.cfg command.

0

Have you tried Boot-Repair? It's a live USB that tries to automatically fix your Grub installation.

  • looks interesting, but I need a permanent repair, I will need to be able to regenerate the grub configs and possibly reinstall it quite a few times. – Cestarian Feb 26 '16 at 1:46
  • Boot repair is permanent. And is always recommend as a first step +1 – DnrDevil Feb 26 '16 at 11:43
  • I'm sorry, this is crapware. I tried it on two machines with a broken grub (one with broken grub entries, and the machine in question) on one machine which has a wired internet connection, it kept constantly nagging me about not being able to connect to the internet (while I was actually browsing firefox without problems) but I managed to struggle through the repair process somehow, and nothing was fixed. On the machine in question which is wireless, I had pretty much the same results. I wish I could downvote this shit answer more than once. (From what i understand this is aimed at ubuntu) – Cestarian Mar 7 '16 at 16:43
0

Was your /boot filesystem mounted when you ran grub-install?

(Unless you explicitly specify all the parameters, grub-install will attempt to auto-detect the partition that contains the /boot/grub directory, and will set the partition number and the default prefix accordingly. If /boot is a separate filesystem and not mounted while you're running grub-install, the auto-detection may get confused.)

As a partial workaround (for the directory part of the prefix), you can do this while the /boot filesystem is mounted:

cd /boot
ln -s . boot

Now there is a symbolic link /boot/bootwhich points right back to /boot, which looks nonsensical. (Don't worry, tools like find and locate are smart enough not to get trapped in an infinite loop from this.)

But when GRUB is trying to access (partition)/boot/grub, it hits the symbolic link: when replaced with the link's target, the path becomes (partition)/./grub which is equal to just (partition)/grub... which is what you want.

  • /boot was mounted, but it's been a long time since I had this problem and no longer have the system available to verify solutions. But the problem was that the prefix wasn't just for the wrong directory path, it was for the wrong partition as well. A symlink would not solve it. I did manage to hotfix it like you're suggesting by moving the contents of /dev/sdb1 to the /boot directory on /dev/sdb3 (where /dev/sdb1 would normally be mounted) – Cestarian Sep 14 '18 at 23:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.