Drive Sequence and boot drive, with expansion SATA board

With an old G41M motherboard, I have a system with drives going to the motherboard interface, and drives connected through an expansion board.

If I boot with a Slackware install USB, the drives on the expansion board are mounted "first", meaning they come up as sda, sdb, etc.

I would like for the drives on the motherboard to come up "first" and have those as sda, sdb, etc.

I know that I can edit the fstab and use UUID to control the assignment of drives with control of what partition goes where. However, with drives on the expansion board changing periodically, the administration of the UUIDs becomes a bit of a problem. I also understand that can reassign UUIDs to partitions, but again, I am trying to manage a large number of drives, and the administration becomes problematic.

Changing the "boot" order on the motherboard does not have an effect on this, and in fact the system apparently tries to boot off the first drive on the expansion board when drives are connected.

Any ideas? I would like the first SATA interface on the motherboard to be the one which the system boots from by default.

Edit: I am using LILO for the time being with this system.

Device labels have been dynamic (meaning fluid and undependable) for a long time and there is no direct solution other than writing your own udev version that is not dynamic.
Dealing with that is, however, pretty easy. Using UUID is one way, and since both devices and partitions can be assigned a UUID that works pretty well and is the way most automated setups do things.
There is an older and more manual way, involving giving partitions (or, really, filesystems) a LABEL and then using that for LILO and FSTAB. I would think that that older way would fit SLACKWARE nicely, but I have not tested it. Were I you, I would look into that.

Do you know name/model of this "SATA expansion board"? The command "/sbin/lspci" might give some clue.

My guess is that the board itself has some kind of bios causing it to boot from its drives. Maybe, during boot, there is some key to press to get into that bios and disable booting from drives connected to the expansion board?

regards Henrik

Marvel Technology Group 88SE9215, something like: Weastlinks PCI-E to 4 Ports SATA III 3.0 6G Controller Card Marvell 88SE9215 non raid pcie 2.0 x1 expansion card Low profile available at Newegg.

The board causes a pop-up during bios boot, but after (obviously) the motherboard boot.

I have not been able to keep the expansion board devices from ending up in the /dev/sda slot. If I disconnect the drives, boot, and then plug in the drives, I get the sequencing I need. Ultimately this machine will be remote, so manual intervention is not desirable. ha ha

Will look for some online docs for the chipset.

So a lookup in a similar Amazon listed product states that the 9215 works with Linux, but the 9230 does not, and the device disconnects. It also states that one cannot boot through this adapter. (I seem to recall using this adapter to boot a system in the past, so that may not be true.)

One question is: When does the kernel do the assignment of drives, and is there a flag anywhere to tack new drives on at the end of the drive list?

The drives show up as plugdev group, and I did a quick look through dmesg to see if there was any clue I could find there. The motherboard connected drives are shifted to later in the list. I can still boot from them (like /dev/sdd) but I end up booting with a USB and entering an incantation.

Originally Posted by wpeckham Device labels have been dynamic (meaning fluid and undependable) for a long time and there is no direct solution other than writing your own udev version that is not dynamic. Dealing with that is, however, pretty easy. Using UUID is one way, and since both devices and partitions can be assigned a UUID that works pretty well and is the way most automated setups do things. There is an older and more manual way, involving giving partitions (or, really, filesystems) a LABEL and then using that for LILO and FSTAB. I would think that that older way would fit SLACKWARE nicely, but I have not tested it. Were I you, I would look into that.

I am not sure that approach will work, because as I understand it the fstab fires up after the kernel is loaded, and it appears that the drive sequence is somehow established by BIOS prior to the kernel being loaded. But I could be wrong, and I have not gone through the plethora of literature on how Linus boots up.

Right now, the only working workaround I have is to boot with drives attached to the motherboard SATA, and then afterwards, plug the additional drives into the SATA expansion board.

The Marvell chipset documentation does not provide any hints about changing the configuration. I will look further for a firmware document, but I kind of doubt I will find anything available relative to this thread.

https://www.marvell.com/content/dam/...et-2018-12.pdf

