Bug 1031168 - Resizing partition results in inconsistent file-system state
Resizing partition results in inconsistent file-system state
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-11-15 14:03 EST by lasse.schuirmann
Modified: 2014-10-13 07:52 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-13 11:23:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description lasse.schuirmann 2013-11-15 14:03:53 EST
Description of problem:

I'm not a developer - but I want you to know about this bug before it occurs on a user. This report ist not to complain about the issues and lost data but to help you. I found a wiki entry where it is stated that not a bug of this kind is reported yet - be sure to edit it. I was not able to get a log of some kind.

Anaconda corrupted a partition through resizing it.

Information about the Hardware:
I have no SSD, Intel 64 bit (i3) processor. A 500GB harddrive.

How reproducible:
I didn't try to reproduce it.

Steps to Reproduce:
Not known.

This is what I've done:
1. Wrote Fedora 20 image to DVD (downloaded 15 Nov. 2013)
2. Booted from the CD
3. Navigated into the grafical partitioning manager
4. Resized sda2, sda8, sda9 (minus 20gb per partition roughly)
5. Configured the rest normally
6. Hit the install button

Actual results:
First it said "resizing /dev/sda8", then after some time it switched to "resizing /dev/sda9". Thats when the error occurred, some python traceback was shown (I'm sorry I didn't capture it) and I got just one button proposing the abortion of the installation. After the reboot /dev/sda8 was corrupted. (The other partitions seem not to be harmed.) Mount returned the usual 'bad superblock'. Restoring the superblock from a backup didn't help because the size didn't match. I was able to restore some of the data via testdisk, some other data seems corrupted as well.

Expected results:
Anaconda resizes the partitions and installs fedora.

Additional info:
Some diagnostic information about my partition layout:

255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x60602ced

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848   307202047   153497600    7  HPFS/NTFS/exFAT
/dev/sda3       307204156   976771071   334783458    5  Extended
Partition 3 does not start on physical sector boundary.
/dev/sda5       969011200   976771071     3879936   82  Linux swap / Solaris
/dev/sda6   *   307204158   502516656    97656249+  83  Linux
Partition 6 does not start on physical sector boundary.
/dev/sda7       502516658   502711968       97655+  83  Linux
Partition 7 does not start on physical sector boundary.
/dev/sda8       502711970   605861887    51574959   83  Linux
Partition 8 does not start on physical sector boundary.
/dev/sda9       698025984   948529151   125251584   83  Linux

Partition table entries are not in disk order

If you need more information I'll do my best to obtain it. At least I have a image of the corrupted partition; just in case.
Comment 1 David Lehman 2013-11-15 15:24:28 EST
Have you rebooted since the error occurred? If not, please attach the following log files:


Comment 2 lasse.schuirmann 2013-11-15 15:33:27 EST
(In reply to David Lehman from comment #1)
> Have you rebooted since the error occurred? If not, please attach the
> following log files:
>  /tmp/anaconda.log
>  /tmp/program.log
>  /tmp/storage.log
> Thanks.

I found out about the file system inconsistency after the reboot. I am sorry that I can not provide you the files. I didn't think that this might be an unreported bug as it occurred.

Note You need to log in before you can comment on or make changes to this bug.