[SOLVED] How does the kernel decide what device to create when a new drive is plugged in?
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How does the kernel decide what device to create when a new drive is plugged in?
I have 1 permanent drive. I often plug in a USB drive. Usually it's assigned /dev/sdb . Sometimes it's assigned /dev/sdc even though sdb is available. Why? I have scripts that expect /dev/sdb.
sda, sdb, sdc and so on are not persistent names. I can't tell you what causes your particular disk to be sometimes sdb, sometimes sdc, but in any case it's risky (as you just learned ) to believe that the disk will always get the same device name.
Your disk has various properties that your system uses to generate persistent names, such as UUIDs, filesystem or swap LABELs, hardware paths, SCSI addresses and so on. In most distros, udev creates symbolic links under /dev/disk whose names are guaranteed to always refer to the same disk.
(not quite actually - when you clone a disk, the clone will receive all UUIDs and LABELs, and you can connect the same disk to different hardware paths. As long as you know what you are doing, though, the persistent naming mechanisms work reliably)
Since I don't know your application, I don't have a full solution for your problem, but I suggest to educate yourself about persistent naming.
following the comments above...I get around this by creating a mount point and adding an entry to /etc/fstab with the mount point and the UUID of the drive. I use the mount point in my scripts. If the USB drive changes, change fstab to recognise this
The fact that my learned friends have not already mentioned this makes me wonder...am I missing the point
I have 1 permanent drive. I often plug in a USB drive. Usually it's assigned /dev/sdb . Sometimes it's assigned /dev/sdc even though sdb is available. Why? I have scripts that expect /dev/sdb.
I've experienced this. I think it has something to do with timing. If sdb is available, it will always be assigned sdb. In some cases sdb WAS assigned (and probably not properly unmounted), then next time (shortly after) it was assigned sdc instead of sdb although sdb appeared to be available.
I don't know the root cause, but I can confirm the "issue". And personally I think it has something to do with inproper unmount of a device and device timeout.
Quote:
Originally Posted by Firerat
You should not use scripts that require sda sdb etc.
following the comments above...I get around this by creating a mount point and adding an entry to /etc/fstab with the mount point and the UUID of the drive. I use the mount point in my scripts. If the USB drive changes, change fstab to recognise this
The fact that my learned friends have not already mentioned this makes me wonder...am I missing the point
Absolutely. For example, what if there is no file system on the disk? Or not even a UUID?
I suggest to educate yourself about persistent naming.
That's an argument never to ask any question.
Quote:
Originally Posted by Firerat
What if you have 2 usb drives...?
Then I know that and act appropriately.
Quote:
Originally Posted by Firerat
/dev/disk/by-uuid
Is probably what you want
Turns out not to be the case.
Quote:
Originally Posted by timl
following the comments above...I get around this by creating a mount point and adding an entry to /etc/fstab with the mount point and the UUID of the drive. I use the mount point in my scripts. If the USB drive changes, change fstab to recognise this
Good idea. I hadn't thought of this. Unfortunately it requires an entry for every device, more of an inconvenience than I have now.
Quote:
Originally Posted by Firerat
Which tells me said script needs to be re-written or at least fixed.
It already works. I was just curious about what is persisting in the mind of the kernel that keeps /dev/sdb unavailable.
Quote:
Originally Posted by berndbausch
Absolutely. For example, what if there is no file system on the disk? Or not even a UUID?
I have 1 permanent drive. I often plug in a USB drive. Usually it's assigned /dev/sdb . Sometimes it's assigned /dev/sdc even though sdb is available. Why? I have scripts that expect /dev/sdb.
Quote:
Originally Posted by Firerat
Your script doesn't work, the reason you started the thread proves that.
Edit: "is broken" is a better fit than "doesn't work"
if you are going to troll, at least be smart about it.
Quote:
Originally Posted by RandomTroll
No it doesn't. My script works. Sometimes it finds /dev/sdb unavailable even though it doesn't exist. It tries /dev/sdc next.
not something you said in the OP
If you want to carry on using error prone, flaky scripts on your slackware
It won't make too much difference.
If you want to carry on using error prone, flaky scripts on your slackware
It won't make too much difference.
If the behaviour of sdx is predictable, then there should not be an issue in writing such a script. sdx SHOULD be predictable if you use it to be predictable, and thus the script SHOULD work.
The issue here is the behavious of sdx IS NOT predictable despite using sdx in a way that it SHOULD be predictable. The question is why. I added my view and have experienced the same behaviour, and I think the conclusion of the thread is pretty much the same with "the orphan in /etc/mtab".
The more important question is, why does that happen?
My theory had to do with inproper unmount and timeout. After x time, you will be assigned sdb in either case, but factor y causes sdc "issue" before x time factor, due to cause z.
Is cause z inproper unmount? I don't know. Is there an x timeout factor? I'm not sure. z=y?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.