On Sat, 6 May 2023 at 19:51, Helmut Grohne <hel...@subdivi.de> wrote: > > 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
There is absolutely no need to be so aggressive. I care about both use cases, but evidently you have formed a different view in your mind, so nothing productive is going to come out of this subthread right now, so I'll stop replying. It's off-topic anyway. Kind regards, Luca Boccassi
