Forgot one thing in that script, just after the shebang, mount -t proc proc /proc mount -t sysfs sysfs /sys
or else you won't be getting very far On 1/15/10, Hops Error, Line 21, alcoholi.c <[email protected]> wrote: >> I will re-read it, I'm glad I'm headed in the right direction. >> Is there anything else that might help me with the process? Any help >> at all would be greatly appreciated. > > Just this, from bitter experience: build everything so it boots from a > USB stick first, and then write just your filesystem to a non-bootable > CD second. Then, when that works, build a livecd. This avoids making a > million coasters and costing you a king's ransom in plastic whose only > value is sparkling and cracking in the microwave. > > Disclaimer: None of the following is specific to LFS, and it all has > to do with live cds and problems you'll run into on any linux at all. > > A USB stick can be partitioned just like a hard disk (provided you > don't try to read it in a windows machine even if it has ext3 support; > windows just can't read partitioned disks), and grub can be installed > into the root of the device. So the process is identical to a hard > disk install. > > What isn't identical, is your module configuration. This is where that > "works" thingie you were talking about comes into play. Your kernel is > going to have to be able to configure your device drivers. In order to > do that, it needs to recognize your device drivers. Which means, > before you, the user, ever touch the keyboard or type command #1 in, > your computer has to run modprobe a few dozen times. To make matters > more complicated, there are a few cases where probing the wrong driver > on the wrong hardware hard locks your computer and/or makes your > kernel panic. > > The beauty of setting things up this way, is that if it doesn't work, > you just tweak a couple things and try again, no cds or dvds being > thrown into the garbage. > > My favorite way of working all those miracles is with an initrd. > Chances are your favorite distro does things exactly the same way. To > make one, go into a directory you want to be your root directory, and > then do this: > > mkdir -p lib/modules/ > cp -r /lib/modules/2.6.[kernel version] lib/modules > cat > init << "EOF" > #!/bin/sh > > MODULES= > ROOT=/dev/sr0 > ROOTTYPE=iso9660 > > for module in $MODULES > do > modprobe $module > done > > mount -t $ROOTTYPE $ROOT /newroot > if [ -x /newroot/sbin/init ] > then > umount /sys /proc > exec switch_root /newroot /sbin/init > else > echo "init not found, dropping to debug shell" > /bin/sh > fi > EOF > mkdir {newroot,dev,sys,proc,bin} > > Then, drop a static shell (busybox might be tempting here, but the > question that led me to this list involved busybox sucking with > kernels > 2.6.26, dunno if they ever fixed the way it looks up device > drivers) (to compile a static shell, make coreutils with the > CFLAGS=-static and CPPFLAGS=${CLFAGS} options) in ./bin > > Now, to make that initrd, it's > find . | cpio -H newc -o | gzip - > ../initrd.igz > > And, to open it back up and modify it, it's > zcat ../initrd.igz | cpio -i > > which will dump the contents back into the current directory. > > Grub has instructions and support for using that initrd with your kernel. > > That script I gave you won't work the first time, by the way. It's > designed to drop you down to a shell that will let you run modprobe, > etc, look at your device drivers, and do whatever you have to do to > get your system to boot. Once you're inside your system, you can open > up and modify your initrd so that your script will repeat whatever > steps you took to get into your system. Since your system is on a CD, > that means that when you do decide to make a live CD, every driver and > part of your system will already be working properly, and if it > doesn't just to spite you, you have a tool for getting it to work. > > At the end of the day, it limits the number of CDS you have to burn > before everything works to 3. > > To get a device driver to work, look in /lib/modules/2.6.[kernel > version]/kernel for a file that ends in ko, and then do this > modprobe `basename ${file%.ko}` > > To get it to show up, you're probably going to be relying on your udev > daemon or a script (this was precisely where busybox failed me; its > mdev script just couldn't make heads or tails of the way linux moved > stuff around in /sys). A good trick to see if your kernel is > recognizing something that udev isn't is this > > lsusb > > and another one is > > lspci > > if either of those say anything about your hardware (manufacturer, > whether it's a wireless card, etc), your hardware is working, your > kernel module is loaded properly, and udev is dropping the ball. > > All that sounds a lot more complicated than it is (sorry about that), > but it all boils down to this: > > Make a bootable usb stick, THEN make a livecd > > Good luck :D Let me know how things go for you, I know my e-mail addy > is funny looking but it's real and it works, and remastering livecds > in general (not specifically LFS, I started with DSL and Knoppix) is a > wall I've been beating my head against for a while. Please feel free > to ask me any questions not directly related to BLFS, especially > related to remastering. Helping you helps me. > -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
