Heya, Chris Marusich <cmmarus...@gmail.com> skribis:
> I've been looking into this off and on over the last few weeks, but I > haven't made any breakthroughs. The closest I got was this: > > 1) Create a disk image for testing: > > ./pre-inst-env guix system --root=/tmp/disk-image-gc-root --fallback > disk-image ~/guix/gnu/system/install.scm > cp $the_resulting_path /tmp/disk-image > > 2) Try to boot it (with an attached hard disk), and watch it fail: > > qemu-img create -f qcow2 /tmp/test 10G > sudo qemu-system-x86_64 -machine type=pc-i440fx-2.5,accel=kvm -boot > order=dc,menu=on -m size=4G -k en-us -name guixsd -cdrom "/tmp/disk-image" > "/tmp/test" > > 3) Mount it as loopback device: > > sudo losetup -P /dev/loop0 /tmp/disk-image > sudo mkdir /mnt/disk-image-partition-1 > sudo mount /dev/loop0p1 /mnt/disk-image-partition-1 > > 4) Make a bootable CD-ROM image of it (see (grub) Invoking grub-mkrescue): > > sudo grub-mkrescue -o /tmp/test-img.iso /mnt/disk-image-partition-1 > > 5) Try to boot (partial success): > > sudo qemu-system-x86_64 -machine type=pc-i440fx-2.5,accel=kvm -boot > order=dc,menu=on -m size=4G -k en-us -name guixsd -cdrom "/tmp/disk-image" > "/tmp/test" > > There appear to be (at least) two problem that prevent this naive > solution from working, which might point us in the right direction: > > First, the GRUB menu is trying to find a file system with label > "gnu-disk-image" (via "search --label --set gnu-disk-image"), which > won't work because there is no file system with that label in the > resulting image. So it seems that the crux of the problem is that ISO9660 lacks file system labels, which breaks the whole thing, right? > Possible fix: the manual for grub-mkrescue says "The > root device will be set up appropriately on entering your 'grub.cfg' > configuration file", so perhaps we can simply omit our --search. FYI, > the boot process continues successfully past this point precisely > because GRUB has already set the root; the fact that our search command > failed generates an error message but does not change the fact that it > succeeds in booting to the initrd. Good. > Second, the init process from the initrd (I think that's what it's > called?) is trying to look for a file system with label > "gnu-disk-image", which it never finds. It just sits there waiting to > find it, and it never shows up, so it freaks out. Possible solution: > modify the behavior of our initrd's init process. I'm not sure how to > customize the init process here, but there must be a way. We'll > probably also need the kernel module that enables reading of iso9660 > file systems, if it wasn't present already. So we could try detecting the root partition by a mechanism other than partition labels/UUIDs, but I don’t know which mechanism. Ideas? How do people address this? > If you don't like grub-mkrescue, you can "roll your own" ISO generation > program, like Nix does by customizing the xorriso invocation [1]... But > honestly, it looks pretty complicated [2]. So if we can let > grub-mkrescue do that work for us, that would be swell. Indeed, though of course grub-mkrescue invokes xorriso behind the scenes. Once we’ve figured out the partition designation issue above, I guess we could integrate that and have, say, guix system iso-image … to produce an ISO image. Sounds doable! Thanks for the explanations, Ludo’.
