# Partition table disappears after reboot?

## deadearth

A very peculiar issue, the likes of which i've never seen before. 

Bought a new 1TB (Hitachi SATA) hard drive and a new PCI-express SATA controller (http://www.amazon.com/gp/product/B000GGTIKG/ref=oss_product).

Compiled support into the kernel for it and it along with the drive show up just fine.  Formatted the disk, mounted it, and then started using it.  No issues.  

Then the next day I reboot the machine and when it comes back, the partition table is gone!  The partitions are still there and if I recreate the partition table, i can actually mount the previously created ext3 file system and see the data.  

I've re-created the partition table about 5 times and every time it disappears after reboot.  I've flashed the bios on the SATA controller to newest RAID Bios as well as non-raid bios (not using the built in raid function regardless).   Neither make a difference.

Here's what fdisk shows it as after rebooting:

```

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes

255 heads, 63 sectors/track, 121601 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x00000000

Disk /dev/sda doesn't contain a valid partition table

```

And here is me partitioning the disk:

```

file ~ # fdisk  /dev/sda

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel

Building a new DOS disklabel with disk identifier 0xf7fe3513.

Changes will remain in memory only, until you decide to write them.

After that, of course, the previous content won't be recoverable.

The number of cylinders for this disk is set to 121601.

There is nothing wrong with that, but this is larger than 1024,

and could in certain setups cause problems with:

1) software that runs at boot time (e.g., old versions of LILO)

2) booting and partitioning software from other OSs

   (e.g., DOS FDISK, OS/2 FDISK)

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): p

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes

255 heads, 63 sectors/track, 121601 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0xf7fe3513

   Device Boot      Start         End      Blocks   Id  System

Command (m for help): n

Command action

   e   extended

   p   primary partition (1-4)

p

Partition number (1-4): 1

First cylinder (1-121601, default 1): 

Using default value 1

Last cylinder, +cylinders or +size{K,M,G} (1-121601, default 121601): 

Using default value 121601

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

Syncing disks.

```

Afterwards, fdisk shows it correctly:

```

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes

255 heads, 63 sectors/track, 121601 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0xf7fe3513

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1               1      121601   976760001   83  Linux

```

I've never seen anything like it!  Any ideas would be greatly appreciated.   Thanks!

----------

## BradN

The only time I've seen behavior like this was with an old western digital 540MB drive that had this habit of nuking its MBR when it experienced power glitches (bad connection on one of the power wires).  That was very frustrating considering I was using windows 95 back then that would zero out the beginning of a partition when you recreate it.

Best bet might be trying the drive on another system and seeing if it does the same things - if it does I would RMA it if it's still under warranty.

----------

## Logicien

If you try partitioning the disk with an other partition editor it will give more precision if Fdisk can be in cause or not.

----------

## idella4

yes, odd.

Check if your kernel config has

```

 │       [*]   PC BIOS (MSDOS partition tables) support                                │ │

  │ │       [*]     BSD disklabel (FreeBSD partition tables) support                      │ │

```

While it's most unlikely it doesn't, rule out the basics.

As Logicien said, try another, e.g. parted.  They do vary slightly in how they write and read partitions.

I can only say you're lucky the partitioning was only one primary partition in one file system, otherwise re-creating it anything else would have me asking just how could you do it.  I take it your system is on a /dev/sdb or such?

----------

## kimmie

From your amazon link:

 *Quote:*   

> Technical Details
> 
> Supports RAID 0 (striping) and 1 (mirroring) for speed and data protection / Friendly SATA RAID management software utility is provided to make configuring RAID easy

 

My bet would be that it's a fake raid card doing something unclever, like not finding a signature and then wiping. Does it have a BIOS? Have you checked settings in that? If not, perhaps you can run their utility from windows or however and somehow make it happy. Have a look in the manufacturer's support for a non-raid BIOS. Anyway, that should be enough ammunition to google with...

I have a promise fake raid controller in one of my machines with a BIOS that needed a special sector near the end of the disk... really surprised me one day when my data overwrote it and then the RAID controller trashed the partition table on the next boot. After I figured out what was going on, I knew to leave a small empty partition at the end of each disk.

EDIT: Apologies, I failed to read the part where you'd flashed the non-raid BIOS. You might still have a problem with a left-over signature causing issues... one thing to try would be to dd zeroes to that first few meg and last few meg of the disk, then go into the controller BIOS and set it up again.

----------

## deadearth

Thanks for everyone's responses.  Sorry for the delay, didn't get a chance to play around with it any more until tonight.  I'm about at my wits end on this issue.  

Let me summarize everything I've tried/discovered:

1.  The controller and the drive work just fine in a different system running Windows (even across reboots/poweroffs).

2.  I confirmed that the partition table is indeed being wiped upon boot before it gets to the grub prompt (I did this by putting the controller in a windows machine, formatting it, putting it back in the linux machine, booting to grub, interrupting the timeout, powering off the machine, and putting it back into the windows system resulting in the drive being 'un-initialized').  

3.  I've looked in my bios for any sort of option that may be available related with ATA and could not find any (the motherboard is gigabyte GA-m61p-s3) 

I've tried messing with the windows RAID utility but since it currently has the non-raid bios installed, it won't get very far upon launch.  

Oh, and with the non-raid bios, there isn't really any configuration on the card.  The bios of the card flashes a message stating the bios version and what not, but no key combination to access any sort of menu.  With the raid version of the bios it does show this.

Trying the dd to the start and end of the disk right now.

----------

## deadearth

dd'ing the start and end of the disk didn't seem to help much either.  Any more ideas?    :Crying or Very sad: 

Thanks!!

----------

## kolcon

 *deadearth wrote:*   

> dd'ing the start and end of the disk didn't seem to help much either.  Any more ideas?   
> 
> Thanks!!

 

Try it in different computer - without the (maybe buggy) SATA card. Then you can at least determine if the problem

is in the HDD or somewhere else

----------

## chithanh

Not really a solution but more a workaround: you could use GPT instead of MBR partitioning. In parted, run 

```
mklabel gpt
```

 and create the partition. For that, you need EFI partition support enabled in your kernel.

```
CONFIG_EFI_PARTITION=y
```

----------

## thegeezer

could you possibly have a 'antivirus protection' in the BIOS, that would be 'protecting' your hard drive from a MBR virus?

----------

