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
