Bug#778554: unblock: systemd/215-12

[Niels Thykier <niels@thykier.net>]

On 2015-02-17 15:11, Martin Pitt wrote:
> Hey Niels,
> 
> Niels Thykier [2015-02-16 20:10 +0100]:
>> I have not had time to review this fully.  However, I noticed #778565,
>> which suggests a regression in this version of udev.  I am putting this
>> unblock request on hold until you have had a time to review #778565.
> 
> Michael and I responded to that and asked for some more information
> and log output. This looks very dubious, given that udev hardly
> changed at all in 215-12 except for blacklisting the mmcblkb-*rpmb
> devices (which are totally unrelated).
> 

Noted, as mentioned in a different mail, I have decided to unblock this.

>>> [...]
>>
>> Personally, I am leaning towards (2) in the absence of a patch/diff for (3).
> 
> The bug trail has a pointer to the experimental fix for this:
> 
>   http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=929bece5326
> 
> But anyway, this will not cover the edge cases that the (rather vocal)
> reporters of #755722 are concerned about, e. g. if the machine is
> always offline. So (3) is probably not a full solution yet, and this
> might require some more adjustment in fsck or other places.
> 

Ok.

>>   Though, as I understood the link to the upstream date, part of the
>> reason for not sync'ing the time was to make it easier on live-CDs.  Is
>> this the sort of change that will break live-CDs?  If so, what will it
>> take to "not break" live-CDs with (2) (or possibly (3)).
> 
> I figure this rather means "live CDs are not supposed to touch the
> system", and syncing the hw clock to a potentially wrong time of a
> live system is bad. However, that's precisely what has happenend under
> sysvinit (through util-linux' /etc/init.d/hwclock.sh) all the years;
> that's what I meant with "bug compatible to sysvinit" :-)
> However, with (3) we'd essentially get the same behaviour if the live
> system gets network connectivity.
> 
> Personally I'm leaning towards the hwclock-save.service (2) or even
> ignoring this (1).
> 
> Martin
> 

In lack of anything else to distinguish them, my preference is to go
with "same bugs as usual" - so that would make (2).  It also have the
advantage of users will perceive fewer issues with the systemd.
  Admittedly, I presume a migration to (3) in Stretch will be no easier
or harder given we go with (2).

Thanks,
~Niels