I'm trying to copy the partition structure of a drive that died, all the info I have is that it has an MBR, uses an msdos partition table (not sure if this matters?) and has 9 partitions and looks something like this:
/dev/sda,sector 0 is MBR
/dev/sda1 is kernel (RAW) - 190MB
/dev/sda2 is swap (SWAP) - 478MB
/dev/sda4 is rescue (RAW) - 190MB
/dev/sda5 is root - ext3 - 4.66GB
/dev/sda6 is app - ext3 - 4.66GB
/dev/sda7 is config - ext3 - 6.1MB
/dev/sda8 is user - ext3 - 956MB
/dev/sda9 is maps - ext3 - rest of drive
Since sda3 is "missing" I'm guessing that's the extended partition? However when trying to do that in gparted or the Ubuntu disk tool, the next logical partition gets named sda5 instead of sda4. I'm going to be copying filesystems to the drive that have hardcoded device names in all the scripts so the numbers need to match exactly.
Is there a way to rename the sda5 to sda4? Or maybe I'm completely off on the extended partition thing?
Any help would be greatly appreciated, thanks.
Best Answer
I can help with parts of this.
If the disk uses an MBR partition table, then it has to use an extended partition as you suspected because the MBR can only support four primary partitions. This is one of the reasons GPT partition tables are favored. They don't have that limitation. They also support larger partitions.
When Linux looks at a disk drive, it assigns devices to each partition it finds sequentially on the drive. If that drive is the first drive it sees, it will call it /dev/sda and the partitions on it will be assigned starting with /dev/sda1. So you cannot rename these.
It is good practice not to rely on device names for exactly the type of issues you are running into. Most people use the UUIDs of partitions to refer to them which is a big improvement. I go one step further and use unique, human readable/meaningful partition labels to refer to partitions. If you have multiple drives, you cannot guarantee that they will be recognized in the same order at each boot, so a device that was /dev/sdb one time might be /dev/sdc another time. It gets even worse when you have removable disks that don't even get a device file until they are physically attached to the system. UUIDs are more invariant, but will also change if you resize or move a partition. Labels are not modified, but rely on you to name them uniquely.
I don't know why /dev/sda4 is being skipped - especially if swap is already assigned to /dev/sda2. I don't know how to fix that. If you look at the new drive, there should be "something" where /dev/sda4 is supposed to be. Maybe /dev/sda3 fills up the rest of the disk, but even if it does, I would think /dev/sda4 would still be the first extended partition within it. Or, maybe the opposite, it doesn't fill the rest of the disk and so /dev/sd4 is being reserved for the space after the whole /dev/sd3 extended partition.
As a possible workaround, if you have access to another computer, you could build the new drive on it, obtain the UUIDs or labels of all the new partitions and then run all your scripts through sed to change all the device references to use UUIDs or labels. You could even switch to a GPT partitioning scheme if you wanted to.