[Pkg-sysvinit-devel] Bug#697002: [PATCH initramfs-tools 0/5] Only mount /usr if the real init is systemd

[Ben Hutchings]

On Thu, 2014-10-02 at 23:04 +0100, Ben Hutchings wrote:
> On Thu, 2014-10-02 at 22:26 +0100, Ben Hutchings wrote:
> > On Thu, 2014-10-02 at 18:39 +0100, Ben Hutchings wrote:
> > > On Mon, 2014-09-29 at 01:44 +0100, Ben Hutchings wrote:
> > > > Currently initscripts will not work correctly if /usr is mounted by
> > > > initramfs-tools.  Firstly, fsck will fail and the boot process will
> > > > stop.  If you press Ctrl-D to continue, the boot process will succeed
> > > > but /usr will not be remounted read-write if necessary.
> > > [...]
> > > 
> > > Also, we must not run fsck in the initramfs because the system clock may
> > > not be correct yet; see #763777.
> > >
> > > Unfortunately, systemd does not fsck /usr if it's already mounted.
> > > Which means this is now broken for all init systems!
> > 
> > It looks like we can sort out the system time just by adding hwclock and
> > some config files into the initramfs.  hwclock already hooks into udev,
> > and the kernel ensures that the adjustment of system time to a local
> > time zone is done only once.  So please assume that the initramfs will
> > continue to fsck /usr.
> 
> Currently this works fine with systemd, but util-linux will need a small
> patch to avoid double-adjusting the clock when booting with
> sysvinit/initscripts.

I' made an NMU to util-linux to avoid double-adjustment (2.20.1-5.11).
The necessary change is also on the 2.25 branch.

I've just now uploaded initramfs-tools 0.118 which includes these
changes, many more fixes, and a versioned dependency on util-linux.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20141004/03abf5d4/attachment.sig>