[Bug 47768] Solutions for USB Boot problem.

Thu Apr 17 13:33:58 UTC 2008

Hi!

Well, I had an idea what could be the problem about USB drives, and
began to create this report. Meanwhile I was googling around and
realized the true  error, and have written down some solutions, and so
reedited the text. But finally the whole thing became a little fuzzy,
and now I don't have the mood to fix it. So there it goes, solution,
problem, reason of the problem, and everything, but very mixed. Read
through.

The ubuntu system uses the UUID of the disks and partitions to identify
them at boot time. If you open /etc/fstab and /boot/grub/menu.lst - if
you use grub which is used on ubuntu by default boot manager, if you use
lilo i don't know what is the proper file - you will see, that there are
no /dev/hdaX names, as it should, when humans create it by hand, but
very long alphabetical strings tagged with minus signs. These are UUID's
created to indetify disks independent from boot order, master-slave
structure, and way of connection. So if you unplug your ata drive, put
it in a rack, and reconnect with USB you should still have the same
UUID, and so the booting system could find it in the same way. When
using /dev/sda-s this could be a problem, because your disk's device
name would be changed from /dev/hdX to sdX

Ooops...
But... Maybe the problem is, that your ubuntu system doesn't use this UUID's. Well, I admit, that I only installed gutsy a few months ago, and I don't know the older systems - before I used Gentoo. Gutsy uses these UUID's, but maybe earlier releases don't, and so You might have a release where it is handled differently. Anyway You should look after the generation of UUID's, and see if this could be a problem. If I had to bet, I would put a lot of money on, that this is the source of the problem.

I just looked for this UUID thing, and realized, that this feature is
usable only from 2.6.20 kernel, which means only after feisty. So this
might be not your problem. Well, still, my report can give you some
thoughts.

Well I don't know how these strings are counted, but I know, that ACPI
USB support means that if you connect an USB tool at boot time, which is
recognized as data storage, then it will be categorized either as usb
pen, or as usb hard drive. This categorizing happens simply by guessing
about the size. If the USB storage is bigger than a specific size limit,
then it is used as a drive, otherwise as a pen. This size limit can be
changed but, I have never met a BIOS where this size limit was current.
Usually the maximum of this value was always about the average USB pen
size on the market, but there are chances, that you couldn't even set
this size limit.

If that's the case, then I don't know if it has something to do with the
UUID-s generated for drives, but it might be. The hardware configuration
has changed, new drives are in, and so the uuid's could be changed too.
(later post) Well this is definitely what UUID should NOT work. And I
think it works well. The problem of yours was not using UUID's.

Why UUID's, and what is this all about:
UUID's are created so that it could identify your drive, even if it is connected to a different place. This is useful in a desktop computer, where you might put in a new disk, maybe change two disks place, but you want to be able to still boot in and use your linux. But changing the order of the disks changes /dev/sdX names too, so if you would use these names, the boot manager would try to boot a different disk from your real kernel. 

Example1: You have an IDE drive jumpered, to master, your friend comes,
and he has a master too, but he needs one jumper to make it slave, which
you don't have. So you make your drive slave, but make the bios still
boot your drive. But, /dev/hda will be the master, and /dev/hdb will be
the slave, and so grub can't find you.

(While creating these examples I realized what the real problem was, so here it comes)
Example2 - this might be the case for all of yours: You have a sata drive, a ACPI BIOS with 512MB hard drive limit, and a 1GB USB pen. You install the system, and your SATA drive gets the /dev/sda name in grub, and in fstab. Then you attach the pen, which is recognised by the ACPI as a USB drive. and so propagated to the system. Because USB drives get the /dev/sdX names too, and the naming depends which device is found earlier, You might get the /dev/sda device identifier for your pendrive, and a /dev/sdb identifier for your SATA drive. To be exact: the BIOS will still boot your SATA drive - because it knows that it's a new drive, and not the one to boot. Grub will found your image too, because it searches the image partition not by dev name, but by it's 
own naming system. You can see this in /boot/grub/menu.lst as 'hd(0,0)' or similar. This isn't affected by usb drives either.

