On 10/24/2016 06:29 AM, Carlos E. R. wrote:

On 2016-10-24 12:23, Constant Brouerius van Nidek wrote:

...

With the last update or the one before I found that my 3 harddrives have been renamed. What was sda, sdb and sdc is now sde,sdf and sdg. I have done nothing with my drives and there seems to be no harm done but I wonder if somebody else has had this change too.

Well, that's why we were told years ago to NOT use such names as sda, sdb etc in our config files and scripts. They can change.

While I understand UUIDs, they are about as memorable as 64-charectore passwords. I mean when you have 7wqSb}jAQR2ew)\g&lW^J|,ZE;M?HwMM{P^aL/T+z\(kT7E6rVl|-fw}xqW.,b6Q LDTf=h'cD2DL',swpZzwL?*,zOa?j(4E`)w&Me9(FOkMP0[%+Zrq,^Gx)?+9Qz#$ShQ~h)9 it may be great for security (assuming you're not dealing with one of those crippled sites that won't accept non-alpha or truncates to 8 characters), but its not exactly memorable.. So I LABEL everything. let's face it, /dev/disk/by-label/BOOT /dev/disk/by-label/HOME /dev/disk/by-label/LOCAL /dev/disk/by-label/ROOT /dev/disk/by-label/SWAP /dev/disk/by-label/TMP /dev/disk/by-label/USERSHARE are more intelligible than /dev/sda1 /dev/dm-10 /dev/dm-6 /dev/dm-2 .... Or, for that matter, PCI bus address & sub-address or SCSI address. Labelling drives is a little more than labelling partitions or file systems. That's not to depreciate partition names, they are better than Disklabel/1, Disklabel/2 ... But then again, things like scsi-SATA_WDC_WD10EACS-00Z_WD-WCASJ2195141 scsi-SATA_ST31000528AS_9VP4P4LN scsi-SATA_OCZ-VECTOR_OCZ-0974C023I4P2G1B8 are immensely useful when trying to relate the s/w side to the hardware side. Just not easy to remember! But look at this way. Ultimately all those names and labels are symlinks. In /usr/lib/udev/rules.d you will find a file 60-persistent-storage.rules which defines the way symlinks are dynamically set up on boot. All those /dev/disk/{by-id,by-uuid,by-label,by-path} symlinks are set up. Based on that you can add your own, local, custom set of symlinks for the drives with /etc/udev/rules.d/60-persistent-storage.rules One reason I use LVM is that it makes persistent names and mapping more apparent. You can see mention of this, in passing, in the LVM documentation. -- Without friends no one would choose to live, though he had all other goods. -- Aristotle (384 BC - 322 BC), Nichomachean Ethics -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 24 Oct 2016 06:46:44 -0400 Felix Miata wrote:

Constant Brouerius van Nidek composed on 2016-10-24 17:23 (UTC+0700):

...

With the last update or the one before I found that my 3 harddrives have been renamed. What was sda, sdb and sdc is now sde,sdf and sdg. I have done nothing with my drives and there seems to be no harm done but I wonder if somebody else has had this change too.

It's not terribly unusual. Things that come to mind that can cause it: 1-PATA vs. SATA controller or HD device reordering in BIOS 2-switching SATA cable connectors around 3-different kernel 4-addition of USB storage device readers 5-adding a disk controller card 6-booting with USB storage connected and turned on

I've often noticed this when making fresh installations and it would seem that (3) could be the explanation for it as none of the others fit. I've also noticed that on fresh installs, the boot-loader locations immediately after installation appear to be different to those I'd set during the installation. This could be something that has appeared with Leap; I'll have to take notes the next time I try a new install and make a report if it happens again. -- Graham Davis, Bracknell, Berks., UK. openSUSE 42.1; KDE Plasma 5.8.2; Qt 5.7.0; Kernel 4.8.4; AMD Phenom II X2 550 Processor; Sound: ATI SBx00 Azalia (Intel HDA); Video: nVidia GeForce 210 (Driver: nouveau) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10/25/2016 04:43 AM, Philipp Thomas wrote:

* L.A. Walsh (suse@tlinx.org) [20161025 02:11]:

...

This is why it is best to build your own kernel and build-it those drivers that your system uses

No, it's not! The bst way is either labeling your drives and use /dev/disk/by-lable or use /dev/disk/by-id like we used to in the past. It's this simple. No need to compile your own kernel (and recompile with each /update).

+1 Adding labels is easy and straight forward. -- The Romans made their bridge-builders stand under their bridges. Is there a good reason why the software engineers of today don't have to entrust their lives to their code? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 25. Oktober 2016 12:53:59 MESZ, schrieb Anton Aylward :

I don't even have to edit the on-disk grub.cfg or do a new mkinitrd.

Since both grub2 and dracut ignore system settings (they enforce by-uuid) its helpful to rerun mkinitrd, grub-mkconfig and grub-install to update their view on the system. Unless of course the uuid of the old filesystem is applied to the new filesystem. Ola2 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2016-10-25 15:45, Anton Aylward wrote:

On 10/25/2016 08:33 AM, Olaf Hering wrote:

...

Am 25. Oktober 2016 12:53:59 MESZ, schrieb Anton Aylward :

...

I don't even have to edit the on-disk grub.cfg or do a new mkinitrd.

Since both grub2 and dracut ignore system settings (they enforce by-uuid) its helpful to rerun mkinitrd, grub-mkconfig and grub-install to update their view on the system.

Could you please expand/document/reference that assertion.

I've been using, for example, grub2, for many years and booting with "by-label" in the config.

The kernel parameters in grub use label, yes, but the lines belonging to grub use uuid.

I'm still experimenting with Dracut. I have no argument with the permanence and uniqueness of UUDI, despite what Linda says, but my point about intelligibility of those long strings holds.

You can change manually the uuid, and write a label instead, while it is a uuid. Or use an hybrid. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-10-25 16:08, Anton Aylward wrote:

On 10/25/2016 09:55 AM, Carlos E. R. wrote:

...

On 2016-10-25 15:45, Anton Aylward wrote:

...

On 10/25/2016 08:33 AM, Olaf Hering wrote:

...

Am 25. Oktober 2016 12:53:59 MESZ, schrieb Anton Aylward :

...

I don't even have to edit the on-disk grub.cfg or do a new mkinitrd.

Since both grub2 and dracut ignore system settings (they enforce by-uuid) its helpful to rerun mkinitrd, grub-mkconfig and grub-install to update their view on the system.

Could you please expand/document/reference that assertion.

I've been using, for example, grub2, for many years and booting with "by-label" in the config.

The kernel parameters in grub use label, yes, but the lines belonging to grub use uuid.

I'm sorry but that doesn't make sense to me. Could you say that differently please. Perhaps illustrate/example.

/other/Gestor/boot/grub2/custom.cfg: menuentry 'Gestor (por uuid)' --id cer-gestor-001 { insmod part_gpt insmod ext2 set root='hd1,gpt2' if search --no-floppy --fs-uuid --set=root 943d650b-ea9c-4fbd-9d2c-993abae7655b ; then chainloader +1 else echo Could not find this OS instance, will not boot (3) sleep 1 fi } The "set root" has to use uuid. /other/Gestor/boot/grub2/grub.cfg: ### BEGIN /etc/grub.d/10_linux ### menuentry 'openSUSE Leap 42.1' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-943d650b-ea9c-4fbd-9d2c-993abae7655b' { savedefault load_video set gfxpayload=keep insmod gzio insmod part_gpt insmod ext2 set root='hd0,gpt2' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2' 943d650b-ea9c-4fbd-9d2c-993abae765 else search --no-floppy --fs-uuid --set=root 943d650b-ea9c-4fbd-9d2c-993abae7655b fi echo 'Loading Linux 4.1.27-24-default ...' linux /boot/vmlinuz-4.1.27-24-default root=UUID=943d650b-ea9c-4fbd-9d2c-993abae7655b resume=/dev/disk/by-label/Swap_0 splash=verbose console=tty1 showopts echo 'Loading initial ramdisk ...' initrd /boot/initrd-4.1.27-24-default } Same here. Only in the line: "linux /boot/ ..." you can replace "root=uuid=..." with the equivalent for labels. Like the "resume".

...

...

I'm still experimenting with Dracut. I have no argument with the permanence and uniqueness of UUDI, despite what Linda says, but my point about intelligibility of those long strings holds.

You can change manually the uuid, and write a label instead, while it is a uuid. Or use an hybrid.

I'm unclear by the "while it is a uuid". Either you've changed it or not.

uuid=943d650b-ea9c-4fbd-9d2c-main_gestor Long enough to be unique. You could replicate the partition, keep the "u-label", but change the random part on the left. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-10-26 09:00, Olaf Hering wrote:

When grub installs its first stage loader it probably also uses uuid to find the second stage.

No, it is hardcoded. LBA location, IIRC. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-10-25 01:59, L.A. Walsh wrote:

Others will tell you to use UUIDS or other names, but those can change and fail as well. (UUID's can change and be changed by the user),

No, UUIDs can not change on their own. You can choose UUID, ID, Label, or path. Each method has advantages and disadvantages, so the admin can choose the best method. Also on GPT disks there are partLabels and partUUIDs. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-10-25 15:27, Greg Freemyer wrote:

On Tue, Oct 25, 2016 at 8:58 AM, Carlos E. R. <> wrote:

...

You can choose UUID, ID, Label, or path. Each method has advantages and disadvantages, so the admin can choose the best method.

Also on GPT disks there are partLabels and partUUIDs.

I didn't know that. It's a nice feature.

Telcontar:~ # l /dev/disk/by-[TAB][TAB] by-id/ by-label/ by-partlabel/ by-partuuid/ by-path/ by-uuid/ Telcontar:~ # l /dev/disk/by- I found out when looking at the fields in "lsblk" command. I think they could stay unchanged in case of formatting. I'm unsure. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)