[opensuse-factory] grub2 vs. by-label
Hi guys, 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. -- Viele Grüße, Sascha Peilicke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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, 2 Apr 2014 09:45, Sascha Peilicke <saschpe@...> 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. He will have two of each label if he has used the same disk layout for both, the old and the new disk, of the old takes priority over the new. it's either uefi / bios or later udev or kernel that will ruin your day. NOT funny. Srsly. SHIT. 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. UUID gives me that M$-Windows feel, in terms of never explain what you really do, and fuck over the user as much as possible. As I said, a warning. Be careful. Think ahead, before lamenting later. Best wishes to you, - Yamaban. -- 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 <saschpe@...> 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, <aschnell@suse.de> 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 Wednesday 02 April 2014, Arvin Schnell wrote:
On Wed, Apr 02, 2014 at 02:08:36PM +0200, Yamaban wrote:
On Wed, 2 Apr 2014 09:45, Sascha Peilicke <saschpe@...> 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.
So now dd'ing one disk to another one could mount the other disk next time like it was in times when we had only /dev/sdx? AFAIR it was also not only fun to use /dev/disk/by-id/.
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.
So why?
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.
If there are good reasons then please explain them. cu, Rudi -- 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
В Wed, 2 Apr 2014 17:10:20 +0200 Olaf Hering <olaf@aepfle.de> пишет:
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.
The worst thing is, booting will continue to work just fine but next time someone needs to reinstall bootloader it will fail. Fortunately, it happens now far less often in 13.1 and above; unfortunately due to defaults during openSUSE installation such failure will be fatal and render system unbootable. YaST support for relocating system to different disk is long missing. I learned this problem hard way when my disk failed and I had to copy system onto replacement HDD. -- 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, <aschnell@suse.de> 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
В Wed, 2 Apr 2014 17:59:56 +0200 Arvin Schnell <aschnell@suse.de> пишет:
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).
a) when you relocate data to new disk you usually copy file system content; MBR signature is different or disk UUID is different b) the problem with grub (or probably every bootloader for that matter) is that it needs OS device to indicate where bootloader is installed. How exactly MBR signature or GPT GUID help here? -- 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
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? That would be nice since the ID does not change like the by-id links sometimes do. Regards, Arvin -- Arvin Schnell, <aschnell@suse.de> 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
В Wed, 2 Apr 2014 18:36:51 +0200 Arvin Schnell <aschnell@suse.de> пишет:
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 Wed, Apr 02, 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.
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. For bootloader configuration there is not much one can do, other than hoping for to yet be written smartass bootloader configurator. 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. 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. mkinitrd has some code to do that, unfortunately it defaults to by-id. dracut just fails hard last time I looked at that topic. It expects everything in cmdline. bnc#855258 "initrd fails to boot with with empty /proc/cmdline" Olaf -- 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
Am 02.04.2014 14:08, schrieb Yamaban:
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 did change slightly amost every two years for the last 10 years, due to "bug fixes" (where backwards compatibility was screwed). No, thanks. I'd rather use by-label (and yes, I re-label my filesystems before putting the old disk onto the "backup" stash. So making sure by-label works is something I agree with :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Wed, 02 Apr 2014 09:45:38 +0200 Sascha Peilicke <saschpe@mailbox.org> пишет:
Hi guys,
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.
I guess the most generic solution would be to check whether root=XXX already present in kernel arguments and skip adding it in this case. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Andrey Borzenkov -
Arvin Schnell -
Felix Miata -
Olaf Hering -
Ruediger Meier -
Sascha Peilicke -
Stefan Seyfried -
Yamaban