Hi,
I've been creating a custom spin with revisor and it's going very well, except for one fairly major problem...
It seems that when booting an installed system, /dev/sda corresponds to a PATA device, but during installation (via anaconda), /dev/sda corresponds to a SATA device.
To clarify... when anaconda runs I would like it to install to the primary master PATA drive if present. Strangely (or strange to me anyway), it seems that SATA devices get detected first. I thought that PATA devices would be detected first, so that in my kickstart file I could specify my desired partitioning to be on disk /dev/sda.
When there are only PATA devices installed this works fine, it goes on the primary master. However if SATA devices are present as well as PATA, it installs to the first SATA device.
If I set grub.conf of the installed system to boot from /dev/sda, it tries to boot from the PATA disk rather than the SATA disk to which it installed. I can get around this by pointing grub.conf to the UUID of the disk to which it installed. However, I'm surprised that /dev/sda seems to be a SATA disk during installation, and a PATA disk during boot.
Any thoughts as to why this might be? What decides the device detection order? Is it libata or something else?
Thanks,
installed. I can get around this by pointing grub.conf to the UUID of the disk to which it installed. However, I'm surprised that /dev/sda seems to be a SATA disk during installation, and a PATA disk during boot.
Any thoughts as to why this might be? What decides the device detection order? Is it libata or something else?
Module load order. That would imply that your different setups are loading drivers in a different order which is moving the devices around.
It ought not to matter to grub because grub uses the BIOS interfaces and the first hard disk the BIOS finds is what defines that interface - at least as far as finishing loadind grub and hunting for kernels .
Alan
Alan Cox wrote:
installed. I can get around this by pointing grub.conf to the UUID of the disk to which it installed. However, I'm surprised that /dev/sda seems to be a SATA disk during installation, and a PATA disk during boot.
Any thoughts as to why this might be? What decides the device detection order? Is it libata or something else?
Module load order. That would imply that your different setups are loading drivers in a different order which is moving the devices around.
It ought not to matter to grub because grub uses the BIOS interfaces and the first hard disk the BIOS finds is what defines that interface - at least as far as finishing loadind grub and hunting for kernels .
Alan
It has been my experience, that different version of BIOS determine which drive controller comes first.
I would happily accept a correction to this proposition.
I do not think that there is any way for anaconda, given the constraints of libata and the BIOS, to determine if the first drive offered is PATA.
Please, prove me wrong!
I do not think that there is any way for anaconda, given the constraints of libata and the BIOS, to determine if the first drive offered is PATA.
In theory you can map BIOS drives to PCI devices using EDD 3.0 tables and then use word 93 of the identify data to map the devices to PATA v SATA.
In practice EDD tables seem to be pretty good but various devices get word 93 wrong - notably cruddy ATAPI devices.
Our current order is basically
- link order for compiled in drivers (if any), which is fairly undefined but does put acpi, generic, legacy last
- module load order otherwise
For multiple devices off the same module it is then defined by the PCI bus ordering of devices which depends on the PCI scan order.
The order modules get loaded is from userspace
Alan Cox wrote:
I do not think that there is any way for anaconda, given the constraints of libata and the BIOS, to determine if the first drive offered is PATA.
In theory you can map BIOS drives to PCI devices using EDD 3.0 tables and then use word 93 of the identify data to map the devices to PATA v SATA.
In practice EDD tables seem to be pretty good but various devices get word 93 wrong - notably cruddy ATAPI devices.
Our current order is basically
- link order for compiled in drivers (if any), which is fairly undefined
but does put acpi, generic, legacy last
- module load order otherwise
For multiple devices off the same module it is then defined by the PCI bus ordering of devices which depends on the PCI scan order.
The order modules get loaded is from userspace
Thanks, that's all useful info. Maybe I can use it to figure out a solution.