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

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

Banishing UUIDs from grub

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

Contents

  Banishing UUIDs from grub Dave Sherohman <dave@sherohman.org> - 2018-01-18 11:00 +0100
    Re: Banishing UUIDs from grub Michael Lange <klappnase@freenet.de> - 2018-01-18 11:20 +0100
    Re: Banishing UUIDs from grub Stephan Seitz <stse+debian@fsing.rootsland.net> - 2018-01-18 11:30 +0100
      Re: Banishing UUIDs from grub Dave Sherohman <dave@sherohman.org> - 2018-01-18 14:30 +0100
        Re: Banishing UUIDs from grub David Wright <deblis@lionunicorn.co.uk> - 2018-01-18 15:30 +0100
    Re: Banishing UUIDs from grub deloptes <deloptes@gmail.com> - 2018-01-18 18:50 +0100
      Re: Banishing UUIDs from grub Gene Heskett <gheskett@shentel.net> - 2018-01-18 20:00 +0100
        Re: Banishing UUIDs from grub Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-18 20:30 +0100
          Re: Banishing UUIDs from grub Gene Heskett <gheskett@shentel.net> - 2018-01-18 20:50 +0100
            Re: Banishing UUIDs from grub Don Armstrong <don@debian.org> - 2018-01-18 22:10 +0100
              Re: Banishing UUIDs from grub Gene Heskett <gheskett@shentel.net> - 2018-01-19 00:10 +0100
                Re: Banishing UUIDs from grub Don Armstrong <don@debian.org> - 2018-01-19 00:40 +0100
                Re: Banishing UUIDs from grub Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-01-19 03:00 +0100
                  Re: Banishing UUIDs from grub Michael Stone <mstone@debian.org> - 2018-01-19 03:00 +0100
            Re: Banishing UUIDs from grub David Wright <deblis@lionunicorn.co.uk> - 2018-01-19 02:30 +0100
              Re: Banishing UUIDs from grub Gene Heskett <gheskett@shentel.net> - 2018-01-19 05:20 +0100
      Re: Banishing UUIDs from grub Dave Sherohman <dave@sherohman.org> - 2018-01-19 14:10 +0100
    Re: Banishing UUIDs from grub Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-18 20:10 +0100
      Re: Banishing UUIDs from grub Stefan Monnier <monnier@iro.umontreal.ca> - 2018-01-19 04:00 +0100

#191258 — Banishing UUIDs from grub

What is the recommended method for preventing grub from using UUIDs to
refer to filesystems in the current Debian stable distribution?

---

In an attempt to head off a "but you really want to use UUIDs!" debate:

The specific use-case I'm dealing with here is cloned virtual machines.
When I clone them, the virtual disks' UUIDs are cleared and new UUIDs
are assigned, which is as it should be.  However, this causes the first
boot to fail because grub can't find the UUID it wants to boot from,
requiring me to manually boot the system through the grub rescue shell.

Once the cloned VM is up and running, I can run grub-install to fix it,
but the use of UUIDs prevents the cloned VMs from booting unattended
until this is done.  If grub were to try to boot from lvm/system[1]
instead of lvm/UUID, that would remove the need for per-machine manual
intervention.

[1] ...and it will always and forever be lvm/system.  Removable media
and hardware which can autodetect in nondeterministic sequences are not
concerns here.

-- 
Dave Sherohman

[toc] | [next] | [standalone]

#191259

Hi,

On Thu, 18 Jan 2018 03:31:30 -0600
Dave Sherohman <dave@sherohman.org> wrote:

> What is the recommended method for preventing grub from using UUIDs to
> refer to filesystems in the current Debian stable distribution?

not sure about this; have you tried to set

GRUB_DISABLE_LINUX_UUID=true

in /etc/default/grub ?

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Death, when unnecessary, is a tragic thing.
		-- Flint, "Requiem for Methuselah", stardate 5843.7

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

#191261

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

