Help; partition has (apparently) disappeared

[satuser083]

I've got a partition-problem on my Acer. The HDD used to look like this:

|  sda1    |  sda2    |  sda3   |  sda5  |  sda7   |  sda6  |
|  FAT32  |  FAT32  |  FAT32  |  Ext3  |  Swap  |  Ext3  |
|  1GB     |  35GB   |  19GB  |  10GB  |  2GB   |  5GB   |

In order to release some space on sda3 (the 19GB partition) I resized it (with PCC -> Manage Disk Partitions) to 10GB, leaving a space of 9GB behind it. That seemed to work. I then created a partition in the space just made and PCC said that the partitions had been renamed: sda5 -> sda6, sda6 -> sda7, sda7 -> sda8 and the new partition to sda5 (I think  , because I didn't pay a lot of attention to this message; probably an error). I then formatted the new partition to ext3, again with PCC. All seemed to be OK, at least there were no system compaints.
I then rebooted with the live CD (2009.2) and, just to be absolutely certain, checked the partitions with PCC. Partition sda3 is still 19GB and sda5 -sda7 are still just that (i.e. they have not been renamed). There's no sdsa8!!. Strange, I thought, so checked with KDiskFree; this shows the same structure as PCC, except that sda3 is only 10GB, meaning that the 9GB partition (whatever it's called) has just disappeared.
Assuming that this new partition is there somewhere, can anyone tell me if there's some utility or another which can reveal the dreaded details? Thanks.

[Bald Brick]

Try running fdisk -l as root in a terminal, and post the output. (The "l" in "-l" is a lowercase "L".)

[satuser083]

Thanks, blackbird. Here it is:

Code: [Select]

[root@localhost ~]# fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         765     6144831   12  Compaq diagnostics
/dev/sda2   *         766        5214    35736592+   7  HPFS/NTFS
/dev/sda3            5215        7766    20498940    c  W95 FAT32 (LBA)
/dev/sda4            7767        9729    15767797+   5  Extended
/dev/sda5            7767        8900     9108823+  83  Linux
/dev/sda6            9163        9729     4554396   83  Linux
/dev/sda7            8901        9162     2104483+  82  Linux swap / Solaris

Partition table entries are not in disk order

 

[Bald Brick]

Thanks, blackbird. Here it is:

Code: [Select]

[root@localhost ~]# fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         765     6144831   12  Compaq diagnostics
/dev/sda2   *         766        5214    35736592+   7  HPFS/NTFS
/dev/sda3            5215        7766    20498940    c  W95 FAT32 (LBA)
/dev/sda4            7767        9729    15767797+   5  Extended
/dev/sda5            7767        8900     9108823+  83  Linux
/dev/sda6            9163        9729     4554396   83  Linux
/dev/sda7            8901        9162     2104483+  82  Linux swap / Solaris

Partition table entries are not in disk order

 

Well, fdisk seems to agree with Diskdrake in PCC: it still sees sda3 as around 19 gibibytes (20 decimal gigabytes). I had hoped at least to see a gap between sda3 and the extended partition sda4, but there isn't any. If KDiskFree only reports 10 GiB for sda3, it looks like part of the partition has simply become invisible.

You could look at the disk with GParted. It's a more modern partitioner, and at least it will show you the logical partitions as being within the extended partition, which Didskdrake doesn't. You could also try to redo the repartitioning with GParted.

[kjpetrie]

You can only have four primary partitions on a disc, and only one of them can be an extended partition. All logical partitions must exist within the extended partition.

You have tried to split a primary partition in half which is outside the extended partition. That can't be done. All you can do is shrink that partition, but there is no room in the partition table to add a partition there. It is arguably a bug in Diskdrake that it allowed you to 'create' and format an impossible partition which it was then unable to write to disc.

The only way you can reclaim that space is to delete and remake the extended partition, but that would destroy all your virtual partitions too.

[Old-Polack]

You can only have four primary partitions on a disc, and only one of them can be an extended partition. All logical partitions must exist within the extended partition.

You have tried to split a primary partition in half which is outside the extended partition. That can't be done. All you can do is shrink that partition, but there is no room in the partition table to add a partition there. It is arguably a bug in Diskdrake that it allowed you to 'create' and format an impossible partition which it was then unable to write to disc.

The only way you can reclaim that space is to delete and remake the extended partition, but that would destroy all your virtual partitions too.

