Casper only scans vfat filesystems for cow files

Bug #230703 reported by Agostino Russo
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
casper (Ubuntu)
Won't Fix
Undecided
Agostino Russo
Hardy
Won't Fix
Undecided
Unassigned
Intrepid
Won't Fix
Undecided
Agostino Russo

Bug Description

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.

Agostino Russo (ago)
Changed in casper:
status: New → Confirmed
Agostino Russo (ago)
Changed in casper:
assignee: nobody → ago
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in casper:
status: Confirmed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here

Changed in casper:
status: New → Fix Committed
Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Changed in casper:
status: Fix Committed → In Progress
Martin Pitt (pitti)
Changed in casper:
status: Fix Released → Fix Committed
status: Fix Committed → In Progress
Revision history for this message
Mario Limonciello (superm1) wrote :

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.

Revision history for this message
Tollef Fog Heen (tfheen) wrote :

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.

Revision history for this message
Agostino Russo (ago) wrote :

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).

Revision history for this message
Colin Watson (cjwatson) wrote :

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.

Revision history for this message
Colin Watson (cjwatson) wrote :

See also bug 41624.

Revision history for this message
Agostino Russo (ago) wrote :

I reverted the changes in the hardy.proposed branch

Agostino Russo (ago)
Changed in casper:
status: In Progress → Won't Fix
Revision history for this message
Martin Pitt (pitti) wrote :

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

Revision history for this message
Steve Langasek (vorlon) wrote :

This has been accepted now into hardy-proposed.

Revision history for this message
Colin Watson (cjwatson) wrote :

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

Changed in casper:
status: In Progress → Won't Fix
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers