This breaks a number of setups like:
- the sbuild autopkgtest
https://salsa.debian.org/debian/sbuild/-/jobs/3353627/raw
- the dropbear autopkgtest
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dropbear/26716581/log.gz
- autopkgtest-virt-qemu image builders
- the MNT reform image builder
- the mmdebstrap testsuite which builds a qemu system image for its
local tests
- the mmdebstrap jenkins job
On Sun, Oct 09, 2022 at 09:41:29AM +0200, Johannes Schauer Marin Rodrigues wrote:
This breaks a number of setups like:
- the sbuild autopkgtest
https://salsa.debian.org/debian/sbuild/-/jobs/3353627/raw
- the dropbear autopkgtest
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dropbear/26716581/log.gz
- autopkgtest-virt-qemu image builders
- the MNT reform image builder
- the mmdebstrap testsuite which builds a qemu system image for its
local tests
- the mmdebstrap jenkins job
This is a bug in mmdebstrap:
| open my $fh, '>', "$options->{root}/etc/machine-id"
| or error "failed to open(): $!";
| print $fh "uninitialized\n";
| close $fh;
the last upload of src:systemd (251.5-1) enabled firstboot by default on Debian. From debian/changelog:
* Enable firstboot, disabled by default on Debian.
Quoting Bastian Blank (2022-10-09 10:24:26)
On Sun, Oct 09, 2022 at 09:41:29AM +0200, Johannes Schauer MarinRodrigues wrote:
This breaks a number of setups like:
- the sbuild autopkgtest
https://salsa.debian.org/debian/sbuild/-/jobs/3353627/raw
- the dropbear autopkgtest
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dropbear/26716581/log.gz
- autopkgtest-virt-qemu image builders
- the MNT reform image builder
- the mmdebstrap testsuite which builds a qemu system image for its
local tests
- the mmdebstrap jenkins job
This is a bug in mmdebstrap:
| open my $fh, '>', "$options->{root}/etc/machine-id"
| or error "failed to open(): $!";
| print $fh "uninitialized\n";
| close $fh;
Yes, maybe. I saw that you filed #1021478 against mmdebstrap --thanks for that!
If this is a bug in mmdebstrap, then mmdebstrap should do the same thing as debootstrap which is currently being discussed in #1018740 which I see you also
commented on.
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!
Hi,
On Sun, 9 Oct 2022 at 08:41, Johannes Schauer Marin Rodrigues <josch@debian.org> wrote:
the last upload of src:systemd (251.5-1) enabled firstboot by default on Debian. From debian/changelog:
* Enable firstboot, disabled by default on Debian.
I'm confused by the above, one part says "enabled firstboot by default
on Debian" and the other "disabled by default on Debian", which one is
it?
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: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,
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,
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)?nor virtual systems.
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
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 caneasily skip doing anything, since you actively would need to hook up into the first boot semantics to use them. (ConditionFirstBoot).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 24:05:07 |
Calls: | 6,707 |
Calls today: | 1 |
Files: | 12,239 |
Messages: | 5,352,248 |