Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 409565 - Hibernate may destroy fat32 partitions on USB-devices
Summary: Hibernate may destroy fat32 partitions on USB-devices
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: Normal major
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-24 17:00 UTC by Till Crueger
Modified: 2012-11-04 23:55 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Log messages of sleep and wakeup (usbfail.log,22.24 KB, text/plain)
2012-03-24 19:32 UTC, Till Crueger
Details
The .config I am using (.config,86.74 KB, text/plain)
2012-03-24 19:34 UTC, Till Crueger
Details
One of the files that was overwritten (moderncvthemecustom.sty,8.03 KB, text/plain)
2012-03-24 19:38 UTC, Till Crueger
Details
output of "emerge --info" (emerge_info.txt,4.76 KB, text/plain)
2012-04-07 09:35 UTC, Till Crueger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Till Crueger 2012-03-24 17:00:13 UTC
Here is what happened:

I worked on the laptop with a automounted usb-drive using fat32. While the drive was mounted I put the laptop into hibernation, without prior unmounting of the device. When the usb-drive was powerless (no indicator light on the usb drive) I removed it from the laptop. When I woke up the computer the drive was not reattached (forgotten). After reattaching the drive no partitions were automounted. 

Manual mounting of the drive failed:

chi mnt # mount -t vfat /dev/disk/by-id/usb-JetFlash_Transcend_4GB_QTMFKJQQ-0\:0-part1 usb/
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       Manchmal liefert das Syslog wertvolle Informationen – versuchen
       Sie  dmesg | tail  oder so

dmesg | tail reported the following: 

FAT-fs (sdb1): bogus number of FAT structure
FAT-fs (sdb1): Can't find a valid FAT filesystem

doing an fsck.vfat on the partition of the stick resulted in the following:

chi mnt # fsck.vfat /dev/disk/by-id/usb-JetFlash_Transcend_4GB_QTMFKJQQ-0\:0-part1 
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
Cluster size is zero.

Some files could be manually recovered using TestDisk and PhotoRec, however some files seem to have been overwritten.

The system should cleanly synch and/or unmount usb drives prior to entering sleep mode.
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2012-03-24 17:28:41 UTC
I don't see how this could be anything other than a hardware failure. It would seem that the destructive write to the partition table occurred before or during syncing.

1) Please post relevant dmesg output of the event in a comment or attachment.
2) Please tell us how you make the system hibernate (what command you issued, for 
   instance).
3) Please attach your kernel .config.
Comment 2 Till Crueger 2012-03-24 19:32:43 UTC
Created attachment 306553 [details]
Log messages of sleep and wakeup

This is the relevant lines of my messages file for the time of the problem. The system was put to sleep around 23:27 and woken up a few minutes later at around 23:32. Some things I do not understand:

During the time when the system was entering sleep mode, only the networkmanager and the dhcp were producing messages. There is not notice of synced disks. However there is a noticed of the system syncing disks at 23:32, when the system was waking up. Either this message was delayed, or the actual sync did not happen in time before the system went to sleep. Also after the system woke up there are some messages about a possible power failure on the usb system. Here are the lines I do not understand:

Mar 23 23:32:37 chi kernel: PM: Syncing filesystems ... done.

Mar 23 23:32:37 chi kernel: usb usb2: root hub lost power or was reset
Mar 23 23:32:37 chi kernel: usb usb3: root hub lost power or was reset
Mar 23 23:32:37 chi kernel: usb usb1: root hub lost power or was reset

Mar 23 23:32:37 chi kernel: usb 1-5: USB disconnect, device number 4
Comment 3 Till Crueger 2012-03-24 19:34:32 UTC
Created attachment 306555 [details]
The .config I am using

This .config was generated by the genkernel script. For now I am not using my own configured kernel, but the default kernel configuration provided by genkernel.
Comment 4 Till Crueger 2012-03-24 19:38:27 UTC
Created attachment 306557 [details]
One of the files that was overwritten

This is one of the files which was overwritten. For some reason it starts with "USBC". All other files, which I found to have been overwritten also contain USBC in the first bytes. However this might also be an artifact created by the restoration process.
Comment 5 Till Crueger 2012-03-24 19:39:56 UTC
I am not using any command for hibernation. Hibernation is entered automatically by closing of the laptop lid.

Let me know if you have any more questions and I will supply the necessary information as soon as possible.
Comment 6 Mike Pagano gentoo-dev 2012-04-06 13:04:43 UTC
emerge --info, please
Comment 7 Till Crueger 2012-04-07 09:35:09 UTC
Created attachment 308077 [details]
output of "emerge --info"
Comment 8 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2012-11-04 23:55:28 UTC
As this is most likely an unfortunate hardware failure as USB drive was not properly unmounted, despites being synced; this might have to do something with the controller of the USB drive so we are most likely not going to find the cause of this, hence I'll close this bug until more users experience this or more details on the exact problem arise.

It would definitely help if this issue were reproduce-able (multiple people are able to replicate it) as that would point out an actual issue and not something like a power spike or a hardware controller problem...

A Windows user has experienced something similar as well in http://superuser.com/questions/436520/restoring-mbr-partition-table-and-boot-sector-of-memory-card-without-data-loss where an answerer mentions "It's a electronic failure in the memory card reader (at least in my case).". Since I know that asker is active you might get more information on what he did exactly to get an idea. 

To understand the other things that happened, here's some explanation and things that might be worth experimenting with:

> dmesg | tail reported the following: 

> FAT-fs (sdb1): bogus number of FAT structure
> FAT-fs (sdb1): Can't find a valid FAT filesystem

> doing an fsck.vfat on the partition of the stick resulted in the following:

> chi mnt # fsck.vfat /dev/disk/by-id/usb-JetFlash_Transcend_4GB_QTMFKJQQ-0\:0-part1 
> dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
> Cluster size is zero.

Even if the USB drives were not in sync, it would not change the FAT structure or cluster size in a way it renders the drive inaccessible; it could break part of the FAT file table (due to changes that were not committed to the USB drive), but not make it entirely inaccessible.

> The system should cleanly synch and/or unmount usb drives prior to entering sleep mode. ... Either this message was delayed, or the actual sync did not happen in time before the system went to sleep.

`grep -r "Syncing filesystems" /usr/src/linux` yields

kernel/power/user.c:            printk("Syncing filesystems ... ");
kernel/power/hibernate.c:       printk(KERN_INFO "PM: Syncing filesystems ... ");
kernel/power/suspend.c: printk(KERN_INFO "PM: Syncing filesystems ... ");

So, you did a hibernate, let's look at kernel/power/hibernate.c

        printk(KERN_INFO "PM: Syncing filesystems ... ");
        sys_sync();
        printk("done.\n");

        error = freeze_processes();
        if (error)
                goto Free_bitmaps;

        error = hibernation_snapshot(hibernation_mode == HIBERNATION_PLATFORM);

What we see here is that it is syncing the file system and immediately after that it freezes the processes. Because of that, your system logger will be unable to place those in your messages files until after it has done the hibernation and unfrozen the processes again.

As shown above, a sync does happen and the processes are frozen and the hibernation snapshot is made. If you don't believe me you can go and insert your own debug output to verify it's running that code.

sys_sync is somewhat generic, so that should work. If you want to be sure, you can explicitly call sys_syncfs() as well or perhaps just change your hibernate command in the application that responds to the lid close to explicitly do a `sync && ...`.

> Also after the system woke up there are some messages about a possible power failure on the usb system.

You have plugged out the USB drive; that's simply why it warns you they have lost their power, as the kernel still assumes they are mounted after you woke the laptop up.