On Do, Jan 18, 2018 at 03:31:30 -0600, Dave Sherohman wrote:
>What is the recommended method for preventing grub from using UUIDs to
>refer to filesystems in the current Debian stable distribution?

In /etc/default/grub I have the option:

# Uncomment if you don’t want GRUB to pass „root=UUID=xxx” parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

Shade and sweet water!

	Stephan

-- 
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

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

#191263

On Thu, Jan 18, 2018 at 11:11:32AM +0100, Stephan Seitz wrote:
> On Do, Jan 18, 2018 at 03:31:30 -0600, Dave Sherohman wrote:
> >What is the recommended method for preventing grub from using UUIDs to
> >refer to filesystems in the current Debian stable distribution?
> 
> In /etc/default/grub I have the option:
> 
> # Uncomment if you don’t want GRUB to pass „root=UUID=xxx” parameter to Linux
> #GRUB_DISABLE_LINUX_UUID=true

That doesn't seem to be a complete solution for booting from an LVM
volume.  I've enabled it:

$ grep UUID /etc/default/grub 
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
# Linux
GRUB_DISABLE_LINUX_UUID=true

and re-run update-grub, but /boot/grub/grub.cfg still has a mix of
device names and UUIDs:

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-c5bb6082-0b8b-46e5-a253-c4811a1f011a' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_msdos
        insmod lvm
        insmod ext2
        set root='lvmid/wf5YhU-vt2F-uZM9-cVso-qn6Z-fdY9-iQO26v/sBd6ej-DTMK-RUxu-LuRW-MjLj-rRLf-C6OwT2'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='lvmid/wf5YhU-vt2F-uZM9-cVso-qn6Z-fdY9-iQO26v/sBd6ej-DTMK-RUxu-LuRW-MjLj-rRLf-C6OwT2'  c5bb6082-0b8b-46e5-a253-c4811a1f011a
        else
          search --no-floppy --fs-uuid --set=root c5bb6082-0b8b-46e5-a253-c4811a1f011a
        fi
        echo    'Loading Linux 4.9.0-5-amd64 ...'
        linux   /boot/vmlinuz-4.9.0-5-amd64 root=/dev/mapper/system ro  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-4.9.0-5-amd64
}


