How to prevent /sda /sdb changes between boots?

[midnite]

I am going to install Gentoo Linux onto an old hardware, which motherboard is having both IDE and SATA hard drives. I have two IDE and one SATA hard drives connected, and plan to do RAID on them.

However I notice a problem: The hard drive mapped to /dev/sda changes on every boot!

I was searching for answers from the Internet. And I found Persistent Device Names could be a solution. However I am worrying about will it run into compatibility problems system wide? In addition, it is quite inconvenient (because the names are quite long) unless I can use /dev/disk/by-label. But it seems by-label cannot refer to /dev/sda and /dev/sdb - only /dev/sda1 is possible. Moreover, for my old hardware that uses BIOS, I think I can only use MBR, but not GPT. How to change the disk labels in the MBR environment?

On the other hand, the ideal solution in my mind would be, the /dev/sda is mapped to the same hard disk in every boot. Imaginary, this can be achieved by saving a file named "bootmap" on the hard disk. And "/sda" is written in the "bootmap" file. While the system boots, if it finds "/sda" inside "bootmap", the drive is mapped to /dev/sda. If it finds "/sdb", it maps to /dev/sda. And so on. (But I know it is probably not so ideal.)

So, how to avoid the mapping of /dev/sda changes from boot to boot?

As an alternative, way to edit the label would be nice too. - givn that it wont get a compatibility issue anywhere.

[mv]

There is no possibility to guarantee consistency (it might be even your BIOS which sets the order different with each booting), so you have to go with PARTUUID, UUID, or LABEL. There's 3 things involved: The bootloader, the kernel finding the root partition, and fstab.

For none of these 3, I can imagine why you would need the harddisk (sdb, in contrast to the partition sdb1) unless you have a very specific setup with lvm.

• If you use grub2 as the boot loader, you can use the "search" command to obtain the correct partition (look e.g. at the file grub-mkconf generates for you).
• To let the kernel find the correct root partition, use root=PARTUUID=... (use the blkid program to find out the PARTUUID). (In theory, it is also possible to use a ramdisk and root=UUID=..., but this is much more complicated to setup).
• In fstab, finally, you can use LABEL, UUID, or some path from /dev/disk-by/... How you set the label depends on the filesystem. On encrypted filesystems, you can usually not set it. For practically every other filesystem there are filesystem specific commands to set it.

[szatox]

am going to install Gentoo Linux onto an old hardware, which motherboard is having both IDE and SATA hard drives. I have two IDE and one SATA hard drives connected, and plan to do RAID on them.

like in "i'm going to slow my SATA drive down to IDE range"?

You don't have to know or care what drive is being assigned what letter unless you're doing something very low level, like formatting it.
1) use labels or UUIDs. Either one will work, but labels are more human-friendly and UUIDs are less likely to cause a collision in the future. >>man tune2fs<< (or it's counterpart for other filesystems) is your friend.
2) use LVM. It will use UUIDs internally and then let you name the logical volumes.

Finally, you have some funny setup. Usually boot drive would be mapped to sda. Since it's not your case... Well, forget it. You could play with compiling hard disk controlers statically or as modules if you really want your system to "find" and use one of them first, but the effort may not be worth the result.

[NeddySeagoon]

midnite,

Use root=PARTUUID on your kernel command line and UUID= in /etc/fstab.
Filesystem UUID requires the userspace mount command, which in turn requires an initrd to use UUID to mount root.

Be aware that PARTUUID can be fragile with MSDOS partition tables if it is pointed to a logical partition.

[krinn]

But it seems by-label cannot refer to /dev/sda and /dev/sdb - only /dev/sda1 is possible.

label is set on a fs, and everyone use a partition for a disk, but you can just use a whole disk without one (like an usbkey). But there's no real point in having sda instead of sda1, on both label will works.

Moreover, for my old hardware that uses BIOS, I think I can only use MBR, but not GPT. How to change the disk labels in the MBR environment?

because label is set on fs, it is a fs tool that will set it and not a partition tool, for swap, you have none to my knowledge and label is set while formatting the swap file (that is not a problem as you don't care about swap content) with mkswap -L label
for ext? fs, it also use -L label with mkfs.ext? but you have a tool if you don't want destroy your fs content, e2label device label
for other fs, i don't know, i don't use anything except ext? fs.

[frostschutz]

Moreover, for my old hardware that uses BIOS, I think I can only use MBR, but not GPT.

That's usually not a problem. GPT looks like a msdos partition table to things that are not GPT aware. If your BIOS is looking for a boot flag you can set that too (in parted, disk_set pmbr_boot on).

As for device name changes... it might work better if you use built-in drivers instead of modules. Or the other way around, modules might work better if you load them in a specific order, possibly with delay in between to allow the kernel to detect stuff.

But in general you should not rely on device names for anything, ever. UUID all the way.

[midnite]

Thanks all guys for the replies!!

I studied Writing udev Rules and had a few trials and errors. As it teaches us to change /dev/sdb to /dev/my_spare_disk by the udev rule KERNEL=="hdb", NAME="my_spare_disk", I created the rule KERNEL=="sd?", ATTRS{model}=="TOSHIBA MK1034GS", NAME="sdz", and run udevadm test /block/sda to test it. However I am getting the error kernel device nodes can not be renamed. Someone on web said we could change the device name /dev/sd*, but it is not possible now.

However, by an inspiration, I found that I can simply mv sda sdz! How amazing! But it's followed by another problem, the symlinks do not follow this change. So I have two questions now ...

1. How to change all symlinks that was originally pointed to /dev/sda to /dev/sdz?
2. Will there be a problem by these renames? I have tried rename, mount, and list without problems, it seems.

   Code: Select all

   mv /dev/sda1 /dev/sdz1
   mount /dev/sdz1 /mnt/custom
   ls /mnt/custom

=============================================

There is no possibility to guarantee consistency (it might be even your BIOS which sets the order different with each booting), so you have to go with PARTUUID, UUID, or LABEL.

As for device name changes... it might work better if you use built-in drivers instead of modules. Or the other way around, modules might work better if you load them in a specific order, possibly with delay in between to allow the kernel to detect stuff.

But in general you should not rely on device names for anything, ever. UUID all the way.

But all the manuals were telling us to use /dev/sda and /dev/sdb1 and so on. I heard from someone that in motherboards having both IDE and SATA, these indeterministics happens. But in normal multi-disk setups, the sequence of sda and sdb should be quite static, isn't it?

like in "i'm going to slow my SATA drive down to IDE range"?

Thanks for remind. I will think about how the setup going to be.

1) use labels or UUIDs. Either one will work, but labels are more human-friendly and UUIDs are less likely to cause a collision in the future. >>man tune2fs<< (or it's counterpart for other filesystems) is your friend.

If not using sda or sdb, I guess I will use by-id for the entire disk, and by-label for the partitions.

Use root=PARTUUID on your kernel command line and UUID= in /etc/fstab.
Filesystem UUID requires the userspace mount command, which in turn requires an initrd to use UUID to mount root.

Be aware that PARTUUID can be fragile with MSDOS partition tables if it is pointed to a logical partition.

Thanks NeddySeagoon. For sure I will take these settings when I do those configurations.

because label is set on fs, it is a fs tool that will set it and not a partition tool, for swap, you have none to my knowledge and label is set while formatting the swap file (that is not a problem as you don't care about swap content) with mkswap -L label
for ext? fs, it also use -L label with mkfs.ext? but you have a tool if you don't want destroy your fs content, e2label device label
for other fs, i don't know, i don't use anything except ext? fs.

Thanks krinn. Yes I have also found a few commands to change the labels, finally. Such as e2label and ntfslabel.

[frostschutz]

I found that I can simply mv sda sdz!

This idea will, sooner or later, cause you to suffer utter and complete data loss. It will confuse everything and everyone. Don't do it.

You do not need custom udev rules to get static device names, you find them by default in /dev/disk/by-(uuid,label,id,...)

But in normal multi-disk setups, the sequence of sda and sdb should be quite static, isn't it?

In practice the sd* names do not change for many people. However: you should never rely on it. Strange things can happen, e.g. if your hard disk takes longer to spin up than expected one day... or if it's detected late due to a cable problem. It doesn't take much change in timing and whoops, disk letters are the other way around.

[midnite]

I found that I can simply mv sda sdz!

This idea will, sooner or later, cause you to suffer utter and complete data loss. It will confuse everything and everyone. Don't do it.

You do not need custom udev rules to get static device names, you find them by default in /dev/disk/by-(uuid,label,id,...)

But in normal multi-disk setups, the sequence of sda and sdb should be quite static, isn't it?

In practice the sd* names do not change for many people. However: you should never rely on it. Strange things can happen, e.g. if your hard disk takes longer to spin up than expected one day... or if it's detected late due to a cable problem. It doesn't take much change in timing and whoops, disk letters are the other way around.

So, in conclusion, no matter how the sda sdb switches, leave them alone. We should use by-id and by-label all the way. Isn't it?

PS - btw that machine is still not setup yet. It is still booted up by the sysresccd, so all the drives were not mounted in the first place

[szatox]

PS - btw that machine is still not setup yet. It is still booted up by the sysresccd, so all the drives were not mounted in the first place

That might turn out to be the solution to your problem with names.
Boot drive tends to be considered "the first": (hd0), /dev/sda, and so on.
Still, labels are so easy to use there is hardly any point in using names (even if we leave possible inconsistencies and resulting from them failures aside)

[Tony0945]

The IDE drives should be named /dev/hda /dev/hdb et cetera. Your udev rules (or the default rules) are changing them from the default names. Besides, as was mentioned, loading the drivers as modules creates a race condition. Even with the default udev rules, the names should be consistent if the drivers are built in. I have one system with Gentoo on the IDE drive and XP on the SATA drive. The boot drive is /dev/hda. The XP drive is /dev/sda and there is never a confusion.

EDIT:
You need CONFIG_IDE=y (DEPRECATED) to get the /dev/hd* names.

Unless you mobo doesn't support SATA, buy a new drive. You can get a pretty big SATA 7200RPM drive or a medium size SSD for around $100

[krinn]

have a look viewtopic-t-1007788.html it might help you figure out everything.

the deprecated ide config is not really a solve, except if you have no dev manager, as last time i saw, u(eu)dev fail to work with it enable.

[NeddySeagoon]

midnite,

In summary, you cannot prevent sda, sdb and friends swapping around.
You don't have to use these kernel names to find your filesystems and block devices.
UUID is supposed to be unique.
Labels can be unique, but its up to you to manage, including any USB sticks you may connect.

/sbin/blkid is your friend

[steveL]

As for device name changes... it might work better if you use built-in drivers instead of modules. Or the other way around, modules might work better if you load them in a specific order, possibly with delay in between to allow the kernel to detect stuff.

But in general you should not rely on device names for anything, ever. UUID all the way.

PARTUUID is much better than UUID, certainly for (real_)root=, as the kernel decides, so it requires nothing from userland.

Not knocking UUID later, but if PARTUUID suffices, I'd prefer it.

But all the manuals were telling us to use /dev/sda and /dev/sdb1 and so on. I heard from someone that in motherboards having both IDE and SATA, these indeterministics happens. But in normal multi-disk setups, the sequence of sda and sdb should be quite static, isn't it?

It will be if you build-in the modules for the rootfs hard-disk controller to the kernel, as frostschultz mentioned.
Unless you're doing something with USB (in which case you want rootwait, and someone else's experience) sda will always be sda with the module built-in (=y not: m).

Use root=PARTUUID on your kernel command line and UUID= in /etc/fstab.
Filesystem UUID requires the userspace mount command, which in turn requires an initrd to use UUID to mount root.

Be aware that PARTUUID can be fragile with MSDOS partition tables if it is pointed to a logical partition.

Thanks NeddySeagoon. For sure I will take these settings when I do those configurations.

You're missing the point: that does what you need and means you don't have to worry about the rest.

Definitely do not monkey around with moving device nodes about.

[frostschutz]

PARTUUID is much better than UUID, certainly for (real_)root=, as the kernel decides, so it requires nothing from userland.

Not knocking UUID later, but if PARTUUID suffices, I'd prefer it.

That's fine, PARTUUID is UUID too... it just had to be named differently to avoid confusion with filesystem and other content-based UUIDs.

Partitions have UUIDs, LVM PV have UUIDs, MDADM RAID have UUIDs, and filesystems have UUIDs... as long as it's unique that's fine.

PARTUUID can bite you only if you do strange things, like cloning partition tables the wrong way (suddenly PARTUUID no longer unique), or auto formatting (/dev/urandom cryptswap) partitions based on PARTUUID. If you decide to use such a partition for something else, resize it, format it, etc. - the other UUIDs change automatically when you run mkfs/pvcreate/mdadm-create/etc. but PARTUUID stays the same until you delete, and re-create the partition.

But those are obscure cases. You could argue the same for filesystem UUIDs if you're silly enough to duplicate filesystems using dd.

It beats "random device names" by a long shot in either case. If you manage to make things go wrong with UUID, you only have yourself to blame.

[Tony0945]

the deprecated ide config is not really a solve, except if you have no dev manager, as last time i saw, u(eu)dev fail to work with it enable.

Not true. I just finished updating that system. it's running fine with the old IDE config and eudev.

[krinn]

the deprecated ide config is not really a solve, except if you have no dev manager, as last time i saw, u(eu)dev fail to work with it enable.

Not true. I just finished updating that system. it's running fine with the old IDE config and eudev.

Code: Select all

grep CONFIG_CHECK eudev-3.1.5.ebuild 
	CONFIG_CHECK="~BLK_DEV_BSG ~DEVTMPFS ~!IDE ~INOTIFY_USER ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 ~SIGNALFD ~EPOLL ~FHANDLE ~NET"

Well, that's not a proof it doesn't work, but a proof the ebuild is looking for it.
And your "it works with me" is not also a proof that it "fully" work. I don't remember the symptoms of the problem, but you might have a configuration that doesn't trigger any trouble with it.
Still that's not quiet safe.

[Tony0945]

Code: Select all

grep CONFIG_CHECK eudev-3.1.5.ebuild 	CONFIG_CHECK="~BLK_DEV_BSG ~DEVTMPFS ~!IDE ~INOTIFY_USER ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 ~SIGNALFD ~EPOLL ~FHANDLE ~NET"

I have this on all my boxes:

Code: Select all

gentoo ~ # cat /etc/portage/package.mask | grep eudev
>=sys-fs/eudev-1.99

The higher ebuilds always gave me trouble trying to pull in systemd. Maybe they fix bugs, but not bugs that affect me. Would really like to see more info re changes in new ebuilds. "Version bump" tells me nothing.

.
And your "it works with me" is not also a proof that it "fully" work. I don't remember the symptoms of the problem, but you might have a configuration that doesn't trigger any trouble with it.
Still that's not quiet safe.

The problem was that ithe IDE and SATA drives kept switching between sda and sdb between boots. With my solution, the IDE is always hda and the sata is always sda. It was also pointed out that the problem might disappear if the drivers were compiled into the kernel rather than modularized.

A major problem with udev and derivatives like eudev is that when a problem is encountered, the proposed solution is to throw out past practice and concoct some scheme involving unpronounceable names. Along with the aforementioned bias toward systemd.

[steveL]

That's fine, PARTUUID is UUID too... it just had to be named differently to avoid confusion with filesystem and other content-based UUIDs.

Ah I see, so you were referring to UUIDs in general; the trouble is in you're in a thread where this is context:

Use root=PARTUUID on your kernel command line and UUID= in /etc/fstab.
Filesystem UUID requires the userspace mount command, which in turn requires an initrd to use UUID to mount root.

Be aware that PARTUUID can be fragile with MSDOS partition tables if it is pointed to a logical partition.

(Quoting the whole thing, so the caveats are preserved, not in order to be pedantic.)

As such, advice simply to use UUID is very much open to misinterpretation; it was this I was avoiding.

It beats "random device names" by a long shot in either case. If you manage to make things go wrong with UUID, you only have yourself to blame.

Perhaps, though they are unwieldy, and that does lead to a certain non-attention to the actual identifier.[1]

Personally I prefer building in the modules for the hard-disk controller and rootfs; that way there is nothing random about "sda".
Only because I am compiling everything from source anyway, so why bother with more hassle and less speed, when it comes to things like initramfs, which ironically enough after all the pooh-poohing about shell from the nubskulls who tried to impose it on everyone, is pretty much always reliant on a shell script for startup.
In that case "ew, shell" (which we can't write anyway) became "just use a quick shellscript to set up your mounts(etc.)"

It's a custom machine, which is what I want for my development workstation, and why I chose Gentoo: compiling from source means access to source for everything, and trivial recompilation of needed libs, for example, and always being able to work with upstream vcs code, as needed.
So, since I have (and want) to configure and compile the kernel myself, part of bring-up is getting rootfs working to launch the rest. This is much less sweat than worrying about an initr(d|amfs) ime, and a root/(the rest) split is what makes the idea of tight linkage more than a pipe-dream, thus forming the basis for collaboration around early userspace; whatever the current installation might use (including another *nix.)
/ramble

==
[1] I sincerely doubt very much whether most users would ever notice any UUID changing under them, if the fstab (or whatever other config-file for eg autorun) were modified to match.

[NeddySeagoon]

steveL,

The fragile I had in mind with MSDOS PARTUUID is

Code: Select all

/dev/sda6: UUID="9657e667-5b60-f6a3-0391-65e6dcf662fa" TYPE="ext4" PARTUUID="0553caf4-06"

So we can write root=PARTUUID=0553caf4-06 in the boot loader configuration. Everything works as expected.

Now we delete /dev/sda5 from the partition table and the box won't boot because the root at /dev/sda6 has just become /dev/sda5, so its PARTUUID has changed.
With MSDOS PARTUUID, only the 0553caf4 is saved on the disk. The -XY is the partition number. That's fixed for primary partitions but logical partitions are stored as a linked list.

Keep your systemrescuecd handy if you want to try this at home.

[Tony0945]

Personally I prefer building in the modules for the hard-disk controller and rootfs; that way there is nothing random about "sda"..

I thought so! That's why I repeated the instruction to build in the kernel instead of modules. The deprecated CONFIG_IDE is only to separate hda from sda.

As I think on it, even on my machines that are only Sata and only libata, there never is a problem even though each has three hard drives and one boots from /dev/sdb!
The IDE may be a red herring here and the real problem is the use of libata as a module instead of built in.

[frostschutz]

The names are always random (first come, first serve), you can never rely on sda to be always first.

Usually that may be the case for most people but even so you can not rely on it. You still have to use UUID no matter what, even if your device names seem to be static.

Device names may change for various reasons. One is obviously hardware failure (if your sda goes bad, sdb will be the new sda next time you boot). Another is software updates, device name changes due to changes in kernel drivers has happened before and will probably happen again. Since there is no real guarantee regarding drive order in the kernel in the first place...