On Sun, 9 Oct 2022 at 12:55, Sven Mueller <s...@incase.de> wrote: > > > Am 09.10.2022 12:20 schrieb Luca Boccassi <luca.bocca...@gmail.com>: > > On Sun, 9 Oct 2022, 10:23 Johannes Schauer Marin Rodrigues, > <jo...@debian.org> wrote: > > > I do not understand enough about systemd to be able to say whether an empty > value or "uninitialized" is the correct default value for tools like > debootstrap or mmdebstrap to set. If nobody else chimes in, I'll change > mmdebstrap to write the empty string as suggested by Bastian. > > Thanks! > > > Empty machineid is the right default, we don't support firstboot semantics in > Debian for now (users that want to try it can opt in and change it). > > > Two main questions: > > 1) How can a user meaningfully change this? The only time this is relevant is > during initial boot after installation. > > Secondly, I know we ran into trouble with an empty (but existing) machine ID > file, though I'd have to search for more info when I'm back at work. I seem > to recall some issues with actually creating the systemid when the system > booted for the first time, but I'm far from sure. It might have been the > semantics: as soon as /etc becomes writeable, systemd tries to commit the > generated ID to the file and assumes that this will persist from then on. > This is a different from the first boot semantics timing, where it is only > written once the first-boot-complete.target is reached.
Yes, that's how it's supposed to work, and how it already works, no change here. By users here I meant image builders. > And (2) what exactly are the unsupported first boot semantics you talk > about? Simply starting the firstboot service (which is basically a no-op > unless you specifically hook into it, from what I understood)? > > Side questions: > > Who is "we"? The maintainers of specific packages? Debian as a whole? If the > latter: seems I missed any discussion of this. > > What is the downside of enabling the semantics of ConditionFirstBoot? As > mentioned above, I've seen evidence that not doing so might be problematic. > Since we modified our installation system to enable it, we haven't seen any > issues, neither in physical nor virtual systems. > > If you are doing bootstrapping for a chroot, you are unlikely to actually > start systemd there (well, for the use cases I know). If you are > bootstrapping for a VM or physical system, you likely want the ability to do > some stuff during first boot and can easily skip doing anything, since you > actively would need to hook up into the first boot semantics to use them. > (ConditionFirstBoot). Writing "uninitialized" into machine-id to trigger first boot behaviour is not a first-class supported feature at this stage, and no Debian tool does that (AFAIK). Debian's supported workflow is to use the Debian installer image to get Debian onto a system. Kind regards, Luca Boccassi