My guess at explaining this would be that the GRUB_DISABLE_LINUX_UUID
flag is very literal and *only* affects whether "GRUB [passes]
"root=UUID=xxx" parameter to Linux", but not how grub itself identifies
the root device ("set root='lvmid/[UUID]').


-- 
Dave Sherohman

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

#191265

On Thu 18 Jan 2018 at 07:19:45 (-0600), Dave Sherohman wrote:

> My guess at explaining this would be that the GRUB_DISABLE_LINUX_UUID
> flag is very literal and *only* affects whether "GRUB [passes]
> "root=UUID=xxx" parameter to Linux", but not how grub itself identifies
> the root device ("set root='lvmid/[UUID]').

It's subtle, but that's probably why the parameter is called
GRUB_DISABLE_LINUX_UUID and not GRUB_DISABLE_UUID.

>From the docs:

'GRUB_DISABLE_LINUX_UUID'
     Normally, 'grub-mkconfig' will generate menu entries that use
     universally-unique identifiers (UUIDs) to identify the root
     filesystem to the Linux kernel, using a 'root=UUID=...' kernel
     parameter.  This is usually more reliable, but in some cases it may
     not be appropriate.  To disable the use of UUIDs, set this option
     to 'true'.

Cheers,
David.

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

#191273

Dave Sherohman wrote:

> What is the recommended method for preventing grub from using UUIDs to
> refer to filesystems in the current Debian stable distribution?

what is the reason to avoid UUIDs? (if not very private)

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

#191276

On Thursday 18 January 2018 12:42:41 deloptes wrote:

> Dave Sherohman wrote:
> > What is the recommended method for preventing grub from using UUIDs
> > to refer to filesystems in the current Debian stable distribution?
>
> what is the reason to avoid UUIDs? (if not very private)

UUID's have turned out to be quite volatile over system upgrades. Give me 
a familiar disklabel any day.

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#191279

Le 18/01/2018 à 19:54, Gene Heskett a écrit :
> 
> UUID's have turned out to be quite volatile over system upgrades.

Not on mine.

> Give me a familiar disklabel any day.

Don't you mean a filesystem or partition label ?
"Disklabel" is a synonym for "partition table".

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

#191280

On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:

> Le 18/01/2018 à 19:54, Gene Heskett a écrit :
> > UUID's have turned out to be quite volatile over system upgrades.
>
> Not on mine.
>
> > Give me a familiar disklabel any day.
>
> Don't you mean a filesystem or partition label ?
> "Disklabel" is a synonym for "partition table".

Yes of course. I have had the UUID change on this system, on my 
amandatapes drive at almost every install or upgrade. I finally labeled 
that partition as amandatapes about 5 years back. No further problems. 
It been the same 1T seacrate disk since they came out, and this one came 
out of the box with 25 re-allocated sectors. I updated its firmware a 
week later, UUID changed. Labeled the partition, and nearly 70 thousand 
spinning hours later it still shows 25 re-allocated sectors. I am both 
amazed and pleased as punch. It hovers in the 80% usage range, as a 
vtape is actually a directory, there are 30 of them, 1, very 
occasionally 2 of them gets cleaned out and reused every night.

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#191281

On Thu, 18 Jan 2018, Gene Heskett wrote:
> On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:
> > Le 18/01/2018 à 19:54, Gene Heskett a écrit :
> > > UUID's have turned out to be quite volatile over system upgrades.
> >
> > Not on mine.
>
> I have had the UUID change on this system, on my 
> amandatapes drive at almost every install or upgrade.

Which UUID changed? The filesystem UUID shouldn't change unless you
reformat the partition, and the partition UUID shouldn't change unless
you repartition it (or you specifically change the UUID).

I've been using UUIDs for *ages*, and I've never seen one change unless
I've specifically done something which would change it.

-- 
Don Armstrong                      https://www.donarmstrong.com

There is no mechanical problem so difficult that it cannot be solved
by brute strength and ignorance.
 -- William's Law

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

#191287

On Thursday 18 January 2018 16:04:26 Don Armstrong wrote:

> On Thu, 18 Jan 2018, Gene Heskett wrote:
> > On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:
> > > Le 18/01/2018 à 19:54, Gene Heskett a écrit :
> > > > UUID's have turned out to be quite volatile over system
> > > > upgrades.
> > >
> > > Not on mine.
> >
> > I have had the UUID change on this system, on my
> > amandatapes drive at almost every install or upgrade.
>
> Which UUID changed? The filesystem UUID shouldn't change unless you
> reformat the partition, and the partition UUID shouldn't change unless
> you repartition it (or you specifically change the UUID).
>
In this case, I installed a fresh firmware image on the drive, didn't 
lose a byte, but the UUID was changed, discovered when amanda couldn't 
find its virtual tapes drive after the reboot. I checked the fstab, then 
ran blkid, and it had changed. So I applied a label to the partition, 
edited fstab, and its been 69,600 or so spinning hours since. I've 
updated the system from ubuntu hardy to debian wheezy, no change.

One of these days I need to convert it to 64 bit. Probably by putting 
most of that stuff on the amandatapes partition, putting in a fresh 1T 
drive, and installing a 64 bit jessie. Once thats running, I have a 2T 
drive that I'll format for amanda and swap this one out. Nothing wrong 
with it, but I keep adding more machines to the disklist. 7 now.

> I've been using UUIDs for *ages*, and I've never seen one change
> unless I've specifically done something which would change it.


Cheers, Gene Heskett
The above content, added by Maurice E. Heskett, is Copyright 2018 by 
Maurice E. 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)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#191288

On Thu, 18 Jan 2018, Gene Heskett wrote:
> On Thursday 18 January 2018 16:04:26 Don Armstrong wrote:
> > Which UUID changed? The filesystem UUID shouldn't change unless you
> > reformat the partition, and the partition UUID shouldn't change
> > unless you repartition it (or you specifically change the UUID).
> >
> In this case, I installed a fresh firmware image on the drive, didn't
> lose a byte, but the UUID was changed, discovered when amanda couldn't
> find its virtual tapes drive after the reboot. I checked the fstab,
> then ran blkid, and it had changed.

I'm still not clear which UUID was changed. Even if you change the
firmware image,[1] the filesystem UUID should not change, because that
would require changing the filesystem.

[Pretty much anything which changes the partition UUID can also change
the partition label, though perhaps whatever did the update doesn't
change the label.]

But in any event, LABEL works just as well.

-- 
Don Armstrong                      https://www.donarmstrong.com

Identical parts aren't.
 -- Beach's Law

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

#191293

On 1/18/18, Gene Heskett <gheskett@shentel.net> wrote:
> On Thursday 18 January 2018 16:04:26 Don Armstrong wrote:
>
>> On Thu, 18 Jan 2018, Gene Heskett wrote:
>> > On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:
>> > > Le 18/01/2018 à 19:54, Gene Heskett a écrit :
>> > > > UUID's have turned out to be quite volatile over system
>> > > > upgrades.
>> > >
>> > > Not on mine.
>> >
>> > I have had the UUID change on this system, on my
>> > amandatapes drive at almost every install or upgrade.
>>
>> Which UUID changed? The filesystem UUID shouldn't change unless you
>> reformat the partition, and the partition UUID shouldn't change unless
>> you repartition it (or you specifically change the UUID).
>>
> In this case, I installed a fresh firmware image on the drive, didn't
> lose a byte, but the UUID was changed, discovered when amanda couldn't
> find its virtual tapes drive after the reboot. I checked the fstab, then
> ran blkid, and it had changed. So I applied a label to the partition,
> edited fstab, and its been 69,600 or so spinning hours since. I've
> updated the system from ubuntu hardy to debian wheezy, no change.


I've had it happen, too. Feels like recently, but was probably a
couple years ago, if not more like 3. I could never figure out how it
happened.

>From one reboot to the next, the value or values changed, but I had
not *knowingly* done anything that should have changed it. By
"knowingly", I mean via gparted which is the only place I've ever
changed those manually. I've probably only done *that* maybe twice in
five or six years, probably just to have done it to know how it would
affect things.

/etc/fstab was my go-to to see where things didn't match. Had a copy
floating around just to remind myself whenever I stumbled back over it
occasionally. I never thought to check grub.cfg before getting
everything to match back up properly at the time.

It hasn't happened since, and I've messed all kinds of other things up
in the meantime... like killing my sound (again) about 2 days ago
while trying to roll my own of something that I've already forgotten
what it was. I think it was something about "that" dialup modem. :D

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

* runs with duct tape *

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

#191294

On Thu, Jan 18, 2018 at 08:50:11PM -0500, Cindy-Sue Causey wrote:
>I've had it happen, too. Feels like recently, but was probably a
>couple years ago, if not more like 3. I could never figure out how it
>happened.

vfat filesystem?

Mike Stone

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

#191292

On Thu 18 Jan 2018 at 14:46:26 (-0500), Gene Heskett wrote:
> On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:
> 
> > Le 18/01/2018 à 19:54, Gene Heskett a écrit :
> > > UUID's have turned out to be quite volatile over system upgrades.
> >
> > Not on mine.
> >
> > > Give me a familiar disklabel any day.
> >
> > Don't you mean a filesystem or partition label ?
> > "Disklabel" is a synonym for "partition table".
> 
> Yes of course. I have had the UUID change on this system, on my 
> amandatapes drive at almost every install or upgrade. I finally labeled 
> that partition as amandatapes about 5 years back. No further problems. 
> It been the same 1T seacrate disk since they came out, and this one came 
> out of the box with 25 re-allocated sectors. I updated its firmware a 
> week later, UUID changed. Labeled the partition, and nearly 70 thousand 
> spinning hours later it still shows 25 re-allocated sectors. I am both 
> amazed and pleased as punch. It hovers in the 80% usage range, as a 
> vtape is actually a directory, there are 30 of them, 1, very 
> occasionally 2 of them gets cleaned out and reused every night.

What sort of filesystem does this partition hold?

Cheers,
David.

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

#191296

On Thursday 18 January 2018 20:25:51 David Wright wrote:

> On Thu 18 Jan 2018 at 14:46:26 (-0500), Gene Heskett wrote:
> > On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:
> > > Le 18/01/2018 à 19:54, Gene Heskett a écrit :
> > > > UUID's have turned out to be quite volatile over system
> > > > upgrades.
> > >
> > > Not on mine.
> > >
> > > > Give me a familiar disklabel any day.
> > >
> > > Don't you mean a filesystem or partition label ?
> > > "Disklabel" is a synonym for "partition table".
> >
> > Yes of course. I have had the UUID change on this system, on my
> > amandatapes drive at almost every install or upgrade. I finally
> > labeled that partition as amandatapes about 5 years back. No further
> > problems. It been the same 1T seacrate disk since they came out, and
> > this one came out of the box with 25 re-allocated sectors. I updated
> > its firmware a week later, UUID changed. Labeled the partition, and
> > nearly 70 thousand spinning hours later it still shows 25
> > re-allocated sectors. I am both amazed and pleased as punch. It
> > hovers in the 80% usage range, as a vtape is actually a directory,
> > there are 30 of them, 1, very occasionally 2 of them gets cleaned
> > out and reused every night.
>
> What sort of filesystem does this partition hold?
>
Std ext4.

> Cheers,
> David.


Cheers, Gene Heskett
The above content, added by Maurice E. Heskett, is Copyright 2018 by 
Maurice E. 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)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#191316

