I asked: >> I've been using Qemu to cross-compile packages and root filesystems >> for a while and thought I'd try nspawn instead. [ . . . ] >> Here's the base sequence: >> Install >> ========== [ . . . ] >> Boot as Qemu >> =============== [ . . . ] >> Login with nspawn >> =============== >> mount -t auto -o ro,loop,offset=1048576 /opt/debian.raw /mnt/loop >> [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.
Andrei Borzenkov <[email protected]> wrote: > Did you check if loop device was unconfigured? Just to exclude the > obvious. I'm not sure what you mean by "unconfigured". I tried rebooting in case systemd had somehow taken a reference on the raw image and wasn't releasing it, but that didn't help. "fdisk -l debian.raw" still shows the partition table. I'm creating a new GPT-partitioned image that I can save in /var/lib/machines in order to employ the more-recommended methods, but I'm curious why this method didn't work. I can still start the loop partition with nspawn, but Qemu doesn't like it anymore. Thanks, Alison -- Alison Chaiken [email protected] 650-279-5600 http://{she-devel.com,exerciseforthereader.org} One consumes a great deal of silence in the course of becoming educated. -- Matthew B. Crawford _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
