[Pkg-sysvinit-devel] Bug#623174: mountkernfs.sh unconditionally mounts /run

[rleigh]

On Tue, May 10, 2011 at 11:31:23PM +0200, chris h wrote:
> * rleigh <rleigh at codelibre.net> [110510 20:43]:
> > On Tue, May 10, 2011 at 11:55:48AM +0200, Michael Biebl wrote:
> > > Am 10.05.2011 11:39, schrieb rleigh:
> > > > On Tue, May 10, 2011 at 11:11:20AM +0200, Michael Biebl wrote:
> > > >> Am 09.05.2011 23:40, schrieb rleigh:
> > > >>> On Mon, May 09, 2011 at 10:56:39PM +0200, chris h wrote:
> > > >>>> with initscripts 2.88dsf-13.5 from exp and initramfs-tools maks/run
> > > >>>> there's a new warning during boot:
> > > >>>> mount: can't find /run in /etc/fstab or /etc/mtab
> > > >>>>
> > > >>>> Apparently this is caused by mountkernfs.sh which assumes that it has
> > > >>>> the authority to mount /run (line 42).
> > > >>>> With the newer initramfs-tools /run gets moved by the initramfs' init,
> > > >>>> but this doesn't make it into the mtab, causing the warning.
> > > >>>>
> > > >>>> I'm unsure what the correct solution would be...
> > > >>>
> > > >>> You need the patch from #621803 applying to the maks/run branch?
> > > >>> Or was this already applied?
> > > >>
> > > >> I can reproduce this issue. I used sysvinit/initscripts 2.88dsf-13.5 and built
> > > >> initramfs-tools from the maks/run branch (a6167ad4d32f56db89989e40d1863887c199cc61)
> > > >>
> > > >> During boot I get
> > > >> mount: can't find /run in /etc/fstab or /etc/mtab
> > > >> mount: can't find /sys in /etc/fstab or /etc/mtab
> > > >>
> > > >> and as a consequence
> > > >> startpar: service(s) returned failure: mountkernfs.sh ... failed!
> > 
> > Could you retry with
> > 
> > http://people.debian.org/~rleigh/sysvinit_2.88dsf-13.6.dsc
> > http://people.debian.org/~rleigh/initscripts_2.88dsf-13.6_amd64.deb
> > 
> > Works for me, but since I don't use startpar it would be good to
> > have that confirmed to work as well.  Chris, could you also try
> > this out please?
> 
> Tried with latest initramfs-tools maks/run plus initscripts_2.88dsf-13.6
> and the /run warning is indeed gone.

Great, thanks for testing!

> > [..]
> > It would be ideal if we could upgrade to a current version of mount,
> > such as 2.19 (2.19.1 is due out soon).
> > http://www.kernel.org/pub/linux/utils/util-linux/v2.19/util-linux-2.19.tar.bz2
> > This will work much better with /proc/mounts when built with libmount
> > support enabled, and it's now actively used with /etc/mtab being a
> > symlink (with Fedora/systemd) so it's likely that this sort of niggle
> > when using /proc/mounts will have been fixed.
> > Given that util-linux is not exactly kept up-to-date in Debian, if
> > anyone wanted to package and NMU it, that would be another big step
> > to getting systemd and read-only root working in Debian.  With this
> > version in Debian, we can finally make the switch to having /etc/mtab
> > as a symlink.
> 
> On a related note: we're building a live CD with an aufs-based
> overlay /-fs.
> As an artifact of this, during initramfs time we have to loop-mount
> a squashfs to /image.squashfs. This mount point is never visible to 
> the user, and mtab.sh complains that the mount point doesn't exist
> when it tries to populate /etc/mtab.
> 
> I guess you don't want to have a general exception for
> mounts of type 'squashfs' or something similar broad in mtab.sh?

Probably not.  The main reason being, /etc/mtab will be replaced by
a symlink to /proc/mounts fairly soon.  With the new mount; test
packages at
  http://people.debian.org/~rleigh/util-linux_2.19.1-1.dsc
and #603858 fixed (just sent a patch)
and /run available
mount will use /proc/mounts and /run/mount/utab (additional info
about mounts not storable in /proc/mounts) and mtab will never
be updated again.

So it's probably not worth adding any special casing at this point
given that the majority of the mtab.sh script will be deleted when
this is done.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20110510/6d346313/attachment.pgp>