10.04RC system boot random assignment of sda, sdb

[Ridgeland]

Ubuntu 10.04 RC
System has two hard drives. 15 partitions on SATA 1TB drive. 12 partitions on ATA/IDE 120GB drive.
Each boot U1004RC assigns random drive letters. 1TB to sda or maybe 1TB to sdb.
My large Data partition on sda5 shows as sdb5 often, about 30% of the time on boot.
So I changed /etc/fstab to use UUID for all partitions. Still this happens.
I play with lots of Linux OS (27 partitions, 3 for Data). I have not seen this anywhere but 10.04.
The truly maddening part is root always shows as /dev/sda11, but if Data shows as sdb5 then changes made to root are stored in /dev/sdb11 not /dev/sda11 !!!!! The first step each boot is a terminal window and 'df' to see if the drives are backwards again. And I changed the desktop background as an obvious error flag.
Expected: each boot the drives always have the same device ID
Seen: random assignment of sda, sdb
---
Architecture: amd64
DistroRelease: Ubuntu 10.10
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
Package: linux (not installed)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/bin/bash
Tags: maverick
Uname: Linux 2.6.37-020637rc2-generic x86_64
UnreportableReason: The running kernel is not an Ubuntu kernel
UserGroups: adm admin audio cdrom david david4schwab dialout dip fax floppy fuse joyce lpadmin netdev plugdev sambashare tape video

[Dave Gilbert (ubuntu-treblig)]

Hi,
  I think this is the same as #261178 I first reported in Intrepid - but I actually think it's the correct
behavior - let me explain.

  As of recent kernels the drivers for different devices initialize in parallel for speed; in the old days
it would check each device, wait for the drives on that to start up and then move onto the next one - these
days it does different controllers at the same time - in your case I suspect your SATA is on one controller
and your IDE on a different one. This is a LOT faster, but which one is sda depends on which is fastest.

Having said that the answer is supposed to be that you should be able to use UUID (or labels if you prefer)
everywhere and it shouldn't matter if it's called sda or sdb

So, I suggest you add your /etc/fstab and anything similar to this bug report after switching them to UUID or labels.

Dave

[Ridgeland (rambutan1)]

Thanks Dave.
I'm attaching fstab. I am using only UUID since seeing this issue. 10 boots found my /Data on sda 6 times sdb 4 times.

In rc.local I have:
# Spins down the sdb drive - to be quieter and save energy
hdparm -y /dev/sdb

That is now broken. I will write a script that finds /Data then spins down the other drive.

Can I use udev rules to always have sda assigned to my 1TB drive? I'll explore it.

Sidebar: fstab said Use 'blkid -o value -s UUID' - that gives a list of 25 UUIDs with no partition locations. I prefer 'ls -l /dev/disk/by-uuid/' to see which UUID with which partition.

David

[Mathieu31 (mathieu-belleville)]

Same here. The system disk (should be sda) is connected to the motherboard IDE port.
A secondary disk (should be sdb) is connected to a SATA controler on a PCI card. I need to pass kernel options to libata, because the 80c cable is not recognised, and the SATA controler is a VIA VT6421, to which I want to pass options as well.
However, when the disks are not in the order I expect them to be, the wrong options are passed to the wrong ata channel, causing kernel panic or no boot waiting for root partition to come up in the worse case.

Similarly, when doing a clean install from the CD, the boot loader was installed on /dev/sda, which happens to be the SATA drive, whereas the system boots on the IDE drive (cause grub error 15 from a previous Linux installation). I had to disconnect the sata drive to resolve the ambiguity during install.

Mathieu

[Ridgeland (rambutan1)]

I'm using totally UUID for fstab etc. No issues there for me.

I learned how to use script commands like:
tune2fs -c -1 -i 3m -L 1TB_09 /dev/disk/by-uuid/dd6032a7-02ec-4b78-afff-8c5795345667
where before I used:
tune2fs -c -1 -i 3m -L 1TB_09 /dev/sda9

