[solved]How do I force an external disk to be /dev/sdb?

[Irre]

With newer kernel my external usb-disk (often) shows up as /dev/sda in stead of /sdb!

I am using Lilo bootloader and risk destroying Windows boot-record on the real /dev/sda if I forget where I am!

Code: Select all

fdisk -l
Disk /dev/sda: 3,7 TiB, 4000787029504 bytes, 7814037167 sectors  <<<<<<<<<< EXTERNAL USB-disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 32C07481-F996-4DFC-B675-41BD291880B2

Device          Start        End    Sectors  Size Type
/dev/sda1        2048     206847     204800  100M BIOS boot
/dev/sda2      206848   21178367   20971520   10G Linux filesystem
/dev/sda3    21178368   42149887   20971520   10G Linux filesystem
/dev/sda4    42149888   84092927   41943040   20G Linux swap
/dev/sda5    84092928 4278396927 4194304000    2T Linux filesystem
/dev/sda6  4278396928 6375548927 2097152000 1000G Microsoft basic data


Disk /dev/sdb: 698,7 GiB, 750156374016 bytes, 1465149168 sectors  <<<<<<<< INTERNAL disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x005cd7ed

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdb1             2048     409599     407552   199M  7 HPFS/NTFS/exFAT
/dev/sdb2           409600  266649599  266240000   127G  7 HPFS/NTFS/exFAT
/dev/sdb3  *     266649600  309069823   42420224  20,2G a5 FreeBSD
/dev/sdb4        309069824 1465147119 1156077296 551,3G  5 Extended
/dev/sdb5       1464936448 1465147119     210672 102,9M  c W95 FAT32 (LBA)
/dev/sdb6        309071872  330043391   20971520    10G 83 Linux
/dev/sdb7        330045440  351016959   20971520    10G 83 Linux
/dev/sdb8        351019008  371990527   20971520    10G 83 Linux
/dev/sdb9        371992576  791422975  419430400   200G  7 HPFS/NTFS/exFAT
/dev/sdb10       791425024 1210855423  419430400   200G  7 HPFS/NTFS/exFAT
/dev/sdb11      1210857472 1422516223  211658752 100,9G  7 HPFS/NTFS/exFAT
/dev/sdb12      1422518272 1464936447   42418176  20,2G  7 HPFS/NTFS/exFAT

The external disk is /dev/sda and the internal is /dev/sdb! I think this is crazy!
My Lilo config:

Code: Select all

# /etc/lilo.conf
lba32
compact
boot = /dev/sdb <<<<<<<<<<<<<<<<<<<<<<<<<<
#
timeout = 100
vga = normal
prompt
menu-title="Boot via usb-4t /dev/sdb" 
image = /boot/kernel-genkernel-x86_64-4.11.7-gentoo
             label = "Linux-4.11.7"
             initrd=/boot/initramfs-genkernel-x86_64-4.11.7-gentoo
             #root = /dev/sdb2
             root = "UUID=24754012-32d6-496b-8e8e-263424db3576"
             read-only
image = /boot/kernel-genkernel-x86_64-4.5.3-gentoo
             label = "Linux-old"
             #root = /dev/sdb2
             root = "UUID=24754012-32d6-496b-8e8e-263424db3576"
             read-only

Running "lilo" now will destroy the boot record on the builtin hard disk!
If I run kernel 4.5.3 there is no problem!

[frostschutz]

You don't.

Well, you could influence it indirectly by loading USB mass storage module late. (if it's an usb drive and not esata)

But the /dev/sdx names are random by nature (first come, first serve) so you should never rely on these names.

If you need static names, you find them in /dev/disk/by-*/* there is UUID, LABEL, id (serial number), path (controller and port), ... one of them should suit you.

[mv]

If you need static names, you find them in /dev/disk/by-*/* there is UUID, LABEL, id (serial number), path (controller and port), ... one of them should suit you.

In addition, you can use udev rules to provide static names. But don't use sd* for these names!

[Irre]

It is hard for me to accept that my system randomly chooses between sda and sdb. It should be possible to tell (kernel?) that disk "0x005cd7ed" is /dev/sda!

[frostschutz]

I don't know of a kernel parameter that would make it reserve a specific /dev/sdX name for a specific drive. You're supposed to be using UUIDs instead of relying on device names.

Show dmesg, maybe we will learn more. If it doesn't always show up as /dev/sda then make two separate dmesg (when it happens, when it doesn't happen) and compare. Maybe there is a reason.

[Irre]

I don't know of a kernel parameter that would make it reserve a specific /dev/sdX name for a specific drive. You're supposed to be using UUIDs instead of relying on device names.

I do, where it is possible.

Show dmesg, maybe we will learn more. If it doesn't always show up as /dev/sda then make two separate dmesg (when it happens, when it doesn't happen) and compare. Maybe there is a reason.

Thank you, I will test that!

[NeddySeagoon]

Irre,

Its not random. The kernel does parallel initialisation, so there in a race between devices allocated names on a first come first served basis.
Its not just HDD. A more famous example is udevs 'persistent device naming' for network interfaces.

You should use PARTUUIDs if the kernel needs to work with unique IDs without an initrd or fliesystem UUIDs anywhere else.
Actually, PARTUUIDs with DOS disk lables are not very safe on partitions above 4.

