Re: Banishing UUIDs from grub

[Felix Miata]

Michael Stone composed on 2018-01-19 08:57 (UTC-0500):
...
> It's  also possible to use filesystem labels, but in practice it turned out 
> to be not uncommon for two different systems to have something like "root", 
> which caused a lot of trouble when you put a drive from one system into 
> another system. You could give the labels unique random names, but then 
> you've (re)invented the UUID.

I create non-random labels with a bit more complexity, e.g.:

p01jessie
p02home
p05usrlcl
p06stretch
p07buster

More complexity, though still human manageable, would be including a few of the
last characters of the physical device's serial number and/or model number, or
all or a portion of the hostname:

st5p08debsid-Z1W

If you assign a label to a swap partition, then mount swap by label, it can be a
little easier to deal with the installer's proclivity to reformat swap when a
new installation is added.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

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

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

Re: Banishing UUIDs from grub

[Michael Stone]

[not responding to the OP, I think he's already gotten an answer. this 
is for people reading the archive.]


The filesystem UUID is written into the filesystem when it is created. 
It's possible (though not necessarily easy) to change using tune2fs and 
other specialized filesystem tools. It does not "just change". It is 
also possible to write a label, or name, on the filesystem. It is 
written into the filesystem right next to the UUID. There are a couple 
of exceptions: FAT filesystems don't support a true UUID, for example. 
There are also partition UUIDs, the details for which depend on the 
partition table type. So why use UUIDs? In the old days we just used 
drive letters to identify filesystem locations, something like sda1 or 
hda1, and these rarely changed because they were associated with disk 
controllers with static cabling. (Although it was a bit of a pain to add 
or remove a controller.) On a modern system, though, it's actually not 
at all uncommon for drive letter assignments to change depending on 
what's plugged in at boot time, because of USB and other dynamic bus 
attachments. In practice, using UUIDs for filesystem assignments has 
been more reliable than relying on drive letters for quite a while. It's 
also possible to use filesystem labels, but in practice it turned out to 
be not uncommon for two different systems to have something like "root", 
which caused a lot of trouble when you put a drive from one system into 
another system. You could give the labels unique random names, but then 
you've (re)invented the UUID.


I understand that some people are saying that "something happened" and 
years ago they had a UUID change, but that's not really much to help 
diagnose a problem. In general it would be bad advice for people to 
assume there's a real problem and abandon UUIDs based on hearsay. If 
someone has a current case where they think a UUID is changing it would 
be useful to bring it up here so we could see exactly which ID they're 
talking about and try to diagnose what's going on. (It's probably not the 
case that the filesystem UUID is just randomly changing.)


For the curious, you can run "blkid" to see all of the IDs associated 
with your filesystems.


Mike Stone

Re: Banishing UUIDs from grub

[Dave Sherohman]

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

Re: Banishing UUIDs from grub

[Dave Sherohman]

On Thu, Jan 18, 2018 at 11:52:11AM -0500, Marc Auslander wrote:
> Dave Sherohman  writes:
> 
> >What is the recommended method for preventing grub from using UUIDs to
> >refer to filesystems in the current Debian stable distribution?
> 
> I don't know about "recommended" but could you put your own menu
> entry into /etc/grub.d and make it the default?

Short and sweet.  Why didn't I think of that?

Thanks!

-- 
Dave Sherohman

Re: Banishing UUIDs from grub

[Gene Heskett]

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 

Re: Banishing UUIDs from grub

[Stefan Monnier]

>> 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

Re: Banishing UUIDs from grub

[Michael Stone]

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

Re: Banishing UUIDs from grub

[Cindy-Sue Causey]

On 1/18/18, Gene Heskett  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 *

Re: Banishing UUIDs from grub

[David Wright]

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.

Re: Banishing UUIDs from grub

[Don Armstrong]

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

Re: Banishing UUIDs from grub

[Gene Heskett]

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 

Re: Banishing UUIDs from grub

[Don Armstrong]

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

Re: Banishing UUIDs from grub

[Gene Heskett]

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 

Re: Banishing UUIDs from grub

[Pascal Hambourg]

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".

Re: Banishing UUIDs from grub

[Pascal Hambourg]

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.

Re: Banishing UUIDs from grub

[Gene Heskett]

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 

Re: Banishing UUIDs from grub

[David Wright]

On Thu 18 Jan 2018 at 11:52:11 (-0500), Marc Auslander wrote:
> Dave Sherohman  writes:
> 
> >What is the recommended method for preventing grub from using UUIDs to
> >refer to filesystems in the current Debian stable distribution?
> >
> 
> I don't know about "recommended" but could you put your own menu
> entry into /etc/grub.d and make it the default?

I prefer to let grub do the grunt work and then run a filter over
grub.cfg. I use LABELs myself; the filter finds the necessary
information in /run/udev/data and performs substitutions of --fs-uuid
options, root=UUID= and the UUIDs themselves. (It also mangles, to my
taste, the menuentry_id_option strings etc a little further.)
It takes no time to run a filter whenever grub.cfg gets rebuilt.

I don't encrypt system partitions or use VMs so I don't know how
well a filtering scheme would translate to that.

Cheers,
David.

Re: Banishing UUIDs from grub

[deloptes]

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)

Re: Banishing UUIDs from grub

[Marc Auslander]

Dave Sherohman  writes:

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

I don't know about "recommended" but could you put your own menu
entry into /etc/grub.d and make it the default?

Re: Banishing UUIDs from grub

[David Wright]

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.

Re: Banishing UUIDs from grub

[Dave Sherohman]

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

Re: Banishing UUIDs from grub

[Stephan Seitz]

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 |


smime.p7s
Description: S/MIME cryptographic signature

Re: Banishing UUIDs from grub

[Michael Lange]

Hi,

On Thu, 18 Jan 2018 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?

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

Banishing UUIDs from grub

[Dave Sherohman]

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