On 9/14/2011 9:45 AM, Constant Brouerius van Nidek wrote:
Do not know what has caused it but I assume it was me playing with a drdos iso disk. At least since then, the /sdc drive name has been changed into /sdk
No further problems but I would like to return it to /sdc. Any ideas?
There is no such thing as reliably controlling the device node name any more. It is dynamically assigned at detection time, which means at boot time and/or at any disconnect/reconnect after boot. Use ID or UUID or LABEL as your mount point reference. the days of static hardware addressing are long gone. Why was it sdc for some long period of time and why is it now sdk even after rebooting? You changed the order in which this disk was detected. What does that mean? Several possible things: * You modified bios settings which altered boot order, or added/removed drives from the boot list. * You modified bios settings that altered detection or enabling of drives. * A particular example of above, you enabled usb legacy support. * You modified bios settings which altered pci/pcie irq assignments. * You added or removed physical drives. * A particular example of above, you have one or more usb thumb drives plugged in that you didn't used to have plugged in, or were previously not treated as a hard drive because of usb legacy settings or merely the type of formatting of the thumb drive itself. * You added/removed pci/pcie cards, or moved pci/pcie cards around to different slots than they were in before. * I'm assuming you don't have a hardware raid card which can provide any number of individual whole virtual "disks" just by going into it's bios and carving out chunks of the physical drive space any way you want. But that would be yet another way a given drive letter will change from one boot to next, or from one disconnect/reconnect to next. * I'm assuming you're not playing with fancy stuff like AoE or iSCSI which can add/remove virtual drives dynamically at any time, thus possibly altering detection order of other pre-existing drives. * You have more than one external usb drive, and you changed which drives were plugged in to which usb ports. * You changed the order in which the kernel drivers are loaded, perhaps by simply upgrading/downgrading kernels, or by building a new kernel with some drivers built-in vs as modules or vice/versa. * You haven't rebooted at all but merely unplugged/replugged a removable drive, like an sata drive in a hot-swap enclosure or an external esata/firewire/usb drive. When you do this the old drive letter is not re-used. instead it is assigned the next highest available letter. If you haven't changed the hardware or bios settings _AT ALL_, then simply rebooting should cause it to get re-detected in the same order as always. The real answer is that you can't count on or predict drive detection order any more, and so you can't count on or predict drive letter name any more. It's all dynamic now. Even if it seemed to be consistent for 100 reboots for 2 years, that is just luck and means nothing. The very next reboot could be all different in response to any of the possibilities above and more that I don't even know. If rebooting doesn't put the drive back to /dev/sdc , then go in and modify /etc/fstab to use ID=xxxx, UUID=xxxx, or VOLUME=xxxx instead of /dev/sd* look in /dev/disk/by-* to find the value to put after the equals sign. UUID is the most robust, guaranteed unique etc, but ID is more human readable and just about as robust for all practical purposes. When you read /etc/fstab (and if necessary /boot/grub/menu.lst and /boot/grub/devices.map and /etc/grub.conf), ID=scsi-SAdaptec_3805_RAID10_233F9F03-part1 is a lot more meaningful and useful to you the human reader than UUID=35316b05-e83a-4fc2-9dfe-d4f60eb13b07 After that you always just issue mount commands based on the mount point not by the device or id or uuid, just "mount /usb3" and fstab will always find it by ID wherever it's plugged in, whatever order the kernel detected it, regardless of disconnect/re-connect re-assignments. LABEL=xxxx is even more human readable since you make up the xxxx to be whatever you want. But that's also exactly why its a little unsafe, you may fail to be careful about making sure you use unique volume names some time. That may be good or bad depending on what you need. If you use a simple volume name like "freedos" and have more than one disk with the same volume name, the system can't tell the two apart and you may not expect or like the results. ID and UUID will never accidentally collide or be ambiguous like that. On the other hand, the same potential for ambiguity could be used on purpose. If you WANT to have different physical disks to be detected the same way, like you could have 7 different drives of the same size & type, which will all have different ID's and UUID's, but you formatted them all the same way and gave them all the same volume name "BACKUP", you could maintain a continuous rolling weeks worth of backups by plugging only one drive in at a given time, but a different one each day. No matter which of the 7 drives you plug in, it will get detected as "LABEL=backup" and get mounted to the same /media/backup or wherever you wanted, and so you can have the same simple backup job every day seemingly writing to the same drive, yet really you have a perpetual 7 day history without having to do any fancy scripting. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org