How to rescue your partitions after upgrade to Fedora 18 Alpha eats them

Sun Sep 23 23:43:44 UTC 2012

On 09/23/2012 07:22 PM, Roger wrote:
> On 09/24/2012 02:09 AM, Eddie G. O'Connor Jr. wrote:
>> On 09/23/2012 07:33 AM, Jakub Kicinski wrote:
>>> Hi all,
>>>
>>> I recently had a weird problem after "upgrade" to Fedora 18 Alpha. I
>>> decided to share the solution, maybe it will help someone.
>>>
>>> But first:
>>>
>>> 1. The rant
>>>
>>> Clearly something bad is going on in Fedora world. I've been
>>> upgrading to Alphas/Betas for years now and it never caused more
>>> trouble than occasional need to rebuild some packages manually.
>>>
>>> I read this:
>>> http://lwn.net/Articles/506831/
>>> but I didn't suspect that not only Rawhide, but also Alpha releases
>>> became unusable.
>>>
>>> First of all PreUpgrade crashes before it starts. I thought, well, I'll
>>> try DVD. It kind of worked. I was looking for words like "upgrade" or
>>> "update" in the new and shiny anaconda but no luck. Eventually it
>>> started the installation (without any "Warning: write changes to
>>> disk?" or alike). At that point partitions of Fedora 17 where already
>>> magically renamed to Fedora 18, so I hoped for the best. Unfortunately
>>> anaconda crashed when it tried to format my Win7 partition to the
>>> widely used filesystem "None"?! Imagine my amusement when after reboot
>>> I realised that MBR and GPT where wiped out and all of my partitions
>>> were nowhere to be found.
>>>
>>> 2. The problem
>>>
>>> It turned out anaconda not only wipes out MBR but also removes magic
>>> numbers from partitions superblocks (anyone can explain why?). So the
>>> good news was my data was still there, the bad news was: none of
>>> automatic "lost partition detection" tool could find them (at least none
>>> that I know of).
>>>
>>> 3. The solution
>>>
>>> If it happens to you as well, here is what you can try to get your
>>> data back:
>>>
>>>   a. Accept that you do all this on your own risk ;)
>>>   b. Backup your HDD, preferably all of it. Backup can be done with dd.
>>>   c. Connect damaged HDD to some other Linux box or use a Live
>>>      distribution.
>>>   d. Now you need to locate your first partition. There is a good chance
>>>      that this will be your /boot and Fedora usually locates it at
>>>      0x100000 (i.e. it starts in 2048 sector). Other possibility is
>>>      sector 63/64 from pre-GPT world.
>>>   e. Set magic value in superblock (see below).
>>>   f. Try mounting partition using offset option in mount.
>>>   g. Calculate where next partition is most likely to start using block
>>>      count and block size from superblock.
>>>   h. Fix your MBR. You can probably do that in parted or some similar
>>>      tool, but who would trust tools after one just nearly destroyed all
>>>      your data.
>>>   i. If you have more partitions to find, go back to (d).
>>>
>>>
>>> Important: All values on disk are LITTLE ENDIAN.
>>> Important: Try mounting your partitions read-only first.
>>>
>>> Notes on EXT4.
>>> Ext4 is quite easy to find. You will recognize it by two zeroed out
>>> sectors (1024 bytes of zeroes) at the beginning of every partition.
>>> NOTE: those zeroes are *in* the partition, do not skip them when trying
>>> to mount. After zeroes there is a superblock. What you are looking
>>> for is offset +0x38 in the superblock, where you once had a magic value
>>> of 0xEF53, you will probably have to put it back there. More information
>>> on EXT4:
>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
>>>
>>> Notes on NTFS.
>>> NTFS partition starts with EB 52 90, there are no zeroes in front. Magic
>>> value which is removed by anaconda is "4E 54 46 53 20 20 20 20"
>>> at offset 0x03 into a partition. Its literally "NTFS    " (with spaces).
>>> More info:
>>> http://technet.microsoft.com/en-us/library/cc781134%28v=ws.10%29.aspx
>>>
>>> Useful tools:
>>> dd - will help you to copy blocks of data around. If you don't know it
>>> already, I advise you to read some tutorial and practise first. It's
>>> easy to destroy thing with one wrong dd.
>>>
>>> emacs, okteta etc. - hex editor...
>>>
>>> losetup - is a tool which enables you to mount files and drives at
>>> particular offset as loop devices. Very useful, read more here:
>>> http://rackerhacker.com/2010/12/14/mounting-a-raw-partition-file-made-with-dd-or-dd_rescue-in-linux/
>>>
>>> dumpe2fs, nftsinfo - will decode superblock for you.
>>>
>>> bash calculator - $((1+2+3+4*4)) can save you a lot of time.
>>> bash printf - printf "%d\n" 0x1AB2F or printf "%x\n" $((7863*4096)) is
>>> handy as well.
>>>
>>> Good luck from (a sightly less happy) Fedora user
>>>     -- Kuba
>> WOW!.....that's terrible! But I guess that's just one of the reasons 
>> I purposely wait until a release has been out for almost 3 
>> months....before installing / upgrading. It just makes it a little 
>> easier when the glitches have been made apparent and are either 
>> completely worked out or are in the process of being worked out. In 
>> all honesty...I actually prefer to wait a few releases before 
>> upgrading, I kind of have my OWN "schedule" I usually wait and let 
>> one release pass by, then I'll wait for the next version...and 3 to 4 
>> months into _that _I'll upgrade.....this helps me remain a little 
>> more "stable" and not have to scurry around upgrading every 6 months....
>>
>>
>> EGO II
>>
>>
> Yes I am much the same. I'll skip an upgrade or two, wait for 
> stability then after copying all my files, do a fresh install.
> Roger
>
>
It just seems that.....of all the different methods....THAT one is the 
safest. I've accumulated quite a few "irreplaceable" files throughout 
the years...and I'd hate to lose some or all of them due to a 
restructuring of the build for the installer!..


EGO II
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120923/b5dc4247/attachment-0001.html>