Your message dated Tue, 29 May 2018 20:25:16 +0200
with message-id <[email protected]>
and subject line Re: Bug#900366: postinst creation of /etc/machine-id breaks
CustomFirstBoot unit parameter
has caused the Debian Bug report #900366,
regarding postinst creation of /etc/machine-id breaks CustomFirstBoot unit
parameter
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
900366: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900366
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 238-5
The postinst for the systemd deb pkg contains the following:
# Create /etc/machine-id
systemd-machine-id-setup
This generates /etc/machine-id as the package is installed.
However the systemd unit option ConditionFirstBoot uses the presence or
absence of this file to detect whether or not this is the first boot.
From 'man systemd.unit'
"ConditionFirstBoot= takes a boolean argument. This condition may be
used to conditionalize units on whether the system is booting up with an
unpopulated /etc directory (specifically: an /etc with no
/etc/machine-id). This may be used to populate /etc on the first boot
after factory reset, or when a new system instance boots up for the
first time."
Since no unit can start until after systemd is installed, and the
install always creates this file, this test will always be False which
renders this option useless.
signature.asc
Description: OpenPGP digital signature
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--- End Message ---
--- Begin Message ---
Am 29.05.2018 um 18:45 schrieb Matthew Richardson:
> I spotted this when trying to use the ConditionFirstBoot option writing
> out and enabling a new systemd service in the installer, and wondering
> why it was never firing on the first 'real' boot.
>
> While I appreciate that removing machine-id or playing around with it
> are options, they aren't general ones - you wouldn't want to put 'rm
> /etc/machine-id' in a package for general distribution!
>
> The man page for systemd-machine-id-setup says:
>
> Use systemd-firstboot(1) to initialize the machine ID on mounted (but
> not booted) system images.
Creating system images usually involves removing state after the
debootstrap process.
> which was what made me think that calling systemd-mahcine-id-setup in
> postinst might not be the correct thing to do, and perhaps enabling a
> systemd-firstboot.service might be another approach.
>
> (However I'm not that knowledgeable on the intricacies of systemd, so am
> happy to be wrong here).
>
> The 'inverse bug' as it were is then: if the postinst remains unchanged,
> what can be done to make it clear that ConditionFirstBoot is always
> False to those following the systemd docs and writing units?
Well, it isn't as I explained. For system images where /etc/machine-id
has been removed, the Condition will trigger.
I'm going to close this bug report. I'm pretty certain that calling
systemd-machine-setup in postinst is the right thing to do.
The use case of system image or stateless /etc requires special setup
anyway. Removing /etc/machine-id should be part of that setup
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