On Thu, Jan 18, 2018 at 06:42:41PM +0100, deloptes wrote:
> Dave Sherohman wrote:
> > What is the recommended method for preventing grub from using UUIDs to
> > refer to filesystems in the current Debian stable distribution?
> 
> what is the reason to avoid UUIDs? (if not very private)

The specific system where this is an issue is a backing image used as
the master for eight cloned developer virtual machines, so that each of
our devs can have their own private space to work in which mimics the
production server and can easily be reset to a pristine state by
throwing out the clone and making a new one.  In the cloning process,
the disk and LVM volume UUIDs are discarded and new UUIDs are generated
(which makes sense, because it's no longer the same disk or same
volume), but grub is still looking for the original UUIDs and drops into
a recovery shell when it fails to find them.

At this point, I have the rest of the process automated.  The one step
that still requires manual intervention is walking grub through the
first boot of the system and telling it to boot from (lvm/system)
instead of (lvm/[vg UUID]/[volume UUID]).

-- 
Dave Sherohman

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

#191277

Le 18/01/2018 à 10:31, Dave Sherohman a écrit :
> What is the recommended method for preventing grub from using UUIDs to
> refer to filesystems in the current Debian stable distribution?

One method for you use case it to put /boot or at least /boot/grub in a 
plain partition on the same disk as GRUB's core image.

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

#191295

>> What is the recommended method for preventing grub from using UUIDs to
>> refer to filesystems in the current Debian stable distribution?
> One method for you use case it to put /boot or at least /boot/grub
> in a plain partition on the same disk as GRUB's core image.

Indeed, that's what I have here and it works fine when the UUID is wrong
(as long as that wrong UUID doesn't map to any accessible partition),
because the "search --set=root" is not needed anyway.


        Stefan

[toc] | [prev] | [standalone]

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

csiph-web