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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
