On 2014-04-02 10:10 (GMT+0200) Olaf Hering composed:

On Wed, Apr 02, Sascha Peilicke wrote:

...

our default grub2 configuration always uses UUIDs. For several reasons, I'd like to use labels instead but when looking at the scripts that generate /boot/grub2/grub.cfg it looks like UUID is more or less the only thing that works. So before I start tinkering with the scripts I'm curious if there is some prior art around already.

bnc#870321, if that counts.

Seriously? This is an *open* SUSE mailing list, not a Novell list, not a SLES list, not a SLED list. <quote> <red> Access Denied </red> <large><large> You are not authorized to access bug #870321. </large></large> Please press Back and try again. </quote> And, thanks not for the clickable URL that produces it: https://bugzilla.novell.com/show_bug.cgi?id=870321 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Apr 02, 2014 at 02:08:36PM +0200, Yamaban wrote:

On Wed, 2 Apr 2014 09:45, Sascha Peilicke wrote:

...

our default grub2 configuration always uses UUIDs. For several reasons, I'd like to use labels instead but when looking at the scripts that generate /boot/grub2/grub.cfg it looks like UUID is more or less the only thing that works. So before I start tinkering with the scripts I'm curious if there is some prior art around already.

A warning: If you use /dev/disk/by-label/* be prepared for the case where one has a internal disk, and plugs in a 'old'-system disk either internal or external and does a reboot.

That's the same with UUID, so by switching to LABEL it does not change.

I'm using /dev/disk/by-id/ata-{disk-id}-part{part-no}, for me thats readable, unique (disk-id contains serial-no of disk), and safe in handling.

If it works for you, be happy. But of course the default was not changed for fun. The feature request to use UUID list 8 bugreports where the old setup did not work. Sorry, some are internal so I will not even try to post the links here. Regards, Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Apr 02, Ruediger Meier wrote:

If there are good reasons then please explain them.

There has to be some default. UUID is, for many setups, the one which will cause the least trouble. If VMs get moved around, or if the underlying hypervisor changes slightly, by-id or by-path will change. The VM disk will remain the same, so initrd and tools parsing fstab will continue to find their block devices. grub may fail because its device.map can only cope with whole disks, which do not have a UUID. So at least this part has to be adjusted if the "worst case" actually happens. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Apr 02, 2014 at 05:10:20PM +0200, Olaf Hering wrote:

UUID is, for many setups, the one which will cause the least trouble.

Grub may fail because its device.map can only cope with whole disks, which do not have a UUID.

Partition tables have a "Disk Signature" (MBR) or "Disk UUID" (GPT). Regards, Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Apr 02, Andrey Borzenkov wrote:

How exactly MBR signature or GPT GUID help here?

Not at all. At least grub has no concept of "use partition where the files actually reside". Instead it has some odd device.map. grub2 is (most likely) not any better. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

В Wed, 2 Apr 2014 18:36:51 +0200 Arvin Schnell пишет:

On Wed, Apr 02, 2014 at 06:23:08PM +0200, Olaf Hering wrote:

...

On Wed, Apr 02, Andrey Borzenkov wrote:

...

How exactly MBR signature or GPT GUID help here?

Not at all. At least grub has no concept of "use partition where the files actually reside". Instead it has some odd device.map.

grub2 is (most likely) not any better.

I didn't say that grub2 can handle those IDs.

But in general, why shouldn't it be possible to tell a bootloader to install on the disk with a specific ID?

I'm afraid I lost track which problem is discussed here. It started with LABEL being less reliable than UUID for partition reference and by-id having potential problem after cloning disk (or disk replacement in general). How exactly using MBR signature/GPT GUID fits into it?

That would be nice since the ID does not change like the by-id links sometimes do.

by-id links change only if disk changes. In which case as I already said you most likely will at least install new partition table on it which will have new signature. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-04-02 19:25 (GMT+0200) Olaf Hering composed:

Andrey Borzenkov wrote:

...

by-id links change only if disk changes. In which case as I already said you most likely will at least install new partition table on it which will have new signature.

Not very likely here. Cloning a disk here usually means literal cloning, followed by assigning new UUIDs, relabeling, and adjusting references to them in device.maps, bootloader menus and fstabs. The MBR signature does not get changed except in the unusual case tjat I find a reason to need to, in which case I do it manually.

They change also if the "disk firmware" changes. Which can be either the enclosure providing the disk (USB, Firewire, eSATA, IDE), or it can be the hypervisor backend driver. by-id or by-path is certainly not reliable.

And like UUID, not memorable, unlike humanly chosen labels and device names.

For bootloader configuration there is not much one can do, other than hoping for to yet be written smartass bootloader configurator.

Awareness helps in coping. hostonly="no" in dracut.conf can help. Cross-distros, I've had too many encounters with cmdline root= being disregarded.

For mounting the root, data, resume and dump partitions its up to the admin to put his prefered mount variant into fstab. And all tools have to follow that decision. grub2 fails to follow.

+1

And in fact, grub2 does not have to bother with root= at all. Instead it has to leave everything related to root,data,resume,dump partition alone. The only place where such settings matter is the initrd. As such its up to mkinitrd and dracut to grab the value from fstab and put it inside the initrd in case no root=,resume=,etc was given on cmdline.

Do people really ever do a resume right after updates that include new initrd(s)? OTOH, does YaST-driven bootloader re-configuration ever omit root= or *resume* from a stanza?

mkinitrd has some code to do that, unfortunately it defaults to by-id.

/boot/grub/device.map is easily enough corrected manually.

dracut just fails hard last time I looked at that topic. It expects everything in cmdline. bnc#855258 "initrd fails

Again, no thanks for a clickable URL to an inaccessible non-openSUSE bug: https://bugzilla.novell.com/show_bug.cgi?id=855258 This is an *open* SUSE mailing list, not a Novell list, not a SLES list, not a SLED list. <quote> <red> Access Denied </red> <large><large> You are not authorized to access bug #870321. </large></large> Please press Back and try again. </quote> -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org