Re: Fixing a Grub Foul-up
Dan Ritter <dsr@randomstring.org> writes:
> Here's what you can do:
>
> On a good system, mount your drive. Let's pretend that it's
> recognized as /dev/sdg, and you have a /boot on /dev/sdg1 and
> a root partition on /dev/sdg2.
>
> ls -al /dev/disk/by-partuuid/| grep sdg
>
> will get you the partition UUIDs for that disk. One of them will
> be for /dev/sdg1 and another for /dev/sdg2.
>
> The kernel really likes these as root filesystems identifiers.
> The kernel parameter that you put in /etc/default/grub is
>
> ROOT=PARTUUID=dddf0dd6-dd6b-d542-9eac-015a765cd6f6
>
> although you will want to substitute in the appropriate
> part-uuid for /dev/sdg2.
>
> Finally, you can run
>
> grub-install /dev/sdg
>
> to get a new copy of grub into the master boot sector of the
> disk.
>
> Hope that helps,
>
> -dsr-
This does help a lot and I have read similar examples how
to work on a drive that has been mounted on a different system
than the system on which it will ultimately be used but I am
still doing something wrong and the results are dangerous to say
the least.
At one time, the otherwise good drive was mounted on
/dev/sdd with the root partition on /dev/sdd1.
I typed sudo grub-install /dev/sdd. It ran for a few
seconds, announced that grub was installed without any errors and
exited.
After looking at /dev/sdd1/grub and seeing no updated
date stamps, I had a sinking feeling and looked at /dev/sda1
which is the boot partition on the system I haven't killed yet
and, sure enough, grub-install had run on that drive.
$ ls -lt /boot/grub
total 2372
drwxr-xr-x 2 root root 12288 Nov 29 11:26 i386-pc
drwxr-xr-x 2 root root 4096 Nov 29 11:26 locale
-r--r--r-- 1 root root 7276 Sep 3 05:43 grub.cfg
-rw-r--r-- 1 root root 2396122 Sep 3 05:43 unicode.pf2
-rw-r--r-- 1 root root 1024 Jun 29 2019 grubenv
drwxr-xr-x 2 root root 4096 Jun 29 2019 fonts
It didn't even touch any part of /dev/sdd1. With
trepedation, I rebooted the good system and thankfully, it came
right up since I hadn't modified /etc/default/grub. That was a
bit of good luck but I thought it was supposed to write to /dev/sdd1
which would translate to /dev/sda1 when the drive was connected
to the controller of the system that is presently belly up.
I suspect the problem is the issue with the modules which
another poster described.
What am I failing to do to make the changes occur on the
designated drive? Having it write this kind of stuff to drives
other than the desired target is scary.
Thanks for a good explanation and I may not be so lucky next
time.
Martin
Reply to: