Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #235898 > unrolled thread

A Grub Boot Question about initrd

Back to article view | Back to linux.debian.user

Contents

  A Grub Boot Question about initrd "Martin McCormick" <martin.m@suddenlink.net> - 2021-06-05 19:50 +0200
    Re: A Grub Boot Question about initrd deloptes <deloptes@gmail.com> - 2021-06-05 20:10 +0200
    Re: A Grub Boot Question about initrd Reco <recoverym4n@enotuniq.net> - 2021-06-05 20:30 +0200
      Re: A Grub Boot Question about initrd "Martin McCormick" <martin.m@suddenlink.net> - 2021-06-05 21:30 +0200
    Re: A Grub Boot Question about initrd Felix Miata <mrmazda@earthlink.net> - 2021-06-05 21:30 +0200
      Re: A Grub Boot Question about initrd "Martin McCormick" <martin.m@suddenlink.net> - 2021-06-05 23:30 +0200
        Re: A Grub Boot Question about initrd Greg Wooledge <greg@wooledge.org> - 2021-06-06 01:20 +0200
        Re: A Grub Boot Question about initrd Felix Miata <mrmazda@earthlink.net> - 2021-06-06 01:50 +0200
        Re: A Grub Boot Question about initrd Cindy Sue Causey <butterflybytes@gmail.com> - 2021-06-06 02:20 +0200
          Re: A Grub Boot Question about initrd Gene Heskett <gheskett@shentel.net> - 2021-06-06 04:30 +0200
          Re: A Grub Boot Question about initrd "Andrew M.A. Cater" <amacater@einval.com> - 2021-06-06 14:30 +0200
    Re: A Grub Boot Question about initrd Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-06 13:20 +0200
      Re: A Grub Boot Question about initrd "Martin McCormick" <martin.m@suddenlink.net> - 2021-06-06 20:40 +0200
        Re: A Grub Boot Question about initrd Felix Miata <mrmazda@earthlink.net> - 2021-06-06 22:40 +0200
          Re: A Grub Boot Question about initrd "Martin McCormick" <martin.m@suddenlink.net> - 2021-06-07 00:00 +0200
            Re: A Grub Boot Question about initrd "Martin McCormick" <martin.m@suddenlink.net> - 2021-06-07 03:10 +0200
            Re: A Grub Boot Question about initrd Felix Miata <mrmazda@earthlink.net> - 2021-06-07 04:40 +0200
              Re: A Grub Boot Question about initrd "Martin McCormick" <martin.m@suddenlink.net> - 2021-06-07 14:20 +0200
              Grub Success at Last "Martin McCormick" <martin.m@suddenlink.net> - 2021-06-09 00:20 +0200
                Re: Grub Success at Last, but way offtopic Gene Heskett <gheskett@shentel.net> - 2021-06-09 01:00 +0200
      Re: A Grub Boot Question about initrd David Wright <deblis@lionunicorn.co.uk> - 2021-06-07 20:40 +0200

Page 1 of 2  [1] 2  Next page →

#235898 — A Grub Boot Question about initrd

I have a plan but I need some more information.  Is there any
personalization done by the boot setup process?  Do our UUID's
or any other specific information pertaining to the installation
make it in to the initrd files?

	While reading about the boot process, it doesn't appear
that the initrd files or initranfs are personalized with anything
pertaining to this computer and this installation.

	If that is so, then two computers using the same
processor type should be able to use copies of the same initrd files
and the only thing that is personalized on an individual computer
is all the grub configuration in which the UUID's of at least /
and /swap partitions are sprinkled throughout grub.cfg and
/etc/default/grub.

	One should be able to write a program to get the
appropriate UUID's out of fstab on the working system
and translate them in to corresponding UUID's for the system on
the operating table.

	If the target system actually boots, it is probably a
good idea to run update-grub to make sure that still produces a
working boot but this would still more than likely produce the
same results if this process works in the first place.  It's also
possible that the reconstructed grub setup is okay except for the
drive designation which usually starts out as /dev/sda1.  On my
good Buster system, this is now /dev/sdc1 and on the sick one,
the attempt is being made on /dev/sda1.

	The idea here is to copy the concept of what is happening
rather than the literal configurations which definitely will
never work unless one used dd to generate the clone drive and I
have actually done that once and it worked but the cloned system
was then adapted for other uses.  Here, all I want to do is
rescue the boot process so it lives on and not have to reinstall
everything else.

	As an aside, one ought to be able to do something like
this.  It makes life a lot simpler.  Both systems are using the
same kernel and versions of the same processor the only real
differences are the UUID's.  The grub configurations of both are
the same down to the serial console.

Martin

[toc] | [next] | [standalone]

#235899

Martin McCormick wrote:

> As an aside, one ought to be able to do something like
> this.  It makes life a lot simpler.  Both systems are using the
> same kernel and versions of the same processor the only real
> differences are the UUID's.  The grub configurations of both are
> the same down to the serial console.

Uff, IMO too much writing for trivial problem. You are correct into some
extent. I did not understand exactly your use case (everything is the same
except the console)

I have cloned many installations. You are right if done with dd UUID is the
same - but this is perhaps not exactly what you want. I usually either boot
in rescue (initrd shell) or have a USB or Debian installation medium to
chroot and adjust some settings and finally execute install/update-grub.
Now with UEFI it is more likely you have a slightly different use case but
UUIDs are what they are.

If there is a utility to do it I am not aware of such, but at the end is it
really that much of work. I mean it boils down to the UEFI and/or boot
partition, cause the rest is usually set on an LVM which is autodetected.

[toc] | [prev] | [next] | [standalone]

#235901

On Sat, Jun 05, 2021 at 12:46:13PM -0500, Martin McCormick wrote:
> I have a plan but I need some more information.  Is there any
> personalization done by the boot setup process?

Yes. One of the GRUB's tasks is to supply kernel which is about to boot
with root=... cmdline parameter. Root filesystem UUID can be used for
this.


> Do our UUID's or any other specific information pertaining to the
> installation make it in to the initrd files?

In Debian - no, unless you include it there for some bizarre reason.
It's not needed for the things initrd usually does.


> 	If that is so, then two computers using the same
> processor type should be able to use copies of the same initrd files
> and the only thing that is personalized on an individual computer
> is all the grub configuration in which the UUID's of at least /
> and /swap partitions are sprinkled throughout grub.cfg and
> /etc/default/grub.

It's not the CPU difference you need to worry about.
Different SATA controllers, video cards, NICs - i.e. what they call
periphery devices - those things require different kernel modules that
should be (or could be) used in early boot process, and therefore need
to be included in initrd.

Luckily, Debian uses initramfs-tools for building initrd, and
initramfs-tools should build initrd with everything and a kitchen sink
included (MODULES=most in /etc/initramfs-tools/initramfs.conf).


> 	One should be able to write a program to get the
> appropriate UUID's out of fstab on the working system
> and translate them in to corresponding UUID's for the system on
> the operating table.

Er, they've invented filesystem labels for exactly this many decades
ago.


> 	As an aside, one ought to be able to do something like
> this.  It makes life a lot simpler.  Both systems are using the
> same kernel and versions of the same processor the only real
> differences are the UUID's.

Perfectly possible for the last 15 years or so. Assuming Debian and
MODULES=most, of course.

Reco

[toc] | [prev] | [next] | [standalone]

#235903

Reco <recoverym4n@enotuniq.net> writes:
> On Sat, Jun 05, 2021 at 12:46:13PM -0500, Martin McCormick wrote:
> > I have a plan but I need some more information.  Is there any
> > personalization done by the boot setup process?
> 
> Yes. One of the GRUB's tasks is to supply kernel which is about to boot
> with root=... cmdline parameter. Root filesystem UUID can be used for
> this.
> 
> 
> > Do our UUID's or any other specific information pertaining to the
> > installation make it in to the initrd files?
> 
> In Debian - no, unless you include it there for some bizarre reason.
> It's not needed for the things initrd usually does.
> 
> 
> >       If that is so, then two computers using the same
> > processor type should be able to use copies of the same initrd files
> > and the only thing that is personalized on an individual computer
> > is all the grub configuration in which the UUID's of at least /
> > and /swap partitions are sprinkled throughout grub.cfg and
> > /etc/default/grub.
> 
> It's not the CPU difference you need to worry about.
> Different SATA controllers, video cards, NICs - i.e. what they call
> periphery devices - those things require different kernel modules that
> should be (or could be) used in early boot process, and therefore need
> to be included in initrd.
> 
> Luckily, Debian uses initramfs-tools for building initrd, and
> initramfs-tools should build initrd with everything and a kitchen sink
> included (MODULES=most in /etc/initramfs-tools/initramfs.conf).
> 
> 
> >       One should be able to write a program to get the
> > appropriate UUID's out of fstab on the working system
> > and translate them in to corresponding UUID's for the system on
> > the operating table.
> 
> Er, they've invented filesystem labels for exactly this many decades
> ago.
> 
> 
> >       As an aside, one ought to be able to do something like
> > this.  It makes life a lot simpler.  Both systems are using the
> > same kernel and versions of the same processor the only real
> > differences are the UUID's.
> 
> Perfectly possible for the last 15 years or so. Assuming Debian and
> MODULES=most, of course.
> 
> Reco
> 
> 
It sounds like I haven't missed anything obvious so I will see if
I can write a perl script or some other text-muncher that will
recreate the grub configuration of the working system but with
the UUID's of the non-working system plus a grub.cfg file exactly
like the grub.cfg file on the system that refuses to boot but
with the correct UUID labels describing the boot partition on
that system plus a copy of the kernel and it's module directory.

	As for partition labels, I have always thought the name
was much easier to deal with than the 36 randomly-selected
characters that make up the UUID on a unix partition but UUID
labels are supposed to be unique and are what you encounter today
so I will see if I can make the script modern compatible.

	Thanks to you and deloptes@gmail.com.

[toc] | [prev] | [next] | [standalone]

#235902

Martin McCormick composed on 2021-06-05 12:46 (UTC-0500):

> I have a plan but I need some more information.  Is there any
> personalization done by the boot setup process?  Do our UUID's
> or any other specific information pertaining to the installation
> make it in to the initrd files?

Dracut includes a root=UUID=<UUID> statement in the initrd. A root= statement on
the Grub linu* line overrides it. The override can be any of the accepted forms,
including root=LABEL= and root=<device name>.

