* rleigh <rle...@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
signature.asc
Description: Digital signature