root              hd(0,0)  -- not affected by pen drive
kernel           vmlinuz... root=/dev/sda (!!!) -- mixed by the pendrive as acpi says it's a drive too.

And there it goes. Boot in, root not found, kernel panic.

The solution could be:

1. change the size limit in BIOS upper your USB drive's size.
2. figure out what new device name is given to your root partition, and create an entry in grub:

If the normal boot had the parameter /dev/sda5 then it should have
/dev/sdb5. If two usb will be attached it should be /dev/sdc5

title           Ubuntu 7.10, USB attached
root            (the same as normal)
kernel          (the same as normal) root=/dev/sdb5 (the same as normal)
initrd          (the same as normal)

3. change to kernel above 2.6.20 where there is UUID support.
4. disable acpi drive support. This makes only this one thing. It makes the USB drive available to use at boot time, so normal OS'es can use them as boot drives. And that's exactly what bothers you.

5. look for another way to identify your root filesystem. On my gutsy I have /dev/disk/by-... directories. These are links to the disk in the same way, as /dev/sdX are. So they are exchangeable. If you find some good identification link which is not affected by the USB's ... (good chance, that pci addresses are not affected for example), you could use that in '/boot/grub/menu.lst' and in '/etc/fstab'
I don't know if there is any GUI program to make these changes. I had gentoo, where everything should be set up by hand-editing these files, so I am familiar with it.

The reason of this problem is, that USB drives are handled by kernel on
the same interface as SATA. It means kernel creates a controlling
interface to operate the disks, and then disk drivers use this to make
the SATA disks reachable. The USB driver uses this SATA controlling
interface too, so it is threated as a SATA drive too. This is a nice,
easy, and effective solution for operating USB drives, as SATA is
created for fast disk connections, and USB is a fast disk. But it leads
to this error in identification. Solution could be to make USB drives
identified later than true SATA drives. But now, as there is UUID's the
whole question get's outdated. But I think this should be done anyway -
linux is about choices, so should operate well in this old way too.

How to change dev/sdaX:
First choose a suitable new identifier for your drive from /dev/disk/by- directories. If there is no dirs like this, Then I can't help you.
I choose for example  '/dev/disk/by-path/pci-0000\:00\:12.0-scsi-0\:0\:0\:0'
You should really take care, to choose the identifier right for your true root disk.

My /etc/fstab file has a line:
(To be honest it doesn't really have, as I use gutsy, which uses UUID's, but this is an example)

proc              /proc           proc    defaults                                    0       0
/dev/sda5        /               ext3    defaults,errors=remount-ro     0       1

I would change it to:

proc                                                                                      /proc           proc    defaults                                   0       0
/dev/disk/by-path/pci-0000\:00\:12.0-scsi-0\:0\:0\:0-part5   /                   ext3    defaults,errors=remount-ro   0       1

Do this with all the other fstab lines too, which is about /dev/sdaX (or
sdbX, so it's your root disk). For any other lines not affecting this
drive leave it unchanged. Notice the -part5 at the end. if you change
sda4, this should have -part4 at the end.

The root partition's name should be changed in '/boot/grub/menu.lst' too
- this is much more important than the fstab file.

Finally let me point that I'm not an Ubuntu developer, and this solution is not an official one. This is just workaround for the problem. And surely it's not that easy to do it right. Messing with /etc/fstab and /boot/grub/menu.lst can make your system unbootable, even without pen drives - don't be so scared, it will not ruin data on your disk. By doing these changes You should have a Live CD at hand, and make copies from the original files. These files can only be edited with root privileges, so GUI editors are a bit complicated to use too. For that type in terminal 'sudo gedit /etc/fstab' in gnome,
and 'sudo kde-guieditor-name /etc/fstab' in kde :)

Let me express that it's true there are 3 or 4 different bugs in this
thread. My solution is for the very first bug, and only, if the
connected usb periperial was a pen drive, or a camera. If the first
error posters had these booting problems with an usb mouse too, then
there was some really serious bug, and not something like this.

Best regards, Gábor.

-- 
Mount Root Files System Failed
https://bugs.launchpad.net/bugs/47768
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to initramfs-tools in ubuntu.