S-ATA Hard drives swapped

[cplinux]

Hi!
I'm not sure if this is really a bug.

I have an Asus A8N-FM with an AMD64 4000+, installed Ubuntu 8.04 AMD64.
I have attached the following drives:
- SATA 1: Seagate 400GB
- SATA 2+3: Samsung 400GB
- SATA 4: LG DVD Burner
Additional USB card reader (dont know if that matters)

Strange is, that the Bios will let the OS boot from the Seagate hard drive - SATA1, which us plugged to the first SATA port.
Ubuntu yet always assigns the drives that way:

SATA1 -> /dev/sdb
SATA2+3 -> /dev/sda+sdc
etc.

Normally SATA1 should be /dev/sda, shouldn't it?

So, to do a normal bootup, I have to change grub's settings to have root hd(1,0) instead of hd(0,0) after the installation.
Even I have installed grub to all discs, because i've noticed some problems at bootup.

I hope I explained it in a good way.
I'm using sda+c with mdadm, so I will not change it anymore, but it's strange anyway.

Kind regards
cplinux

[cplinux (christian-cplinux)]

Perhaps I should note, that i've setup the software raid with mdadm after the installation.
So normally it should not matter.

[Francesco Pretto (ceztko)]

Confirmed. And I would say it's a serious bug for newbies, as simply the booloader is default installed in the wrong hard disk, not the first in the order that bios follows. What's strange (to me) is that:

- grub from bios (on start-up): sees the hard drives in the correct order;
- grub from live cd 8.04.01: sees the hard drives in the WRONG order.

I would say here that, not being in real-mode, grub from live cd is not using bios calls to detect hard drives but relays on an higher level linux syscalls/driver interface. Really dunno.

Distributions that work (detect sata drives in the correct order):
- Ubuntu 7.10;
- Gentoo 2008 (2.6.24 kernel).

Next I'll attach dmesg, /proc/interrupts, lspci output from ubuntu 8.04.01 and 7.10.

[Francesco Pretto (ceztko)]

Let me know if you want further debug info (hdparm, udev...). I don't know how to query udev for more details, so you'll have to instruct me.

Thanks

[Francesco Pretto (ceztko)]

Sorry, maybe it wasn't clear: I reassigned this bug to udev because even the name mangling of udev is swapped.

/dev/sda --> /dev/sdb
/dev/sdb --> /dev/sda

So certainly, this bug is not pertinent to grub only, but refer to the way udev and grub detect their ordering (so may be system wide or similar on the 2 progs). May be even a kernel bug, but please note that Gentoo 2008 (comes with 2.6.24) works perfectly, like ubuntu 7.10.

Please instruct me on how to collect more information from udev and grub to spot where they are assuming the wrong ordering and I'll report here. Thanks

[Scott James Remnant (Canonical) (canonical-scott)]

As I said in my comment, the fact that the names change is perfectly normal and expected behaviour.

This is why you'll find nowhere in Ubuntu that refers to the drives by these names, instead fstab will be written in the form UUID=... which do not change.

[Francesco Pretto (ceztko)]

2008/7/23 Scott James Remnant <email address hidden>:
> As I said in my comment,

If you further commented, your comment got lost somewhere.

> This is why you'll find nowhere in Ubuntu that refers to the drives by
> these names, instead fstab will be written in the form UUID=... which do
> not change.
>

Alright, I know UUID mechanism.

> the fact that the names change is perfectly
> normal and expected behaviour.
>

Are you saying that something changed in udev and now it's expected to
see modified ordering in hds (and maybe for ATA controllers in
general)? I'm sorry, but just because as little as possible apps
should rely on the static name mangling of the devices, and for very
specific needs, this should be as close as possible to what bios
detects (or want to detect).

Let's do an example: grub from booted linux MAY (really dunno) relies
on udev to do its job. So, grub could ask to udev:

Grub: "Udev, please give me de device of the first hd on a
ATA/SATA/SCSI controller, so I may expose it as hd0 to the user and
install the bootloader here"
Udev: "Ok, It's /dev/sda"

If udev itself change this ordering, this will simply breaks
application expecting to find an ordering as close as possible to the
bios one.
IMHO, the behaviour should be reverted to the previous (working) one.

[Scott James Remnant (Canonical) (canonical-scott)]

We do not consider this a bug.

[Francesco Pretto (ceztko)]

At least explain when and where this behaviour in ordering changed within udev and why shouldn't be a bug. Or, are you telling me that at the SAME TIME, udev changed its behavior in ordering and grub guys introduced a new bug that inadvertently broke the ordering?

Tryed running grub (would be more correct to say the grub shell frontend, that's the component run when you are running linux) with --device-map option. This force grub to produce this device.map file:

(fd0) /dev/fd0
(hd0) /dev/sda <-- This ISN'T the hd bios want to boot
(hd1) /dev/sdb

That is the wrong ordering, as said before.

I'm sorry, but it's simpler to me to think that the grub shell frontend is just assuming the default LANANA device ordering to map devices, looking for the hd that hopefully will be booted by bios.

So, for example, hd0 in grub is just the first /dev/hdX in alphabetical order (excluding cd-roms) if you use the old linux ATA driver, or /dev/sdX in alphabetical order (excluding cd-roms and usb mass storages) if you are using LIBATA or SCSI.

In this case, you MAY think that changing the device ordering in udev is not a bug, but you would be inadvertently breaking other applications.

Let's hope to hear a word from Grub devs soon. In the mean time, please, stay tuned.

[Scott James Remnant (Canonical) (canonical-scott)]

Nothing has changed in udev, and udev is not the culprit or cause, it just makes the devices as the kernel expects.

The kernel assigns device enumerations (eth0, eth1, sda, sdb, even the old hda, hdb) based on the order the device is made known to the kernel.

With disk drives, especially SATA and USB storage devices, the time that it takes the drive to be detected can vary between boots. Often you'll find that one SATA port on your board always beats another, sometimes you won't.

This means your drives will appear to dance around between different sdX names with no consistency.

Given that all drives now appear with these names, including removable ones, we could either fight against the instability (as we do for ethernet devices - your USB key would always be sde, a different USB key would be sdf, sdg, etc.) or we can embrace it.

For drives, we opted the latter.

This means that drive letters are expected to change, and thus you should not rely on them for more than one session. For all permanent references, use the UUID or LABEL of the filesystem on the drive.

The relationship with grub is only a perceived one.

In fact, grub has no matching or intelligence between sdX drives and its own designators. This is the reason it uses its own in the first place. Grub's device ordering depends entirely on the BIOS view of the drives, in particular this means grub does not see any drive not seen by the BIOS.

Grub has its own issues as well; a favourite bug report is that grub changes *its* device ordering when adding or removing drives, for no readily apparent reason. (On my own machine, a new SATA drive on port 3 became hd0 shuffling up those on ports 0-2)

The only mapping between sdX and hdN names is /boot/grub/device.map which is attempted to be kept in sync, but can fail between reboots.

Switching grub to UUIDs solves both sets of problems.

[Francesco Pretto (ceztko)]

2008/7/24 Scott James Remnant <email address hidden>:
> Nothing has changed in udev

Maybe not in udev, but something has to be changed.

Ubuntu 7.10: *always* correct bios ordering;
Gentoo 2008.0 (kernel 2.6.24, udev 115): *always* correct bios ordering;

Ubuntu 8.04.01: *always* SWAPPED ordering;

Where *always* is "in all my attempts".

I'm not saying it's not a lecit change, but please identify when this
behavior changed.

>
> The relationship with grub is only a perceived one.
>
> In fact, grub has no matching or intelligence between sdX drives and its
> own designators. This is the reason it uses its own in the first place.
> Grub's device ordering depends entirely on the BIOS view of the drives,
> in particular this means grub does not see any drive not seen by the
> BIOS.
>

Let's make this important distinction:
1) Grub as a mbr: let's call it grub-mbr;
2) Grub as a shell frontend: let's call it /sbin/grub.

grub-mbr obviously use bios, and after an install of ubuntu 8.04, the
detected ordering of grub at boot is always "correct" (the bios one).

/sbin/grub on livecd 8.04 gets different ordering, clearly not the
bios one. So, I'm assuming that /sbin/grub is NOT using bios for its
probes. It may use the current device files, but it's just my guess.
We should ask this to grub maintainers (if they are listening...).

You pointed:

> Grub has its own issues as well; a favourite bug report is that grub
> changes *its* device ordering when adding or removing drives, for no
> readily apparent reason. (On my own machine, a new SATA drive on port 3
> became hd0 shuffling up those on ports 0-2)
>
> ...
>
> Switching grub to UUIDs solves both sets of problems.
>

1) To make this working, grub-mbr must itself use UUIDs, not only
/sbin/grub. In this way, even in grub.com/menu.lst you'll have root
directives with UUIDs, for example "root
(f0f68b8c-cf26-4c76-8a21-6a5c02c028dd)" instead of "root (hd0,0)". If
this is not already implemented, it will require major changes to
grub.
2) Not fully true. Switching to UUIDs won't solve the problem of
finding the drive bios will boot (read where to install grub-mbr). I
know, this problem is unsolvable in all the cases: people may want to
boot from a SCSI drive even if they have an ATA drive, and grub can't
say which is the preferred drive. However, we have to offer a
"sensible default": relying on bios ordering and choosing the first
hard disk is, IMHO, a good one in case of not so complicated
configurations. Distros worked this way from the beginning, and nobody
ever complained. If, for some reason, /sbin/grub is unable to detect
bios ordering, this is a major problem and will breaks many
configurations with >= 2 hard disks.

> The only mapping between sdX and hdN names is /boot/grub/device.map
> which is attempted to be kept in sync, but can fail between reboots.

device.map is used only by /sbin/grub when you are using the switch
--device-map. Changes on this file won't reflect to grub-mbr unless
you re-install it from /sbin/grub using the command "setup (hdX)". So,
simply keeping it synced correctly won't solve the problem either.

[Francesco Pretto (ceztko)]

No reactions from grub maintaner(s) or the the installer team? Are the right people already notified of this bug?

[Colin Watson (cjwatson)]

Work on more stable device identification in grub is in progress, and tracked in other bugs. We know about it - it's just a substantial chunk of work to get right.

[Phillip Susi (psusi)]

No, this is not a bug. Device names are assigned by the kernel in the order they are detected in, which can change from boot to boot. It looks like there was some discussion about adding uuid support to grub to be able to deal with this, which has been done in grub2.

[Steve Langasek (vorlon)]

It certainly was a bug - but it's also a bug that I believe i fixed in later versions of the grub 1 package, where we also implemented UUID handling.