Bryan Kadzban wrote:
I have it copying all kernel modules into the initramfs, which ends up making it enormous if I run it after installing the nvidia module. (The nvidia module is 9M. Non-nvidia modules total up to about another 8-9M uncompressed on my system. The compressed initramfs is about 8M.) I could just copy modules that are expected to be required to get the root FS up, but then I'd have to rerun depmod, and that means I'd have to create a separate copy of the /lib/modules/$KVER tree.
Debian users of initramfs-tools can choose which set of modules to include in the initramfs via config file. Yaird even guesses this information automatically at initramfs build time by looking into sysfs, but (as a result) an initramfs created by yaird is not suitable for other computers, because it includes only the minimal set of modules.
(And I don't copy /lib/firmware to the initramfs. Perhaps I should.)
Yes, you should. IBM ServeRAID looks like a SCSI adapter, but requires firmware.
I'd like to get this working with devmapper and dm-raid if possible eventually (and other setups), though I can't test any of that. But before I do that, I'd like to get some comments from others.
You can test dmraid even without the corresponding hardware. Simply install qemu or any other emulator, connect two disks of the same size to the virtual machine, and dd the two attached files to them, so that they both appear at 11th sector from the end of the disks. On a real machine, it is the BIOS job to write them, but the attached fake signatures are just as good for testing. E.g., for qemu and 2GB disk images:
dd if=/dev/null of=hda.dsk seek=4194304 dd if=/dev/null of=hdb.dsk seek=4194304 dd if=format0.bin of=hda.dsk conv=notrunc seek=4194293 dd if=format1.bin of=hdb.dsk conv=notrunc seek=4194293 qemu -hda hda.dsk -hdb hdb.dsk -cdrom lfslivecd-x86-6.2-5.iso -boot dThen, in qemu, run "dmraid -ay". In bootable setups, this goes both to the initramfs and in the bootscripts, immediately after udev, and you also need the -i switch due to /var/lock not being available for writing. This command will find the fake HPT45X RAID1 signatures from the attached files and make the /dev/mapper/hpt45x_cabijbfdeg device. You can "partition" it with fdisk (ignore the error at the end) and rerun "dmraid -ay" for the device mapper to see the newly created partitions (they would have names such as /dev/mapper/hpt45x_cabijbfdeg1). Then, treat these devices as you would normally do: make a filesystem, install LFS (by transferring a known good installation via tar, because QEMU is too slow to compile stuff).
To install GRUB into MBR, use these commands instead of what the book says: mkdir -p /mnt/raid/boot/grub cp /usr/lib/grub/i386-pc/*stage* /mnt/raid/boot/grub grub and in the grub shell, type: device (hd0) /dev/mapper/hpt45x_cabijbfdeg root (hd0,0) setup (hd0) quit Then "qemu -hda hda.dsk -hdb hdb.dsk" should boot from this fake RAID. Hope this helps. -- Alexander E. Patrakov
format0.bin
Description: Binary data
format1.bin
Description: Binary data
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
