Re: Welcome to your new installation of Debian GNU/Linux bookworm/sid
On Sun, 9 Oct 2022 at 12:55, Sven Mueller <sven@incase.de> wrote:
>
>
> Am 09.10.2022 12:20 schrieb Luca Boccassi <luca.boccassi@gmail.com>:
>
> On Sun, 9 Oct 2022, 10:23 Johannes Schauer Marin Rodrigues, <josch@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
Reply to: