On Mon, Feb 01, 2010 at 09:22:00PM +1100, Hamish Moffatt wrote: > Package: schroot > Version: 1.4.0-1 > Severity: critical > Justification: causes serious data loss > > I upgraded schroot from 1.2.3-1+b1 to 1.4.0-1, which wanted to replace > some config files, which I have customised. I declined, intending to fix > it later.
OK. This shouldn't be an issue, since they haven't changed that much, and the changes /should/ be forward-compatible. However, it's possible, at least in theory, that a mixture of old and new files could interact badly and do this. But, I must stress that the scripts already have a certain level of sanity-checking built in to prevent anything bad happening to the host. > I started an schroot into an old sid 32-bit chroot (from my sid 64-bit > host), and didn't notice any error messages, but found I was still > running 64-bit binaries. I think the actual chroot() failed. If you run with the additional options '-v --debug=notice', you should get a much more detailed log of what schroot is doing, including every file copy. This should tell you what's going wrong. > Later after exitting, I found that a bunch of files in /etc were now > empty: passwd, group, shadow, hosts, protocols, services. Firstly, many apologies for schroot losing your data. The new version has had several months of testing before going into unstable, and this is the first dataloss bug I've seen. This is really strange. Could you please check a few things for me? Firstly, in /etc/schroot/setup.d/00check at the bottom, there's a check that CHROOT_PATH is defined and NOT '/'. This to make sure any subsequent scripts don't scribble over the host filesystem if it's not been defined. Is this still present? This sanity check should never ever trigger unless there's a schroot bug or configuration error. Now, the files you report empty are all NSS database files. In schroot 1.2.x, these were copied in by the 20copyfiles script, using the file list in COPYFILES (script-config->script-defaults). In 1.4.x, this is done by the 20nssdatabases script which uses getent(1) which allows copying of all NSS data, irrespective of source, e.g. db, nis, ldap etc. This uses the NSSDATABASES option to specify the databases to copy. Was resolv.conf also affected? Next, in /etc/schroot/setup.d/20copyfiles, is the copy code using CHROOT_PATH to copy? This script is most likely the cause of your problems. Alternatively, /etc/schroot/setup.d/20nssdatabases is the other possible culprit, and the same question goes here. I suspect it's a combination of your mixed old/new configuration, *but*, the 20copyfiles should redundantly copy into the chroot without any negative effects. Neither of these scripts should *ever* do anything untoward with the host under any circumstances. It might be helpful to have a copy of all the dpkg cruft (dpkg-new, dpkg-dist, dpkg-old etc), or even a tarball of your entire /etc/schroot directory if possible to see what inconsistency causes this misbehaviour. Thanks, 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