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

2012-09-25 Thread Bill Davidsen

Eddie G. O'Connor Jr. wrote:

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
 0x10 (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 monthsbefore
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 

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

2012-09-25 Thread Bill Davidsen

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
 0x10 (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 monthsbefore 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

I followed FC from 4-6-9-13-16-17, generally updating when a security issue 
popped up I didn't want to patch myself. The 16-17 was because of the kernel, 
too much good stuff added to miss on my VM 

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

2012-09-25 Thread Patrick O'Callaghan
On Tue, 2012-09-25 at 01:31 +0100, Ian Malone wrote:
 On 25 September 2012 00:55, Joe Zeff j...@zeff.us wrote:
  On 09/24/2012 04:44 PM, Jakub Kicinski wrote:
 
  On Mon, 24 Sep 2012 08:09:11 -0430, Patrick O'Callaghan
  pocallag...@gmail.com  wrote:
 
  On Sun, 2012-09-23 at 13:33 +0200, Jakub Kicinski wrote:
 
  I recently had a weird problem after upgrade to Fedora 18 Alpha. I
  decided to share the solution, maybe it will help someone.
 
  
  This should be posted to the Fedora test list, not here. F18 is not a
  released system.
 
  Sorry, won't happen again.
 
 
  Please don't think you've offended us, Kuba, or that we want you to go away
  and stay there.  It's just that in this case, you asked a question that
  we're really not qualified to answer, so Patrick pointed you in the right
  direction.
 
  And, there's no reason to sign off of the list if you haven't already done
  so.  It won't be too long before F18 has its coming out party, making it
  very appropriate for this list.
 
 Actually, I think it's worth having this mentioned on this list. The
 problem (F18 alpha will eat your data) is fairly well known on the
 devel list, but the fact that Jakub thought this needed a post
 suggests that people on the users list aren't aware of it at a time at
 which they might start trying Alpha. So starting a 'here be dragons'
 thread is not completely unwarranted. (Also a bit extreme to say we
 absolutely cannot mention F18 here when the assumption on devel is
 often that you are a maintainer or developer, this is the users list
 after all.)

None of these lists have rigid rules, but they do have community
guidelines. Keeping discussion of unreleased development versions to the
Test list is a sensible example. My take on Jakub's post is that he was
unaware of the Test list until it was pointed out to him. Someone who's
going to be trying out F18 at this stage (it's still months from
release) really needs to get on the list that's specifically for devels
*and testers* or they're going to have a frustrating time of it.

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-24 Thread Frank Murphy

On 24/09/12 00:43, Eddie G. O'Connor Jr. wrote:




It just seems that.of all the different methodsTHAT 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!..



External drive(s) may be a safer place to keep irreplacable files.
I use a simple Raid1 NAS for must keep files.

--
Regards,
Frank
Jack of all, fubars
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-24 Thread Eddie G. O'Connor Jr.

On 09/24/2012 03:55 AM, Frank Murphy wrote:

On 24/09/12 00:43, Eddie G. O'Connor Jr. wrote:




It just seems that.of all the different methodsTHAT 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!..



External drive(s) may be a safer place to keep irreplacable files.
I use a simple Raid1 NAS for must keep files.

Oh I agree TOTALLY! Although I have like over a thousand files that are 
directly stored on my PC I ALSO have them stored on a 1TB drive in an 
encrypted folder, so should anything ever happen, I can put back what's 
lost or corrupted. Also I run the Backup tool every month, with 
incremental backups between the monthly ones. I do NOT intend on losing 
data EVER again! The last time I DID lose data was when I was going from 
Windows to Linux, and ever since losing some very vintage guitar 
sounds from my Cakewalk days, I've never done ANYTHING without a backup 
made first.


On a totally different note, but related just the same...because of all 
the files I have now I'm thinking maybe it's time for a dedicated 
server to hold them all, can someone recommend an OS/distro that would 
handle this along with possible printer duties and security that 
will be easy to use and light on the hardware?(and just FYI I have 
no command line/scripting skills so something with a GUI would be 
preferred!...)



EGO II
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-24 Thread Patrick O'Callaghan
On Sun, 2012-09-23 at 13:33 +0200, Jakub Kicinski wrote:
 I recently had a weird problem after upgrade to Fedora 18 Alpha. I
 decided to share the solution, maybe it will help someone.

This should be posted to the Fedora test list, not here. F18 is not a
released system.

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-24 Thread Mikkel L. Ellertson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/24/2012 07:39 AM, Patrick O'Callaghan wrote:
 On Sun, 2012-09-23 at 13:33 +0200, Jakub Kicinski wrote:
 I recently had a weird problem after upgrade to Fedora 18 Alpha. I
 decided to share the solution, maybe it will help someone.

 This should be posted to the Fedora test list, not here. F18 is not a
 released system.

 poc

One program I did not see talked about is testdisk. It is designed
to find deleted partitions. I have not needed to use it for real,
but I have deliberately messed up a partition table to see how well
it works. It does a great job on drives that have only been
partitioned and formatted once. If you have had different
partitioning sachems, you may have to pick out the correct
partitions from a list of partitions it finds. But it usually isn't
too hard.

Mikkel
- -- 
Do not meddle in the affairs of dragons, for thou art crunchy and
taste good with Ketchup!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlBgYegACgkQqbQrVW3JyMQAYgCfZUpeQ1WZ1oxr/GD6O7Q5p7n/
GDYAnRY3jzhT34idR6/UFH3pM5GsHBMo
=0ClG
-END PGP SIGNATURE-

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-24 Thread Jakub Kicinski
On Mon, 24 Sep 2012 08:36:41 -0500, Mikkel L. Ellertson
mellert...@gmail.com wrote:

On 09/24/2012 07:39 AM, Patrick O'Callaghan wrote:
 On Sun, 2012-09-23 at 13:33 +0200, Jakub Kicinski wrote:
 I recently had a weird problem after upgrade to Fedora 18 Alpha. I
 decided to share the solution, maybe it will help someone.

 This should be posted to the Fedora test list, not here. F18 is not a
 released system.

 poc

One program I did not see talked about is testdisk. It is designed
to find deleted partitions. I have not needed to use it for real,
but I have deliberately messed up a partition table to see how well
it works. It does a great job on drives that have only been
partitioned and formatted once. If you have had different
partitioning sachems, you may have to pick out the correct
partitions from a list of partitions it finds. But it usually isn't
too hard.

Well I didn't mention it because I said:

 anaconda [...] removes magic numbers from partitions superblocks [...]
and
 none of automatic lost partition detection tool could find them.

I tried testdisk with a few different settings, none of them worked.
Only partition it was kind of able to detect was the first on (/boot)
and even there it messed up starting point (2046 instead of 2048
sector).

But yes, nevertheless, if someone just wipes out his MBR testdisk
would be very useful I agree.

  -- Kuba
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-24 Thread Jakub Kicinski
On Mon, 24 Sep 2012 08:09:11 -0430, Patrick O'Callaghan
pocallag...@gmail.com wrote:

On Sun, 2012-09-23 at 13:33 +0200, Jakub Kicinski wrote:
 I recently had a weird problem after upgrade to Fedora 18 Alpha. I
 decided to share the solution, maybe it will help someone.

This should be posted to the Fedora test list, not here. F18 is not a
released system.

Sorry, won't happen again.

  -- Kuba
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-24 Thread Joe Zeff

On 09/24/2012 04:44 PM, Jakub Kicinski wrote:

On Mon, 24 Sep 2012 08:09:11 -0430, Patrick O'Callaghan
pocallag...@gmail.com  wrote:


On Sun, 2012-09-23 at 13:33 +0200, Jakub Kicinski wrote:

I recently had a weird problem after upgrade to Fedora 18 Alpha. I
decided to share the solution, maybe it will help someone.


This should be posted to the Fedora test list, not here. F18 is not a
released system.

Sorry, won't happen again.


Please don't think you've offended us, Kuba, or that we want you to go 
away and stay there.  It's just that in this case, you asked a question 
that we're really not qualified to answer, so Patrick pointed you in the 
right direction.


And, there's no reason to sign off of the list if you haven't already 
done so.  It won't be too long before F18 has its coming out party, 
making it very appropriate for this list.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-24 Thread Ian Malone
On 25 September 2012 00:55, Joe Zeff j...@zeff.us wrote:
 On 09/24/2012 04:44 PM, Jakub Kicinski wrote:

 On Mon, 24 Sep 2012 08:09:11 -0430, Patrick O'Callaghan
 pocallag...@gmail.com  wrote:

 On Sun, 2012-09-23 at 13:33 +0200, Jakub Kicinski wrote:

 I recently had a weird problem after upgrade to Fedora 18 Alpha. I
 decided to share the solution, maybe it will help someone.

 
 This should be posted to the Fedora test list, not here. F18 is not a
 released system.

 Sorry, won't happen again.


 Please don't think you've offended us, Kuba, or that we want you to go away
 and stay there.  It's just that in this case, you asked a question that
 we're really not qualified to answer, so Patrick pointed you in the right
 direction.

 And, there's no reason to sign off of the list if you haven't already done
 so.  It won't be too long before F18 has its coming out party, making it
 very appropriate for this list.

Actually, I think it's worth having this mentioned on this list. The
problem (F18 alpha will eat your data) is fairly well known on the
devel list, but the fact that Jakub thought this needed a post
suggests that people on the users list aren't aware of it at a time at
which they might start trying Alpha. So starting a 'here be dragons'
thread is not completely unwarranted. (Also a bit extreme to say we
absolutely cannot mention F18 here when the assumption on devel is
often that you are a maintainer or developer, this is the users list
after all.)

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-23 Thread Roberto Ragusa
On 09/23/2012 01:33 PM, Jakub Kicinski wrote:

 I realised that MBR and GPT where wiped out and all of my partitions
 were nowhere to be found.

A useful habit to have:

fdisk -l /dev/sd? save_this_file_away__it_could_be_important_some_day.txt


-- 
   Roberto Ragusamail at robertoragusa.it
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


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

2012-09-23 Thread Eddie G. O'Connor Jr.

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
 0x10 (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 
monthsbefore 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
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: 

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

2012-09-23 Thread Roger

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
 0x10 (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 
monthsbefore 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
-- 
users mailing list

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

2012-09-23 Thread Eddie G. O'Connor Jr.

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
 0x10 (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 
monthsbefore 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