SlackwareThis Forum is for the discussion of Slackware Linux.
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.
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?
Last edited by linuxbird; 12-05-2016 at 07:18 PM.
Reason: udev discussion
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.
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
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.
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.
It is true that changing the fstab to UUID won't fix your boot problems, but you can also change lilo to UUID, which will fix your problem. I wrote up an article on the SlackWiki on that subject, and Slackware includes a lilo-uuid-diskid utility that can convert your lilo automatically, but I've never used it and always done mine manually.
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:
Originally Posted by linuxbird
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.
There is also a possibility that if you switch to the generic kernel and an initrd, if the initrd and kernel don't contain the module for your sata addon card, it would likely prevent the drive names from getting mixed up. But I've never tested this, and it would only possibly work if the sata addon card's driver isn't built into the kernel.
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.
My opinion is the board's bios only supports ordering of integrated SATA/IDE/Floppy controllers, and doesn't support ordering of USB and PCI-SATA controllers.
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.
My opinion is the board's bios only supports ordering of integrated SATA/IDE/Floppy controllers, and doesn't support ordering of USB and PCI-SATA controllers.
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.
I'll accept that as opinion, but I can't ignore several data points. First, this is only happening with my ASRock motherboards. It doesn't happen with any of the others. I have probably 14 or more others, and admittedly, I have only tested 8 others. But the ordering issue doesn't happen with those.
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.
Last edited by linuxbird; 12-08-2016 at 12:55 PM.
Reason: repair quote
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.
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.
This underlined is the culprit IMO.
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?
Can you post your /etc/lilo.conf, your /etc/fstab, and the output of blkid?
Here you are:
Code:
# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# MBR is /dev/hda, partition is /dev/hda1
#boot = /dev/sda
boot = /dev/disk/by-id/ata-MAXTOR_6L060J3_663217953398
#compact # faster, but won't work on all systems.
# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
bitmap = /boot/slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
bmp-timer = 65,27,0,255
# Standard menu.
# Or, you can comment out the bitmap menu above and
# use a boot message with the standard menu:
#message = /boot/boot_message.txt
# Append any additional kernel parameters:
append="noparmset vt.default_utf8=0"
prompt
timeout = 150
# VESA framebuffer console @ 1024x768x256
vga = 773
# Normal VGA console
# vga = normal
# VESA framebuffer console @ 1024x768x64k
# vga=791
# VESA framebuffer console @ 1024x768x32k
# vga=790
# VESA framebuffer console @ 1024x768x256
# vga=773
# ramdisk = 0 # paranoia setting
# explicit to avoid LBA32 warning
LBA32
# End LILO global section
# Boot by UUID, which was required because Syba SATA adapter drives
# are sometimes loaded before ASRock G41M-S3 motherboard drives
#
image = /boot/vmlinuz
# root = /dev/sda3
root = /dev/disk/by-id/ata-MAXTOR_6L060J3_663217953398-part3
# root = UUID:"aa2c0ed6-aa0f-429e-9b95-f429712c2aef"
label = LinuxSCANuuid
read-only
#
# Linux bootable partition config begins
# tried for Syba Marvell controller using: append = "ahci.marvell_enable=1 "
# tried per Syba: append = "ata.generic=all_generic_ide=1 "
image = /boot/vmlinuz
root = /dev/sda3
label = LinuxSCAN
read-only
#
image = /boot/vmlinuz
root = /dev/sda1
label = LinuxBASE
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.