On Sun, Jun 06, 2010 at 12:26:32PM +0100, Roger Leigh wrote: > severity 567932 important > thanks > > On Thu, Feb 18, 2010 at 10:16:51AM +1100, Hamish Moffatt wrote: > > On Wed, Feb 17, 2010 at 11:12:52PM +0000, Roger Leigh wrote: > > > On Thu, Feb 18, 2010 at 09:41:17AM +1100, Hamish Moffatt wrote: > > > > Here are the only files which were modified. I have since put in the > > > > versions from 1.4.0-1 and customized those and schroot is working fine. > > > > > > Many thanks, I'll look at these in more detail tomorrow. > > > > > > Just to check, if you didn't upgrade the altered conffiles during the > > > update, this left 10mount in its customised state with the replacement > > > as 10mount.dpkg-new, and all the other setup scripts were updated? > > I'm downgrading the serverity of this bug to "important". Because there > has been just the one reported instance of this bug, and we haven't as > yet identified the cause, I think this is more appropriate. I won't > close it though--if we find out what in the scripts triggered this > behaviour, I would like to add additional safeguards into the current > scripts if that's possible.
Hi Hamish, I now have an idea about what might have gone wrong (at the end of this mail). It would be great if you could let me know if this idea is correct or not. Looking at the 10mount script you provided, it looks like it originated in version 1.1.5; this is the version which provides the most minimal sensible diff: --- bin/schroot/setup/10mount 2010-06-06 22:14:49.515889319 +0100 +++ /tmp/10mount 2010-06-06 22:10:40.783889915 +0100 @@ -1,5 +1,5 @@ #!/bin/sh -# Copyright © 2005-2007 Roger Leigh <rle...@debian.org> +# Copyright � 2005-2007 Roger Leigh <rle...@debian.org> # # schroot is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by @@ -102,10 +102,12 @@ if [ "$CHROOT_TYPE" != "plain" ]; then do_mount "-t proc" "proc" "${CHROOT_PATH}/proc" - do_mount "-o rw,bind" "/dev/pts" "${CHROOT_PATH}/dev/pts" + #do_mount "-o rw,bind" "/dev/pts" "${CHROOT_PATH}/dev/pts" + do_mount "-o rw,bind" "/dev" "${CHROOT_PATH}/dev" do_mount "-t tmpfs" "tmpfs" "${CHROOT_PATH}/dev/shm" do_mount "-o rw,bind" "/home" "${CHROOT_PATH}/home" do_mount "-o rw,bind" "/tmp" "${CHROOT_PATH}/tmp" + do_mount "-o rw,rbind" "/srv" "${CHROOT_PATH}/srv" fi elif [ $1 = "setup-stop" ]; then While this doesn't directly explain why the files got deleted, this is a rather old version of the script and it may be the case that it did make some assumptions which didn't hold for newer schroot versions. However, your script should still have functioned perfectly well, and I don't think it's related unless you have some unusual setup such as a symlink from /etc to some shared location under /srv. I don't think this explains why the files *on your host filesystem* got zeroed. The only explanation I can think of there is that the 20nssdatabases script does this: dup_nss "$db" "${CHROOT_PATH}/etc/$db" where dup_nss is simply getent "$1" > "$2" Normally, this would boil down to getent passwd > /var/lib/schroot/session/$session/etc/passwd This would also normally be OK. The only circumstance where it could delete the file is if /etc/passwd and /var/lib/schroot/session/$session/etc/passwd *are the same file*. i.e. you have your root filesystem (or at least /etc) as the chroot filesystem either mounted or bind mounted directly or as an additional mount. Could this possibly be the case with your setup? In earlier versions where 20copyfiles copied the databases, we checked if the file contents and/or inodes were the same so that a file would never be copied on top of itself. With 20nssdatabases, the shell I/O redirection will zero the file prior to exec'ing getent. This means that getent will read and empty database file (unless using NIS/LDAP etc.) and then have nothing to write. But, this will only occur in the specific situation where the root filesystem (or parts of it) are mounted inside. While we specifically check if / is used directly, it's quite possible to bind-mount /etc. 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.
signature.asc
Description: Digital signature