> 	While reading about the boot process, it doesn't appear
> that the initrd files or initranfs are personalized with anything
> pertaining to this computer and this installation.
										
As already answered, it may be either modules specific to the hardware, or a more
global supply of modules, according to the machine's configuration files.

> 	If that is so, then two computers using the same
> processor type should be able to use copies of the same initrd files
> and the only thing that is personalized on an individual computer
> is all the grub configuration in which the UUID's of at least /
> and /swap partitions are sprinkled throughout grub.cfg and
> /etc/default/grub.
										
Specific processor type isn't relevant among x86 or amd64 classes. It's the I/O
hardware that matters.

> 	One should be able to write a program to get the
> appropriate UUID's out of fstab on the working system
> and translate them in to corresponding UUID's for the system on
> the operating table.
										
The translation is easy. UUIDs are assigned to devices. The device names are
acceptable substitutes, just as they used to be the only option before libata made
device names capable of playing musical chairs. If devices also have labels,
labels can be used instead of device names.

> 	If the target system actually boots, it is probably a
> good idea to run update-grub to make sure that still produces a
> working boot but this would still more than likely produce the
> same results if this process works in the first place.  It's also
> possible that the reconstructed grub setup is okay except for the
> drive designation which usually starts out as /dev/sda1.  On my
> good Buster system, this is now /dev/sdc1 and on the sick one,
> the attempt is being made on /dev/sda1.
										
UUIDs were designed for computer scripts, not human brains. You'll need to make a
conversion, but instead of UUIDs, I highly recommend using labels when you know
device names will be different on the system migrated to. UUIDs are appropriate
too, just rather unwieldy unless scripted.

> 	The idea here is to copy the concept of what is happening
> rather than the literal configurations which definitely will
> never work unless one used dd to generate the clone drive and I
> have actually done that once and it worked but the cloned system
> was then adapted for other uses.  Here, all I want to do is
> rescue the boot process so it lives on and not have to reinstall
> everything else.
										
Grub provides a shell. From the shell it's possible to boot using the information
you have. Instead of trying to figure it all out in advance, drop to the shell and
use the device names you know. It's really not hard if you have a copy of a grub
menu from the two PCs planted in your brain or on paper. Once you've booted, it's
easy to fix everything up by running grub-mkconfig, and if necessary,
/etc/default/grub.

> 	As an aside, one ought to be able to do something like
> this.  It makes life a lot simpler.  Both systems are using the
> same kernel and versions of the same processor the only real
> differences are the UUID's.  The grub configurations of both are
> the same down to the serial console.
										
Don't let the massive volume of data in grub.cfg mislead you. Its primary job is
to find and load a kernel and initrd. If you know where they are and their names,
none of the menu components or apparent search and identification bloat are
necessary. Before Grub2 you could simply tell Grub's shell the root device, the
kernel name (with associated parameters, most of which aren't actually necessary),
and the initrd name, then boot. With Grub2 you may need to precede the root device
name with loading a module or two or three, which you see in your copy of a
grub.cfg, then proceed with the important three. I do a lot of cloning, so I've
done it often.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

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

Felix Miata

[toc] | [prev] | [next] | [standalone]

#235905

First I greatly appreciate all this information as the idea is to
fix a problem I probably created long ago though I am not sure
how but the short story is that apt-get upgrade ran update-grub
and update-initramfs late last Fall and I was able to rescue it
but it happened again at the end of April so I figured I had
better fix it correctly since I didn't know it was a ticking
bomb.

Felix Miata <mrmazda@earthlink.net> writes:
> Martin McCormick composed on 2021-06-05 12:46 (UTC-0500):
> 
> > I have a plan but I need some more information.  Is there any
> > personalization done by the boot setup process?  Do our UUID's
> > or any other specific information pertaining to the installation
> > make it in to the initrd files?
> 
> Dracut includes a root=UUID=<UUID> statement in the initrd. A root= 
> statement on
> the Grub linu* line overrides it. The override can be any of the accepted 
> forms,
> including root=LABEL= and root=<device name>.

	Good to know.

> The translation is easy. UUIDs are assigned to devices. The device names 
> are
> acceptable substitutes, just as they used to be the only option before 
> libata made
> device names capable of playing musical chairs. If devices also have 
> labels,
> labels can be used instead of device names.

Very much like the reasoning behind udev which is a God-send if you
have multiple sound cards as one example.

> UUIDs were designed for computer scripts, not human brains. You'll need 
> to make a
> conversion, but instead of UUIDs, I highly recommend using labels when 
> you know
> device names will be different on the system migrated to. UUIDs are 
> appropriate
> too, just rather unwieldy unless scripted.

There's 1 UUID for the root file system in /boot/grub/grub.cfg
which is the file one must not normally edit by hand.  It 
reads

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-658da8df-942e-4ad7-8c5b-695f2f2eb4ed' {

> Grub provides a shell. From the shell it's possible to boot using the 
> information
> you have. Instead of trying to figure it all out in advance, drop to the 
> shell and
> use the device names you know. It's really not hard if you have a copy of 
> a grub
> menu from the two PCs planted in your brain or on paper. Once you've 
> booted, it's
> easy to fix everything up by running grub-mkconfig, and if necessary,
> /etc/default/grub.
> 
> >       As an aside, one ought to be able to do something like
> > this.  It makes life a lot simpler.  Both systems are using the
> > same kernel and versions of the same processor the only real
> > differences are the UUID's.  The grub configurations of both are
> > the same down to the serial console.
> 
> Don't let the massive volume of data in grub.cfg mislead you. Its primary 
> job is
> to find and load a kernel and initrd. If you know where they are and 
> their names,
> none of the menu components or apparent search and identification bloat 
> are
> necessary. Before Grub2 you could simply tell Grub's shell the root 
> device, the
> kernel name (with associated parameters, most of which aren't actually 
> necessary),
> and the initrd name, then boot. With Grub2 you may need to precede the 
> root device
> name with loading a module or two or three, which you see in your copy of 
> a
> grub.cfg, then proceed with the important three. I do a lot of cloning, 
> so I've
> done it often.

	Thanks again.  I was starting to get discouraged but I
will try using actual labels since I thought you really shouldn't
do that.

Martin

[toc] | [prev] | [next] | [standalone]

#235906

On Sat, Jun 05, 2021 at 04:28:20PM -0500, Martin McCormick wrote:
> There's 1 UUID for the root file system in /boot/grub/grub.cfg
> which is the file one must not normally edit by hand.  It 
> reads
> 
> menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-658da8df-942e-4ad7-8c5b-695f2f2eb4ed' {

Yes, there's probably a UUID for the root file system somewhere in this
entry, in the part you omitted.

The part you included just has a *name* which was automatically generated
to refer to this boot option.  This name happens to include the same UUID
that the root file system designation uses, but this name is only a name,
and does not invoke any functionality.

Here's part of mine, for comparison:


menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-c4691ccb-2090-491e-8e82-d7cc822db04a' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        set root='hd0,gpt7'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt7 --hint-efi=hd0,gpt7 --hint-baremetal=ahci0,gpt7  c4691ccb-2090-491e-8e82-d7cc822db04a
        else
          search --no-floppy --fs-uuid --set=root c4691ccb-2090-491e-8e82-d7cc822db04a
        fi
        echo    'Loading Linux 5.10.0-7-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-7-amd64 root=UUID=c4691ccb-2090-491e-8e82-d7cc822db04a ro  
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-7-amd64
}


The actual UUID for the root file system appears down at the bottom, three
lines above the closing curly brace.  It's where it says root=UUID=....

Of course, this is just one menu entry.  I have three kernels installed
at the moment, so I have 6 of these menu entries, 2 per kernel (one
called "simple" and one called "advanced").

[toc] | [prev] | [next] | [standalone]

#235907

Martin McCormick composed on 2021-06-05 16:28 (UTC-0500):

> the short story is that apt-get upgrade ran update-grub
> and update-initramfs late last Fall and I was able to rescue it
> but it happened again at the end of April so I figured I had
> better fix it correctly since I didn't know it was a ticking
> bomb.

> menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-658da8df-942e-4ad7-8c5b-695f2f2eb4ed' {
										
Maybe, to prevent this from happening yet again, you should show us also the
content of /etc/fstab and /etc/default/grub, and output from blkid, all unwrapped
if possible with your mail program.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

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

Felix Miata

[toc] | [prev] | [next] | [standalone]

#235909

On 6/5/21, Martin McCormick <martin.m@suddenlink.net> wrote:
> First I greatly appreciate all this information as the idea is to
> fix a problem I probably created long ago though I am not sure
> how but the short story is that apt-get upgrade ran update-grub
> and update-initramfs late last Fall and I was able to rescue it
> but it happened again at the end of April so I figured I had
> better fix it correctly since I didn't know it was a ticking
> bomb.


In a different email where deloptes says...

On 6/5/21, deloptes <deloptes@gmail.com> wrote:
> I have cloned many installations. You are right if done with dd UUID is the
> same - but this is perhaps not exactly what you want. I usually either boot
> in rescue (initrd shell) or have a USB or Debian installation medium to
> chroot and adjust some settings


Right there at that part is where I run "update-initramfs -u" in my
own similar kind of maneuvering. THEN I do this


> and finally execute install/update-grub.
> Now with UEFI it is more likely you have a slightly different use case but
> UUIDs are what they are.


My success rate has been much higher since taking that tactic. One
caveat. I'm using LILO these days because GRUB refused to acknowledge
GPT hard drives in my usage case.

One thing I noticed toward the end before I dumped GRUB was that there
were repeatedly mismatches down my whole grub.cfg file. Multiple
blocks would have two different UUIDs that GRUB found for what should
have been one singular UUID per each partition.

Because there is SO MUCH information in that file, that tiny detail
didn't immediately leap off the page as surely being a problem in the
making. I never did figure out what was occurring because the second
UUID, the wrong one, NEVER matched anything in my system.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#235910

On Saturday 05 June 2021 20:17:38 Cindy Sue Causey wrote:

> On 6/5/21, Martin McCormick <martin.m@suddenlink.net> wrote:
> > First I greatly appreciate all this information as the idea is to
> > fix a problem I probably created long ago though I am not sure
> > how but the short story is that apt-get upgrade ran update-grub
> > and update-initramfs late last Fall and I was able to rescue it
> > but it happened again at the end of April so I figured I had
> > better fix it correctly since I didn't know it was a ticking
> > bomb.
>
> In a different email where deloptes says...
>
> On 6/5/21, deloptes <deloptes@gmail.com> wrote:
> > I have cloned many installations. You are right if done with dd UUID
> > is the same - but this is perhaps not exactly what you want. I
> > usually either boot in rescue (initrd shell) or have a USB or Debian
> > installation medium to chroot and adjust some settings
>
> Right there at that part is where I run "update-initramfs -u" in my
> own similar kind of maneuvering. THEN I do this
>
> > and finally execute install/update-grub.
> > Now with UEFI it is more likely you have a slightly different use
> > case but UUIDs are what they are.
>
> My success rate has been much higher since taking that tactic. One
> caveat. I'm using LILO these days because GRUB refused to acknowledge
> GPT hard drives in my usage case.
>
> One thing I noticed toward the end before I dumped GRUB was that there
> were repeatedly mismatches down my whole grub.cfg file. Multiple
> blocks would have two different UUIDs that GRUB found for what should
> have been one singular UUID per each partition.
>
> Because there is SO MUCH information in that file, that tiny detail
> didn't immediately leap off the page as surely being a problem in the
> making. I never did figure out what was occurring because the second
> UUID, the wrong one, NEVER matched anything in my system.
>
That should never happen, Cindy and when it occured, the next thing I'd 
run is memtest86, but after I'd changed the sata cables if they are 
magenta colored. Aka hot red. There is a caustic effect in that 
particular plastic dye that gives them a 4 or 5 year life at best. Its 
been known to me as a C.E.T. & 1st phone licensee since back in the 70's 
when the J. A. Pan company started useing it in their CB radio mic 
cables. There, with the constant flexing a microphone cable gets, the 
life of the hot red colored wire was often less than 6 months in a large 
car environment. You could cut it off to get fresh copper to solder to, 
and literally pour a dark copper rust looking powder out of that 
conductor in the cable where it was supposed to be copper.

UUID problems, when they surface here, result in the partition being 
given a unique LABEL in my /etc/fstab's. Fixes it right up for the rest 
of that drives life.

> Cindy :)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#235913

On Sat, Jun 05, 2021 at 08:17:38PM -0400, Cindy Sue Causey wrote:
> On 6/5/21, Martin McCormick <martin.m@suddenlink.net> wrote:
> > First I greatly appreciate all this information as the idea is to
> > fix a problem I probably created long ago though I am not sure
> > how but the short story is that apt-get upgrade ran update-grub
> > and update-initramfs late last Fall and I was able to rescue it
> > but it happened again at the end of April so I figured I had
> > better fix it correctly since I didn't know it was a ticking
> > bomb.
> 
> 
> In a different email where deloptes says...
> 
> On 6/5/21, deloptes <deloptes@gmail.com> wrote:
> > I have cloned many installations. You are right if done with dd UUID is the
> > same - but this is perhaps not exactly what you want. I usually either boot
> > in rescue (initrd shell) or have a USB or Debian installation medium to
> > chroot and adjust some settings
> 
> 
> Right there at that part is where I run "update-initramfs -u" in my
> own similar kind of maneuvering. THEN I do this
> 
> 
> > and finally execute install/update-grub.
> > Now with UEFI it is more likely you have a slightly different use case but
> > UUIDs are what they are.
> 
> 
> My success rate has been much higher since taking that tactic. One
> caveat. I'm using LILO these days because GRUB refused to acknowledge
> GPT hard drives in my usage case.
> 
Hi Cindy-Sue

If you're using LILO you are _REALLY_ on your own since LILO is not 
maintained any more. IMHO, you really, really need to convert to grub somehow 

Where possible, I suggest moving to UEFI boot and grub in all cases when 
installing Debian.. "Legacy" [MBR] boot is going away and GPT disks are 
standard for larger disks. It doesn't work for all machines - I've an HP 
Microserver that will live on legacy MBR forever - but for most things built 
in the last 5-10 years there's an option to use UEFI.

All the very best

Andy C.

[toc] | [prev] | [next] | [standalone]

#235911

[Multipart message — attachments visible in raw view] — view raw

On Sb, 05 iun 21, 12:46:13, Martin McCormick wrote:
> 
> 	One should be able to write a program to get the
> appropriate UUID's out of fstab on the working system
> and translate them in to corresponding UUID's for the system on
> the operating table.

Alternatively you might want to consider using standardized labels on 
all your system, e.g. 'rootfs' is always the root partition, etc.

If all your devices have GPT partition tables you could also use 
partition labels instead, as they will survive a re-format of the file 
system.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#235918

Thanks to all for the advice and knowledge you shared about how
grub works.  I am writing this on June 6 and early this morning,
I  edited the boot command in the grub shell after
verifying that my stubborn no-boot drive truly was sitting at
hd0,1msdos and grub-install had picked out hd2,1msdos for every
single drive reference, even the bare metal one.

	I did try that one first in case I was missing some magic
but the only drive on the whole system was that one and listing
the contents of (hd0,1msdos) show exactly what you see if looking
at / so grub showed it exactly where one would expect it to be
and hd2,msdos is pure science fiction on that system so I set
every drive reference to hd0,1msdos except the root which grub
wanted to set to /dev/sdc1.

	The sample that Greg Wooledge showed looked very close to
