-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Bryan Kadzban wrote: > And I haven't done much with qemu other than build a pair of initial > 4G disk image files with the RAID signatures. I haven't actually > booted up the LiveCD on it yet.
OK, I got qemu running (after recompiling it with gcc-3.3.6, since the gcc-4 version segfaults on me when it tries to call through a NULL pointer), and I got a system copied to the fake fakeraid device. And I've checked in something that sort-of works. It runs through the initramfs without errors, and boots up and starts running the real init. However, if I activate the dmraid disk inside the initramfs, it won't re-activate once I hand control off to the real system. And I can't get at the initramfs's /dev/mapper/hpt* device files from the real system, so I can't just copy them. (Plus that'd be a problem when the udev script mounts its tmpfs/ramfs over /dev anyway.) I can't find much of anything that says how to recover from this; I assume that if I had the /dev/mapper/hpt* device file, I'd be able to manipulate the RAID, but if I had the file, I wouldn't have any issues either. So that doesn't really help. Any ideas? I'm assuming I'm going about this all wrong... Actually, looking at the Paldo /init that Dan linked to earlier, it appears they mount a separate tmpfs on /dev inside the initramfs, then "mount -o move" that to the real root just before running run-init. I suppose that would work, but it'd require changes in the LFS udev script. What do people think? Change the udev script, or is there another way to regenerate the /dev/mapper/hpt* node(s) before mountfs? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGiF+cS5vET1Wea5wRA1jRAJ9K8x8MvDx6GZbEdJD28nlrMAkv6wCfT1qq U1PfBWvNT5bj3kshRidWpwI= =OEPp -----END PGP SIGNATURE----- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
