# messed up partitions - bad primary partition error [SOLVED]

## salmonix

Hi there,

After a freeze and shutdown Grub2 drops Error 17.

From a rescue system I can not mount sda5, and I see sda4 not. ( The latter is a separate /home )

From cfdisk I receive :

 *Quote:*   

> Bad primary partition 3 error: partition ends in the final partial cylinder

 

Some info on the layout:

 *Quote:*   

>  cat /proc/partitions 
> 
> major minor  #blocks  name
> 
>    7        0     103624 loop0
> ...

 

As I see there is a mess-up at sda4-5. The other partitions I can mount but those are either some Wintendo stuff or other Linux installations I sometimes play with. The main Gentoo installation is on sda5 - as I remember -, home with data is sda4.

Any help is appreciated!

----------

## srs5694

Actually, as far as I can tell your partition table looks OK. Don't worry about the cfdisk warning about a partition ending in the final partial cylinder; this is a sign of cfdisk being ancient and applying 30-year-old standards to your modern hard disk. The data you've presented are imprecise, though; they report partition boundaries in terms of cylinders, which haven't been relevant for at least a couple of decades, although Linux's fdisk and related tools have used them by default until about a year ago. You can get sector-precise values by updating to a newer fdisk or by typing "fdisk -lu" rather than "fdisk -l". If you post that information, please post it with code tags to preserve the columnar formatting; it's a pain to read these things once the forum software reformats it.

My suspicion is that you've got filesystem damage, not partition table damage. Note that you shouldn't be able to "see" any files on /dev/sda4, since it's an extended partition that holds logical partitions. An inability to mount /dev/sda5 could indicate filesystem damage that might be correctable by fsck; however, if it's possible you should do a low-level backup of the partition before attempting to fix the damage. Although it happens rarely, fsck and similar filesystem recovery tools sometimes make matters worse rather than better.

----------

## salmonix

Thanx a lot, indeed.

Slowly I have caught up the scenario - it was too long ago to meet this problem.

Yesterday I ran Gparted from the rescue disk issuing a fake partition resize and it seems that recovered the /home partition which is the most important. 

I follow your advise and report the outcomes. 

thx again.

----------

## salmonix

Unfortuantely the rescue disk fdisk available gives no different output.

The /dev/sda9 is not recognized as a partition, however, is marked as unknown.

Its size is 15124480 blocks, 14.42 Gb. It was the main OS having Grub2 files.

fsck.ext4 -n /dev/sda9 says:

 *Quote:*   

> Attempt to read block from filesystem resulted in short read while trying to open /dev/sda9.
> 
> Could this be a zero-length partition?

 

----------

## srs5694

I don't see a problem with your /dev/sda9 definition -- but once again, you've presented fdisk output that shows values in cylinders, which are much less precise than sector values.

I recommend you download and run the Boot Info Script. This will produce an output file called RESULTS.txt, which will contain detailed partitioning information, information on boot loader installations, and information on filesystem identification for all your partitions. This may help identify the problems. Post the RESULTS.txt file here, either in a code block or as an attachment.

----------

## NeddySeagoon

srs5694,

The fdisk precision is not changed by the output format.  fdisk allocates space in cylinders anyway, to comply with that old DOS rule of thumb that partitions need to start on a cylinder boundary. They don't and never did, not even for DOS.

The partition table looks self consistent - thats always good. Thats not the same are correct.

----------

## srs5694

 *NeddySeagoon wrote:*   

> srs5694,
> 
> The fdisk precision is not changed by the output format.

 

There are two issues: Obtaining information about partitions and creating new ones.

For obtaining information about partitions, fdisk has two modes: cylinders and sectors. Cylinders used to be the default, but that default has changed to sector precision fairly recently (about a year ago, or maybe two). Switching modes is done with the "u" command in fdisk. To demonstrate this, see what happens:

```

$ sudo fdisk /dev/sdd

Command (m for help): p

Disk /dev/sdd: 2038 MB, 2038431744 bytes

25 heads, 30 sectors/track, 5308 cylinders, total 3981312 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0xfddd37e6

   Device Boot      Start         End      Blocks   Id  System

/dev/sdd1            2048      411647      204800   83  Linux

Command (m for help): u

Changing display/entry units to cylinders (DEPRECATED!)

Command (m for help): p

Disk /dev/sdd: 2038 MB, 2038431744 bytes

25 heads, 30 sectors/track, 5308 cylinders

Units = cylinders of 750 * 512 = 384000 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0xfddd37e6

   Device Boot      Start         End      Blocks   Id  System

/dev/sdd1               3         549      204800   83  Linux

```