The /dev/sdx naming won't change, (it will still be down to chance) but your filesystem tree will always be consistent.
If you need names that you can remember, labels will be better ... until you reuse the same label.

[frostschutz]

I do, where it is possible.

Where isn't it possible?

Doesn't LILO work with /dev/disk/by-id/... instead of /dev/sdb?

[C5ace]

I use partition labels:

My laptop's fstab:

Code: Select all

# <fs>              <mountpoint>    <type>  <opts>          <dump/pass>
LABEL=TG_BOOT       /boot           ext4    noatime         1 2
LABEL=TG_ROOT       /               ext4    noatime         0 1
LABEL=TG_HOME       /home           ext4    noatime         0 2
LABEL=TG_SWAP       none            swap    sw              0 0
/dev/cdrom          /mnt/cdrom      auto    noauto,ro       0 0
# /dev/fd0          /mnt/floppy     auto    noauto          0 0
LABEL=TG_WIN7       /mnt/win7       ntfs    noatime         0 0

/boot/grub/grub.conf: (grub-static)

Code: Select all

default 0
timeout 10

title TOSH-64 Gentoo Linux 4.9.34-gentoo
root (hd0,2)
kernel /boot/kernel-genkernel-TOSH-64-x86_64-4.9.34-gentoo net.ifnames=0 root=/dev/ram0 real_root=LABEL=TG_ROOT scandelay=5
initrd /boot/initramfs-genkernel-TOSH-64-x86_64-4.9.34-gentoo

title=Windows 7
root (hd0,0)
makeactive
chainloader +1

The kernel is build with: genkernel --menumake --disklabel all

The USB drive partition is labelled USB_DATA.

This automatically creates a icon on my Xfce desktop when plugged in.

Use Windows to set the label on the Windows partition and e2label on the linux partitions. e2label is part of sys-fs/e2fsprogs.

[Tony0945]

But the /dev/sdx names are random by nature (first come, first serve) so you should never rely on these names.

So what use are they?

Why doesn't the kernel search sequentially? I never saw a mobo with more than eight slots. The time difference should be negligible. Also, why aren't USB disks on their own nomenclature like nvme drives and dvd-rom drives are?

[Irre]

Doesn't LILO work with /dev/disk/by-id/... instead of /dev/sdb?

I didn't think of that!

Code: Select all

boot = /dev/disk/by-id/wwn-0x5000c5008b7bb8de

in lilo.conf seems to work.
Thank you all.

[szatox]

Also, why aren't USB disks on their own nomenclature like nvme drives and dvd-rom drives are

because they are served by the same module. Just like you could have sda and hda for SATA and IDE/PATA) long time ago, and then support for IDE was included in SATA driver renaming all the hds to sds.
Nvme drives are served by different module, and the same thing goes about many CD/DVD devices, though CD/DVD can be mapped as sds too.

- But the /dev/sdx names are random by nature (first come, first serve) so you should never rely on these names.
- So what use are they?

User's convenience, systems with only a single hard drive, history long passed, etc. It is handy when you do something manually. It's not reliable when you use unsupervised scripts, so go for one or another depending on the task at hand.
Don't use /dev/sdb/ in cron script just as you don't want to type UUID when you launch mkfs manually.

[Tony0945]

because they are served by the same module. Just like you could have sda and hda for SATA and IDE/PATA) long time ago, and then support for IDE was included in SATA driver renaming all the hds to sds.
Nvme drives are served by different module, and the same thing goes about many CD/DVD devices, though CD/DVD can be mapped as sds too.

Actually, I was looking at the kernel code a few months ago and I think I saw a way to patch it it so that usb's had a different name scheme. Never tried it though.

[Tony0945]

User's convenience, systems with only a single hard drive, history long passed, etc. It is handy when you do something manually. It's not reliable when you use unsupervised scripts, so go for one or another depending on the task at hand.
Don't use /dev/sdb/ in cron script just as you don't want to type UUID when you launch mkfs manually.

But /etc/fstab is an unsupervised script. Yes, when I make a physical change to the system, the names can change. At one time I had sda,sdb, and sdc drives. If I plugged in a USB stick, it was sdd, but if I booted with it in, it was sdc and the third drive was sdd. But the behavior was consistent.

The computer I'm typing on has sda, sdb, sdc, sr0 and sr1, all SATA, all in slot order. If I unplug one all Hell breaks loose, but probably because Gigabyte marked the slots wrong and it's hard to figure out the order. But once it has an order, it's consistent.

Ethernet was another story, finally blacklisted the Realtek module, only loading the Intel module.

[Ant P.]

But the /dev/sdx names are random by nature (first come, first serve) so you should never rely on these names.

So what use are they?

Same as inodes.

[Tony0945]

But the /dev/sdx names are random by nature (first come, first serve) so you should never rely on these names.

So what use are they?

Same as inodes.

We don't open files by inode but we do mount drives by /dev/sdx name.

[Ant P.]

And consequently you get support threads like these...

[mv]

It is hard for me to accept that my system randomly chooses between sda and sdb. It should be possible to tell (kernel?) that disk "0x005cd7ed" is /dev/sda!

As mentioned, it is possible to tell that disk "0x005cd7ed" is /dev/[...]. However, it is clear that such configuration data does not belong into the kernel itself but into userland. This is why {e,m,}udev was introduced.
When you configure {e,m,}udev you should merily choose a collision-free name for [...] instead of "sda", because otherwise you obviously risk races.