[buildd-tools-devel] Bug#608428: Bug#608428: schroot: [kfreebsd-*] cannot handle long (>= 14 chars) chroot names

[Roger Leigh]

On Thu, Dec 30, 2010 at 09:06:28PM +0100, Jakub Wilk wrote:

Hi Jakub,

> On kfreebsd-*, schroot is not able to unmount everything if chroot name  
> is longer than 13 characters:
>
> # schroot -c 123456789abcde echo Hello world
> Hello world
> E: 10mount: umount: unmount of /var/lib/schroot/mount/123456789abcde-e7de3ef4-e02c-430c-b9d9-0e4eb34f3bd0/dev/f failed: Invalid argument
>
> If the name is longer than 18 characters, it cannot even run a command:
>
> # schroot -c 123456789abcdefghij echo Hello world
> E: 10mount: mount: dev : File name too long
> E: 10mount: umount: unmount of /var/lib/schroot/mount/123456789abcdefghij-cf720545-3204-4bda-93a8-82bbd3ac46ca/ failed: Invalid argument
>
> Given that e.g. sbuild-createchroot creates chroot named  
> "$SUITE-kfreebsd-$CPU-sbuild" (which is >= 23 characters), this is quite  
> an unfortunate limitation.

Yes, it is.  Given that schroot only runs the system's standard
"mount" and "umount" commands, is this an underlying limitation in
either those commands or in the system calls?  Or in the shell?

The mount(2) manpage for freebsd indicates that 1023 characters is the
maximum length, with 255 characters the limit for a single path
component.  It doesn't look like that's an issue (though you are getting
ENAMETOOLONG in your second example).  The initial error in your
examples is mount/umount returning EINVAL, which the manpage says means
"The super block for the filesystem had a bad magic number or an out of
range block size."

It would be useful to run the above commands with
"--verbose --debug=notice" so that we can see exactly what's going on.
If the path is getting truncated or mangled, that should show up.
This might not be sufficient to get the exact mount commands; running
as root "strace -f -o $log" might do that better.

> Also, please don't try my examples at home, because the only way to  
> unmount stuff mounted by schroot seems to be: put SESSIONS_RECOVER="end"  
> into /etc/default/schroot and reboot. :/

I'm afraid I don't have a kfreebsd installation to test on right now,
and I haven't used it before.  While I'm sure I can set one up in kvm,
this appears (at least at first glance) to be [k]freebsd-specific
since we haven't run into this problem on Linux in the 5½ years I've
been maintaining schroot.  If anyone with specific BSD knowledge
could provide some more detailed investigation, that would be great.

In particular, do you run into failures if you manually mount/umount
progressively longer paths?  In the examples above, it looks like the
lengths are around 80 chars unless they were clipped, and that's far
too short.

Also, it's weird it umounts on reboot.  The schroot init script
simply calls "schroot --end-session $session" for each open
session; which just runs the umount commands in the 10mount setup
script like above.  It's odd that it's failing when run by the
user and not when run by the setup script, since both do exactly
the same thing.  Maybe worth trying to manually create a session
with --begin-session/--run-session/--end-session and compare the
behaviour with automatically running a command (the default
behaviour).  Again, there shouldn't be a difference, but is worth
looking at in case there's something odd going on there (possibly
the case if it's writing out something odd into the session file,
but very unlikely).


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101230/b27d01fc/attachment.pgp>