Note that the first output uses the (new) default of sector precision, and it reports a partition as beginning on "2048" and ending on "411647", whereas the second output uses cylinder values and reports the start and end points as "3" and "549", respectively. The second output is imprecise. Given the 25 heads and 30 sectors/track reported for this disk, a start point of sector 2048 works out to cylinder 2.73, which fdisk has rounded to "3". Likewise, the end sector of 411647 works out to cylinder 548.86, which fdisk has rounded to 549. This kind of slop can produce confusing or unclear results, including end cylinders that are higher than the number of cylinders in the disk (as is the case in salmonix's output). Chances are this is OK in salmonix's case, but it's conceivable that the end of /dev/sda4 and/or /dev/sda9 is beyond the physical end of the disk. The only way to rule out this possibility with certainty is to get sector-precise data on the partitions.

 *Quote:*   

> fdisk allocates space in cylinders anyway, to comply with that old DOS rule of thumb that partitions need to start on a cylinder boundary.

 

This used to be true; but as I've said, fdisk has recently changed its behavior to use sector values by default, for both displays and accepting input. The input precision is adjusted by the same "u" switch that adjusts the output precision. To illustrate the input side of it, consider this, which picks up where my previous code block ended and so requires another "u" command to switch back to sector mode:

```

Command (m for help): u

Changing display/entry units to sectors

Command (m for help): n

Partition type:

   p   primary (1 primary, 0 extended, 3 free)

   e   extended

Select (default p): p

Partition number (1-4, default 2): 2

First sector (411648-3981311, default 411648): 411650

Last sector, +sectors or +size{K,M,G} (411650-3981311, default 3981311): +150M

Command (m for help): p

Disk /dev/sdd: 2038 MB, 2038431744 bytes

25 heads, 30 sectors/track, 5308 cylinders, total 3981312 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0xfddd37e6

   Device Boot      Start         End      Blocks   Id  System

/dev/sdd1            2048      411647      204800   83  Linux

/dev/sdd2          411650      718849      153600   83  Linux

```

Note that fdisk accepted a partition start point of 411650, which is not on a cylinder boundary.

All this said, salmonix seems to be using an old version of fdisk. That's part of why I asked for output from Boot Info Script; that will provide sector-precise data, which will reveal if there are any problems that might be obscured by the use of cylinder values in the fdisk output that's already been posted. Boot Info Script also provides basic data on what types of filesystems are in the partitions and information on boot loaders. In short, it provides loads of useful diagnostic data when you're confronted with a problem like this one.

----------

## NeddySeagoon

srs5694,

Thank you for the education on fdisk.  

Its also lost its warning about partitons not starting/ending on cylinder boundaries.

----------

## srs5694

 *NeddySeagoon wrote:*   

> srs5694,
> 
> Thank you for the education on fdisk.  
> 
> Its also lost its warning about partitons not starting/ending on cylinder boundaries.

 

Yup. FWIW, these are long-overdue changes that have been forced by the emergence of Advanced Format disks, and to some extent also RAID arrays and SSDs, all of which work best with partitions aligned on power-of-2 multiples of sectors, ranging from 8 sectors (for Advanced Format) up to at least 512 sectors (for some types of RAID arrays). Performance degradations on small-file writes can be staggering if partitions are misaligned on Advanced Format disks, so switching alignment policy in fdisk is a no-brainer.

Microsoft switched to 1 MiB (2048-sector) alignment with Vista, so of course older versions of fdisk produce alignment warnings on disks partitioned with Vista or later, and that can be confusing to those unfamiliar with the issues.

----------

## NeddySeagoon

srs5694,

I gave up on fdisk about a year ago as the MSDOS disk lable has a hard limit at 4G sectors.

I've made the move to GPT disk lables and parted for new installs even if the drives are under the 2Tb limit.

----------

## salmonix

Hi there,

I did fake repartitioning with Gparted and that made those partitions mountable. I could also restore some other broken superblocks.

However, the problem seems to be with the crappy hdd - the /home partition throws numerous low-level I/O errors, e2fsck does not stop complaining, even after reformatting the disk, like

 *Quote:*   

> ata2.00: status: {DRDY err}
> 
> ata2.00: error: {UNC}
> 
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> ...

 

Thanx for all you concern!

----------

## NeddySeagoon

salmonix,

Get smartmontools ans post the drives internal log.

Formatting doesn't do any more than write the filesystem data for an empry filesystem

If you want to know the that the drive is good, you need to write all of it.

Your error is typical of a failed block that the drive should have remapped while it could still read it.

Provided the drive still has spare sectors, a write (which will fail) will force the drive to map the failed logical sector to a different physical sector.

Your smartmon log will tell us more.

----------

## salmonix

I hope you meant that.

http://pastebin.archlinux.fr/444100

----------

## NeddySeagoon

salmonix,

Thats it

```
197 Current_Pending_Sector  -O--C-   100   100   000    -    229
```

The 229 is the number of sectors the drive isn't happy that read relibably and its considering relocating.

```
 5 Reallocated_Sector_Ct   PO--CK   100   100   036    -    0
```

Shows that no sectors have been reallocated yet.

```
  After command completion occurred, registers were:

  ER -- ST COUNT  LBA_48  LH LM LL DV DC

  -- -- -- == -- == == == -- -- -- -- --

  40 -- 51 00 00 00 0b c0 00 a0 a8 00 00  Error: UNC at LBA = 0xbc000a0a8 = 50465906856
```

Shows the logical block address of one of the problem sectors.

The figures in the table headed

```
 ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
```

are nomalised

The rule is that when a a VALUE  <= THRESHold, that parameter is out of specification and the drive is end of life.  

```
187 Reported_Uncorrect      -O--CK   001   001   000    -    8083
```

IS therfore a bad sign.  However, if you force sector relocation, that may fix itself too.

RAW_VALUE is drive vendor specific.You can see very high numbers here that mean very little as several bit fields can be combined.  To know how to read RAW_VALUE, you need to visit the vendors wbsite. 

Your drive isn't dead yet. You could try partitioning the drive as a single partition and formating it it with 

```
mke2fs -cc /dev/sd...
```

that does a write test of the drive surface, actually four writes as 00 55 AA and FF are written to the drive and verified before the filesystem is created.

This should coax the drive to do the sector reallocation. 

Ideally, once the format is complete, you should have zero pending sectors and 229 (maybe more) reallocated sectors.  The format will take a long time, its going to write and read the entire drive four times.

----------

