unknown partition table

mtb · 03-11-2007, 05:14 AM

I have turned on my pc this morning, and found out that the home partition has disappeared

. It was on hdb5, here is the fstab file:

Code:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/hda1       /               reiserfs notail          0       1
/dev/hdb5       /home           ext3    defaults        0       2
/dev/hda6       none            swap    sw              0       0
/dev/hdb1       /mnt/xp         ntfs    ro,iocharset=iso8859-15,umask=022 0 0
/dev/hdb8       /mnt/otherdir   ext3    rw,user,noauto  0       0

In fact, older ( yesterday.. )boot messages, in /var/log , pointed out:

Code:

Mar 10 20:26:14 localhost kernel:     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Mar 10 20:26:14 localhost kernel: hdb: Maxtor 6B160P0, ATA DISK drive
Mar 10 20:26:14 localhost kernel: hdb: max request size: 512KiB
Mar 10 20:26:14 localhost kernel: hdb: 320173056 sectors (163928 MB) w/8192KiB Cache, CHS=19929/255/63, UDMA(100)
Mar 10 20:26:14 localhost kernel: hdb: cache flushes supported
Mar 10 20:26:14 localhost kernel:  hdb: hdb1 hdb2 hdb3 <ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 11
Mar 10 20:26:14 localhost kernel:  hdb5 hdb6 >
Mar 10 20:26:14 localhost kernel: EXT3 FS on hdb5, internal journal

Now:

Code:

Mar 11 09:59:19 localhost kernel:     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Mar 11 09:59:19 localhost kernel: hdb: Maxtor 6B160P0, ATA DISK drive
Mar 11 09:59:19 localhost kernel: hdb: max request size: 512KiB
Mar 11 09:59:19 localhost kernel: hdb: 320173056 sectors (163928 MB) w/8192KiB Cache, CHS=19929/255/63, UDMA(100)
Mar 11 09:59:19 localhost kernel: hdb: cache flushes supported
Mar 11 09:59:19 localhost kernel:  hdb: unknown partition table

I did tried to boot windows ( on hdb1 ) and the first time crashed, the 2nd, in "modalità provvisioria" ( should be translated as failsafe method or something similar ) booted.

The hd itself doesn't seem damaged.

I have tried with testdisk ( nothing happened, hoping i used it in the right way ) and gpart that is still running, for now reports:

Code:

 gpart /dev/hdb

** Error: invalid extended ptbl found at sector(30716280).

Begin scan...

What should i do?

I have a good numbers of backups, but also some file, unfortunatly few and only the most recent ones, are on the hd. I have read this forum about forensis, should it work? And i don't understand, is it filesystem-indipendent?

btw, some info:

running etch with 2.6.18 .

I was interesteded in partition hdb5, ext3 fs on top.

hdb1 is ntfs ( don't care ), hdb2 fat32 ( don't care ), hdb3 is the extended containing hdb5 that is the home, and hdb6 that contains nothing special.

I thinkg hdb1+hdb2 is something about 10-15 gb, home is about 100gb (

).

Thank you in advance.

Unknown_User · 03-11-2007, 05:41 AM

You may have a corrupt superblock.

Have you tried booting into the recovery mode of your distro and manually run e2fsck? You may need to point your tables to a reserve superblock if errors are found.

If you are unfamiliar with e2fsck the manual is at http://man.he.net/man8/e2fsck and there are loads of guides around to explain further, just search e2fsck on google.

mtb · 03-11-2007, 05:43 AM

Gpart is still running...

I have noticed a quite strange thing: yesterday evening i did an apt-get upgrade, new packages installed or updates were:

Quote:

login
python-newt
whiptail
libnewt0.52
passwd
mozilla-firefox
initramfs-tools
iceweasel
libsensors3
libparted1.7-1
libglide2
parted

Parted... quite strange that the day after nothing works anymore...

Running it ( parted /dev/hdb ):

Code:

 parted /dev/hdb
GNU Parted 1.7.1
Using /dev/hdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: Unable to open /dev/hdb - unrecognised disk label.
(parted) q
Information: Don't forget to update /etc/fstab, if necessary.

Unknown_User · 03-11-2007, 05:54 AM

What does mk2efsck -n /dev/hdb (or e2fsck -c /dev/hdb) report?

mtb · 03-11-2007, 06:03 AM

# e2fsck -c /dev/hdb
e2fsck 1.40-WIP (14-Nov-2006)
Impossibile trovare il superblocco ext2 trying backup blocks...
e2fsck: Bad magic number in super-block durante l'apertura di /dev/hdb

Il superblocco è illeggibile, o non descrive un corretto filesystem ext2
Se il device è valido e contiene realmente un filesystem ext2
(e non swap, ufs o altro), allora il superblocco è corrotto, e si potrebbe
provare ad eseguire e2fsck con un superblocco alternativo:
e2fsck -b 8193 <device>

# e2fsck -c /dev/hdb5
e2fsck 1.40-WIP (14-Nov-2006)
e2fsck: No such file or directory durante l'apertura di /dev/hdb5

Il superblocco è illeggibile, o non descrive un corretto filesystem ext2
Se il device è valido e contiene realmente un filesystem ext2
(e non swap, ufs o altro), allora il superblocco è corrotto, e si potrebbe
provare ad eseguire e2fsck con un superblocco alternativo:
e2fsck -b 8193 <device>

mtb · 03-11-2007, 06:19 AM

gpart has finished

gpart /dev/hdb

Code:

** Error: invalid extended ptbl found at sector(30716280).

Begin scan...
End scan.

Checking partitions...
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(3)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Does someone has tried the procedure on http://www.unixwiz.net/techtips/recovering-ext2.html ?

saikee · 03-11-2007, 06:49 AM

It is possible that your partition table has been corrupted, rendering it to be rejected by XP and many partitioning software. The situation is salvageable if you have a record of the partition table.

You will find of all the partitioning sofware the last line of defence is the oldest program fdisk in Linux, meaning it can still read a corrupted partition table when all other software refuse to have anything to do with it. If fdisk can't read it then your disk would be in real trouble.

See if you can post here the output of

Code:

fdisk -l

using any Live CD or simply from booting up the installation CD and opt for the rescue mode.

Unless it is a hardware fault a total destruction of the partition table does not harm any data inside the partprtitions and you can suffer no loss if you rebuild the partition table again. The full partition table has only 64 bytes and the hdb3 occupies the 3rd slot of 16 bytes. You are therefore restoring these 16 bytes.

Acoording to your report in Post #1 the primary partitions of hdb1 and hdb2 should be healthy and you are only having a problem of the starting and finishing cylinder numbers of the hdb3 which has been used as an extended partition containing at least hdb5, hdb6, hdb7 and at least hdb8. (actually hdb3 conatins the address for hdb5, hdb5 carries the address of hdb6 and so on).

The battle could be an easy one if you haven't used up the primary partition slot hdb4 and so hdb3 can always be re-created at position immediately after hdb2 to the end of the disk, assuming you have no unallocated space in the hdb disk. Thus even without a record of the partition table you may be still able to reclaim all the information.

The procedure to salvage it with fdisk principally involved

(1) Record the details of hdb3 as seen by fdisk, important information is the partition type number as it looks you are not using LVM. The boundaries (cylinder numbers) at the two ends are crucial too.

(2) If hdb3 is corrupted deleting it with fdisk.

(3) Reboot the system and try to run system in hdb1 and information in hdb2 to ensure everything except hdb3 is in order, thereby verifying the non-Linux portion of the disk is heathy.

(4) Reboot again using Linux installation CD rescue mode back into the root terminal and use fdisk to re-creat hdb3 in the "exactly" the same location with "exactly" the same partition type.

(5) On a reboot everything should be back to normal again if your internal partitions of hdb5 to hdb8 have not been corrupted. If they are then the uncorrupted partitions should still be accessible.

------------------------------
Edited

Your Post #6 suggests your partition table is now empty for hdb. This may be the result of you doing something before like forcing a correction of some sort or Gparted can't cope with hdb partition table and decided the only way it can handle it is to treat it as a raw disk. The last alternative is known to happen with Gparted.

When a partition table has entries that doesn't make sense an operating system or a partitioning software does not know how to handle it and most would "wash" its hand on it. Gparted is really trying to offer to use it to start everything from new.

The corruption can be really simple or trivial say the end boundary exceed the physical disk by one byte and no operating system in the world can cope with a partition table with end boundary bigger than the physical disk.

mtb · 03-11-2007, 06:51 AM

Testdisk output:

Code:

TestDisk 6.5, Data Recovery Utility, October 2006
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/hdb - 163 GB / 152 GiB - CHS 19929 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

Partition sector doesn't have the endmark 0xAA55

Disk /dev/hdb - 163 GB / 152 GiB - CHS 19929 255 63

     Partition                  Start        End    Size in sectors

No partition found or selected for recovery

Unknown_User · 03-11-2007, 07:05 AM

Saikee offers some good advice.

If all else fails and you are desperate to get at your data try using Helix 3 from http://www.e-fense.com/helix/

It is a free suite of forensic tools that I have used to recover all sorts of data from really corrupted drives.

Good luck!

mtb · 03-11-2007, 07:08 AM

Quote:

Originally Posted by saikee

It is possible that your partition table has been corrupted, rendering it to be rejected by XP and many partitioning software. The situation is salvageable if you have a record of the partition table.

Unfortunatly NO. I have never thought about making a backup of the part table

. Will surely do in the future.

Just to understand, something like this ( done for hda ) could have improved the situation a lot?

Code:

 fdisk -l /dev/hda

Disk /dev/hda: 60.0 GB, 60040544256 bytes
255 heads, 63 sectors/track, 7299 cylinders
Units = cilindri of 16065 * 512 = 8225280 bytes

Dispositivo Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1         851     6835626   83  Linux
/dev/hda4             852        7299    51793560    5  Esteso
/dev/hda5            3188        7299    33029608+  83  Linux
/dev/hda6             852         944      746959+  82  Linux swap / Solaris
/dev/hda7             945        3187    18016866   83  Linux

Partition table entries are not in disk order

Quote:

You will find of all the partitioning sofware the last line of defence is the oldest program fdisk in Linux, meaning it can still read a corrupted partition table when all other software refuse to have anything to do with it. If fdisk can't read it then your disk would be in real trouble.

See if you can post here the output of

Code:

fdisk -l

using any Live CD or simply from booting up the installation CD and opt for the rescue mode.

Disk /dev/hdb: 163.9 GB, 163928604672 bytes
255 heads, 63 sectors/track, 19929 cylinders
Units = cilindri of 16065 * 512 = 8225280 bytes

Il disco /dev/hdb non contiene una tabella delle partizioni valida ( doesn't contain a valid partition table

)

I can still boot from hda where i have the os but not the home...

Quote:

Unless it is a hardware fault a total destruction of the partition table does not harm any data inside the partprtitions and you can suffer no loss if you rebuild the partition table again. The full partition table has only 64 bytes and the hdb3 occupies the 3rd slot of 16 bytes. You are therefore restoring these 16 bytes.

Acoording to your report in Post #1 the primary partitions of hdb1 and hdb2 should be healthy and you are only having a problem of the starting and finishing cylinder numbers of the hdb3 which has been used as an extended partition containing at least hdb5, hdb6, hdb7 and at least hdb8. (actually hdb3 conatins the address for hdb5, hdb5 carries the address of hdb6 and so on).

The hw seems ok. Cat /dev/hdb >/dev/null works without errors in stderr.

I can trust booting again windows xp? Or it will create something not good?

So if i report the size of hdb1 and the size of hdb2, can be useful?

Quote:

The battle could be an easy one if you haven't used up the primary partition slot hdb4 and so hdb3 can always be re-created at position immediately after hdb2 to the end of the disk, assuming you have no unallocated space in the hdb disk. Thus even without a record of the partition table you may be still able to reclaim all the information.

I don't think i have never done other partitions.

Quote:

The procedure to salvage it with fdisk principally involved

(1) Record the details of hdb3 as seen by fdisk, important information is the partition type number as it looks you are not using LVM. The boundaries (cylinder numbers) at the two ends are crucial too.

...

Quote:

(3) Reboot the system and try to run system in hdb1 and information in hdb2 to ensure everything except hdb3 is in order, thereby verifying the non-Linux portion of the disk is heathy.

Can i trust or xp will write something on hdb3? And what about trying explore2fs from there? I can even try to obtain a program like partition magic, could it be useful?

Thank you a lot.

saikee · 03-11-2007, 07:51 AM

There are three major blows here.

(a) fdisk can't find a valid partition table. It found a 170Gb Pata hard disk. That means the hard disk has been detected correctly but the 64 bytes of the partition table have no entry.

(b) Testdisk also failed to see a partition table

(c) You have not kept a record of the partition table of hdb.

The combination of (a) and (b) could be self-inflicited when you were trying various opinions from different partitioning tools and "might" have accidentally just permitted one of them to "correct" the fault by erasing the partition table or "write" the software's opinion of what you hard disk partition table should look like.

I am only familiar with the Dos version of the testdisk which can be googled under the name of "WPARTNFIX". That program will attempt to build the partition table back by scanning the filing idices of boot sectors. May be you would consider giving it a trial. I did have somne success with it. It has a facility to search "deeper".

I have lost partition tables of my hda and hdc, both 300Gb and with the maximum 63 partitions in each, at least a dozen times when installing a large number of distros in my box. I have suffered the loss of only one or two partitions in all these occasions (in some case I saw distros starting to reformat the whole hard disk during installation). I got by with a record of their partition tables. If you keep any record it may be worthwhile to go over them now to see the sizes of your hdb1 and hdb2 could be establish, as hdb3 can be filled in as the missing piece as I described earlier.

