Robert Wotzlaw: > The script is a part of the Debian binary package pm-utils version > 1.4.1-8. The script remounts ext3 file systems with the option > commit. It is triggered by a DBUS service. The service is called > during the GNOME Desktop session log in.
Ok, now it becomes clear that - the journal-commit script remounts ext[34] *only*, but it executes the remount command for all mounted fs. - every fs except ext[34] returns an error (or silently ignores) since the journal-commit script gives it an unknown option. - in the error case, only aufs prints the message about the unknown option. > The script tries to remount bound etx3 partitions but the origins of > the bound do not exists in the chroot environment. An error is the > consequence. I am afraid you don't fully describe the symptom. The script tries remouting aufs giving an ext3 option. > The question is how can I avoid the above problems with the script > journal-commit: > > - Sure, do not use it. > - Convince the developer to rewrite their script. > - Ignore the kernel message and the failed remount. > Desktop user can ignore the failed commit but batterie powered > computer should use a commit because the commit reduce the power > consumption. > > Or have you another solution? It totally depends upon how you think "what the problem is". How do you think abount these? - the journal-commit script should not remount fs other than ext[34]. - aufs should not print the message. > Maybe the bind mounts and a chroot environment based on AUFS are > more general problem. For me, this is just a problem in the journal-commit script. J. R. Okajima ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
