> > > If I understand right, the steps are: > > > > > > 1. Create and compile a kernel of your choice. > > > 2. Create a Minix file system and populate it with the contents of > > > root.lrp > > > 3. Compress the Minix filesystem with gzip and put on disk as initrd.gz > > > 4. Modify linuxrc to run /sbin/init at the end > > > > I don't think this is the best way to solve this. IMHO, it's better to have > > the kernel boot with root=[!ram0], which will get linuxrc running. Linuxrc > > should then set the real root device to /dev/ram (or your tmpfs or ramfs > > device) by writing to /proc/sys/kernel/real-root-dev (see initrd.txt in the > > kernel Documentation directory). > > How does this affect the steps I put forth? I don't see that it does.
There ARE minor changes... > I had assumed that /linuxrc would just run; now you say that the "root" > parameter needs to point somewhere other than /dev/ram0 . That's > alright, but that doesn't change the steps does it? > > According to initrd.txt, it would appear that the usual way of doing > things is, at the end of /linuxrc, to pivot_root and then run init. That's one way...keep reading... > I was thinking one doesn't need to pivot_root at all - and the > documentation alludes to such situations. Is there a problem if > pivot_root isn't used? > > Is it right to say that pivot_root and /proc/sys/kernel/real-root-dev > are both new to Linux 2.4? No. /proc/sys/kernel/real-root-dev came straight from my 2.2.x documentation. OK, in the normal kernel 2.2.x (and I believe 2.4.x), linuxrc is a mechanism mainly intended for installing kernel modules so you can boot off that brand-new fiber-channel SAN array (or SCSI drive, or whatever) without having to build thousands of unique kernels if your making a distrubition. The kernel sort of does an implicit 'pivot root' when running a typical boot-sequence with an initial ramdisk. First, the initrd is mounted as root, and linuxrc is run. When linuxrc exits, the kernel mounts the real-root-dev, and spawns init (hopefully never to return). The linuxrc script can CHANGE the value of real-root-dev while it is running by writing into /proc. If linuxrc does not do this, the root device will remain whatever it was before (either the device hard-coded into the kernel, or whatever you passed on the kernel command line). OK, now one problem is that linuxrc doesn't always get run. If the kernel is booting with an initial ramdisk, AND the root device is the ramdisk, the kernel assumes you built a tiny recovery file-system and want to run init, NOT linuxrc, so the above processing is completely bypassed (the ramdisk is mounted as the real-root-device, and init is run...if it ever returns, it's kernel panic time). This is the reason for the existance of the linuxrc-always patch...it runs linuxrc EVEN IF the root device is the ramdisk. Again, the code in init/main.c goes a long way towards explaining exactly what's going on...compare the patched and un-patched version to see the changes the LRP patches make. IMHO, the "boot-loader" functionality should be done with /linuxrc functionality, and once enough of a root filesystem has been pieced together on some other mount-point, the boot code exits, the kernel mounts the new FS as root, and init starts running. Exactly how much is done in the "boot-loader" code, and how much is done in startup scripts once init is running is still up in the air at this point, and there are lots of tradeoffs. Regardless, the boot code in the initial ramdisk could easily be discarded or copied to the new root filesystem, depending on particular system requirements... _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