I operaing a policy with partitioning with only cfdisk program in Linux (for also Dos, Windows, BSD etc) and can easily reproduce partition sizes back using unit in 1000Mb.

As far as I am aware in each partition there is always a boot sector and part of the front end used up for the filing indexing system with which an operating system can find the files back. The trick is to know the starting point and finishing point of the partition in the hard disk plus the partition ID, which governs the filing system type the operating system has to use to read/write the files. The partition table keeps this inofrmation and without it you are serach a needle in a haystack.

I have never experienced any interference from any operating system on partition table that doesn't belong to that system. Although I dislike MS systems I have to say they are respectable systems that simply do not damage any of your hard ware or software when used in an ordinary fashsion. I also use ext2ifs in XP to read/write Linux partitions. You can discount the damage from the MS systems. What I cannot substantiate is a virus infected from a MS system.

You can try Partition Magic but it is an product inferior to fdisk or cfdisk as far as handling partitions are concerned. It is well known that some older versions of PM can declare errors on a perfectly health Linux hard disk, offer to fix the errors and if accepted can damage the partition table beyond repair. At least two incidences of my rebuilding the parttition table exercises were courtesy of Partition Tragic! If you search the forum it is littered by complaints by this software which should only be used on OS where it belongs and that is Winodws only.

mtb · 03-11-2007, 08:46 AM

Thank you again, i'll try later tonight. Tomorrow afternoon i'll buy a new big hd, maybe 320 gb, hoping there will be no problem with the bios that is limited to 160.

Now i have just tried with foremost , on an usb key: it has recovered really a lot of even deleted files ( they were on a fat filesystem ).

I post here what i did, hoping it could be useful to someone else:

foremost -i /dev/sda -o .

-i /dev/sda is the input device

-o . is the destination directory

For what i have understood reading more, it should be able to find files in raw dd data, or raw hd without partition like my hdb, is it right?

saikee · 03-11-2007, 09:04 AM

I haven't try it myself but I am aware there are software to recover individual files from a hard disk without resorting to a partition table. It must hard work though. I remember reading a thread on recovering MP3 files because the binary pattern of the header can be recognised if one scans the whole disk. Fat16/32 filing systems have always been easy to recover because the way it is formulated, making undelete possible in Dos. I have not come across a software that can deal with all filing systems though.

If you are pushed into a corner to recover files directly of the hard disk without a partition table it may be worthwhile to start a new thread so that others with experience can come to your aid by looking at the new title.

mtb · 03-11-2007, 09:29 AM

Fortunatly for me, i think i don't have to go so deep, so i'll continue posting here

Launched windows ( it took more than usual to boot, anyway ), then checked hdb1 and hdb2, everything is ok

Then installed explore2fs, i see what i called hdb5 and hdb6 . Still unable to mount them with linux, i don't know what to do, but i have some "new" info, note that with grub i swap hd0 with hd1

http://www.mytempdir.com/1250323 : ntfs volume information
http://www.mytempdir.com/1250328 : fat 32 data
http://www.mytempdir.com/1250329 : home data ( from explore2fs )
http://www.mytempdir.com/1250332 : other ext3 partition data

So if everything fail, at least i'll be able to use explore2fs to grab data missing from backups ( even if, in order to perform the operation safely, i'll need to buy a new hd ). And this is seems to me as a good starting point!

Btw, in the past i had much worser ( really physical ) problem s( http://www.linuxquestions.org/questi...d.php?t=368058 ), with a good success trying to recover data.

mtb · 03-11-2007, 01:29 PM

Really cool news: i turned off windows just after the previous post, then i have been away.

Now i have restarted the system, with linux, and works. Seems that explore2fs ( or windows? ) has fixed the partition table... What else could have been happened?

The fdisk table is here, soon i'll print it and put it in a safe place, and i strongly suggest everyone reading this thread to do so - with 1 minute you can save hours or days of time:

Code:

fdisk -l /dev/hdb

Disk /dev/hdb: 163.9 GB, 163928604672 bytes
255 heads, 63 sectors/track, 19929 cylinders
Units = cilindri of 16065 * 512 = 8225280 bytes

Dispositivo Boot      Start         End      Blocks   Id  System
/dev/hdb1               1         566     4546363+   7  HPFS/NTFS
/dev/hdb2             567        1912    10811745    7  HPFS/NTFS
/dev/hdb3            1913       19887   144384187+   5  Esteso
/dev/hdb5            1913       12111    81923436   83  Linux
/dev/hdb6           12112       17210    40957686   83  Linux

I would like to say a really big thank you to saikee and Unknown_User .

I still don't understand what has caused this problem, anyway.