While the above is technically true, the data, in the logical partitions, would remain in it's present position on the drive. If the third primary partition were first shrunk, then the extended partition created to cover the rest of the drive, starting at the next cylinder after the last cylinder of the new third primary partition, a new partition could be created from the staring cylinder of the new extended partition, and ending at cylinder 7766. The remaining space could then be reconstructed as it currently exists. Each of the present logical partition's designations would increment by 1, as the new partition would then be the new /dev/sda5.

The sda3 partition would first need to be shrunk by whatever application one chooses to do that. The rest is fairly simple to achieve using Linux fdisk.

[kjpetrie]

If you want to go that way, I'm sure O-P can walk you through it, but back up your / and /home partitions first in case of slips.

I don't know whether that process will change the UUIDs of the partitions, or whether menu.lst and fstab on your system use UUID or hd(0,x-1) and /dev/sdax, but remember pclos won't boot unless these files point to the correct partitions.

I'll be fascinated to watch.

[Old-Polack]

If you want to go that way, I'm sure O-P can walk you through it, but back up your / and /home partitions first in case of slips.

I don't know whether that process will change the UUIDs of the partitions, or whether menu.lst and fstab on your system use UUID or hd(0,x-1) and /dev/sdax, but remember pclos won't boot unless these files point to the correct partitions.

I'll be fascinated to watch.

UUID numbers are created during the formatting of the partition and stored in the superblocks. The ones for the logical partitions will stay the same, but I don't know if the partition, and subsequent file system shrinking process, will create a new UUID number for sda3. UUIDs don't usually change unless a partition is actually reformatted. I really don't know if the system sees a file system size change as a formatting of sorts. If the system is not using UUID, but rather block device designations, menu.lst and fstab would have to be edited to reflect any changes to those designations.

satuser083:

As always, backing up the data on any changed partition would be the best insurance for complete success. The backups can be deleted later, if everything goes as planned and disk space is a concern.

[MadCatMk2]

Although I've read most of this thread in a rush, I take it satuser083's priority is still to recover the files that were in this partition.

• apt-get install testdisk as root (or get it from cgsecurity.org)
• Run testdisk (via console) as root
• Follow this link and select what the partition was before you formatted it:
  http://www.cgsecurity.org/wiki/TestDisk
  
  For example, for a FAT partition take a look here:
  http://www.cgsecurity.org/wiki/TestDisk:_undelete_file_for_FAT

What this tutorial describes is locating the lost partition, viewing the files in it and copying them to a partition that is working properly.
Once you are done recovering files and have made sure they are in working condition you can format over this partition again.

Good luck!

[Old-Polack]

Although I've read most of this thread in a rush, I take it satuser083's priority is still to recover the files that were in this partition.

• apt-get install testdisk as root (or get it from cgsecurity.org)
• Run testdisk (via console) as root
• Follow this link and select what the partition was before you formatted it:
  http://www.cgsecurity.org/wiki/TestDisk
  
  For example, for a FAT partition take a look here:
  http://www.cgsecurity.org/wiki/TestDisk:_undelete_file_for_FAT

What this tutorial describes is locating the lost partition, viewing the files in it and copying them to a partition that is working properly.
Once you are done recovering files and have made sure they are in working condition you can format over this partition again.

Good luck!

As the posted problem relates to a newly created partition seemingly disappearing after a reboot, there are no lost files needing retrieval; the partition in question was never used, as in possibly never actually created at all. Testdisk is a fine application, but is not relevant to the problem at hand.

[satuser083]

While the above is technically true, the data, in the logical partitions, would remain in it's present position on the drive. If the third primary partition were first shrunk, then the extended partition created to cover the rest of the drive, starting at the next cylinder after the last cylinder of the new third primary partition, a new partition could be created from the staring cylinder of the new extended partition, and ending at cylinder 7766. The remaining space could then be reconstructed as it currently exists. Each of the present logical partition's designations would increment by 1, as the new partition would then be the new /dev/sda5.

The sda3 partition would first need to be shrunk by whatever application one chooses to do that. The rest is fairly simple to achieve using Linux fdisk.

Have read and re-read the fdisk-man, but I'm afraid that I haven't managed to pluck up the courage     to attempt this alone; I wonder if you could, as kjpetrie suggested, walk me through this fdisk procedure? 

I've checked in XP and windows sees sda3 as 9.75GB, so it looks as though this partition has been shrunk OK; hopefully just need the bit which extends sda4 (leftwards) into the area that I released. I assume that this will then be seen by PCC as an empty area into which I can create the required partition?? Thanks.

[Old-Polack]

Have read and re-read the fdisk-man, but I'm afraid that I haven't managed to pluck up the courage     to attempt this alone; I wonder if you could, as kjpetrie suggested, walk me through this fdisk procedure? 

I've checked in XP and windows sees sda3 as 9.75GB, so it looks as though this partition has been shrunk OK; hopefully just need the bit which extends sda4 (leftwards) into the area that I released. I assume that this will then be seen by PCC as an empty area into which I can create the required partition?? Thanks.

While XP sees sda3 as 9.75 GB, what does fdisk see? The last output from fdisk -l showed sda3 as almost 20 GB, and your sda6 and sda7 transposed. If the file system of sda3 has been shrunk, but the partition itself not, we need to know where the last cylinder of the file system is located.

The first thing we need is a fresh look at the output of fdisk -l.

[satuser083]

Thanks for your lightning reply; here's the output:

Code: [Select]

fdisk -lu

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63    12289724     6144831   12  Compaq diagnostics
/dev/sda2   *    12289725    83762909    35736592+   7  HPFS/NTFS
/dev/sda3        83762910   124760789    20498940    c  W95 FAT32 (LBA)
/dev/sda4       124760790   156296384    15767797+   5  Extended
/dev/sda5       124760853   142978499     9108823+  83  Linux
/dev/sda6       147187593   156296384     4554396   83  Linux
/dev/sda7       142978563   147187529     2104483+  82  Linux swap / Solaris

Partition table entries are not in disk order
[root@localhost ~]# fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         765     6144831   12  Compaq diagnostics
/dev/sda2   *         766        5214    35736592+   7  HPFS/NTFS
/dev/sda3            5215        7766    20498940    c  W95 FAT32 (LBA)
/dev/sda4            7767        9729    15767797+   5  Extended
/dev/sda5            7767        8900     9108823+  83  Linux
/dev/sda6            9163        9729     4554396   83  Linux
/dev/sda7            8901        9162     2104483+  82  Linux swap / Solaris

Partition table entries are not in disk order

I don't think that anything's changed.

[Old-Polack]

Thanks for your lightning reply; here's the output:

Code: [Select]

fdisk -lu

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63    12289724     6144831   12  Compaq diagnostics
/dev/sda2   *    12289725    83762909    35736592+   7  HPFS/NTFS
/dev/sda3        83762910   124760789    20498940    c  W95 FAT32 (LBA)
/dev/sda4       124760790   156296384    15767797+   5  Extended
/dev/sda5       124760853   142978499     9108823+  83  Linux
/dev/sda6       147187593   156296384     4554396   83  Linux
/dev/sda7       142978563   147187529     2104483+  82  Linux swap / Solaris

Partition table entries are not in disk order
[root@localhost ~]# fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         765     6144831   12  Compaq diagnostics
/dev/sda2   *         766        5214    35736592+   7  HPFS/NTFS
/dev/sda3            5215        7766    20498940    c  W95 FAT32 (LBA)
/dev/sda4            7767        9729    15767797+   5  Extended
/dev/sda5            7767        8900     9108823+  83  Linux
/dev/sda6            9163        9729     4554396   83  Linux
/dev/sda7            8901        9162     2104483+  82  Linux swap / Solaris

Partition table entries are not in disk order

I don't think that anything's changed.

Nope, it hasn't. Were it me, I'd backup all the data currently on sda3 then delete the partition completely and recreate it in the size I wanted, reformat it, so the size of the filesystem matches the partition size, then restore the data from the backup. The rest of the partition table could be rebuilt with the data in the other partitions left intact.

The problem with sda3 in it's present state would be determining the actual size of the filesystem. If it's being reported as different sizes by different apps, I would not trust it. If we try to shrink the partition to the size of the filesystem, with fdisk, and miss, making the partition smaller than the filesystem, everything on it could possibly be lost.

If we try shrinking the partition with one of the standard GUI partition shrinking apps, with the filesystem already shrunk, I have no idea what the outcome might be. It may work fine, but in may also shrink the filesystem further, in an unpredictable manner, causing data loss.

FYI:

We have tools to resize ext2-3-4 filesystems, independent of the partition itself, to exact sizes, for use when partitions need to be shrunk to predetermined exact sizes, or to expand the filesystem to capacity, if the partition size is increased. I don't see any corresponding Linux tools for resizing DOS filesystems, independent of the partition, in our repo mirrors.

[Was_Just19]

Would it not work to delete the new partition and resize the old one to use all the space -- that should ensure it is the correct size?