Bug#900366: postinst creation of /etc/machine-id breaks CustomFirstBoot unit parameter

[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.

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?

Thanks,

Matthew


On 29/05/18 17:17, Michael Biebl wrote:
> Am 29.05.2018 um 16:53 schrieb Matthew Richardson:
>> 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.
> 
> Well, if you remove /etc/machine-id as part of your debootstrap process,
> then /etc/machine-id will not be present during boot.
> 
> Or if you use a stateless system, then /etc might be empty as well.
> 
> So the Condition still makes sense.
> 
> Can you elaborate, what this bug report is supposed to achieve?
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180529/58de9a29/attachment-0002.sig>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180529/58de9a29/attachment-0002.ksh>