mountpoint does not exist (securityfs, fuse/connections)

Bug #447525 reported by Michael Marley
48
This bug affects 8 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: mountall

I just updated my Karmic AMD64 system to the latest version of mountall, but it causes it to fail to boot when running a custom-compiled kernel without the initramfs. The error message says that mountall died because it could not remove the /forcefsck file because the file system is read only. The standard Ubuntu kernel works fine, and rolling back to version 0.1.8 of mountall works around my problem.

Revision history for this message
Maxim Levitsky (maximlevitsky) wrote :

And I know why...
mountall now tries to mount /sys/kernel/security probably with apparmor filesystem

I don't have one in my kernel.

I think that mountall should never return a failure, as this results in complete lack of ability to boot because lets face it upstart is nice, but less robust/configurable.

Changed in mountall (Ubuntu):
status: New → Confirmed
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Do you see the error "mountall:/proc/filesystems: No such file or directory" ?

Changed in mountall (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Revision history for this message
Michael Marley (mamarley) wrote :

I don't remember. When I can, I will break my system again and see if it does.

Revision history for this message
Nicola Rosati (supernaicol) wrote :

I also incurred in this bug, I have a custom kernel, no appArmor compiled, and when I upgraded from 0.1.8 to 0.2.0 (or 0.2.1, it's the same) it told me:

mount: mount point /sys/kernel/security does not exist
mountall: mount /sys/kernel/security terminated with status 32
mountall: filesystem could not be mounted: /sys/kernel/security
...............
init: mountall main process (1004) terminated with status 3
init: mountall post-stop process terminated with status 1
........
mount of filesystem failed
a maintenance shell will now be started

Then it asks me the root pw, or to press ctrl+d, and i don't know what to do.

os: Kubuntu karmic x86_64
kernel: 2.6.31.3 custom (no appArmor)

Revision history for this message
Nicola Rosati (supernaicol) wrote :

edit to add:

I have a backup of a fully upgraded system except mountall, so i can "break" my system whenever i want.
If you need you can use me as a lab rat. Bye bye!

Revision history for this message
Nicola Rosati (supernaicol) wrote :

another add, sorry:

my custom kernel uses the initrd, so the problem seems not dependant from the presence of initramfs.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 447525] Re: After update from 0.1.8 to 0.2.0, custom-compiled kernel without initramfs fails to boot

On Sat, 2009-10-10 at 10:59 +0000, supernaicol wrote:

> I also incurred in this bug, I have a custom kernel, no appArmor
> compiled, and when I upgraded from 0.1.8 to 0.2.0 (or 0.2.1, it's the
> same) it told me:
>
> mount: mount point /sys/kernel/security does not exist
> mountall: mount /sys/kernel/security terminated with status 32
> mountall: filesystem could not be mounted: /sys/kernel/security
>
Ok, this may well be a different issue to the reporter. For you it's
not the missing initramfs that's the issue, it's missing apparmor in
your kernel.

Could you please file a *new* bug with the text from your comment?

Thanks!

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
Benjamin Heil (benjamin-heil) wrote : Re: After update from 0.1.8 to 0.2.0, custom-compiled kernel without initramfs fails to boot

I see this at a Xen DomU running a custom pv_ops Kernel. This DomU didn't start after the upgrade. Here's the output:

Begin: Running /scripts/local-premount ... done.
[ 1.325687] kjournald starting. Commit interval 5 seconds
[ 1.325719] EXT3-fs: mounted filesystem with writeback data mode.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
mount: mount point /sys/fs/fuse/connections does not exist
mountall: mount /sys/fs/fuse/connections [696] terminated with status 32
mountall: Filesystem could not be mounted: /sys/fs/fuse/connections
mount: mount point /sys/fs/fuse/connections does not exist
mountall: mount /sys/fs/fuse/connections [704] terminated with status 32
mountall: Filesystem could not be mounted: /sys/fs/fuse/connections
init: mountall main process (692) terminated with status 3
rm: cannot remove `/forcefsck': Read-only file system
init: mountall post-stop process (705) terminated with status 1
Mount of filesystem failed.
A maintenance shell will now be started.
CONTROL-D will terminate this shell and re-try.
Give root password for maintenance
(or type Control-D to continue):

Revision history for this message
Michael Marley (mamarley) wrote :

I see a message like this too (about AppArmor) so I think it is the same bug.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Thanks for confirming, Michael.

So we have a set of symptoms here that are all the same underlying bug, missing directories for virtual filesystems that mountall wants to try and mount. That's a condition that should be dealt with.

I wonder, could you all attach the /proc/filesystems file for me? It'll be interesting to see whether the filesystems are even available or not.

summary: - After update from 0.1.8 to 0.2.0, custom-compiled kernel without
- initramfs fails to boot
+ mountpoint does not exist (securityfs, fuse/connections)
Changed in mountall (Ubuntu):
status: Triaged → Confirmed
status: Confirmed → Incomplete
Revision history for this message
Michael Marley (mamarley) wrote :

michael@mamarley-laptop:~$ cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev cgroup
nodev cpuset
nodev tmpfs
nodev binfmt_misc
nodev debugfs
nodev securityfs
nodev sockfs
nodev pipefs
nodev anon_inodefs
nodev inotifyfs
nodev devpts
nodev ramfs
             ext4
             cramfs
nodev hugetlbfs
nodev ecryptfs
nodev fuse
             fuseblk
nodev fusectl
nodev mqueue
nodev smackfs

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

That's odd, you have securityfs but no /sys/kernel/security

After you boot normally does that directory exist?

Revision history for this message
Michael Marley (mamarley) wrote :

Yes, the directory exists, and it is empty.

Revision history for this message
Nicola Rosati (supernaicol) wrote :

Here is mine, from a normal boot with mountall v. 0.1.8

on the other hand, I don't have a /sys/kernel/security directory.

Revision history for this message
Nicola Rosati (supernaicol) wrote :

Tell me if I have to update to the faulty version of mountall and give it a try, as i said I'm allowed to break my system whenever i want.
See ya soon, going out for the saturday night. Bye all.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

I'll check to see whether something makes that directory

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mountall - 0.2.2

---------------
mountall (0.2.2) karmic; urgency=low

  [ Steve Langasek ]
  * Don't emit the local-filesystem signal until after virtual filesystems
    are also done mounting. LP: #448981.

  [ Robert Gerlach ]
  * Fix segfault when root filesystem missing from fstab, or listed
    as /dev/root. LP: #448323.

  [ Johan Kiviniemi ]
  * Don’t queue filesystem check when either device or type is "none".

  [ Scott James Remnant ]
  * Removed /srv from the list of "essential" mountpoints. LP: #448267.
  * Allow overriding of the above list by using the "bootwait" and
    "nobootwait" fstab options, e.g.

    LABEL=foo /home ext4 nobootwait 0 0

  * Mount /proc before attempting to parse /proc/filesystems. LP: #447947.
  * Further improvements to event tagging of filesystems. A virtual bootwait
    filesystem underneath a local or remote filesystem inherits that tag,
    a local bootwait filesystem underneath a remote filesystem inherits that
    tag, remote filesystems do not inherit them. LP: #447654.

  * Replace previous hardcoded "arch specific" flag for /spu with an
    "optional" fstab mount option.
  * Made binfmt_misc,fusectl, debugfs, securityfs and /lib/init/rw optional
    as well.
  * Check whether the mountpoint of optional fstab entries exists before
    trying to mount, and skip over that if it doesn't. LP: #447525.

  * Keep /proc/self/mountinfo open, if it changes while we're running,
    update the knowledge of the mount table and what's mounted. That
    way if something else mounts it while mountall running, you'll still
    get events and mountall will still exit.
  * Try mounts again if another network device comes up while we were
    waiting.

 -- Scott James Remnant <email address hidden> Tue, 13 Oct 2009 02:17:47 +0100

Changed in mountall (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Nicola Rosati (supernaicol) wrote :

Ok. Now my custom kernel boots fine. Thank you Scott. Bye!

Revision history for this message
Michael Marley (mamarley) wrote :

Mine, too. Thanks!

Revision history for this message
Benjamin Heil (benjamin-heil) wrote :

And my DomU is starting again. Great work. Thank you!

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

My karmic linode.com machine (xen hosting) is also back up with this package, thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.