Casper only scans vfat filesystems for cow files

[Agostino Russo]

Binary package hint: casper

find_cow_devices in scripts/casper-helpers explicitly requires a vfat filesystem.
The limitation is needlessly restrictive.

There is already a FIXME in there:

if [ "${devfstype}" = "vfat" ] || [ "${devfstype}" = "ext2" ] ; then # FIXME: all supported block devices should be scanned

There is a function is_supported_fs in scripts/casper that can be used for the purpose with little/no modification.

[Launchpad Janitor (janitor)]

This bug was fixed in the package casper - 1.132

---------------
casper (1.132) intrepid; urgency=low

  [ Colin Watson ]
  * Switch default unionfs implementation to aufs.

  [ Agostino Russo ]
  * Do not scan only vfat volumes when looking for cow devices (LP: #230703)
  * Allow casper to use a squashfs filesystem within an arbitrary path (LP:
    #230716, #207137)

 -- Evan Dandrea <email address hidden> Wed, 28 May 2008 15:01:30 -0400

[Martin Pitt (pitti)]

Accepted into -proposed, please test and give feedback here

[Steve Langasek (vorlon)]

Tollef Fog Heen points out on IRC that this is a potential data loss regression:

 < Mithrandir> slangasek: mounting file systems will always cause the journal to be replayed, something which can cause data loss if the file system is in use by a hibernated system.
 < Mithrandir> so, hibernate, boot live cd, boom, instant file system corruption.
 < Mithrandir> luckily only if you try to use it with persistence enabled, it seems.

This may be considered an acceptable risk going forward, but is an inappropriate change in an SRU. Please drop ext3 from the list of filesystem types to scan.

[Mario Limonciello (superm1)]

Why not just mount without replaying the journal then?

Mount has an ext3 specific option, 'noload':

       noload Do not load the ext3 file system’s journal on mounting.

[Tollef Fog Heen (tfheen)]

This is a really, really bad idea; it can easily cause data loss in the following scenario:

Machine hibernates, user boots an Ubuntu live CD which then proceeds to scan all partitions. Doing this causes the journal of the root partition of the suspended system to be replayed. Later, the hibernated system is resumed without it noticing that the journal having been replayed. This causes file system corruption.

[Agostino Russo (ago)]

Hmm wouldn't the same issue affect hd-media/iso-scan then? And lupin... In fact any dual boot setup sharing the same partition is potentially vulnerable (unless I misunderstood).

[Colin Watson (cjwatson)]

Agostino: yes, it is a real problem elsewhere, and I'm pretty sure there are bugs about it. That doesn't justify introducing the same bug here, in a much more widely used case. Far more people use the Ubuntu live CD than the other cases you mentioned, and it is extremely important that it not trash the system by default.

In the case of hd-media or wubi installations, while it's still a bug, at least you're expecting to perform an installation and it's much more likely that you'll shut down the computer properly first. Hibernating and booting a live CD is a much more plausible real-world scenario than either hibernating and performing a USB stick installation or hibernating and performing a Wubi installation.

This change should be reverted, and a comment should be added above the code in question to indicate that it must not be modified to include any filesystem type that might be able to mount a journalled filesystem, so that we don't forget this in future.

[Colin Watson (cjwatson)]

See also bug 41624.

[Agostino Russo (ago)]

I reverted the changes in the hardy.proposed branch

[Martin Pitt (pitti)]

Please get the reverted patch uploaded to hardy-proposed. ATM we cannot move the current hardy-proposed package into hardy-updates.

[Steve Langasek (vorlon)]

This has been accepted now into hardy-proposed.

[Colin Watson (cjwatson)]

This change was reverted in intrepid in the same way, so syncing up the states to Won't Fix.