On Sun, 14 Jan 2024 20:27:58 +0100 Helmut Grohne wrote: > On Sun, Jan 14, 2024 at 06:36:29PM +0100, Francesco Poli wrote: > > Of course, I have! ;-) > > > > For privacy reasons: I don't want other users to be able to enter my > > home directory and to read any file within it that I might have > > forgotten with world-readable permissions! > > I agree that this is good practice. It's just that working with > namespaces tends to make this annoying. We're still in search for a more > satisfying solution. For now, I'm happy to have identified the cause of > your failure.
Indeed!
Without understanding the cause of the failure, nobody can find a
(good) fix. Hence, identifying the cause is the first step.
>
> > the final touches to sid_amd64.img will be put with the file in its
> > intended destination directory, which is /home/${USER}/mysubdir, since
> > the command-line argument was "sid_amd64.img", a relative path to a
> > file directly within the current working directory (~/mysubdir).
>
> That command that fails is mkfs.ext4. This command is run inside the
> user namespace that mmdebstrap creates for constructing the chroot. The
> uids 0 to 65535 inside the user namespace correspond to your first
> subuid range that is large enough. The mkfs.ext4 operation is performed
> by the root user inside the user namespace. In the initial namespace
> that root user is your first subuid. In particular, it is not your user
> but a different user and this user has no permission to access your
> output image.
Why is my first subuid not my user, but a different user?
Is it by design?
Or can my first subuid be forced to become my user?
[...]
> Let me suggest
> some alternatives. One is storing the output image outside $HOME. If you
> put it into /tmp and the move it from /tmp into your home, that should
> work as well.
I attempted to do this by running mmdebstrap-autopkgtest-build-qemu
from within /dev/shm (and it works, more on this below...).
[...]
> The available options to improve this are not super nice. A simple
> workaround is creating the output image as a temporary file inside the
> namespace and then copying it out. This will perform a 1GB copy
> operation that we'd like to avoid (and rather construct the filesystem
> in-place) for performance reasons, but maybe usability beats
> performance?
Well, performance was not an issue here.
The copy of
$ ls -lFs --si sid_amd64.img
690M -rw-r-xrwx 1 $USER $USER 2.3G Jan 15 23:26 sid_amd64.img*
was really quick.
Maybe it's because my home directory is on an SSD...
However, even on a mechanical hard disk drive, I would be more than
willing to spend some more time in the copy operation. After all, if I
understand correctly, the image will only be created once, and then kept
up-to-date with "sbuild-qemu-update" (which does not require superuser
privileges, does it?).
> I'm also not sure how mmdebstrap downloads sparse files. It
> might make them un-sparse and that'd be quite bad for this use case as
> you'd write 25GB of zeros.
I still have to test with a --size=25G (which is the default size):
a file with actual allocated size of 25 GiB would not fit within
my /dev/shm, but the above-mentioned test with --size=2G produced an
image with an allocated size of about 690 MB, so maybe it can work even
with --size=25G ?!?
Would the use of the .qcow2 format even further help in this?
[...]
> > It looks like it worked, but, unfortunately, it (again) fails to be
> > usable with autopkgtest:
> >
> > $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out --summary
> > ./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${SRCPKG}_amd64.changes
> > -- qemu --overlay-dir /dev/shm ~/Downloads/sid_amd64.img
> > autopkgtest [18:24:23]: starting date and time: 2024-01-14 18:24:23+0100
> > autopkgtest [18:24:23]: version 5.32
> > autopkgtest [18:24:23]: host ${HOST}; command line: /usr/bin/autopkgtest
> > --output-dir './${SRCPKG}_autopkgtest.out' --summary
> > './${SRCPKG}_autopkgtest.summary' --apt-upgrade -B
> > './${SRCPKG}_amd64.changes' -- qemu --overlay-dir /dev/shm
> > ${HOME}/Downloads/sid_amd64.img
> > qemu-system-x86_64: terminating on signal 15 from pid 115770
> > (/usr/bin/python3)
> > <VirtSubproc>: failure: timed out waiting for 'login prompt on serial
> > console'
> > autopkgtest [18:25:24]: ERROR: testbed failure: unexpected eof from the
> > testbed
> >
> >
> > What did I fail to understand?
>
> The difficulty resides in making a bootable image with no root
> privileges. mmdebstrap-autopkgtest-build-qemu is not fully compatible
> with autopkgtest-build-qemu. It specifically required you to pass
> --boot=efi, right? On amd64, autopkgtest-virt-qemu defaults to bios
> boot. In order to use this image, you likewise have to pass --boot=efi
> to the virtualization backend.
Adding the --boot=efi option made it work! :-)
$ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out --summary
./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${SRCPKG}_amd64.changes --
qemu --boot=efi --overlay-dir /dev/shm ~/Downloads/sid_amd64.img
Thanks for all the explanations!
Now I need to:
a. test with --size=25G
b. test sbuild-qemu-update
c. report to you (and suggest possible improvements for
mmdebstrap-autopkgtest-build-qemu)
d. configure sbuild-qemu and learn to use it to build Debian packages
e. report to you and/or Christian Kastner (and suggest possible
improvements for mmdebstrap-autopkgtest-build-qemu and/or
sbuild-qemu)
Please stay tuned!
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpMANffceCk3.pgp
Description: PGP signature
