Re: Fixing a Grub Foul-up Solved!

[Martin McCormick]

David  writes:
> Your lack of success is because the the command you used has designed
> behaviour to install the grub bootloader to the boot sector of
> /dev/sdd, and also install the grub files you listed into the current
> system /boot/grub (which was not on sdd at the time). That is the
> reason why you see those files on /dev/sda1, because it was the boot
> partition at the time you ran the command.

Aha!! that makes perfect sense now that I think a bit.
> 
> If you want a grub-install command that writes /boot/grub files
> somewhere onto /dev/sdd then you will first have to mount the desired
> target boot partiton of /dev/sdd on some mountpoint that you choose,
> and then run a command something like this:
>   sudo grub-install
> --boot-directory=/some/mountpoint/where/is/the/sdd/boot /dev/sdd

I tried it and by Joe, it wrote to the correct drive so I
don't feel quite so paranoid about using grub.

Interestingly, I goofed again and grub ended up in what
is the / directory instead of /boot/grub so it still didn't work
but I knew immediately that the new grub was working because
there was no error message about symbols not found, etc. 

I mounted the drive back on the good system and simply
removed the grub from the top of the tree and then did the
grub-install command again but thihs time, I installed to
/mnt/boot.

It wrote to /boot/grub as it should have and the system
came right up.

There was a minor glitch when I powered the box up as the
keyboard reported a stuck condition and advised me to press F1 to
continue.  I thought this was a bit amusing since the keyboard
appeared to be malfunctioning but F1 did the trick and about a
tenth of a second later, I heard the beep that grub plays when
the kernel is about to fire off.

In short, the faulty grub that made it onto the system
was all that was really wrong.

Thanks to a lot of you, I appreciate grub more as this
has been quite a little mini course in what it does.

Martin

Re: Fixing a Grub Foul-up

[David]

On Mon, 30 Nov 2020 at 14:53, Martin McCormick  wrote:

>  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
[...]
> It didn't even touch any part of /dev/sdd1.

The bootloader on /dev/sdd would have been updated.

[...]

> What am I failing to do to make the changes occur on the
> designated drive?

Your lack of success is because the the command you used has designed
behaviour to install the grub bootloader to the boot sector of
/dev/sdd, and also install the grub files you listed into the current
system /boot/grub (which was not on sdd at the time). That is the
reason why you see those files on /dev/sda1, because it was the boot
partition at the time you ran the command.

If you want a grub-install command that writes /boot/grub files
somewhere onto /dev/sdd then you will first have to mount the desired
target boot partiton of /dev/sdd on some mountpoint that you choose,
and then run a command something like this:
  sudo grub-install
--boot-directory=/some/mountpoint/where/is/the/sdd/boot /dev/sdd

Re: Fixing a Grub Foul-up, Not There Yet.

[Martin McCormick]

I am going to respond to one of my earlier posts as it doesn't
help things at all to spread misinformation which I am guilty of,
here.
"Martin McCormick"  writes:
> I appear to be using grub, not grub2.  

No.  It's grub2.  Old Grub is now grub-legacy and is
probably a dead fly on somebody's wall by now.

> There's an extra little wrinkle in that, as a computer
> warier who happens to be blind, grub isn't really accessible in
> that you can not get direct access to it via a serial port and
> terminal, say, from another computer that is actually working.

I was simply wrong there.  Of course, one has to have the lines now
in /etc/default/grub that used to be in menu.lst but the idea is
the same.  If one has a serial port which is available at boot
time, grub should work headlessly.

The issue with the instance of grub that seems to have a
run-time error due to a problem with modules, may be unusual
because it may actually be a goner before it runs since it
doesn't get to load it's modules.

Martin

Re: Fixing a Grub Foul-up

[Martin McCormick]

Dan Ritter  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 root4096 Nov 29 11:26 locale
-r--r--r-- 1 root root7276 Sep  3 05:43 grub.cfg
-rw-r--r-- 1 root root 2396122 Sep  3 05:43 unicode.pf2
-rw-r--r-- 1 root root1024 Jun 29  2019 grubenv
drwxr-xr-x 2 root root4096 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

Re: Fixing a Grub Foul-up, Not There Yet.

[Martin McCormick]

Dan Ritter  writes:
> in /boot/grub/menu.lst
> 
> serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
> terminal serial
> 
> (yes, that's two lines)
> 
> I hope that helps.
> 
> If you want the option of either serial or console access,
> replace the second line with
> 
> terminal --timeout=10 serial console
> 
> The default will be serial, but if you press a key on the
> console within 10 seconds, it will go there instead.
> 
> -dsr-

Thank you.  That is a tremendous thing to know.  I
thought there was something serial in grub but I couldn't
remember.  This is the first time I ever had any real trouble
with grub and I can put this drive back on the working linux box
and modify that file, assuming the change would take place on the
next run of grub.

Martin

Re: Fixing a Grub Foul-up, Not There Yet.

[Kushal Kumaran]

On Sat, Nov 21 2020 at 05:04:30 PM, "Martin McCormick" 
 wrote:
> Felix Miata  writes:
>> Save yourself many keystrokes by using the symlinks in the root directory 
>> instead
>> of the long-winded full version-named /boot/vmlinuz-4.19.0-5-686-pae
>
> This is wonderful to know and in the root or / directory of this
> disk, there is 
> initrd.img, initrd.img.old, vmlinuz and vmlinuz.old
>
>   Those all point to valid targets.  I presently have the
> no-boot disk mounted on a working linux system where it's root
> directory is /dev/sde1 and the current links plus the old links
> are as follows:
>
> lrwxrwxrwx   1 root root32 Jun 26  2019 initrd.img -> 
> boot/initrd.img-4.19.0-5-686-pae
> lrwxrwxrwx   1 root root31 Jun 26  2019 initrd.img.old -> 
> boot/initrd.img-4.9.0-9-686-pae
> lrwxrwxrwx   1 root root29 Jun 26  2019 vmlinuz -> 
> boot/vmlinuz-4.19.0-5-686-pae
> lrwxrwxrwx   1 root root28 Jun 26  2019 vmlinuz.old -> 
> boot/vmlinuz-4.9.0-9-686-pae
>
>   I finally have found something that may be a clue to
> what's actually wrong. While trying to manually make that drive
> boot, I got this:
>
> grub rescue> set prefix=(hd0,1)//boot/grub
> grub rescue> insmodnormal
> Unknown command `insmodnormal'.
>
> That was a good old syntax error so I tried
>
> insmod normal with a space
> grub rescue> insmod normal
> error: symbol `grub_calloc' not found.
>
>   I'm pretty sure that shouldn't happen at all and is
> what's behind the failure to boot.
>
>   I haven't found any uuid's that are different although I
> first thought I had as I looked at some links which had uuid's
> but they were good when I looked at the actual partition.  It's
> easy to go down a rabbit hole if one doesn't watch out.
>
>   I think there may be something about grub that got left
> out or changed during the upgrade.
>

There was a recent update to grub that was reported to cause the
grub_calloc symbol error.  As I remember it, the problem is because of a
mismatch between the grub binaries and the grub modules.  Reinstalling
grub using the grub-install command fixes it.

For details, bug report is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575

-- 
regards,
kushal

Re: Fixing a Grub Foul-up, Not There Yet.

[Felix Miata]

Martin McCormick composed on 2020-11-21 17:04 (UTC-0600):

>   I haven't found any uuid's that are different although I
> first thought I had as I looked at some links which had uuid's
> but they were good when I looked at the actual partition.  It's
> easy to go down a rabbit hole if one doesn't watch out.

Many more keystrokes and mental gymnastics can be saved when working with
filesystems by ensuring all have unique volume labels, then using those labels,
which you choose and can be seriously short if that's your wish, and using those
labels instead of UUIDs, such as in fstab, and grub cmdline or shell edits or
customization.
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Fixing a Grub Foul-up, Not There Yet.

[Dan Ritter]

Martin McCormick wrote: 
>   I appear to be using grub, not grub2.  One of the
> articles I found had an example of how to use grub rescue that all
> works except, of course, for the actual booting of the kernel.
> 
>   There's an extra little wrinkle in that, as a computer
> warier who happens to be blind, grub isn't really accessible in
> that you can not get direct access to it via a serial port and
> terminal, say, from another computer that is actually working.

in /boot/grub/menu.lst

serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal serial

(yes, that's two lines)

I hope that helps.

If you want the option of either serial or console access,
replace the second line with

terminal --timeout=10 serial console

The default will be serial, but if you press a key on the
console within 10 seconds, it will go there instead.

-dsr-

Re: Fixing a Grub Foul-up, Not There Yet.

[Martin McCormick]

Felix Miata  writes:
> Save yourself many keystrokes by using the symlinks in the root directory 
> instead
> of the long-winded full version-named /boot/vmlinuz-4.19.0-5-686-pae

This is wonderful to know and in the root or / directory of this
disk, there is 
initrd.img, initrd.img.old, vmlinuz and vmlinuz.old

Those all point to valid targets.  I presently have the
no-boot disk mounted on a working linux system where it's root
directory is /dev/sde1 and the current links plus the old links
are as follows:

lrwxrwxrwx   1 root root32 Jun 26  2019 initrd.img -> 
boot/initrd.img-4.19.0-5-686-pae
lrwxrwxrwx   1 root root31 Jun 26  2019 initrd.img.old -> 
boot/initrd.img-4.9.0-9-686-pae
lrwxrwxrwx   1 root root29 Jun 26  2019 vmlinuz -> 
boot/vmlinuz-4.19.0-5-686-pae
lrwxrwxrwx   1 root root28 Jun 26  2019 vmlinuz.old -> 
boot/vmlinuz-4.9.0-9-686-pae

I finally have found something that may be a clue to
what's actually wrong. While trying to manually make that drive
boot, I got this:

grub rescue> set prefix=(hd0,1)//boot/grub
grub rescue> insmodnormal
Unknown command `insmodnormal'.

That was a good old syntax error so I tried

insmod normal with a space
grub rescue> insmod normal
error: symbol `grub_calloc' not found.

I'm pretty sure that shouldn't happen at all and is
what's behind the failure to boot.

I haven't found any uuid's that are different although I
first thought I had as I looked at some links which had uuid's
but they were good when I looked at the actual partition.  It's
easy to go down a rabbit hole if one doesn't watch out.

I think there may be something about grub that got left
out or changed during the upgrade.

Martin

Martin

Re: Fixing a Grub Foul-up, Not There Yet.

[Felix Miata]

Martin McCormick composed on 2020-11-21 12:49 (UTC-0600):

>   I appreciate the good suggestions I have gotten from
> several of you so far.

Save yourself many keystrokes by using the symlinks in the root directory 
instead
of the long-winded full version-named /boot/vmlinuz-4.19.0-5-686-pae

So,
linux (hd0,1)/boot/mlinuz-4.19.0-5-686-pae root=/dev/sda1
becomes
linux (hd0,1)/vmlinuz root=/dev/sda1
and
initrd (hd0,1)/boot/initrd.img-4.19.0-5-686-pae
becomes
initrd (hd0,1)/initrd.img

The root also contains symlinks with .old appended for the previously installed
kernel.

Note that root=/dev/sda1 is an override to the root definition in the initrd. In
your case simply trying to recover boot ability, I seriously doubt you need to
make that override, and thus can safely leave root=/dev/sda1 off the linux line.

Also, unless your old 32bit PC has more than 2G of RAM, it's very unlikely you 
can
enjoy any advantage from PAE kernels. So, just keep linux-image-version-686
installed instead of linux-image-version-686-pae. It's not much typing saved, 
but
I imagine you welcome as much saving as you can get.

HTH
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Fixing a Grub Foul-up, Not There Yet.

[Martin McCormick]

I did some duckduckgo-ing about grub rescue and found useful
things but am still dead in the water.

I appear to be using grub, not grub2.  One of the
articles I found had an example of how to use grub rescue that all
works except, of course, for the actual booting of the kernel.

There's an extra little wrinkle in that, as a computer
warier who happens to be blind, grub isn't really accessible in
that you can not get direct access to it via a serial port and
terminal, say, from another computer that is actually working.  A
really clumsy work-around does work off of the dead computer in
that it is old enough that the Print-screen key dumps an ASCII
character dump of the screen to the parallel printer output every
time you press Print-screen.  I found out after connecting a
second computer to a parallel-to-serial converter that I was in 
grub rescue>  mode.

Each time one types on a keyboard attached to the dead
computer, one then must hit Print-screen to find out whether it
goes or blows.

This is slow and awkward because there is no
character-by-character feedback so if you hit the n instead of
the m, you don't find out that it's a no go until you read the
whole screen.

Also the Tabs you hit don't show up in the output so
it'salloneunbrokenline.

Is there a way I can write the commands in to a text file
that I can call to at least know what commands I am executing in
grub rescue and do in a tenth of a second what it takes minutes
to do otherwise?

What I have right now is a text file called stuffcommands
and it is sitting in the boot level of the dead boot disk.
When I had the drive mounted on a working system, I did chmod +x
stuffcommands but since there are no shells running, I just put
the following lines in the file.  Everyone of these commands
works when typed in except for the final one which boots the
kernel.

What I need to type in with, of course, no mistakes looks
like:

set root=(hd0,1)
linux   (hd0,1)/boot/vmlinuz-4.19.0-5-686-pae   root=/dev/sda1

#I have yet to see this one work.

initrd (hd0,1)/boot/initrd.img-4.19.0-5-686-pae boot

Here is a screen capture of what pressing Print-screen
produces  The first line is that error message and is probably
the clue as to what went wrong.  The successful commands were
laboriously typed in by hand once again to prove they work
although by now, I know the kernel version number about as well
as my last name.

error: symbol `grub_calloc' not found.  

That's the smoke that the booster is going to blow up on the
launch pad.

Entering rescue mode... 
grub rescue> ls 
(hd0) (hd0,msdos5) (hd0,msdos1) (fd0) (fd1) 

The root partition is Partition #1.

grub rescue> (hd0,1)/boot/stuffcommands 
Unknown command `(hd0,1)/boot/stuffcommands'.   

Ah, if only.  Those few lines would make each retry so much more
efficient.

grub rescue> set root=/de/sda1  

It worked.

grub rescue> linux(hd0,1)/boot/mlinuz-4.19.0-5-686-paeroot=/de/sda1 

And that one worked!

grub rescue>

That much works and it would be so nice not to have to repeat
those steps every time.  Is there a way to call that
stuffcommands text file so that grub thinks it's coming from the
keyboard?


I think I'd like a keyboard that one can store commands
like this in so as to keep the donkey work down to the problem
lines.

Actually, if only grub could be made to operate remotely,
I'd just script all the stuff that works and also know if I
fat-fingered anything when it happens so one could backspace and
fix it the way we fix any typing error.

Before I retired in 2015, I occasionally had to setup new
servers and these had lights-out minicomputers that helped one 
remotely access even a powered-down box in another state,
province or country.  The linux kernel, itself can easily be
configured to be accessible via a serial port or on the local
console so grub sorely needs headless capabilities for those rare
times where stuff just doesn't come back from a reboot.

I appreciate the good suggestions I have gotten from
several of you so far.

Martin McCormick

Re: Fixing a Grub Foul-up

[Martin McCormick]

Dan Ritter  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,

It certainly does!
First, thanks to all who answered so far.  I think you have
perfectly described what is causing the problem although grub is
not high in my knowledge base like it probably should be.

When I read /boot/grub/grub.cfg, I see
references to a uuid that isn't any of the partitions that have
UUID's.  On my disk, Partition 1 is / and blkid spits out a
number that starts with 9F.  Partition 2 was created to get an
extended partition of 5 which is swap space so 1 and 5 have
UUID's.  The UUID referenced in grub.cfg starts with 3.
The rest of this message consists
of grub.cfg.

Martin

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

serial --speed=115200 --unit=1 --word=8 --parity=no --stop=1

terminal_input serial
terminal_output serial
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
play 480 440 1
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-3584c851-6616-464f-8a8e-2d634fca5969' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  
3584c851-6616-464f-8a8e-2d634fca5969
else
  search --no-floppy --fs-uuid --set=root 
3584c851-6616-464f-8a8e-2d634fca5969
fi
echo'Loading Linux 4.19.0-5-686-pae ...'
linux   /boot/vmlinuz-4.19.0-5-686-pae 
root=UUID=3584c851-6616-464f-8a8e-2d634fca5969 ro console=tty0 
console=ttyS0,115200n8 quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-4.19.0-5-686-pae
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-3584c851-6616-464f-8a8e-2d634fca5969' {
menuentry 'Debian GNU/Linux, with Linux 4.19.0-5-686-pae' --class 
debian --class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.19.0-5-686-pae-advanced-3584c851-6616-464f-8a8e-2d634fca5969' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  
3584c851-6616-464f-8a8e-2d634fca5969

Re: Fixing a Grub Foul-up

[Kenneth Parker]

On Mon, Nov 16, 2020, 2:32 PM John Boxall  wrote:

> You might be running in to the problem that the blkid that is expected
> may be changed during boot. As I am running into a similar problem on a
> system I upgraded to buster from stretch, this link might help:
>
>
> https://www.thegeekdiary.com/inconsistent-device-names-across-reboot-cause-mount-failure-or-incorrect-mount-in-linux/


I encountered something like this, when installing Stretch (when it was
current) onto a USB Stick on a Dell laptop.  I was installing to the USB
Stick to leave alone the Windows 7 Home installation in the Hard Drive. It
didn't come with a DVD Drive, so I used an external USB DVD Drive for the
Install.

So, during Install, the Hard Drive was /dev/sda, the DVD Drive was /dev/sdb
and the USB Disk with Stretch was /dev/sdc.

On the Reboot, I, of course removed the USB cable for the DVD Drive and got
dumped into the Grub Rescue mode, where it was looking for Stretch on
/dev/sdc but it was now on /dev/sdb!

My final solution was to backup, and then blow away Windows 7 and Install
Buster on the Hard Drive. (Yes, it took long enough for Buster to become
the Stable Build).

The Geek Diary wasn't available to me when I encountered this issue.
Thanks for the link!

Kenneth Parker

>
>
> On 2020-11-16 1:48 p.m., Martin McCormick wrote:
> > I have goofed, I think.  There is a serca-2000-vintage Dell
> > Optiplex that has been working fine up to yesterday when I did
> > the usual apt-get update followed by the apt-get upgrade on
> > buster.  The update and upgrade appeared to work.
> >
> >   One of the things that got visited was grub and it was
> > then that I was reminded that there was another drive in the
> > system that had a bootable image of buster on it also.  Grub
> > reported seeing it on /dev/sdc which is coorrect.
> >
> >   This particular system has a zip drive that always shows
> > up as /dev/sdb so the next hard drive after /dev/sda is /dev/sdc.
> >
> >   I rebooted to make sure all was well and waited and
> > waited . . .
> >
> >   The system sits there like a bump on a log.
> >
> >   I have a usb device that lets one mount IDE and SATA
> > drives that are outside the system so I pulled the sata drive
> > which is the boot drive for the now dead system and plugged it in
> > to the usb converter.
> >
> >   the drive breezes through fsck and looks perfectly
> > normal.
> >
> >   I looked at /boot/grub/grub.cfg which one is not supposed
> > to edit as grub builds it based on /etc/default/grub which one
> > does edit.
> >
> >   If I was to mount that partition on a working system, it,
> > of course, will have a different device number such as /dev/sde1
> > instead of /dev/sda1 which it should have when booting up the
> > system it normally runs in.
> >
> >   Is there a safe way to mount this drive, possibly using
> > chroot, re-run grub-config and get the drive bootable again?
> >
> >   If I look at grub.cfg and /etc/default/grub, everything
> > looks as if it should work but it doesn't.
> >
> >   I think boot problems are some of the most agrevating
> > issues.  They are true show stoppers.
> >
> >   I've got backups but that's beside the point.  Unless I
> > can fix whatever happened, it's going to be quite a time waster.
> >
> > Thanks for any constructive suggestions.
> >
> > Martin McCormick
> >
> --
> Regards,
>
> John Boxall
>
>

Re: Fixing a Grub Foul-up

[David]

On Tue, 17 Nov 2020 at 05:58, Martin McCormick  wrote:

> If I look at grub.cfg and /etc/default/grub, everything
> looks as if it should work but it doesn't.

>   Is there a safe way to mount this drive, possibly using
> chroot, re-run grub-config and get the drive bootable again?

Yes, recovering grub is a routine operation, but you have to
get all the details correct.

> I've got backups but that's beside the point.

If you can easily access your backup of grub.cfg, try restoring
it to the problem drive and see if it works.

If that doesn't work, I suggest to post the grub.cfg that used to work here,
together with the output of 'lsblk -f' when all the drives that you need
to create a restoration setup are active.

That will help us guide you with much less guesswork.

Re: Fixing a Grub Foul-up

[Dan Ritter]

Martin McCormick wrote: 
>   I have a usb device that lets one mount IDE and SATA
> drives that are outside the system so I pulled the sata drive
> which is the boot drive for the now dead system and plugged it in
> to the usb converter.
> 
>   the drive breezes through fsck and looks perfectly
> normal.
> 
>   I looked at /boot/grub/grub.cfg which one is not supposed
> to edit as grub builds it based on /etc/default/grub which one
> does edit.
> 
>   If I was to mount that partition on a working system, it,
> of course, will have a different device number such as /dev/sde1
> instead of /dev/sda1 which it should have when booting up the
> system it normally runs in.
> 
>   Is there a safe way to mount this drive, possibly using
> chroot, re-run grub-config and get the drive bootable again?

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-

Re: Fixing a Grub Foul-up

[John Boxall]

You might be running in to the problem that the blkid that is expected 
may be changed during boot. As I am running into a similar problem on a 
system I upgraded to buster from stretch, this link might help:


https://www.thegeekdiary.com/inconsistent-device-names-across-reboot-cause-mount-failure-or-incorrect-mount-in-linux/

On 2020-11-16 1:48 p.m., Martin McCormick wrote:

I have goofed, I think.  There is a serca-2000-vintage Dell
Optiplex that has been working fine up to yesterday when I did
the usual apt-get update followed by the apt-get upgrade on
buster.  The update and upgrade appeared to work.

One of the things that got visited was grub and it was
then that I was reminded that there was another drive in the
system that had a bootable image of buster on it also.  Grub
reported seeing it on /dev/sdc which is coorrect.

This particular system has a zip drive that always shows
up as /dev/sdb so the next hard drive after /dev/sda is /dev/sdc.

I rebooted to make sure all was well and waited and
waited . . .

The system sits there like a bump on a log.

I have a usb device that lets one mount IDE and SATA
drives that are outside the system so I pulled the sata drive
which is the boot drive for the now dead system and plugged it in
to the usb converter.

the drive breezes through fsck and looks perfectly
normal.

I looked at /boot/grub/grub.cfg which one is not supposed
to edit as grub builds it based on /etc/default/grub which one
does edit.

If I was to mount that partition on a working system, it,
of course, will have a different device number such as /dev/sde1
instead of /dev/sda1 which it should have when booting up the
system it normally runs in.

Is there a safe way to mount this drive, possibly using
chroot, re-run grub-config and get the drive bootable again?

If I look at grub.cfg and /etc/default/grub, everything
looks as if it should work but it doesn't.

I think boot problems are some of the most agrevating
issues.  They are true show stoppers.

I've got backups but that's beside the point.  Unless I
can fix whatever happened, it's going to be quite a time waster.

Thanks for any constructive suggestions.

Martin McCormick


--
Regards,

John Boxall

Fixing a Grub Foul-up

[Martin McCormick]

I have goofed, I think.  There is a serca-2000-vintage Dell
Optiplex that has been working fine up to yesterday when I did
the usual apt-get update followed by the apt-get upgrade on
buster.  The update and upgrade appeared to work.

One of the things that got visited was grub and it was
then that I was reminded that there was another drive in the
system that had a bootable image of buster on it also.  Grub
reported seeing it on /dev/sdc which is coorrect.

This particular system has a zip drive that always shows
up as /dev/sdb so the next hard drive after /dev/sda is /dev/sdc.

I rebooted to make sure all was well and waited and
waited . . .

The system sits there like a bump on a log.

I have a usb device that lets one mount IDE and SATA
drives that are outside the system so I pulled the sata drive
which is the boot drive for the now dead system and plugged it in
to the usb converter.

the drive breezes through fsck and looks perfectly
normal.

I looked at /boot/grub/grub.cfg which one is not supposed
to edit as grub builds it based on /etc/default/grub which one
does edit.

If I was to mount that partition on a working system, it,
of course, will have a different device number such as /dev/sde1
instead of /dev/sda1 which it should have when booting up the
system it normally runs in.

Is there a safe way to mount this drive, possibly using
chroot, re-run grub-config and get the drive bootable again?

If I look at grub.cfg and /etc/default/grub, everything
looks as if it should work but it doesn't.

I think boot problems are some of the most agrevating
issues.  They are true show stoppers.

I've got backups but that's beside the point.  Unless I
can fix whatever happened, it's going to be quite a time waster.

Thanks for any constructive suggestions.

Martin McCormick