Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Luca,
On Sat, May 06, 2023 at 04:52:30PM +0100, Luca Boccassi wrote:
> To have a working system you need several more steps that are
> performed by the instantiator/image builder, such as providing working
> and populated proc/sys/dev, writable tmp/var, possibly etc. And it
> needs to be instantiated with user/password/ssh certs/locale/timezone.
> And if it needs to be bootable on baremetal/vm, it needs an ESP. And
> then if you have an ESP and want to run in a VM with SB, you'll need
> self-enrolling certs on first use or ensuring the 3rd party CA is
> provisioned. And then...
You paint it this way, but it really used to just work until we got the
/usr-merge. Indeed, debvm creates virtual machine images effectively by
bootstrapping a filesystem from packages and turning the resulting tree
into a file system image.
* /proc, /sys, /dev are mounted by systemd. All you need to do here is
create the directories and base-files does so.
* /tmp is shipped by base-files.
* user and password creation is not handled yet, but can be handled by
something similar to systemd-firstboot.
* Not sure what you mean with certs, locale and timezone. You can just
install ca-certificates, locales and tzdata as part of the bootstrap.
* The bootloader part for baremetal is kinda out of scope for
bootstrap, which is why debvm side-steps this. You can also skip it
for containers and build chroots. So it is one out of multiple use
cases that needs extra work here.
In a good chunk of situations, you can get just by without messing
around. Well that is until we broke it via usr-is-merged. I concur with
Simon Richter, that restoring this property is a primary concern.
> You get the point. Going from a bunch of packages to a running system
> necessarily has many steps in between, some that are already done and
> taken for granted, for example when you say "works as a container" I'm
> pretty sure the "container" engine is taking care of at the very least
> proc/dev/sys for you, and it's just expected to work. bin -> usr/bin,
> sbin -> usr/sbin and lib -> usr/lib should get the same treatment: if
> they are not there, the invoked engine should prepare them. systemd
> and nspawn have been able to do this for a while now.
No, this misses the point. You can configure essential in a very limited
environment. However, you cannot do so without the lib or lib64 symlink
(depending on the architecture) and the bin symlink. This is so
critical, that it cannot be deferred to some external entity. It must be
part of the bootstrap protocol. There are some suggested ways to fix
this (such as adding separate bootstrap scripts next to maintainer
scripts), but nothing implemented.
> Not having those hard coded means that the use case of / on a tmpfs
> with the rest instantiated on the fly, assembled with the vendor's
> /usr and /etc trees, becomes possible, which is neat. And said trees
> can pass the checksum/full integrity muster.
It's neat that you can solve your use case by breaking other people's
use cases. This is not constructive interaction however. This kind of
behaviour is precisely what caused so much conflict around the
/usr-merge. What if I gave a shit for your use case? Denying the
/usr-merge and just continuing unmerged as long as possible (as merging
would break my use case) would be my strategy of choice. You can make a
difference here by starting to recognize other people's use cases and
proposing solutions in that merged world. And no, it's not "add duct
tape to every bootstrap tool".
So I really want to see a solution for the bootstrap protocol before
moving the dynamic linker and /bin/sh to its canonical location. The
current bootstrap protocol is kept on life-support by installing the
usrmerge package by default. Dropping usrmerge from the
init-system-helpers dependency as first alternative or moving the
dynamic linker would break it. If I had a solution in mind, I'd
definitely post it right here, but unfortunately I have not.
Helmut
Reply to: