booting linux from a USB flash key

ridesideways · 10-06-2004, 08:45 AM

i am trying to create a usb flash key with a bootable linux partition. basicly, on our main linux server, i partition the usb flash key, copy the root files over, and then run lilo to make the usb flash drive bootable. i take my usb flash key to another machine and install it and boot that machine (that machine has no internal hard drive). the linux kernel loads and boots successfully and then eventually kernel panics saying it can't mount the root file system and to check my 'root=' line in lilo.conf.

i am using linux kernel 2.4.24

i've used the above procedure to create countless bootable linux IDE disks, so i'm quite sure the problem isn't related to my root filesystem, but is related to the fact that it is a usb flash drive.

as you know usb flash drives are seen as scsi drives. my kernel includes all the drivers to run a usb flash drive (uhci, usbcore, sd_mod, usb-storage, etc) and none are modules (they are compiled into the kernel).

here is my lilo config file:
disk=/dev/sda
bios=0x80
boot=/dev/sda
map=/mnt/roflash/boot/map
install=/mnt/roflash/boot/boot-compat.b
lba32
force-backup=/dev/null
image=/mnt/roflash/boot/vmlinuz
label=linux
root=/dev/sda1

as you can see, on our linux server i've mounted the usb flash drive (/dev/sda1) to /mnt/roflash to create the bootable usb flash drive. then when the usb flash drive boots in another machine, it should still be seen as /dev/sda (the first scsi drive). but, unfortunately, it doesn't work. as i mentioned previously, i get the dreaded can't find root filesystem, check you're 'root=' line in lilo.conf.

can anyone offer any suggestions on getting this to work? thanks in advance for any advice!

-eric

ridesideways · 10-06-2004, 09:06 AM

i ran a couple of tests to determine exactly when during the boot process a usb flash drive is detected by the usb-storage kernel driver.

on our server that boots of its local IDE drive, i looked in /var/log/dmesg to determine where in the boot process the usb flash drive is first detected and assigned a USB address.

then i tried booting from usb flash drive in the other machine to see where in the boot process it is failing to find the root filesystem (as described in my post above).

by comparing these two boot sequences, i can see that the USB flash drive is not assigned a USB address until *AFTER* the time when the kernel looks to find the root filesystem. so obviously this is probably the source of the problem.

so now the question becomes, how do i get the usb-storage kernel driver to detect my USB flash drive immediately? because obviously if it doesn't detect the USB drive until later, then the kernel can't find the USB flash drive when it comes time to find the root filesystem (the root filesystem is of course on the still-undetected USB flash drive).

any advice is appreciated!

-eric

Thymox · 10-06-2004, 10:01 AM

You could create an initial ramdrive image (initrd) that initialises the USB system. That way the USB system is initialised before any control is handed over to the system being booted. (Did that make sense?)

I do not know if this would work successfully, being that the initrd would (logically) reside on the same flash-drive as the rootfs, but it's worth a shot. It is, AFAIAA, the same method used when the rootfs is on an fs that can't be read by the kernel (ie the rootfs is, for example, on jfs and requires a kernel module in order to read it).

ridesideways · 10-06-2004, 10:08 AM

Quote:

Originally posted by Thymox You could create an initial ramdrive image (initrd) that initialises the USB system. That way the USB system is initialised before any control is handed over to the system being booted.

yes i should have mentioned that in my previous post. i did make it successfully work with an initrd image. i was able to boot an initrd off the usb key and it worked in a ramdisk.

but, my initrd image is 32MB so it took almost 5 minutes load the image from my flash key (the computers are all USB 1.1). no one wants to wait 5 minutes every time they boot a computer...

since it takes so long to boot a 32MB initrd image, i wanted to create a regular root filesystem on the usb drive to speed up the boot process.

-eric

Thymox · 10-06-2004, 10:14 AM

Why is your initrd image 32Mb? Are there things in it that aren't really required? Has it been compressed (use gzip, not bzip2)?

ridesideways · 10-06-2004, 10:29 AM

Quote:

Originally posted by Thymox
Why is your initrd image 32Mb? Are there things in it that aren't really required? Has it been compressed (use gzip, not bzip2)?

everything in there is required. we are running our company's software suite and it requires various debian packages, not to mention that our software is itself 16MB.

the initrd image is compressed with gzip -9.

i suppose i could split up the initrd filesystem and only have those things absolutely required for booting in initrd, and have the other stuff in another filesystem. it seems like such a split would be relatively time-consuming to implement and require dissection of the OS.

it just seems like there's got to be a way to get the usb-storage driver to recognize USB devices that are present when the usb-storage driver is initialized during kernel boot...

jschiwal · 10-06-2004, 05:40 PM

Are you mistaken about the usb and scsi modules being compiled in the kernel and not modules? If you uncompress the initrd file onto a file ( on a computer with a hard drive ) and mount the file as a loop-back device, you can determine which modules are present in the initrd file. These will be what are taking up the space. (tip: you may need to rename the initrd file as initrd.gz to get it to uncompress)

There may be module support for devices that you don't need which increased the size of the intrd file. If the modules were compiled in the kernel and not as modules, they should be present in the kernel rather than the intrd file, if the initrd file was produced when you re-compiled the kernel.

ridesideways · 10-07-2004, 07:42 AM

i am absolutely certain the scsi/usb drivers are not modules. i have been building linux kernels for years. in fact, when i use the identical kernel binary to boot off the IDE drive in our sever, it sees the USB drive (and lsmod shows no USB drivers listed).

the solution to the problem ended up being to patch to the kernel to retry mounting the root filesystem if it failed. this gives the usb-storage driver a chance to detect the USB drive. basically i modified the mount_block_root function in do_mounts.c of the kernel source. as you can see in the code below, it retries opening the root filesystem until it succeeds.

this solution worked for me. basically when you boot with this patch, you can see the messate "Retrying opening of root filesystem" (so it fails to open the root filesystem once) and then it sleeps for 1 second. during this sleep you get the usual USB messages show that it detected the USB drive. then on the second try of opening the root filesystem, it succeeds and boots normally.

probably a hack so it won't ever be a permanent part of the kernel, but it works. thanks to everyone for their ideas.

Code:

retry:
        for (p = fs_names; *p; p += strlen(p)+1) {
                int err = sys_mount(name, "/root", p, flags, root_mount_data);
                switch (err) {
                        case 0:
                                goto out;
                        case -EACCES:
                                flags |= MS_RDONLY;
                                goto retry;
                        case -EINVAL:
                        case -EBUSY:
                                continue;
                }
                /*
                 * Allow the user to distinguish between failed open
                 * and bad superblock on root device.
                 */
                printk ("VFS: Retrying opening of root filesystem \"%s\" or %s in 1 second.\n",
                        root_device_name, kdevname (ROOT_DEV));
                current->state = TASK_INTERRUPTIBLE;
                schedule_timeout(HZ);
                goto retry;
#if 0
                printk ("Please append a correct \"root=\" boot option\n");
                panic("VFS: Unable to mount root fs on %s",
                kdevname(ROOT_DEV));
#endif
        }
        panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
out: