Open PhilipSnell opened 1 year ago
The same happens for me (via mock/koji/etc.)
DEBUG util.py:535: Using nspawn with args ['--capability=cap_ipc_lock', '--bind=/tmp/mock-resolv.zoubxl9y:/etc/resolv.conf', '--bind=/dev/btrfs-control', '--bind=/dev/mapper/control', '--bind=/dev/loop-control', '--bind=/dev/loop0', '--bind=/dev/loop1', '--bind=/dev/loop2', '--bind=/dev/loop3', '--bind=/dev/loop4', '--bind=/dev/loop5', '--bind=/dev/loop6', '--bind=/dev/loop7', '--bind=/dev/loop8', '--bind=/dev/loop9', '--bind=/dev/loop10', '--bind=/dev/loop11']
DEBUG util.py:445: [ INFO ]: 15:16:00 | Creating raw disk image /builddir/result/image/gdc-c9s-Cloud.x86_64-0.0.2.raw
DEBUG util.py:445: [ INFO ]: 15:16:01 | --> using all_freeMB for the root(rw) partition if present
DEBUG util.py:445: [ INFO ]: 15:16:01 | --> creating root partition [with 0 clone(s)]
DEBUG util.py:445: [ INFO ]: 15:16:01 | --> setting active flag to primary boot partition
DEBUG util.py:445: [ INFO ]: 15:16:01 | --> setting start sector to: 2048
DEBUG util.py:443: [ ERROR ]: 15:16:01 | KiwiCommandError: partx: stderr: partx: /dev/loop1: error adding partition 1
DEBUG util.py:443: , stdout: (no output on stdout)
DEBUG util.py:445: [ INFO ]: 15:16:01 | Cleaning up LoopDevice instance
I've tried to add --verbose
to partx:
[ DEBUG ]: 16:58:36 | EXEC: [partx -v --add /dev/loop0]
[ DEBUG ]: 16:58:36 | EXEC: Failed with stderr: partx: /dev/loop0: adding partition #1 failed: Device or resource busy
partx: /dev/loop0: error adding partition 1
, stdout: partition: none, disk: /dev/loop0, lower: 0, upper: 0
/dev/loop0: partition table type 'dos' detected
range recount: max partno=1, lower=0, upper=0
Trying it with strace
:
ioctl(3, BLKPG, {op=BLKPG_ADD_PARTITION, flags=0, datalen=152, data={start=1048576, length=1142947840, pno=1, devname="", volname=""}}) = -1 EBUSY (Device or resource busy)
Running sudo partx -d /dev/loop0p1
from host, and then running the relevant partx --add
from container does the trick…
[ INFO ]: 17:23:30 | --> setting active flag to primary boot partition
[ DEBUG ]: 17:23:30 | EXEC: [parted /dev/loop0 set 1 boot on]
this command makes the /dev/loop0p1
appear on a host system but not inside of nspawn…
Would it make sense to switch from loop devices and all this mumbo-jumbo to using nbdkit? Not sure how exactly but as I understand it correctly, it should have similar capabilities and would not cause same issues as we have currently in this ticket.
To me this sounds more like a partx issue inside of the container not running udev for device creation ? just guessing. So switching to the old device mapper based kpartx should imho solve your problem. You can try this by making sure your container provides a kiwi config file /etc/kiwi.yml
with the following setting
mapper:
- part_mapper: kpartx
kpartx creates the devices in /dev/mapper and doesn't need extra services or events to do the job
maybe worth a try
@schaefi with kpartx, there are issues inside of systemd-nspawn (but different set of them)...
@schaefi with kpartx, there are issues inside of systemd-nspawn (but different set of them)...
Hmm, ok so you think nbdkit would solve this ? I haven't looked into this and sorry for the late reply. I'm afraid there will be no free slot for me to work on this topic
@rwmjones is the main developer of nbdkit, and he's written some blog posts on it that are quite helpful in understanding it. It seems one of the bigger advantages of nbdkit would be to be able to do everything unprivileged. We might want to also explore ublk for similar reasons...
That said, it seems like the issue has to do with what happens with automatically enumerated partitions from a loop device, which is a kernel thing, not a partx
thing.
ublk
unfortunately won't let you do stuff unprivileged.
nbdkit
will let you create a disk image with a partition, but I'm not sure it really solves what you're trying to do here. Nevertheless these plugins could be interesting: https://libguestfs.org/nbdkit-linuxdisk-plugin.1.html https://libguestfs.org/nbdkit-floppy-plugin.1.html
libguestfs
will run up a qemu instance and let you run commands inside, which is all unprivileged from the point of view of the host.
It looks like loopfs
would help based on this LWN article, but I can't figure out what happened to it..
@brauner, I can't seem to figure out what happened to loopfs
, could you tell us what happened to it? It would be tremendously useful for us if we had it...
So loopfs
as a concept is mostly dead because the block people didn't like it being a filesystem. And I think that they're right. I have a plan to implement something that isn't tied to a filesystem at all. So basically a purely fd based API possibly.
mapper: - part_mapper: kpartx
kpartx
fixed building for me inside a privileged tumbleweed
podman container - I can now retire my image building vm
(many thanks ;o) :iso
image installed without any problemspodman
container with:
sudo podman run -h tumble-dev --name tumble-dev -it --privileged=true -v /path/to/my-volumes/tumbledev:/root -v /path/to/zram-mounted-dir:/build:rw registry.opensuse.org/opensuse/tumbleweed:latest /bin/bash
ext4
formatted zram
device created with zram-generator
oem
build time improved from 10
minutes (10
core vm
) down to 2
minutes (podman
) ;o)FYI @keszybz, this is the kiwi/nspawn issue we discussed at Flock.
Problem description
I am trying to build in a nspawn container and it is failing to find the loop partitions
Expected behaviour
Loop partitions should be created and formatted properly during the build process
Steps to reproduce the behaviour
mknod /dev/loop0 b 7 0
kiwi-ng --debug --type=oem --profile Disk system build --description kiwi-descriptions-master/debian/x86_64/debian-buster --target-dir tmp
OS and Software information