Intermittently fails to recognize file system

[Morten Kjeldgaard]

Binary package hint: sbuild

Once in a while, perhaps one out of every 5-10 times I run my sbuilder, it fails to run. I get an error message like the one below. The program usually starts if I repeat the command, sometimes (rarely) I have to do that twice.

mok@yeti:~/Projects/gpp4$ sbuild -d natty -A gpp4_1.3.1-0ubuntu1.dsc
E: 10mount: mount: unknown filesystem type 'DM_snapshot_cow'
E: natty-amd64-99ed796b-03a4-4808-989c-fdb337c46584: Chroot setup
failed: stage=setup-start
Chroot setup failed
E: Attempt to log to nonexistent log stream
Error creating chroot session: skipping gpp4
─ ...
Finished at 20110222-1057
Build needed 00:00:00, 0k disc space

[Morten Kjeldgaard (mok0)]

Forgot to specify my system info in the above:

LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu 10.04.2 LTS
Release: 10.04
Codename: lucid

[Roger Leigh (rleigh)]

Are you using lvm-snapshot chroots with schroot?

If this is the case, is the snapshot device mounted in your filesystem? If so, and the filesystem is "dirty", i.e. you are making changes to it while you are snapshotting, or there are pending changes not yet written to disc, then the filesystem will be in an inconsistent state in the snapshot, and it may fail to mount.

If this is the case, the solution is to not mount the device being snapshotted. This way, the filesystem will always be mountable. Note that there is a contrib schroot setup script, 09fsck, to fsck the snapshot before mount. It's a workaround, but I wouldn't recommend it unless you had no other choice.

Regards,
Roger
(Debian maintainer of sbuild and schroot)

[Morten Kjeldgaard (mok0)]

The schroots were created using the mk-sbuild script of the ubuntu-dev-tools package. For lucid (amd64 architecture) I've got 2 filesystems, neither of which are mounted unless a build is in progress. "lucid-amd64" appears to be a clone of "lucid-amd64-source", and when updating the builder etc. I run apt-get update etc. on the -source filesystem.

$ schroot -l |grep lucid-amd
lucid-amd64
lucid-amd64-source

These have the following data:

$ schroot -i -c lucid-amd64
  ─── Chroot ───
  Name lucid-amd64
  Description lucid-amd64
  Type lvm-snapshot
  Priority 3
  Users
  Groups sbuild root admin
  Root Users
  Root Groups root sbuild admin
  Aliases
  Environment Filter ^(BASH_ENV|CDPATH|ENV|HOSTALIASES|IFS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMAIN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TERMPATH)$
  Run Setup Scripts true
  Script Configuration script-defaults
  Session Managed true
  Session Cloned true
  Session Purged false
  Device /dev/work/lucid_amd64_chroot
  LVM Snapshot Options --size 4G
  Personality linux
  Mount Options -o noatime
  Source Users
  Source Groups
  Source Root Users
  Source Root Groups root sbuild admin

and

$ schroot -i -c lucid-amd64-source
  ─── Chroot ───
  Name lucid-amd64-source
  Description lucid-amd64 (source chroot)
  Type block-device
  Priority 3
  Users
  Groups
  Root Users
  Root Groups root sbuild admin
  Aliases
  Environment Filter ^(BASH_ENV|CDPATH|ENV|HOSTALIASES|IFS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMAIN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TERMPATH)$
  Run Setup Scripts true
  Script Configuration script-defaults
  Session Managed true
  Session Cloned false
  Session Purged false
  Device /dev/work/lucid_amd64_chroot
  Personality linux
  Mount Device /dev/work/lucid_amd64_chroot
  Mount Options -o noatime
  Filesystem union type none

Hope this helps.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Troy Straszheim (straszheim)]

I've got this on oneiric

[Mathieu Sauve-Frankel (msf)]

I've seen this with sbuilder on lucid amd64