FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 05-09-2011, 08:56 PM
chris h
 
Default Bug#621803: mountkernfs.sh unconditionally mounts /run

Hi,

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...

Thanks,
-ch



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTiniD_te+osz6u0WSMcrWg=ZnL+ehw@mail.gmail.com ">http://lists.debian.org/BANLkTiniD_te+osz6u0WSMcrWg=ZnL+ehw@mail.gmail.com
 
Old 05-09-2011, 09:40 PM
rleigh
 
Default Bug#621803: mountkernfs.sh unconditionally mounts /run

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?

This is possibly due to mountkernfs looking for the mount in fstab
and mtab and not finding it due to it being mounted as 'none' rather
than 'tmpfs' which causes the already-mounted tmpfs to not be
found. The patch makes the initramfs use the same mount options
as initscripts, and hence not mount a second tmpfs on top of
the first. This check is used for all filesystems (re)mounted
by mountkernfs/mountdevsubfs. If you already applied the patch,
this is not the cause.

(By default, initscripts will mount /run if not already mounted by
the initramfs. If already mounted, it remounts using the mount
options from /etc/fstab, if any.)

Alternatively, this could simply be because we haven't yet created
mtab at this point. mount_noupdate is used to cause "-n" to be
passed to mount to avoid any mtab updates. I'll double check on
my systems--I haven't seen this before when testing. If the mtab
entry is correct after booting is complete, this is just a harmless
warning due to mtab not yet having been created. The "-n" option
means no mtab updates, but it may still attempt to read it.

As soon as mount switches to a symlink for /etc/mtab, it will never
be out of date.

I'll take a look later tonight.


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.
 
Old 05-10-2011, 09:11 AM
Michael Biebl
 
Default Bug#621803: mountkernfs.sh unconditionally mounts /run

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!

Output of mount:
/dev/sda6 on / type ext4 (rw,acl,user_xattr,errors=remount-ro,commit=0)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,size=5242880,mode=755)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=755)
tmpfs on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880,mode=1777)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,size=20%,mode=1777)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/sda7 on /home type ext4 (rw,acl,user_xattr,commit=0)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

/proc/mounts:
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs rw,relatime,size=10240k,nr_inodes=192573,mode=755 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=310960k,mode=755 0 0
/dev/disk/by-uuid/9a6d2bd2-58d1-4a75-baff-166b8637e3cc / ext4
rw,relatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,size=5120k,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=310960k 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode= 000 0 0
/dev/sda7 /home ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
 
Old 05-10-2011, 09:39 AM
rleigh
 
Default Bug#621803: mountkernfs.sh unconditionally mounts /run

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!

I think I know what's going on here, but I'll need to test. If
/run and /sys were mounted before reboot, they exist in the old
/etc/mtab before mtab.sh is run. If they weren't, the remount
will fail. mtab is not cleared until S08checkroot.sh, so
mountkernfs still sees the old contents.

The solution here, if this is the problem, is to comment out the
remounting until we have eliminated /etc/mtab by symlinking to
/proc/mounts. If looks like a remount requires mtab/fstab entry
while mount does not.


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.
 
Old 05-10-2011, 09:55 AM
Michael Biebl
 
Default Bug#621803: mountkernfs.sh unconditionally mounts /run

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!
>
> I think I know what's going on here, but I'll need to test. If
> /run and /sys were mounted before reboot, they exist in the old
> /etc/mtab before mtab.sh is run. If they weren't, the remount
> will fail. mtab is not cleared until S08checkroot.sh, so
> mountkernfs still sees the old contents.

I only get this error message once: During next reboot after the upgrade, i.e.
/run is mounted by the initramfs but is not (yet) in /etc/mtab.

A simple way to reproduce the issue is to run
: > /etc/mtab
and reboot


>
> The solution here, if this is the problem, is to comment out the
> remounting until we have eliminated /etc/mtab by symlinking to
> /proc/mounts.

When symlinking /etc/mtab → /proc/self/mounts, I get
Mounting local filesystems... failed

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
 
Old 05-10-2011, 11:40 AM
rleigh
 
Default Bug#621803: mountkernfs.sh unconditionally mounts /run

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!

This is due to mountkernfs returning nonzero, but it did actually
succeed. All the filesystems are mounted, it just failed to apply
the mount options (if any) from fstab due to mtab not being
readable.

> > I think I know what's going on here, but I'll need to test. If
> > /run and /sys were mounted before reboot, they exist in the old
> > /etc/mtab before mtab.sh is run. If they weren't, the remount
> > will fail. mtab is not cleared until S08checkroot.sh, so
> > mountkernfs still sees the old contents.
>
> I only get this error message once: During next reboot after the upgrade, i.e.
> /run is mounted by the initramfs but is not (yet) in /etc/mtab.
>
> A simple way to reproduce the issue is to run
> : > /etc/mtab
> and reboot

Yes, I've now been able to reproduce it, thanks.
I think that we should drop the special-case remount, since we can't
remount until mtab exists and is valid, and it's safe to do this
later. We can do the remounting by calling "mountkernfs reload" after
creating the mtab. I think this would overall be much cleaner:

