[opensuse-factory] renaming of my hard-drives
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. -- opensuse:tumbleweed:20161022 Qt: 5.7.0 KDE Frameworks: 5.26.0 kf5-config: 1.0 KDE Plasma: 5.8.2 Kernel: 4.8.4-1.g402d8c1-default Linux User 183145 working on a Pentium IV . -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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[%<M_tQ<IFlPHn<xxh UNqm^j5|*aD$G)r@E#lUB;@dC!x#km"OXQulhaaj>+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
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 -- "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 Mon, 24 Oct 2016 06:46:44 -0400 Felix Miata <mrmazda@earthlink.net> 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
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.
You don't have any drives named sda, sdb and sdc? -- Per Jessen, Zürich (11.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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.
This could be caused by a new driver in your kernel, that, say, recognizes "USB" drives before those other drives. This is why it is best to build your own kernel and build-it those drivers that your system uses -- then they don't change order unless you add drives -- which is another problem. That one I worked around, at one point by having a boot.fstab-select script that chose a correct fstab based upon what disk it had booted from -- not the most elegant solution, but it worked. The other methods have their shortcomings and requirements as well. I list those methods and reasons I don't use them next. 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), and names require that you have a booted OS running that can interpret the names (usually hidden from users via the pre-boot-OS that boots off of ram disk and non-deterministically loads the drivers which change order -- causing the problem you see). The only way to fix their order, that I've seen it to build them into your kernel. Network devices can also come up at random and be renamed depending on udev's default rules, but its best there to rename the devices based on their HW address, as that's built into the HW and can't change. So I build disk handling SW for my boot disks into my kernel, and rename network interfaces during boot. Eventually, (for better or worse), all of those methods for booting will become obsolete as OS's start ubiquitously start using the "extended BIOS" boot mechanism, then all bets are off... ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* 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). Philipp -- 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
On 10/24/2016 07:59 PM, 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), and names require that you have a booted OS running that can interpret the names (usually hidden from users via the pre-boot-OS that boots off of ram disk and non-deterministically loads the drivers which change order -- causing the problem you see).
You're being ridiculous and outrageous again, Linda. Yes its possible to change a UUID, but why would you? Why would you want to in the normal course of events? In a boundary case where you had to update a new drive to look *exactly* like the old drive all the way down to the UUID, yes I can see that, but its not part of the 'everyday' or the 'normal course of events'. Certainly not part of a normal, regular upgrade cycle. Yes you can chnage names, but that's an acto of volition as well[1]. And as for reading the labels on disks, partitions and file systems, yes, that will take -- shock/horror -- *software*. It might e 'fdisk', it might be the second stage boot after the MBR; sometimes the BIOS can read disk labels. Its all just in the software. Never say Never. [1] Here's an example. I have a BtrFS boot partition and I want to change it to Ext4. So I make a new partition (easy with LVM) and rsync the files across. The original partition is labelled ROOT, the new ROOT4. I test boot editing the command line since my grub.config uses "by-label', so its easy to do -- 'e' and 'f10' and all that. All goes well. So I rename ROOT4->ROOT and ROOT->OLDRT. I don't even have to edit the on-disk grub.cfg or do a new mkinitrd. A serious change made simple. But not a common occurrence. KISS. Oh, and document everything you do as you go along. -- Experience teaches only the teachable. Aldous Huxley (1894 - 1963) -- 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 <opensuse@antonaylward.com>:
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 10/25/2016 08:33 AM, Olaf Hering wrote:
Am 25. Oktober 2016 12:53:59 MESZ, schrieb Anton Aylward <opensuse@antonaylward.com>:
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. 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. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- 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 <opensuse@antonaylward.com>:
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 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 <opensuse@antonaylward.com>:
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.
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. -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. --John Maynard Keynes -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 <opensuse@antonaylward.com>:
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 Tue, Oct 25, Anton Aylward wrote:
On 10/25/2016 08:33 AM, Olaf Hering wrote:
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.
The example you gave earlier mentioned "copy rootfs from A to B". I do that alot on i386-pc with plain partitions and chainloading. While it looks easy to reference everything by-label and expect the copy to work, both grub2 and dracut will ruin your day. Typically /etc/fstab is the one and only place that describes how filesystems are referenced (label,uuid,id,path,kernel name). Thats a decision the installer and the admin make. For my own purpose label is good because its obvious and easy to remember. When dracut creates an initrd it includes values for certain settings in case the kernel cmdline lacks the respective override setting. Instead of using the fstab value for a mount point verbatim it enforces uuid for root=. See the output of dracut as reference. When grub creats its grub.cfg it enforces a global kernel cmdline. Thats probably fine, but each kernel also gets a root=UUID=val. This is wrong because in the end only the initrd cares about that root= option and the initrd already has the correct value. Also the code to search for the partition with the kernel/initrd enforces uuid. Here the values from fstab have for be used verbatime in case of label/uuid. For id/path/kernel name grub has to use some other method because such info is typically not available at firmware level, so uuid would be fine. When grub installs its first stage loader it probably also uses uuid to find the second stage. But I have not checked the code what really happens in that case. It most likely differs between the various supported firmware variants. For short: one can not just copy a partition around and expect a properly configured root filesystem to work. Your example may work because grub is unchanged and grub loads the kernel from btrfs and passes root=ext4 to that kernel. Olaf
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 Tue, 2016-10-25 at 09:45 -0400, Anton Aylward wrote:
On 10/25/2016 08:33 AM, Olaf Hering wrote:
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'm still experimenting with Dracut.
Check out the "persistent_policy" option in dracut.conf(5). Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 Tue, Oct 25, 2016 at 8:58 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
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.
I didn't know that. It's a nice feature. Greg -- 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: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)
participants (11)
-
Anton Aylward -
Carlos E. R. -
Constant Brouerius van Nidek -
Felix Miata -
Graham P Davis -
Greg Freemyer -
L.A. Walsh -
Martin Wilck -
Olaf Hering -
Per Jessen -
Philipp Thomas