How does Linux handle adding SATA controllers & HDDs?

[UbuntuBantu]

Hi

I've successfully installed Ubuntu 6.06 LTS on my Asus 5wdg2-ws-pro workstation. Ubuntu recognises all hardware other than the Marvell 88SE614x on-board SATAII controller (ie SATA channels 5 through 7). SATA channels 1 through 4 are provided by the Intel ICH7R, hence Ubuntu installing and being up and running.

I recently added a Promise SATA300 TX4 SATAII controller and connected my additional drives to this controller, at the same time disabling the Marvell 88SE614x on-board controller. Linux sees and is able to mount all drives on the Promise SATA300 TX4 SATAII controller - I confirmed this via a Ubuntu LiveCD boot. My PC is configured to boot off SATA1 on the motherboard.

Problem: adding the Promise controller resulted in the drive assignments changing and I now have boot problems (even if I select the correct hdd to boot from in the BIOS).


After installing the Promise controller, if no drives are attached to it Dapper boots without issue. If I cable any drives to the Promise controller they displace SATA1 through SATA4 on the motherboard, ie where the SATA1 channel (my boot drive) used to be /dev/sda, with two drives connected to the PCI SATAII controller, the motherboard SATA1 channel becomes /dev/sdc.

On boot Grub subsequently gives me:
Uncompressing linux... Ok booting the kernel
mounting /dev/sda1 on /root failed
mounting /root/dev on /dev/.static/dev failed
mounting /sys on /root/sys on /root/sys failed
mounting /proc on /root/proc failed
Target file system doesn't have /sbin/init
My workaround in an attempt to solve this was to edit /boot/grub/menu.lst and to change references to sda1 to sdc1 and reboot. Dapper successfully booted, however, I lost X.

I then returned menu.lst to its original state and edited /boot/grub/device.map to change (hd0) /dev/sda to (hd0) /dev/sdc. This left me once again with the errors outlined above.

I suppose a simple answer would be to recable my drives, swopping /dev/sda and /dev/sdc, but this shouldn't be necessary -- will it work?

I'm guessing X has a similar hard coded reference to a library location somewhere. In any event, I'm very surprised that Linux/Ubuntu does not handle this sort of scenario automatically - adding and removing drives is a basic necessity these days. Perhaps it does and I just don't know where/how to invoke it?

[dkeav]

X doesnt, but your fstab needs updated as well as menu.list

[UbuntuBantu]

X doesnt, but your fstab needs updated as well as menu.list

So am I correctly surmising that Linux doesn't cope well at all with addition / removal of controllers and drives and that everytime I add/remove something I run the risk of borking the installation and will have to manually edit menu.lst and fstab?

[saikee]

I believe Linux is innocent as it works on the disk order handed down by the Bios.

The insertion of additional Sata controller can change the disk order as it is dictated by the hard ware information.

I would unhook the 2nd Sata controller, Boot up a Live CD, type at root terminal
fdisk -l
and record the disk order as found by the Linux (by the number of partitions and their sizes)

Assuming that is the installed and workable arrangement, I would switch off the PC and hook the 2nd Sata controller and repeat the above exercise.

Assuming there is difference then it is just a matter of editing the partition reference in /boot/grub/menu.lst, /etc/fstab and possibly /boot/grub/device.map

There is a good possibility just to swap the controllers positions in the mobo to avoid the above work, assuming the disks connections have not been altered.

[UbuntuBantu]

I believe Linux is innocent as it works on the disk order handed down by the Bios.

The insertion of additional Sata controller can change the disk order as it is dictated by the hard ware information.

Thx for the tip, it is in line with where my thinking was going. Still, a little surprising given windoze doesn't have the same problem - at worst your boot drive will be assigned a new drive letter but the bugger will still boot. Sounds like a bug waiting to be ironed out - this kind of thing is a showstopper for widespread Linux adoption on the desktop. Don't get me wrong though, I've made the transition and cannot see any reason to revert to a ms environment. Using a PC that doesn't crash is a novelty.

[saikee]

Windows system will have the same problem if it is a NT version like Win2k, Xp and Vista and inside such an installation there is a record on the disk number and partition number the OS was installed. Yours possibly because the Windows Disk wasn't change or you are using a Dos-based Windows that ignores non-MS disks and partitions and boots the first Fat16 or Fat32 partition and assigns it as the "C" drive.

In your case I would try the last line of my Post #4 first.

[UbuntuBantu]

Windows system will have the same problem if it is a NT version like Win2k, Xp and Vista and inside such an installation there is a record on the disk number and partition number the OS was installed. Yours possibly because the Windows Disk wasn't change or you are using a Dos-based Windows that ignores non-MS disks and partitions and boots the first Fat16 or Fat32 partition and assigns it as the "C" drive.

In your case I would try the last line of my Post #4 first.

Never seen this problem in xp or 2k3 so I've either been extremely lucky in the past or its somehow taken care of in win by setting the bios to boot off the appropriate drive, whichever it may be.

I've since rebuilt the box anyhow as I needed to incorporate support for a rocketraid 2322 and i figured it'd be easier to make a clean start, epsecially given all my data resides on other drives.

[dkeav]

not all controllers or additions change the drive order, in fact rarely does an add-in card jump ahead of the onboard devices, so you may have just never ran into this problem as of yet

[cybertron]

This also happened to me, but in my case I didn't even add a card or anything. Just added a new drive to the third built-in SATA port on my mobo and my boot drive got reassigned so it wouldn't boot anymore. It was a real pain, especially since there was absolutely no reason for it to happen. I can't really say whether it was a Linux problem or a BIOS problem though.