Bug 505664 - Garbage in /dev/sdc5 after fedora setup
Garbage in /dev/sdc5 after fedora setup
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
11
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-12 15:58 EDT by Jonas Wielicki
Modified: 2010-01-18 11:43 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-18 11:43:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hexedit /dev/sdc5, sector 128 (2.51 KB, text/plain)
2009-06-12 15:58 EDT, Jonas Wielicki
no flags Details
Anaconda log (144.62 KB, text/plain)
2009-08-14 14:51 EDT, Jonas Wielicki
no flags Details
Anaconda storage log (313.19 KB, text/plain)
2009-08-14 14:52 EDT, Jonas Wielicki
no flags Details
Anaconda program log (?) (166.02 KB, text/plain)
2009-08-14 14:53 EDT, Jonas Wielicki
no flags Details

  None (edit)
Description Jonas Wielicki 2009-06-12 15:58:20 EDT
Created attachment 347658 [details]
hexedit /dev/sdc5, sector 128

greetings at first

Description of problem:
After running the installation, I wanted to mount my backup drive, noticing that there was no partition to mount. I was not sure about what was going on, so, after doing some research, I began to look for a filesystem using parted. As this did not find anything I tried to just recreate the partition, hoping that the file system was not damaged and just the partition table entry got lost. mount -t vfat /dev/sdc5 test informed me that it was uncapable to mount the partition - bad superblock, dmesg | tail told me about an invalid fat32 partition.
Now I wanted to know what was going on and looked at the drive using hexedit. In the first blocks I found nothing unusual, when the range /dev/sdc5 began there were just zeros... I looked further until I reached sector 128 in which was written what I attached as "output.txt". I looked at other sectors and I think that the data stored in the "upper" sectors may be completely intact. I found some plain-text data I recognize.
[I would be glad if at least someone could give a hint how to save this file system]

Version-Release number of selected component (if applicable):
Anaconda version which was given with Fedora 11 release (9.6.09), I do not know the exact version number.

How reproducible:
As you might imagine, I am not very hot on retrying to frag a file system, you know...
  
Actual results:
Garbage in the /dev/sdc5 partition.

Expected results:
/dev/sdc5 should not have been altered, it was a backup partition which was not touched in anaconda.

Additional info:
Comment 1 Jonas Wielicki 2009-06-20 15:10:37 EDT
In the last days I worked again on it, trying to repair the file system. I found out that only the first 2048 sectors of /dev/sdc5 got zeroed-out (except the part I submited).

By the way, I was able to save the file system by copying the first 2048 sectors from an older 1:1 backup of the drive.
Comment 2 David Lehman 2009-08-14 12:17:43 EDT
Do you still have the logs from the install? They would be in /var/log/{anaconda.log,storage.log,program.log}. If not, it might help if you could describe the configuration steps you followed using the fedora installer.
Comment 3 Jonas Wielicki 2009-08-14 14:51:40 EDT
Created attachment 357494 [details]
Anaconda log
Comment 4 Jonas Wielicki 2009-08-14 14:52:08 EDT
Created attachment 357495 [details]
Anaconda storage log
Comment 5 Jonas Wielicki 2009-08-14 14:53:40 EDT
Created attachment 357497 [details]
Anaconda program log (?)
Comment 6 Jonas Wielicki 2009-08-14 14:55:33 EDT
Here they are. I hope they are useful.

greetings
Comment 7 David Lehman 2009-08-14 17:37:29 EDT
Based on the logs it looks like it could be a matter of device scan order changing from one product/release to another. The install logs show sdc as having only one partition, which was not altered in any way. sda, however, started with six partitions and was altered significantly. sdb had no partitions and was not altered either. Does this shed some light on the situation?
Comment 8 Jonas Wielicki 2009-09-07 02:23:53 EDT
sdc was my backup hard drive which only had one partition, which is completely okay. I did not change it.
sda was my old linux setup which I then killed and reformed for secondary usage. sdb was a new drive on which I setup my new setup, so there is now a full-disk-sized luks-encrypted ext4 partition. This does not occur in the logs?

When performing the partitioning, I also used the infos about disk size to determine which hard drives I had to change, thus I was not dependent on the disk names.

greetings
Comment 9 David Lehman 2009-09-07 11:17:25 EDT
(In reply to comment #8)
> sdc was my backup hard drive which only had one partition, which is completely
> okay. I did not change it.
> sda was my old linux setup which I then killed and reformed for secondary
> usage. sdb was a new drive on which I setup my new setup, so there is now a
> full-disk-sized luks-encrypted ext4 partition. This does not occur in the logs?

Your entire initial report talks about sdc5, including the subject/summary of this bug. Now you are saying that sdc has only one partition? Something is not making sense. Can you please clarify?
Comment 10 Jonas Wielicki 2009-09-07 12:46:24 EDT
Yep. I had the one partition as logical partition. I know, that doesnt really make much sense, but it was like this. So sdc is the disk, sdc1 is the extended partition and sdc5 the one which has been fragged.

greetings
Comment 11 David Lehman 2009-09-08 12:08:19 EDT
Ok. In that case, like I said before, there is nothing in the logs that indicates that the installer touched sdc in any way. I don't know what else to tell you.
Comment 12 David Lehman 2010-01-18 11:43:23 EST
I'm sorry you had a bad experience, but there isn't really anything I can do given the information in this report.

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