Warning should be displayed when a filesystem is remounted read-only.

[Scott Bronson]

When the kernel notices massive data corruption or a hardware failure, it remounts the affected partitions read-only. However, the user is never notified. When random stuff suddenly starts breaking or acting really weird, the user will likeliy reboot the computer and miss an important opportunity to back up valuable files.

Instead, when the kernel remounts a partition r/o a dialog box should pop up saying, "Warning! Disk failure on /home. Please limit your activity to a minimum and copy all valuable files to a more reliable location."

In this log, /dev/hda6, the /home partition, fails:

hermanr__ [6617016.214000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hermanr__ [6617016.214000] hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=12640272, high=0, low=12640272, sector=12640271
hermanr__ [6617016.214000] ide: failed opcode was: unknown
hermanr__ [6617016.214000] end_request: I/O error, dev hda, sector 12640271
hermanr__ [6617016.214000] journal_bmap: journal block not found at offset 5132 on hda6
hermanr__ [6617016.214000] Aborting journal on device hda6.
hermanr__ [6617016.366000] ext3_abort called.
hermanr__ [6617016.366000] EXT3-fs error (device hda6): ext3_journal_start_sb: Detected aborted journal
hermanr__ [6617016.366000] Remounting filesystem read-only

There are probably other kernel failures that would warrant a warning dialog too but, due to the probable data loss, this one seems the most important.

filed against the hal package because I don't know of a better package to handle this. Filed on behalf of Herman Robak after a discussion over IRC.

[Martin Pitt (pitti)]

g-v-m should check for this condition and present a warning dialog.

[Martin Pitt (pitti)]

Note to self: This dialog should also have an option to start a file system check on that device.

[Chris Coulson (chrisccoulson)]

Martin,

With Nautilus handling the mounting of removable media now, should this bug be re-assigned?

[Sebastien Bacher (seb128)]

changing to a wishlist since that's a feature request and reassigning to the desktop team rather since the bug had to activity for some years now

[Sebastien Bacher (seb128)]

The request has been sent on http://bugzilla.gnome.org/show_bug.cgi?id=553843

[PomCompot (pomme-compote-launchpad)]

Could confirm the importance of such a dialog. Get a FAT32 external media corrupted (accidentally unplugged while writing) and search for a while what was the reason for the mount read only behavior. dmesg was helpfull but it's not a acceptable solution for the common user.

I use Ubuntu Hardy. Strange thing, my wife's laptop under breezy has mounted the same file system read-write with no problem. Cannot reproduce now that an fsck has resolved the problem.

[h2g2bob (d-j-batley)]

Where does the work for this need to be done? Do we need code to get the information out of the kernel, or code in hal, or just to gnome/gvm? How deep do we need to go?

[Scott Bronson (bronson)]

It seems like it would be related to HAL since that's all about kernel
communication / notification. Perhaps ask HAL upstream?

[Martin Rehn (minpost)]

This also affects removable media such as USB drives and USB sticks. Since these are brittle devices, with crappy FAT file systems, that often get yanked without unmounting, the problem is fairly common. For example, when this happens:

[ 1364.080987] FAT: Filesystem panic (dev sdb1)
[ 1364.080990] fat_get_cluster: invalid cluster chain (i_pos 32499)

The filesystem is at this point still shown as "rw" by mount, and nowhere in the UI is there even an indication that the file system is now read only. Many programs (e.g. OpenOffice) will give very non-informative error messages when they try to write to the file system. Others (e.g. mount) give a proper error message, though.

Three things should be done:

(1) Pop up a notification informing the user of the problem.

(2a) Show the file system as read-only in the UI. Maybe remount it as read-only (such that this is reflected by the output of mount) to accomplish this. Hopefully this would also help some apps to give better error messages.
(2b) Even better would be if the drive icon could also get an emblem indicating that there is a problem.

(3) Offer to remedy the error. "fsck -a /dev/sdb1" followed by an "rw" remount would work in many cases. For a small broken FAT file system such as a USB stick another reasonable option, in many cases, would be to copy the files off the file system, format it and then copy the files back.

[Eero Tamminen (oak-helsinkinet)]

> (3) Offer to remedy the error. "fsck -a /dev/sdb1" followed by an "rw" remount would work in many cases. For a small broken FAT file system

That can take while so it should have a progress bar. Dosfsck (aka fsck.vfat) is also pretty crappy. You may need to run it up to 3 times to fix corrupted VFAT completely which makes showing progress a bit more annoying. With a worst-case full VFAT having tens of GB worth of small files, it can also take up to something like 1GB of RAM (there are some patches for this, I think one of mine (reported by another person) is still unapplied in Ubuntu Bugzilla).

[Jonathan Thomas (echidnaman)]

Hello,

Thanks for reporting this feature request! Unfortunately, at this time Kubuntu does not have the developer manpower needed to implement and maintain many features at the Kubuntu level. This wish would best be reported and tracked at https://bugs.kde.org, so that it can be implemented by the KDE developers themselves. Once implemented in KDE, it will be included in Kubuntu once the KDE version the feature is implemented in reaches Kubuntu.

Thanks!