To spin down the second drive for energy and noise:
hdparm -y /dev/disk/by-id/ata-WDC_WD1200BB-53CAA0_WD-WMA8C1772952
where before I used:
hdparm -y /dev/sdb

The panel's sensors applet to measure HDD temps remains broken. I don't see the fix for that yet.

Mathieu31, since the issues are after GRUB maybe this link can help you troubleshoot.
http://wiki.archlinux.org/index.php/GRUB2#Combining_the_use_of_UUID.27s_and_basic_scripting
Since hitting GRUB2 I just chmod /boot/grub/grub.cfg and manually edit it, careful to keep a backup of my revised /boot/grub/grub.cfg because it can and does get overwritten without permission on new kernels.

[Mathieu31 (mathieu-belleville)]

Ridgeland,
Thanks for taking some time answering this.
In fact, as far as I remember, the stock grub.cfg uses UUID as well, so the system boots, whatever the order of the drives.
Using UUID everywhere would not matter, except when I need to pass option via the kernel boot options to the libata to properly handle the two disk controller available on my system.
libata.force option can take a device id as argument, which is the number of the ata channel. Obviously, this number changes depending on the order the controllers are initialized. As a consequence, the option for controller A can be passed to controller B and vice-versa, which is not good.

I don't know if I can add some script in grub which would get the "which is which" device, and set the appropriate option in the kernel boot line, or if I can pass options to the libata after boot, via init for instance.

The other issue, which may deserve a separate bug report, is that the installer from the live CD assumes that sda is the boot disk, the MBR of which to put grub on. This is not always the case, because of this random name assignement to the disks we are discussing here. When performing the install, while modifying the partition table, I noticed that sda was not the disk the computer normally boots on. But I had no chance to tell the installer that grub should be installed in the MBR of sdb, not sda. Also, if the disk were not partitionned differently, I would have no chance to notice this reversal of device names.

I did not have such an issue with karmic.

[Mathieu31 (mathieu-belleville)]

I found that Bug #572086 is existing regarding the installer issue.

[Bib (bybeu)]

Same issue here.
It wouldn't be a problem if sdX naming convention was fully abandonned. Unfortunatly, many tools keep on using/showing sdX.
Is there a way to lock/stick a UUID to a sdX or to remove all sdX use/display in the system?
These random changes are confusing and puzzeling.
My boot drive is a PATA (/ /tmp) I want always sda. The second drive (/var /home /srv /swap) is a SATA attached to a PCI VIA VT6421
The issue began with the upgrade from KK to LL
Then I found that my 2 drives were swapped (The PATA was always sdb beginning with LL).
A disk dump shows that grub is in the MBR of the PATA and nowhere else.
I have the bios boot sequence set to HDD-0/disabled/disabled/disabled
Later I found that when enabling HDD prefetch mode in the bios (what is anyway a better setting), the random behaviour began. I can't figure if trying to manually set the IRQ's against PCI slots would help. I have no other bios settings that I can imagine related.
I found a file that shown (at a time the drives were swapped the wrong way - sorry I can't attach no more as the link is now broken)
<device DEVNO="0x0801" TIME="1277294149" UUID="06c51727-f382-456c-816c-92f31563673f" TYPE="ext4" LABEL="var">/dev/sda1</device>
<device DEVNO="0x0802" TIME="1277294149" UUID="47b31f91-0702-4543-8302-8c435ad0004f" TYPE="ext4" LABEL="home">/dev/sda2</device>
<device DEVNO="0x0803" TIME="1277294149" UUID="e1c6ec75-1822-4b2c-96c3-26c8b00cebcc" TYPE="ext4"LABEL="srv" >/dev/sda3</device>
<device DEVNO="0x0804" TIME="1277294149" UUID="ab161233-386c-4c17-9a5d-d02c91863145" TYPE="swap">/dev/sda4</device>
<device DEVNO="0x0811" TIME="1277294149" UUID="ab78dd83-1986-49c1-ad6d-e89567bd7f71" TYPE="ext4" LABEL="root">/dev/sdb1</device>
<device DEVNO="0x0812" TIME="1277294149" UUID="4271ee39-ab88-4045-bcfc-c374b15ccef9" TYPE="ext4" LABEL="tmp">/dev/sdb2</device>

[Bib (bybeu)]

EDIT: the file's name above was /etc/blkid.tab
Now, since the boot allocated the PATA to sda (OK), the /etc/blkid.tab link to /dev/.blkid.tab is no more broken so I attach it to compare

[Fabio Marconi (fabiomarconi)]

Hello
Is this problem present with the latest updated Lucid's or Maverick's packages?
Thanks in advance
Fabio

[Ridgeland (rambutan1)]

Hi Fabio,
I'm using Ubuntu 10.10 now. I still use UUID like I explained before like #5 above.
For a test in Ubuntu 10.10 I rebooted the PC 10 times and checked $ df
/dev/sda - 4 times
/dev/sdb - 6 times
On my PC /dev/sda is more likely after a cold boot after the hard drives have stopped spinning.
On a personal note this is not a problem for me. I just learned a different way.

[Ridgeland (rambutan1)]

My explanation looks fuzzy.
I was checking in df to see which drive / root was on.

[Roland Hughes (original-seasoned-geek)]

It stil exists in 10.10

On Monday, October 25, 2010 08:47:39 am you wrote:
> Hello
> Is this problem present with the latest updated Lucid's or Maverick's
> packages? Thanks in advance
> Fabio
>
> ** Changed in: ubuntu
> Status: New => Incomplete

--
Roland Hughes, President
Logikal Solutions

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol reserves.

[Jeremy Foshee (jeremyfoshee)]

Hi Ridgeland,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 569645

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Roland Hughes (original-seasoned-geek)]

I can tell you that 10.10 still had the bug. I had to strip my machine down
to a single SATA drive to get consistent boot.

sad

very sad

On Wednesday, December 01, 2010 11:41:28 am you wrote:
> Hi Ridgeland,
>
> This bug was reported a while ago and there hasn't been any activity in it
> recently. We were wondering if this is still an issue? Can you try with
> the latest development release of Ubuntu? ISO CD images are available
> from http://cdimage.ubuntu.com/releases/ .
>
> If it remains an issue, could you run the following command from a Terminal
> (Applications->Accessories->Terminal). It will automatically gather and
> attach updated debug information to this report.
>
> apport-collect -p linux 569645
>
> Also, if you could test the latest upstream kernel available that would be
> great. It will allow additional upstream developers to examine the issue.
> Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've
> tested the upstream kernel, please remove the 'needs-upstream-testing'
> tag. This can be done by clicking on the yellow pencil icon next to the
> tag located at the bottom of the bug description and deleting the
> 'needs-upstream-testing' text. Please let us know your results.
>
> Thanks in advance.
>
> [This is an automated message. Apologies if it has reached you
> inappropriately; please just reply to this message indicating so.]
>
>
> ** Tags added: needs-kernel-logs
>
> ** Tags added: needs-upstream-testing
>
> ** Tags added: kj-triage
>
> ** Changed in: linux (Ubuntu)
> Status: New => Incomplete

--
Roland Hughes, President
Logikal Solutions

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol reserves.

[Ridgeland (rambutan1)]

Hi Jeremy,

I don't mind helping, but I'm at the level I need much more detailed instructions.
I didn't see how to use your links.

I have 10.10 and installed and booted kernel 2.6.37-rc2.
The problem still exists.

I did not see where to download a 11.04 alpha version. If you want me to test that please give me a link to download the iso.

Thanks,
David

[Ridgeland (rambutan1)]

OK - more tests
I downloaded 11.04 alpha 1 from
http://www.ubuntu.com/testing/natty/alpha1
Date stamp is Dec 3.
Kernel is 2.6.37-7-generic
Bug persists - random assignment of drives as sda or sdb
(unity will be interesting - gets to desktop fast)

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu development release http://cdimage.ubuntu.com/daily-live/current/ . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]