diff --git a/debian/src/initscripts/etc/init.d/mtab.sh b/debian/src/initscripts/etc/init.d/mtab.sh
index 18c9bc7..65ad2d2 100644
--- a/debian/src/initscripts/etc/init.d/mtab.sh
+++ b/debian/src/initscripts/etc/init.d/mtab.sh
@@ -77,10 +77,12 @@ do_start () {
# Add entries for mounts created in early boot
# S01mountkernfs.sh
/etc/init.d/mountkernfs.sh mtab
+ /etc/init.d/mountkernfs.sh reload
# S03udev
domount mtab tmpfs "" /dev "udev" "-omode=0755"
# S03mountdevsubfs.sh
/etc/init.d/mountdevsubfs.sh mtab
+ /etc/init.d/mountdevsubfs.sh reload

# Add everything else in /proc/mounts into /etc/mtab, with
# special exceptions.
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh b/debian/src/initscripts/lib/init/mount-functions.sh
index beb2c1f..076a2ad 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -208,8 +208,8 @@ domount () {
if mountpoint -q "$MTPT"; then
# Already mounted, probably moved from the
# initramfs, so remount with the
- # user-specified mount options.
- mount $MOUNTFLAGS -oremount $CALLER_OPTS $FSTAB_OPTS $MTPT
+ # user-specified mount options later on.
+ :
else
if [ "$VERBOSE" != "no" ]; then
is_empty_dir "$MTPT" >/dev/null 2>&1 || log_warning_msg "Files under mount point '$MTPT' will be hidden."

> > The solution here, if this is the problem, is to comment out the
> > remounting until we have eliminated /etc/mtab by symlinking to
> > /proc/mounts.
>
> When symlinking /etc/mtab → /proc/self/mounts, I get
> Mounting local filesystems... failed

This is due to an inconsistency in /etc/fstab compared with
/proc/mounts. "mount -a -v" should tell you what is wrong.
For me, it was s/^proc/none/ for procfs since the initramfs
sets it to "none" rather than "proc". This is an unrelated
issue, which we can deal with separately. Not yet clear
whether it should be fixed in the initramfs or in fstab; since
it's in all fstab files by default(?), so amending the
initramfs would probably be better. The same might apply to
other initramfs mount commands using "none" if it's common
practice to use other names in fstab.


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.
 
Old 05-10-2011, 06:42 PM
rleigh
 
Default Bug#621803: mountkernfs.sh unconditionally mounts /run

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?

> > The solution here, if this is the problem, is to comment out the
> > remounting until we have eliminated /etc/mtab by symlinking to
> > /proc/mounts.
>
> When symlinking /etc/mtab → /proc/self/mounts, I get
> Mounting local filesystems... failed

I've spent some time looking at this, and it's definitely a more
general issue--I see it for all LVM filesystems, even when the
entries in /proc/mounts and /etc/fstab are identical other than
the opts/passno. The fsname/dir/type are all identical.

I'll need to look more carefully at what's going on, but could well
be a mount bug given the identical contents.

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.


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.
 
Old 05-10-2011, 09:31 PM
chris h
 
Default 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
 
Old 05-10-2011, 09:54 PM
rleigh
 
Default Bug#621803: mountkernfs.sh unconditionally mounts /run

On Tue, May 10, 2011 at 11:31:23PM +0200, chris h wrote:
> * 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.

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.
 
Old 05-10-2011, 10:25 PM
chris h
 
Default Bug#621803: mountkernfs.sh unconditionally mounts /run

* rleigh <rleigh@codelibre.net> [110510 23:55]:
> On Tue, May 10, 2011 at 11:31:23PM +0200, chris h wrote:
> > * rleigh <rleigh@codelibre.net> [110510 20:43]:
> > > On Tue, May 10, 2011 at 11:55:48AM +0200, Michael Biebl wrote:
[..]
> > >
> > > 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!

Thank you for your fast response.

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

FTR, util-linux_2.19.1-1 doesn't seem to build for me, on amd64:
if [ -d debian/cfdisk-udeb ]; then
cd debian/util-linux-locales && find usr/share/locale -type f | while read x; do ln $x ../cfdisk-udeb/$x; done
fi
ln: creating hard link `../cfdisk-udeb/usr/share/locale/pl/LC_MESSAGES/util-linux.mo' => `usr/share/locale/pl/LC_MESSAGES/util-linux.mo': No such file or directory
ln: creating hard link `../cfdisk-udeb/usr/share/locale/zh_CN/LC_MESSAGES/util-linux.mo' => `usr/share/locale/zh_CN/LC_MESSAGES/util-linux.mo': No such file or directory
ln: creating hard link `../cfdisk-udeb/usr/share/locale/zh_TW/LC_MESSAGES/util-linux.mo' => `usr/share/locale/zh_TW/LC_MESSAGES/util-linux.mo': No such file or directory
ln: creating hard link `../cfdisk-udeb/usr/share/locale/eu/LC_MESSAGES/util-linux.mo' => `usr/share/locale/eu/LC_MESSAGES/util-linux.mo': No such file or directory
ln: creating hard link `../cfdisk-udeb/usr/share/locale/hu/LC_MESSAGES/util-linux.mo' => `usr/share/locale/hu/LC_MESSAGES/util-linux.mo': No such file or directory
ln: creating hard link `../cfdisk-udeb/usr/share/locale/gl/LC_MESSAGES/util-linux.mo' => `usr/share/locale/gl/LC_MESSAGES/util-linux.mo': No such file or directory
make: *** [install] Error 1


> 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.

Yep.
For the time being, I will probably introduce a workaround on our side.

Thanks,
-ch
 

Thread Tools




All times are GMT. The time now is 09:36 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org