how my grub.cfg looked after doctoring the drive references to
point to hd0,1msdos.  and I tried booting that way and set the
root parameter to /dev/sda1, /dev/sdb1 and /dev/sdc1 which is the
one that grub chose, again non-existent.  /dev/sdb1 is actually a
Zipdisk drive but I tried it anyway since there is no zipdisk in
there.

	It never booted so I am throwing in the towel, figuring
that in all the messing around, I have corrupted something and
wasted about two weeks on and off trying this, that and the other.

	I have a good 32 GB drive left over from a computer that
died last year so I will just clone it from the working system
that is sending this email.  The drive that can't boot but is
otherwise fine will now be the second drive and will mount as
/home where all the important stuff I used it for can still live.

	The only good thing about this exercise is that I know a
lot more about what grub does than I did and I also discovered
that while I had perfect backups of the home directory, I had
failed to set rsnapshot to backup /boot which was quite a stupid
oversight on my part.  /var, /etc and several other directories off of
/ get daily backups and I could have sworn /boot did but it's not
there so I have been doing a lot of industrial-grade swearing
lately.

	Grub is a very fine tool when used properly and I do
believe that there should be a pristine way to make a disk
bootable that is intuitive and automatic plus unaffected by the
configuration of any other drive on the system, like the old sys
command in DOS to make any DOS diskette bootable.

	The unix incarnation of the sys command would have to do
a lot more such as verify that you have a kernel and modules
ready to go plus consult your /etc/fstab and /etc/default/grub
files but that shouldn't be a real problem.  One would basically
do the grub install in a a total jail so it would come out set as
if one had just been running the installer and this was the only
drive on the system.

	Thank you all for your help and sorry that it took so
long to determine that nothing simple was going to work.

Martin

[toc] | [prev] | [next] | [standalone]

#235921

Martin McCormick composed on 2021-06-06 13:30 (UTC-0500):

> 	The sample that Greg Wooledge showed looked very close to
> how my grub.cfg looked after doctoring the drive references to
> point to hd0,1msdos.  and I tried booting that way and set the
> root parameter to /dev/sda1, /dev/sdb1 and /dev/sdc1 which is the
> one that grub chose, again non-existent.  /dev/sdb1 is actually a
> Zipdisk drive but I tried it anyway since there is no zipdisk in
> there.
										
IMO you gave up too soon. IIRC you never showed us output from parted -l or fdisk
-l. Very likely on the problem PC the / filesystem was/is not on the first
partition, where often lies a swap partition. Very likely root=/dev/sda2 would
have been/be correct.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

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

Felix Miata

[toc] | [prev] | [next] | [standalone]

#235923

Felix Miata <mrmazda@earthlink.net> writes:
> IMO you gave up too soon. IIRC you never showed us output from parted -l 
> or fdisk
> -l. Very likely on the problem PC the / filesystem was/is not on the first
> partition, where often lies a swap partition. Very likely root=/dev/sda2 
> would
> have been/be correct.

Sorry.  I meant to do that.

Swap is the last partition.

Disk /dev/sde: 29.8 GiB, 32017047552 bytes, 62533296 sectors
Disk model: 600             
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000080

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sde1           2048 59314876 59312829 28.3G 83 Linux
/dev/sde2       59314877 62533295  3218419  1.5G  5 Extended
/dev/sde5       59316925 62533295  3216371  1.5G 82 Linux swap / Solaris

$ ls -1 /mnt/

bin
boot
dev
etc
home
initrd.img
initrd.img.old
lib
lost+found
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var
vmlinuz
vmlinuz.old

[toc] | [prev] | [next] | [standalone]

#235924

I admit I made several big mistakes, here.  The first was not
having a backup of /boot as I thought I did.  The next is
thinking I could just copy the whole boot directory from a
known working system and be able to get it to work by using sed to
replace the UUID's of the system it was on with those of the
system it will be on.  Had I backed up the broken system instead
the minute I knew there was a problem, it would have been
fixable.

	Trying to transplant the good boot system to a different
machine really should work if one knows what all changed but if
that was the case, I'd be crowing about how I got it working.

	I may try one last thing which is to decompress the initrd
files and see if there is a way to make sure they work after
transplantation.  At this point, it's probably more important to
know what is poisoning the well as a training exercise since
having good backups of /boot would have turned a major halt in
to a minor irritation.  Trust me.  The good system is going to
get daily backups of boot and grub every 24 hours from this day
on.

	I haven't actually done anything yet to clone the good
system's boot drive because I want to do the clone in the middle
of the night when things are quieter and I don't run fetchmail
in the wee hours so the backup sees a more stable file system.

	If, by chance, I end up actually making the broken system
work, I'll let you know what it was and the one drive can serve
the whole system again.

Martin

[toc] | [prev] | [next] | [standalone]

#235925

Martin McCormick composed on 2021-06-06 16:59 (UTC-0500):
...
> Swap is the last partition.

> Disk /dev/sde:
										
This is a big lurking booby trap that could have been the problem both last time
and this time. It's one of the reasons why installation systems and Grub switched
from using device names to using UUIDs: inconsistent and/or unpredicable device
enumeration.

Is this a PC with both PATA and SATA controllers? These old PCs can compound the
issue.

Different kernel, disk controller, USB controller and BIOS combinations can cause
e.g. an SATA or PATA disk sda to become sde, or sdb become sda, IOW, device names
that don't persist. UUIDs are supposed to prevent inconsistent device names from
being a problem, but in a rescue environment, it can muddy the waters, or backfire.

> 29.8 GiB, 32017047552 bytes, 62533296 sectors
> Disk model: 600             
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x00000080

> Device     Boot    Start      End  Sectors  Size Id Type
> /dev/sde1           2048 59314876 59312829 28.3G 83 Linux
> /dev/sde2       59314877 62533295  3218419  1.5G  5 Extended
> /dev/sde5       59316925 62533295  3216371  1.5G 82 Linux swap / Solaris
										
Is this 32GB (29.8GiB) sde disk in fact the disk in the problem PC, and not a USB
device?

I still think yours is fixable most easily by using volume labels. They're easier
on human brains, yet can be functionally as unique as needs be. Post /etc/fstab
from this disk, and blkid output, the first complete grub.cfg stanza, and
/etc/default/grub to get started. If that 28G partition that is shows above as
sde1 doesn't have a label, give it one with e2label or tune2fs.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

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

Felix Miata

[toc] | [prev] | [next] | [standalone]

#235930

Felix Miata <mrmazda@earthlink.net> writes:
> This is a big lurking booby trap that could have been the problem both 
> last time
> and this time. It's one of the reasons why installation systems and Grub 
> switched
> from using device names to using UUIDs: inconsistent and/or unpredicable 
> device
> enumeration.
> 
> Is this a PC with both PATA and SATA controllers? These old PCs can 
> compound the
> issue.
> 
> Different kernel, disk controller, USB controller and BIOS combinations 
> can cause
> e.g. an SATA or PATA disk sda to become sde, or sdb become sda, IOW, 
> device names
> that don't persist. UUIDs are supposed to prevent inconsistent device 
> names from
> being a problem, but in a rescue environment, it can muddy the waters, or 
> backfire.

	Yes on all counts.  These are old PC's that use IDE
controllers.  The IDE cables end in the normal 34-conductor
header with one pin missing on one side that plugs directly in to
the drive.  In this case, the connector plugs in to a SATA-to-IDE
converter with a female SATA connector.

	I believe you have hit the nail on the head because I
know for a fact that the devices change names.  On the working
system, the boot device we would normally think of as /dev/sda is
/dev/sdc and 5 minutes from now might be /dev/sdq depending on
what drives were plugged in to usb ports when the system booted.

	Just yesterday, I mounted /dev/sdd, thinking it was the
now infamous unbootable drive and immediately realized that I was
looking at the boot drive that starts the good system.  I had
plugged a thumb drive in to a usb port some time earlier and then
rebooted the system while failing to remove the thumb drive as it
wasn't even being used right then.

	Let's see.  $ dd if=/dev/sdd of=/dev/sde  What could
possibly go wrong?  Just kidding this time but that's what we are
dealing with.  That possibly lethal command can work but only
under the right circumstances so if one forgot to recreate the
world one was working with, it's tuition in the school of hard
knocks.  I haven't yet totally given up and done anything else
rash so it's still full steam ahead.  This is one of those
situations where if a person has the time, this can be a
teachable moment.

	I've got several thumb drives that I mount based on their
UUID and that method of doing things is your friend if you
understand how to use it.  If not, what one ends up with is total
chaos.

	Felix's message hasn't saved the day yet but it confirms
my hunch that the UUID's have been at the heart of this problem
all along because there is simply no other logical reason why one
can not transplant the same boot logic from one system to the
other when they are functional copies of each other.  The trick
will be to replace every UUID personalization which is doable.
Whether it is practical still remains to be seen.

	To briefly reference an earlier message, I checked the
good system to see what rsnapshot did over night and /boot is
now committed to a series of little capacitors which is how SSD's
remember things.  From fstab:

# /etc/fstab: static file system information.
UUID="49c4eda8-3bcc-445e-841b-513b07d560fe" /var/cache/rsnapshot ext4 relatime,rw,user,noauto  0       0

	If that drive wasn't always plugged in, the boot drive
would have a different device number than /dev/sdc1 which is also
mounted by UUID.  That drive also plugs directly in to a usb slot
and not any extender to hopefully insure that it is more likely
to be present.

	I will uncompress the initrd files and see how hard it
will be to find the UUID and change it to what it should be on
the problem target system.

Again, thanks to all.

Martin   WB5AGZ

[toc] | [prev] | [next] | [standalone]

#235949 — Grub Success at Last

I did it!  It works!

	Okay.  Here's the short story.  I read some more stuff
