[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#621803: mountkernfs.sh unconditionally mounts /run



* rleigh <rleigh@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.

The target environment doesn't boot with startpar (no sysv-rc
actually), so I probably never saw the mountkernfs.sh failure.


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

Thanks,
  -ch

Attachment: signature.asc
Description: Digital signature


Reply to: