Drive Assignments
Adding additional controllers to a disk farm, I am faced with a change in what drive is /dev/sda, etc. It appears at boot the drive is sda but afterwards it is reassigned, and a drive from a new controller is the new /dev/sda.
I know that I can put UUID in fstab, but I would really like to have a deterministic assignment of sda, sdb, sdc, etc. Is there a way to accomplish that? FWIW, I am using Slackware 14.0 but will upgrade this machine to 14.2 early next year. Thanks. Addendum: It looks like one way to do this is by writing udev rules. Since 14.2 uses eudev, perhaps they would have to be rewritten again. Is there a different way? |
I see that problem ,some time a go , and i open a thread , or sugest in the current sugest ,im not sure.
The problem is caused because kernel have CONFIG_FDDI=y need to recompile kernel with CONFIG_FDDI=m I see same problem in asrock motherboards , altering order on HDD , when plug a USB STICK , and when unplugged , ..order of partitions are altered. I not understand why , FDD support is compiled as YES (forced) in 2016 , as module are ok , for very very very very very old machines , but as YES ..i think NO. |
Quote:
However, I am confused, because I thought CONFIG_FDDI was for fiber. Perhaps you meant something else? |
I think I need the help of a boot time expert.
OK, so here is what is happening: drive 1 = ide, also my boot drive, a mere 60 gb and probably a third as many years old drive 2 = DVDRW, not quite as old, but getting there, and is IDE drive 3-6 = WD 4TB red So when I boot, drive 1 = /dev/sda drive 2 = /dev/sr0 drive 3 = /dev/sdb drive 4 = /dev/sdc drive 5 = /dev/sdd drive 6 = /dev/sde Then I add a Syba SATA adapter, SI-PEX40108, with one drive, and the following drive assignments seem to happen: Adapter drive is drive 7, for this discussion. It becomes the first drive, and the boot dies when it can't find the partition with the kernel on it (because the drive doesn't have a kernel, or anything else on it). I can tell that it is the adapter drive from the messages. So what is happening, with this motherboard, ASRock G41M-S3, is that the adapter drives become mapped to the new first drive of the system, which is where lilo is configured to go. The MBR still resides on drive 1, but while booting the system tried to open the thrid partition of drive 7, which has effectively become the new /dev/sda. USUARIONEUVO says that he thinks this is a problem on ASRock motherboards. I searched on that and found a few instances where this may have happened, but they were a while ago (I am repurposing an older MB), and not exactly the same situation. I did an experiment, booting the system with the SATA adapter in a PCIe slot, but without a hard drive data cable attached. The system boots normal, and when I plug in the SATA drive, it becomes /dev/sdf. What I want is for the SATA adapter card drives to become /dev/sdf-i. I would consider that "normal." Not happening here, at least with any of my attempts. So let's talk about possible solutions. a.) I see no way to tell BIOS to change drive assignments for adapter interfaced SATA drives b.) Changing fstab so that it uses UUID will not work, because the run kernel is on /dev/sda3, and the disk sequence gets messed up bringing up the run kernel, before fstab is mounted. c.) udev may not work (trying it appears to be a bit of work) because udev may run after the run kernel is loaded (perhaps someone knows for sure-I would love to hear non-speculation on that point). There has to be a better way, or even a way which works! All I all I am trying to do is have the drives from a SATA adapter be added AFTER the drives from the motherboard based adapters. |
Quote:
Both your lilo.conf and fstab will need to be using UUIDs (or some other form of persistent naming) for this to function properly. Quote:
|
This is perfect. Great info. I will try to implement, based upon your article, and see if that resolves my issues. THANKS!
|
there is one more option if the last one fails:
while booting generic; have the add-on controller module blacklisted: it won't auto-load until rc.M "plays" So You can control it from rc.modules or rc.local Other than that, Code:
#modinfo <said module> |
Quote:
This is where the kernel steps in and implements some sort of ordering which may not work on all boards, and which may or may not match what was specified in bios and/or boot loader. Blacklisting the offending kernel modules should work, as should disabling a 'secondary boot device' in bios as I suspect the kernel has some logic to decide which is primary regardless of what bios does. |
Quote:
What is so frustrating about the ASRock behavior is that it substitutes the third party adapter linked drives in as the first drive in the sequence, which is the drive the root partition is normally associated with. The "normal" behavior is to have the third party attached drives appended to the end of the disk list, which is more consistent with the manner that additional drives would normally be used. Think large disk farm, raid arrays, etc. Normally it is not the first choice to have the raid host the root partition. Sure it can be done, but it is not the most common architecture. |
Yes, particular vendors are particularly broken ;)
But we, the slackers, manage to "twist the hand" and get our systems straight each time. |
I followed bassmadrigal's nice writeup, and while my hacks booted up nicely without the third-party SATA adapter being used, as soon as I plugged a drive into it, and rebooted, things went south.
Unable to exactly reproduce it here, here is the gist of what I get at boot time: VFS: Cannot open root device :803" or unknown-block(8,3) Please append a correct "root'" boot option; here are the available partitions: then for the sd drivers, it lists them with an apparent UUID of 00000000-0000-0000-0000-000000000000 SCerovec's idea is a no-go because the module used for the third-party SATA drives is the same module used for existing motherboard adapted drives. So it looks like I am again out of ideas. |
Can you post your /etc/lilo.conf, your /etc/fstab, and the output of blkid?
|
Quote:
How would You' as a kernel, distinguish among to apparently identical drivers which is to be counted first? eudev persistent rules come to mind: try to fix the device rules for the MoBo controller somehow? please provide output of following: Code:
# ls /etc/udev/ -lahR Code:
# lsmod Code:
# lspci |
Quote:
Code:
# LILO configuration file Code:
#fstab modified for UUID 1161210 Code:
#blkid |
Quote:
Code:
# ls /dev/udev/ -lahR Code:
#lsmod Code:
#lspci |
All times are GMT -5. The time now is 06:28 AM. |