Open edmeme opened 9 months ago
It looks like qcow2fuse uses qemu-ndb in the background and my past experience with it hasn't been great. It appeared to work for a bit, but eventually images would get corrupted, writes would time out or qemu-nbd would fail to disconnect images cleanly.
I'm not sure how the -o fakeroot option works. Does it provide the ability to run things as another user in that environment? In a normall fakeroot chroot environment, if you are user id 1001 and you chroot into an image, it's treated the same as user id 0. When you create a file and leave the chroot environment, you'll see what was previously owned by root is actually owned by 1001. AFAIK, there's no way to distinguish between user 1001 and 0, which would be important when generating an image. Then if you add user 1002, are you able to run something in the chroot as that user?
I'd be interested if it was possible, stable, reliable, didn't introduce unnecessary complexity and hacky workarounds for things that 'just work' as root. I'm a bit sceptical about it.
Is there any interest in making pi-gen run as a non-privileged user? At the end of the day, pi-gen is creating a disk image file. That should not really require any privileges.
I am aware there are some challenges in doing that. I have played with this idea before, attempting to build arch images, I did not get through but I did some progress.
QCOW2 and Ext images can be mounted with fuse. Fuse2fs allows mounting Ext images, the '-o fakeroot' option allows processes running under fakeroot to create and manipulate root-owned files within the image. Qcow2fuse should do the same for QCOW2.
It could be possible to run debootstrap with fakeroot/fakechroot.
My bane was chroot. It can be replaced with
unshare -mr chroot
.However, procfs seems to be a requirement...Edit: a first step to chroot with procfs in place without root is:unshare --fork --mount-proc=${ROOTFS}/proc --pid -mr chroot ${ROOTFS} /bin/qemu-aarch64-static /bin/bash
APT is not too happy about this, though.