Originally Posted by linuxbird I am not sure that approach will work, because as I understand it the fstab fires up after the kernel is loaded, and it appears that the drive sequence is somehow established by BIOS prior to the kernel being loaded. But I could be wrong, and I have not gone through the plethora of literature on how Linus boots up. Right now, the only working workaround I have is to boot with drives attached to the motherboard SATA, and then afterwards, plug the additional drives into the SATA expansion board.

There is a mapping set in the bios, but you rarely see that under Linux. When Linux loads the kernel loads (among other things) the UDEV subsystem early. UDEV detects the devices installed on the system and device events. "Udev identifies devices by serial numbers, manufacturers, and even vendor ID and product ID numbers." Once it detects a device it maps device paths and runs any defined init for it, which may trigget a device driver load form the kernel module libraries.

That subsystem is pretty critical, but messing with it IS possible. (See articles like https://opensource.com/article/18/11/udev which I quoted above. )

So, we have two different problems here...

The drive order sda, sdb and so on might be possible to fix with udev, just like you can use udev to configure the order of network cards eth0, eth1...

However, the boot order cannot be fixed by udev as linux has not yet been started at boot. As you say, the expansion card does not mention any way to disable boot, it only seems to present some more drives to your computer. If so, you are left to the functionality of the motherboard bios to choose boot drive. As a last resort you might see if it helps to move the expansion card to another PCI slot.

I did google the manual for the G41M motherboard, but it does not provide any block diagram showing how north bridgh, south bridge, build in SATA controllers and PCI lanes are connected.

Did you try messing with those BIOS settings for "On-Chip SATA Mode" and "SATA Port 0/2 Set to"? Maybe if you configure the onboard drives to act as IDE drives they will be selected for boot?

regards Henrik

I still have the same problem, but perhaps I have a different explanation of it. Kindly consider:

Changing drives installed on the system changes /dev/sda2. I cannot get around this.

So what I thought I would do is to try to use UUID specifications instead of the /dev/sda2.

I am having some trouble with this. Probably because I don't completely understand the boot process and what lilo does.

Q1: Do I need a boot = near the top of the lilo.conf?

Q2: If I need a boot = line, can it be done with UUID?

Q3: Where the per image entries are in lilo.conf, can I use a UUID specification?

Thanks.

I think giving partition name scheme as suggested by wpeckham could be a workable strategy if you have many drives
For example give each drive a name, then choose a partition name and combine them for the filesystem label
Like: SAM1-SLKHOME (Samsung hard drive number 1, Slackware /home partition), you could even physically put a label sticker with "SAM1" on the drive

Originally Posted by keefaz I think giving partition name scheme as suggested by wpeckham could be a workable strategy if you have many drives For example give each drive a name, then choose a partition name and combine them for the filesystem label Like: SAM1-SLKHOME (Samsung hard drive number 1, Slackware /home partition), you could even physically put a label sticker with "SAM1" on the drive

As I understand it, udev can be very helpful, and is probably underutilized for managing fs and related events. However, I believe that it needs a kernel operating to run.

Specifically, I am trying to direct where the drive and kernel are to boot up, after which udev could be used. But I need to assign a root partition and get a kernel loaded first.

Using labels, or using UUID strings, allow the BOOT MANAGER to identify the devices the way you want them to. It also helps the KERNEL identify them the way you want them to. Directing the boot process before the kernel loads is the job of the BOOT MANAGER (grub2 and elilo are most common) and these suggestions directly affect the way you would configure those and the way they would work for you.

If you find another way using udev directly, I will look forward to seeing that procedure documented.

Originally Posted by wpeckham Using labels, or using UUID strings, allow the BOOT MANAGER to identify the devices the way you want them to. It also helps the KERNEL identify them the way you want them to. Directing the boot process before the kernel loads is the job of the BOOT MANAGER (grub2 and elilo are most common) and these suggestions directly affect the way you would configure those and the way they would work for you. If you find another way using udev directly, I will look forward to seeing that procedure documented.

Assuming I am using lilo, can you answer the following questions?

Q1: Do I need a boot = near the top of the lilo.conf?

Q2: If I need a boot = line, can it be done with UUID?

Q3: Where the per image entries are in lilo.conf, can I use a UUID specification?

Even if there's no fix in the BIOS, it seems to me there is no need to be concerned which drive/mbr LILO is installed on if it's menu config'd for

other - dev/foo
 label = Foo