On Fri, 03.04.15 14:14, Alison Chaiken (ali...@she-devel.com) wrote: > I've been using Qemu to cross-compile packages and root filesystems > for a while and thought I'd try nspawn instead. While I sometimes > want a full GUI desktop in the walled-off environment, mostly console > is enough, and for that nspawn sounds more efficient. > > Here's the base sequence: > > Install > ========== > qemu-img create -f raw /opt/debian.raw 50G > qemu-system-x86_64 -machine accel=kvm --enable-kvm --cdrom > /opt/debian.iso -boot d -hda /opt/debian.raw -m 4096 -net > nic,model=e1000 -net user,hostfwd=tcp:127.0.0.1:6666-:22 -name debian > -localtime -no-reboot > > Boot as Qemu > =============== > qemu-system-x86_64 -enable-kvm -boot c -hda /opt/debian.raw -m 4096 > -usb -net nic,model=e1000 -net user,hostfwd=tcp:127.0.0.1:6666-:22 > -name debian -localtime -machine accel=kvm -chardev > spicevmc,id=charchannel1,name=vdagent -chardev pty,id=charconsole0 > (inside Qemu) systemctl poweroff > > Login with nspawn > =============== > mount -t auto -o ro,loop,offset=1048576 /opt/debian.raw /mnt/loop
Why this offset? I'd really recommend letting the kernel figure out the partition table. I.e. use "losetup -P" to enable the kernel partition reading, and then mount the parition directly. Also note that systemd-nspawn in git should be able to do this all automatically for you with the "-i" switch, as long as you either have GPT partition table with the right partition type UUIDs, or you have a GPT/MBR partition table with a single data partition only. > [offset moves past /boot partition to linux ext4] > systemd-nspawn -D /mnt/loop > exit > umount /mnt/loop > > So far, all smiles. However, when I try the same "Boot as Qemu" > instructions again, the kernel comes up, but then "Reading hard disk . > . . " appears, and then nothing. So I guess that using > systemd-nspawn has somehow corrupted the filesystem, although I'm not > sure *why* that would happen. Is there some reason that switching > between nspawn and Qemu should fail, or that nspawn would have a > problem with a loop mount? Should I invoke nspawn differently? Hmm, that#s certainly weird. It's the host kernel that does the file systemd access here, it's not clear to me how that or systemd should corrupt the boot logic. Which boot loader is used? Maybe the boot loader relies on stable sectors or so? otherwise I really have no idea what might be going wrong. Note that our functional tests in systemd actually include a test where we boot the same image via qemu und via nspawn and make sure both times everything boots up correctly, hence this really should work... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