about building a boot drive for another system than the one being
used for the rescue.  In this thread were the usual tales of woe
which I have also experienced when misusing grub such as "Oh
#%^*! Now I've got 2 systems that won't boot."  a poster on that
thread states:

   I'm not a grub2 expert (sorry) but try adding --skip-fs-probe to your
   grub-install line, I have found this prevents creation of
   /boot/grub/device.map which can cause booting to a grub prompt. I think
   that without this parameter grub-install, instead of doing what you
   tell it, thinks it is cleverer than you, and may do something
   different.

   Another thing is to be sure you are using the right grub-install (i.e.
   for grub2 and not for original grub). This isn't a problem if you are
   inside Centos but with SystemRecoveryCD both versions are available and
   so you have to use grub2-install. I learned the hard way...

   And as @wurtel pointed out (kudos), you should specify a drive not a
   partition. Grub2 installs in sector 0 of the whole disk drive, and this
   'stub' is what runs at boot time, but it needs to know whereabouts on
   the disk it should install the files for the next stage of booting -
   this is what the --root-directory parameter is for. (I think.)

   Reading man grub-install and googling I see that --root-directory is
   not really meant to be used for grub2 versions 1.99++, though it does
   work in my experience. You are meant to use --boot-directory and refer
   to the actual boot directory, so this would give you:
grub-install /dev/sdb --skip-fs-probe --boot-directory=/media/new_drive/boot

End of quote

	I did the following:

#!/bin/sh
#mount the drive being repaired.  Uncomment lines as needed.
  sudo mount /dev/sdd1 /mnt
cd /mnt/boot
#installing to the mounted disk
  sudo grub-install \
--skip-fs-probe \
--boot-directory=/mnt/boot/ /dev/sdd

	When you boot your disk that starts out on /dev/sda1,
it's the first partition, in this case, so it will be /dev/sda1
not /dev/sdd1 .  This was quite a long thread and people were
remarking on how it is easy to get confused and do the wrong
thing.

	Anyway, It booted right up and then I discovered there
was no network.

	The network issue was only tangentially related because
the update-upgrade process also install some more strict and
modified ethernet interface naming rules and eth2 just doesn't
cut it any more.  Now, it's enp0s17 on the system that just got
revived and enp0s18 or something similar on the system that got
the same upgrades but is a little newer and took the tharapy much
easier.  Everything's working again at least in the Linux world.

	I saw this ad on TV for some product that is supposed to
improve brain function and memory but I can never remember it's
name.  I could use a few more IQ points and things would flow a
little faster around here.

	Thanks for all the help, everybody.

Martin

[toc] | [prev] | [next] | [standalone]

#235951 — Re: Grub Success at Last, but way offtopic

On Tuesday 08 June 2021 18:09:34 Martin McCormick wrote:

> I did it!  It works!
>
> 	Okay.  Here's the short story.  I read some more stuff
> about building a boot drive for another system than the one being
> used for the rescue.  In this thread were the usual tales of woe
> which I have also experienced when misusing grub such as "Oh
> #%^*! Now I've got 2 systems that won't boot."  a poster on that
> thread states:
>
>    I'm not a grub2 expert (sorry) but try adding --skip-fs-probe to
> your grub-install line, I have found this prevents creation of
>    /boot/grub/device.map which can cause booting to a grub prompt. I
> think that without this parameter grub-install, instead of doing what
> you tell it, thinks it is cleverer than you, and may do something
> different.
>
>    Another thing is to be sure you are using the right grub-install
> (i.e. for grub2 and not for original grub). This isn't a problem if
> you are inside Centos but with SystemRecoveryCD both versions are
> available and so you have to use grub2-install. I learned the hard
> way...
>
>    And as @wurtel pointed out (kudos), you should specify a drive not
> a partition. Grub2 installs in sector 0 of the whole disk drive, and
> this 'stub' is what runs at boot time, but it needs to know
> whereabouts on the disk it should install the files for the next stage
> of booting - this is what the --root-directory parameter is for. (I
> think.)
>
>    Reading man grub-install and googling I see that --root-directory
> is not really meant to be used for grub2 versions 1.99++, though it
> does work in my experience. You are meant to use --boot-directory and
> refer to the actual boot directory, so this would give you:
> grub-install /dev/sdb --skip-fs-probe
> --boot-directory=/media/new_drive/boot
>
> End of quote
>
> 	I did the following:
>
> #!/bin/sh
> #mount the drive being repaired.  Uncomment lines as needed.
>   sudo mount /dev/sdd1 /mnt
> cd /mnt/boot
> #installing to the mounted disk
>   sudo grub-install \
> --skip-fs-probe \
> --boot-directory=/mnt/boot/ /dev/sdd
>
> 	When you boot your disk that starts out on /dev/sda1,
> it's the first partition, in this case, so it will be /dev/sda1
> not /dev/sdd1 .  This was quite a long thread and people were
> remarking on how it is easy to get confused and do the wrong
> thing.
>
> 	Anyway, It booted right up and then I discovered there
> was no network.
>
> 	The network issue was only tangentially related because
> the update-upgrade process also install some more strict and
> modified ethernet interface naming rules and eth2 just doesn't
> cut it any more.  Now, it's enp0s17 on the system that just got
> revived and enp0s18 or something similar on the system that got
> the same upgrades but is a little newer and took the tharapy much
> easier.  Everything's working again at least in the Linux world.
>
> 	I saw this ad on TV for some product that is supposed to
> improve brain function and memory but I can never remember it's
> name.  I could use a few more IQ points and things would flow a
> little faster around here.
>
> 	Thanks for all the help, everybody.

I've found that a small vitamin b1 in your daily pilltainer seems to 
help.  Its not magic, nothing is at 86, but it does seem to help the 
concentration.

> Martin


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web