Partitions out of order after the deletion of a logical partition
The contiguous requirement of logical partitions got me in trouble. (Fixing it, though, was educational.) I had previously set up a logical partition (hda5) in my extended partition (hda4) intending to install a linux distro there. Next to the (hda5) partition inside the (hda4) extended partition was my /data partition (hda6) which I had intended to leave untouched. In preparation for installing Ubuntu 6.06-32bit in hda5 I deleted the existing logical partition intending to make free space there for the Ubuntu install. I wanted it in hda5. I had planned it that way and had set up earlier Linux installations on the assumption that hda5 would be a root partition and the next partition would be the /data partition (hda6) where certain boot files would be located governing GRUB options at boot time. Hda5 deleted fine but I noticed afterwards the partition numbers were off. The /data partition (hda6) was now where hda5 was (or numbered as such) and the free space that had been there was moved to the end or where hda6 had been. I went on with the installation thinking so long as the free space was used it didn’t matter if the numbers were off. My data would be ok. But it did matter at least for boot purposes, given my GRUB setup (as described in the Bootloader section here).
When I went to install the boot loader for Ubuntu, I chose hda5 where I originally had wanted it to go. It resulted in an error. Hda5 had no kernel installed in it. It was the /data partition. Worse, the partition table was screwed up. The contiguous requirement of extended partitions had forced, I guess, the extended partition to close up the gap made by the deleted partition and move the free space to the end. There is not supposed to be free space in the middle of things in the extended partition.
This confused me because only a short time earlier I had done the very same thing to hda3, a primary partition, that is, deleted it and created free space where the hda3 partition had been, and all went smoothly installing Ubuntu 6.06-64bit there. The location of the space was preserved, a correctly numbered and formatted partition slipped right into that space without incident. But not so with hda5, a logical partition.
The lesson here is, I think, delete logical partitions with care. Knocking them out, reorders every partition after it and causes havoc with bootloaders and etc/fstab mountings and who knows what else. What I think I should have done is preserve the partition but reformatted it in place. I had had trouble doing this the first time around which made me want to delete and start from scratch with free space. I got away with deletion when the partition was primary but not when it was logical.
I ended up using a boot disk to reset the bootloader to the MBR which messed up my previously neat multi-boot setup (where each root partition had its own bootloader and one in the MBR to rule them all) and screwing up mount points in etc/fstab. But it was the only way that worked for me to get access to at least one of my installed distros. Fortunately, my /data partition (where I stored all my stuff independent of any distro’s /home directory, making it easy to install and reinstall distros without tampering with data meant to be accessible to all) was still intact, just moved to a differently numbered partition. By editing etc/fstab I was able to get at it again.
To fix the partition table numbering, first I did this to see what was up:
vmunoz@linux:~> su
Password:
linux:/home/vmunoz # fdisk -l
Disk /dev/hda: 120.0 GB, 120060444672 bytes
255 heads, 63 sectors/track, 14596 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 192 1542208+ 82 Linux swap / Solaris
/dev/hda2 * 193 2742 20482875 83 Linux
/dev/hda3 2743 5353 20972857+ 83 Linux
/dev/hda4 5354 14596 74244397+ f W95 Ext'd (LBA)
/dev/hda5 7965 14596 53271508+ 83 Linux
/dev/hda6 5354 7964 20972794+ 83 Linux
Partition table entries are not in disk orderNote the warning in bold and that the start and end points of hda5 ought to be where hda6’s are. To fix the disk order of the partitions do this:
Login as root and type:
fdisk /dev/hdaNow, type x (extra functionality (experts only)),
enter,
then select f (fix partition order),
enter,
then p (print the partition table, look over and copy this somewhere, you’ll need it to fix other things),
enter,
then w (write table to disk and exit),
enter.
Now, before the next reboot, you’ll have to adjust your bootloader(s) and etc/fstab mount points using the partition information you got from the p command. (See below for more fdisk commands.)
My fdisk session:
vmunoz@linux:~> su
Password:
linux:/home/vmunoz # fdisk /dev/hda The number of cylinders for this disk is set to 14596.
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) Command (m for help): xExpert command (m for help): f
Done. Expert command (m for help): p
Disk /dev/hda: 255 heads, 63 sectors, 14596 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 00 1 1 0 254 63 191 63 3084417 82
2 80 0 1 192 254 63 1023 3084480 40965750 83
3 00 254 63 1023 254 63 1023 44050230 41945715 83
4 00 254 63 1023 254 63 1023 85995945 148488795 0f
5 00 254 63 1023 254 63 1023 126 41945589 83
6 00 254 63 1023 254 63 1023 41945777 106543017 83
Expert command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
linux:/home/vmunoz #
After changing fstab and bootloaders as described in my Multiple-Linux-distros.doc rebooted. It booted into Suse 10.1 fine. Then I checked partition:
vmunoz@linux:~> su
Password:
linux:/home/vmunoz # fdisk -lDisk /dev/hda: 120.0 GB, 120060444672 bytes
255 heads, 63 sectors/track, 14596 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System
/dev/hda1 1 192 1542208+ 82 Linux swap / Solaris
/dev/hda2 * 193 2742 20482875 83 Linux
/dev/hda3 2743 5353 20972857+ 83 Linux
/dev/hda4 5354 14596 74244397+ f W95 Ext'd (LBA)
/dev/hda5 5354 7964 20972794+ 83 Linux
/dev/hda6 7965 14596 53271508+ 83 Linux
linux:/home/vmunoz # Exactly how I wanted it to look!
See also this post for some confirmation of this extended partition behavior.
It seems when deleting and creating primary partitions some partitioning software (that used in Ubuntu, for example) you have the option to assign the number of the partition. It can be assigned so that a partition created later can be inserted with a smaller number than one already there, allowing for insertion of new partitions in free space between existing partitions while keeping them sequentially numbered. But with logical partitions, there is no such option; later partitions must have higher numbers than earlier ones. My first experience deleting a partition was with a primary one and I could choose my number and all went well. I thought it would be the same when I went to delete another partition which was logical, but there I had no choice but to go with the higher unwanted number.
I should point out that some don’t think the disk order of the partitions is always worth fixing. In which case, I guess you would have to adjust, if necessary, everything else that depended on the old partition numbers on your computer to account for the new partition numbers. Because of my rather complicated multi-boot setup, however, I thought it best to restore the sequential order.
Mixed formats problem
After fixing partition table and getting GRUB back, when I tried to boot into 64bit Ubuntu at a certain point in the boot process I get stopped with a root@Monarch prompt and this error:
reiserfs_open: the reiserfs superblock cannot be found on /dev/hda5hda5 is where the 32bit Ubuntu now is but where the reiserfs /data partitions was and this is what it was complaining about. The 64bit Ubuntu needed its /etc/fstab file adjusted.
I fixed this by editing the /etc/fstab file and changing the “type” of file system to ext3 for /dev/hda5, which is what it really was now, not reiserfs. Now 64bit Ubuntu boots without a problem.
32bit Ubuntu, however, was probably botched in other ways when first installed, it would not boot even with the above changes to its fstab and an attempt at re-installing grub to its boot sector using the install disk in rescue mode. I ended up reinstalling from scratch. Since there was nothing important in that partition, this was not too big a deal.
More fdisk commands (FYI):
Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
Command (m for help): xExpert command (m for help): m
Command action
b move beginning of data in a partition
c change number of cylinders
d print the raw data in the partition table
e list extended partitions
f fix partition order
g create an IRIX (SGI) partition table
h change number of heads
m print this menu
p print the partition table
q quit without saving changes
r return to main menu
s change number of sectors/track
v verify the partition table
w write table to disk and exit
Expert command (m for help): f command "f' fixes the partition table, "w" writes table to disk and exits fdisk. Once you reboot, Linux will use the new partition order, and fdisk will report it.
Thanks for posting this! I was having the same problem, and this was exactly what I needed. The in-depth explanations and fdisk output helped a lot.
Partitions out of order really screw with your system; On mine, “mount /dev/hda7″ or “swapon /dev/hda8″ were affecting *different partitions* than fdisk or parted were reporting as hda7 or hda8, which caused me to blow away data more than once before I finally figured it all out.
Said by NereusRen November 19, 2006 at about 7:28 pm
Thanks for that lucid and extremly helpful write-up.
After a failed attempt at installing an OS, I ended up with an essentially unbootable [second] hard drive. Now I have the information to avoid this trap in the future and to recover gracefully from the error now.
Paul
Said by PGTips91 November 3, 2007 at about 8:19 pm