[systemd-devel] nspawn and Qemu compatibility?

[Lennart Poettering]

On Fri, 03.04.15 14:14, Alison Chaiken (alison at 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