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.
Description: Digital signature