Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
ok. here's a problem Iím having and Iím hoping someone can help?
I'm building a little ucLibc/busybox system that boots off a usb flash drive (flash and a floppy at the moí).
/ is mounted read-only off a cramfs partition on the flash (why bother with a ramdisk - seems inelegant). the intention is to build a ramdisk for /tmp and /var.
In order to avoid having to faff about populating a /dev dir on a ramdisk (again, inelegant) I thought Iíd use devfs.
I have an initrd that loads the necessary modules (cramfs, usb-storage etc).
When i boot the kernel I pass root=/dev/scsi/host0/bus0/target0/lun0/part1 from grub (the cramfs partition on the usb device). However, the node/devfs entry is not made by devfs until after the kernel has started booting, apparently when the usb-storage module loads. This appears to confuse the kernel when it tries to mount root=/dev/scsi/host0/bus0/target0/lun0/part1. It can't find /dev/scsi0/bus0/target0/lun0/part1 and even refers to it as 00:00 (as in the device node major and minor), just before it panics.
It seems to be a devfs thing as Iíve produced the system with an near identical kernel, just without devfs (this time passing root=/dev/sda1 from grub) and it works fine.
Here are a few things Iíve tried:
no devfs kernel, root=/dev/sda1 (works)
devfs kernel but passing root=/dev/sda1 from grub. I believe this should work, but it doesn't...
devfs kernel, monolithic (ie, no modules, no initrd), pass root=/dev/scsi/host0/bus0/target0/lun0/part1. doesn't work ("unable to mount root on 00:00 as before")
no devfs, monolithic (as above), root=/dev/sda1. works fine
As far as i can work out the problem stems form the kernel needing to decipher the location of the rootfs passed from the bootloader at some point before the information is made available to it by the usb-storage code initialising and devfs creating the device node (am i right?). Can anyone think of a way round this? Does anyone have any more info on the process the kernel goes though when passed a root= parameter by a bootloader? Obviously it canít examine a /dev/node as the root is not mounted so how does it work out the root device from the parameter?
Incidentally I have inserted code into domounts.c in the kernel sources to delay the mounting of root to allow for USB device initialisation, which works without devfs but makes no difference with it. usb-storage has plenty of time to initialise as the non devfs kernel mounts root but the devfs one still falls down.
Yeah, this appears to be broken for devfs since 2.4.19. The old patch to wait and retry is needed, but in a different place. In init/do_mounts:mount_root, after the tests for NFS mount, there is a call to devfs_make_root, followed by a call to create_dev. Prior to the call to devfs_make_root, the USB userland daemon needs to run to instantiate the USB device into the system. Then either the devfs path or the non-devfs form on the root= should work. However, notice that the devfs form is pased on the command line in a weird format (see convert_name for details). In the non-devfs format, the device is looked up in the name_to_kdev_t converstion routine, and the MAJOR/MINOR number is taken from the table. If the device exists, devfs is searched to find the real device handle. Otherwise, the links should be setup from the call to devfs_make_root.
In any event, if the device doesn't exist prior to these function calls, you're gonna' panic.
I'm working on a patch, but had hoped to find an "official" patch from kernel.org. So far, no luck.