Deleting earlier partitions after installation

[Qqmike]

Re: Deleting earlier partitions after installation

- - - - - - - - - -
Part 2
I think the question raised by Hans is a good one, I started something here with this experiment, others may find some of this useful, so here's a Part 2 that I could not resist testing. I deleted that newly created partition sdb7 and then grew my Kubuntu 7.04 partition sdb5 to the "LEFT" to take up the space previously used by sdb7. Again, no problems at all with GRUB; no change in the UUID for sdb5.

Part 2:
The result of the first experiment was:

sda1 Windows XP
sda2 Dedicated GRUB partition (See Note)

sdb1 Dedicated GRUB partition (See Note)
sdb2 swap
sdb3 /home (shrunk by 15 GB)
sdb4 Extended (grown by 15 GB)
sdb7 ext3, 5 GB, newly created Logical partition within sdb4
sdb5 root (/) for Kubuntu 7.04; my main Kubuntu that I use daily; grown by 10 GB
sdb6 Kubuntu 7.10 (root and /home); experimental--no time to convert yet! No change.

This time, using GParted Live CD:
1 Delete the newly created Logical partition sdb7 (5 GB).
2 Expand the Kubuntu 7.04 partition sdb5 by moving its LEFT endpoint (the beginning of sdb5) to the start of the extended partition sdb4 (i.e., grow sdb5 from 29.30 to 34.18 GB to the "LEFT"); this takes up the space left by deleting sdb7.

***That took 1 hour, 50 minutes.
Again, no problems booting with my existing GRUB partitions; no changes in the UUID for sdb5.

[Qqmike]

Re: Deleting earlier partitions after installation

Well, I need to finish, and to do that, I need to fix something. I just realized that this does not fully answer the original question, which is, What happens to the device naming of a partition (and GRUB, UUIDs, etc.) when a *preceding* partition is deleted? Sure got hooked on this one, didn't I? To answer it, if you are following the above experiments, for Part 3, I need to create sdb7 following sdb6, install Kubuntu on it, set it up to boot in GRUB, then delete sdb6, grow sdb7 to the "left" in the space left by sdb6, and see what happens to the device naming (and GRUB, UUIDs/fstab, etc.). This will take awhile (up to 3-4 hours or longer). I'll do this later on (starting tomorrow) and report back. Gone too far now to stop.

[Qqmike]

Re: Deleting earlier partitions after installation

Part 3

Hans, in your original post you said:
The disk is now like this:
/dev/sda1 -> ntfs windows partition
/dev/sda2 -> fat data partition
/dev/sda3 -> ext3 Kubuntu partition
(swap)

And you asked:
"I want to delete the windows partition and the data partition (with the Kubuntu live CD) to be able to grow the Kubuntu partition, but I first wanted to know what would happen to the partition numbering. I'm afraid that when I delete the first two partitions, /dev/sda3 will become /dev/sda1 which will make the /etc/fstab entries and grub entries invalid causing my Kubuntu not to boot anymore . . .
Has anybody done this before?"

Answer:
No, I hadn't done this before. I did it after. I just now did what I said in Reply #16 above.

Your conjecture is correct, *based on my experiment.*
Your sda3=(hd0,2) (Kubuntu) will become sda1=(hd0,0).
The change is immediately apparent in GParted.
However, the UUID for your new sda1 will be the same as the UUID for the old sda3.
Your Kubuntu will not boot (until you edit GRUB or boot manually or boot using Super Grub Disk).
Your GRUB boot configuration will have to be fixed.
Your fstab will have to be edited.
All this is easy enough to do in basic setups, as yours is.

A few details:

-- To fix the GRUB bootloader:

Go to your main boot menu (that your PC uses to boot by). Hans, that would be in the new sda1 Kubuntu for you, at /boot/grub/menu.lst. As root, edit and save the following changes:
Delete any references to the deleted partitions, the old (hd0,0) and the old (hd0,1). In your case, you would delete the boot entry for Windows on (hd0,0). (The old (hd0,1) is a data partition and so will not be mentioned in your menu.lst.)

In your Kubuntu boot entry, change the old "root (hd0,2)" to "root (hd0,0)," which is where your Kubuntu is now after the re-partitioning.

If you have problems, or in any case, just in case, I would also re-install GRUB:
> Use Super Grub Disk to do it.
> Or, do it manually:
At the boot menu, press "c" key to get the GRUB prompt, grub>, then each of these:
grub> root (hd0,0)
grub> setup (hd0)
grub> reboot
(to test it)

-- To fix fstab:
Edit and save the following changes to your /etc/fstab in your Kubuntu (which is now on (hd0,0)):
Delete all references to the old partitions sda1 (ntfs Windows) and sda2 (fat data).
Edit the entry for Kubuntu on "# /dev/sda3" to read "# /dev/sda1". The UUID will be the same and there is no need to edit it.

That's it. Done.

Hans, sorry about the diversions here. But thanks for triggering these diversions here--I know more now about GParted now than I ever cared to know . . .
- - - - - - - - - -

Troubleshooting tips:

-- Re-booting after editing the partitions in GParted:

You'll see a boot menu, but it won't work ("Error 22 No such partition" -- (hd0,2) is gone!).
Press ESC key, back to the boot menu now. Highlight the Kubuntu boot entry in the menu.
Press "e" key. Highlight the statement "root (hd0,2)." Press "e" key. Edit the "root (hd0,2)" to read "root (hd0,0)". No need to edit the "root=UUID=etc"--it is not changed for the Kubuntu partition. (Note: Using the "e" key is only a temporary edit--You must still edit menu.lst as root to fix this permanently.)
Press Enter (to accept your edit). Press "b" (to boot).
It will boot into your Kubuntu on the new (hd0,0).

-- Other options for booting into your OS:
Use Super Grub Disk to boot into your OS.
Use the How-To (see below) for other methods of manually booting into your OS at the GRUB prompt.
Once there in Kubuntu, you can edit & save as root the /boot/grub/menu.lst and the fstab files.

-- Hang-ups on re-booting the first time before you fix fstab:
Finish partition editing in GParted, eject the GParted CD, re-boot.
Do your edit of the boot menu using "e" key as explained above.
You may get a stall during re-booting Kubuntu saying "fsck (filesystem check) failed. Unable to resolve UUID such-and-such." If so, it is detecting the old UUIDs of the deleted partitions. If so, press Enter. Press Control-D. That will get you into Kubuntu. After you edit /etc/fstab, you will not have this problem.

-- To know your UUIDs, use these commands:
UUIDs, listing:
From Live CD and HDD: ls /dev/disk/by-uuid/ -alh
From HDD: blkid

-- If, for some strange reason, you can not re-boot successfully into your affected OS, you may use any Kubuntu Live CD to boot up, then mount the OS partition, then edit as root the menu.lst (and even fstab if you wish), so you can get booted right. See my How-To for editing menu.lst from Live CD.

-- Other setups:
If you use dedicated grub partition(s) or have other OSs or any other more complicated setups with your boot menus and fstabs, you must address the above changes in each affected file. Sometimes, you won't know which ones are affected until you get an error from fsck or from GRUB. Just go to each menu.lst and each fstab and fix them as we did here.

-- Comment re my experiment (outlined in reply #16)
The GParted re-partitiong took only 25 minutes (delete the old Kubuntu sdb6 partition and grow the new Kubuntu partition sdb7 into that space, making it the new sdb6 = 2 GParted operations).

How To GRUB Methods - Toolkit
http://kubuntuforums.net/forums/inde...opic=3081671.0
(good idea to print this out if you do this work a lot)

Bigpond, home: http://users.bigpond.net.au/hermanzone/
(GRUB methods, filesystems, mounting, dual booting, and much more)
GParted: http://gparted.sourceforge.net/
GParted how-to: http://www.howtoforge.com/partitioning_with_gparted
Tuxfiles: http://www.tuxfiles.org/
(excellent for command line, filesystems, mounting, permissions, and such)

[dibl]

Re: Deleting earlier partitions after installation

But, Mike, I assume the UUIDs for the changed partitions are now different, right? So, if you were using "mount-by-UUID" in /etc/fstab, it would be necessary to edit those device UUIDs to the new numbers, or they're not going to be mounted during boot.

[Fintan]

Re: Deleting earlier partitions after installation

But, Mike, I assume the UUIDs for the changed partitions are now different, right? So, if you were using "mount-by-UUID" in /etc/fstab, it would be necessary to edit those device UUIDs to the new numbers, or they're not going to be mounted during boot.

I concur. I can sing a very unhappy tune about those drasted uuid's. >

[dibl]

Re: Deleting earlier partitions after installation

I concur. I can sing a very unhappy tune about those drasted uuid's. >

Ahhhhh, but they really work great as long as you don't fiddle with your partitioning, and they NEVER change themselves (unlike those dastardly USB drives under /dev/sdx) !

[Qqmike]

Re: Deleting earlier partitions after installation

dibl, Fintan –

"But, Mike, I assume the UUIDs for the changed partitions are now different, right?"

No. They are not different.

At least on my system, when I did these experiments (repeatedly!), the UUIDs of the changed partitions did not change.

In my last test case,
I had:
sda1 and sda2
sdb1 Dedicated GRUB
sdb2 swap
sdb3 /home
sdb4 Extended partition containing all the rest below:
sdb5 Kubuntu 7.04—my working, production instance of Kubuntu
sdb6 Kubuntu 7.10—my experimental instance of Kubuntu

I then created a new partition sdb7, installed a new Kubuntu 7.10 (and /home) on it, set it up to boot right in GRUB, tested it, then I went into GParted and did the following two new operations:
> Delete sdb6 (and so my previous experimental Kubuntu 7.10 is gone)
> Grow my new sdb7 to the “left” to take up the space previously occupied by the old, deleted sdb6.

Now, afterwards, the changed sdb7 partition is called sdb6.
And, the UUID of my new Kubuntu 7.10 partition sdb6 (formerly called sdb7, but now called sdb6) is the same as it was before (when it was called sdb7). No change.
The only edit you must make on the sdb7 partition is any reference to it called sdb7 – it must now be called sdb6.

In the fstab(s), any references to the old, deleted partition sdb6 or to its UUID must be deleted (otherwise you get errors, of course).

I am mounting-by-UUID, btw. The fstab carries the other device reference as a comment line, like:
# /dev/sdb6
as you know.

So, my fstab had the old comment line
# /dev/sdb7
and that must be changed to
# /dev/sdb6
if you want things to be neat and proper.
BUT, again, NO change to the sdb7 UUID after it was changed and became sdb6 and was grown in size.

[dibl]

Re: Deleting earlier partitions after installation

BUT, again, NO change to the sdb7 UUID after it was changed and became sdb6 and was grown in size.

Wow, that's not what I would have expected. The last time I did some little thing to a partition, I had some pain because it wouldn't mount any more, and it took me awhile to discover that the UUID had changed. I think maybe it was when I changed the filesystem from reiserfs to xfs or something like that. So, I guess some changes affect the UUID, and others do not, apparently.

[Qqmike]

Re: Deleting earlier partitions after installation

I agree. Strange. In the past, I have also had to edit fstab when UUIDs changed after some change I made.

The sdb7 becomes sdb6 after deleting the old sdb6, and that naming, ie sdb6, is as seen in GParted or in fdisk -lu output. Since the fstab file will still show sdb7 (and the UUID), that reference to sdb7 is not correct and so must be changed in the comment line (#sdb7 --> #sdb6), but not the sdb7 UUID.

And, all GRUB statements
root (hd1,6)
that referred to Kubuntu 7.10 on sdb7 must now be changed to
root (hd1,5)
referring to the same Kubuntu 7.10 now on the "new" sdb6.

And as I said, in fstab, all lines referring to the old partition sdb6 must be deleted (or will cause errors -- unable to resolve the UUID of the old & deleted sdb6 Kubuntu 7.10 partition).