Does deleting a partition below Ubuntu mess up grub?
Robert Heller
heller at deepsoft.com
Sun Oct 12 15:49:40 UTC 2014
At Sun, 12 Oct 2014 15:49:18 +0100 "Ubuntu user technical support, not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:
>
> On 12 October 2014 14:53, Robert Heller <heller at deepsoft.com> wrote:
> > At Sun, 12 Oct 2014 14:35:41 +0100 "Ubuntu user technical support, not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:
> >
> >>
> >> On 12 October 2014 14:27, William Scott Lockwood III <scott at guppylog.com> wrote:
> >> >
> >> > On Oct 12, 2014 8:16 AM, "Colin Law" <clanlaw at gmail.com> wrote:
> >> >>
> >> >
> >> >> I want to delete a partition (sda4) which is below the Ubuntu
> >> >> partition (sda5). I seem to remember when I did something similar
> >> >> some time ago that it messed up grub and the machine would not boot,
> >> >> due to the fact that the sda numbers changed when the partition was
> >> >> deleted. Is that still the case, and if so is there a procedure for
> >> >> deleting sda4 that will not cause such problems? This is Ubuntu
> >> >> 12.04.
> >> >>
> >> >> Cheers
> >> >>
> >> >> Colin
> >> >>
> >> >> --
> >> >
> >> > Mount by UUID rather than device name. Also, there are tools that help you
> >> > do this in a sane manor. Any of the gui partition managers should do,this
> >> > just fine.
> >>
> >> Thanks, but I am not sure if that is the problem. Looking in
> >> /boot/grub/grub.cfg it contains direct references to sda numbers, so
> >> my memory was that grub looked for the wrong partition. Perhaps my
> >> memory is wrong, however, and it was mounting the drives that caused
> >> the problem due to having sda numbers in fstab.
> >
> > You may have both issues. Grub does use hard partition numbers to find the
> > kernel and initrd files. There is also the root= kernel parameter, which
> > *might* have a direct references to a sda number. This should be changed to
> > either use UUID= or LABEL=. And yes, you should make sure /etc/fstab is using
> > UUIDs or LABELs.
>
> So if I want to delete a partition should I first edit
> /boot/grub/grub.cfg, and if so can I assume that all sda numbers above
> the deleted one will be decremented? Or can I run gparted from the
> working system, unmount the partition I want to delete (assuming it is
> not in use), delete it, and run update-grub before re-booting? I
> suspect that will not do anything as the new partition numbers will
> not get allocated until re-boot.
>
> > Also: *often* (but not always) partition #4 is the entended partition,
> > containing (logical) partitions 5 and up. Deleting partition #4 *in that case*
> > also deletes partitions 5 and up. Make sure this is not what you are doing!
>
> I mis-typed, it is actually sda3 I want to delete. However, when I
> look at the partition numbering it looks a bit strange, so I am not
> sure how to predict what the sda numbers will be after deleting sda3.
> I have
>
> /dev/sda1 Windows
> /dev/sda3 To be deleted
> /dev/sda4 /home
> /dev/sda2 Extended
> /dev/sda5 /
> /dev/sda6 Swap
>
> Perhaps the easiest thing is just to shrink sda3 down small and leave
> it, but that seems like admitting defeat.
I would *guess* that /dev/sda4 might become /dev/sda3. If /home is mounted
using its UUID or LABEL, you should be OK. I would guess /dev/sda2 would not
change and /dev/sda5 and /dev/sda6 might not change either, but I don't know
for sure. They might become 4 and 5, but maybe not.
If *I* had installed Linux on this machine, I would NOT have used /dev/sda4 for
/home. Instead I would have opted for something like this:
/dev/sda1 Windows
/dev/sda2 /boot (about 1G is plenty)
/dev/sda3 (If this was another Windows partition)
/dev/sda4 LVM Volume Group (the rest of the disk)
Logical volumes for /, /home, and swap.
In this case, /boot's partition number would not change (grub will remain
happy) and even if /dev/sda4 became /dev/sda3, it would have no effect for
accessing Linux file systems, since you would presumably be using vgscan to
find the LVM Volume Group, without reguard to the partition number. Actually,
what I would do is repurpose /dev/sda3 as an additional physical volume and
add it to the volume group on /dev/sda4. This is what I ended up doing on my
laptop's hard drive:
gollum.deepsoft.com% sudo /sbin/fdisk -l /dev/hda
Disk /dev/hda: 60.0 GB, 60011642880 bytes
16 heads, 63 sectors/track, 116280 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 497 250456+ 83 Linux
/dev/hda2 498 2482 1000440 8e Linux LVM
/dev/hda3 2483 116280 57354192 8e Linux LVM
(/dev/hda1 is mounted as /boot, /dev/hda2 and /dev/hda3 are combined into a
single LVM Volume Group:
gollum.deepsoft.com% sudo pvdisplay
File descriptor 4 (/proc/stat) leaked on pvdisplay invocation. Parent PID 469: sudo
--- Physical volume ---
PV Name /dev/hda3
VG Name gollum
PV Size 54.70 GB / not usable 1.95 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 14002
Free PE 690
Allocated PE 13312
PV UUID 5ceb8D-B6jx-Ancl-5d4Q-TUVi-u21s-N1pvB9
--- Physical volume ---
PV Name /dev/hda2
VG Name gollum
PV Size 976.99 MB / not usable 1016.00 KB
Allocatable yes
PE Size (KByte) 4096
Total PE 244
Free PE 244
Allocated PE 0
PV UUID v3nNJD-4NFd-QKZY-Bgbp-3obG-4mQ3-v4PM1r
gollum.deepsoft.com% sudo vgdisplay
File descriptor 4 (/proc/stat) leaked on vgdisplay invocation. Parent PID 474: sudo
--- Volume group ---
VG Name gollum
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 22
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 8
Open LV 6
Max PV 0
Cur PV 2
Act PV 2
VG Size 55.65 GB
PE Size 4.00 MB
Total PE 14246
Alloc PE / Size 13312 / 52.00 GB
Free PE / Size 934 / 3.65 GB
VG UUID 6JwsTu-knuf-BfIh-CXK0-1tfQ-1Hvk-lppou6
If /dev/sda3 was NOT a Windows partition, then this is what I would have done:
/dev/sda1 Windows
/dev/sda2 /boot (about 1G is plenty)
/dev/sda3 LVM Volume Group (the rest of the disk)
Logical volumes for /, /home, and swap, and any other Linux file systems.
This would have greatly simplified things. You would be able to delete the
Linux file system you no longer need and expand any other Linux file systems
as needed *without* having to mess with grub or even rebooting. You would
never need to mess with the partition table ever again.
Dealing with the partition table is so 'old fashioned'. I try to avoid
dealing with *partitions* beyond whatever is needed to keep the BIOS and other
'primititive' systems happy, and opt for using LVM for everything else. It
makes life so much easier...
>
> I wonder why grub does not use UUIDs.
UUIDs refer to *file systems* (not partition numbers) and are handled by udev
-- the initramdisk fires up udev which scans all of the available devices and
partitions (and LVM volume groups, etc.) and collects all of the UUIDs and
LABELs it finds and populates the /dev/disk/by-{id,label,path,uuid}/
directories with symlinks. Then mount, etc. can then do 'lookups' by UUID or
LABEL by looking in /dev/disk/by-uuid or /dev/disk/by-label and use the
symlinks there. Grub does not have udev available for this scanning process
and functions at a much lower level and uses the hard partition numbers to
find the file systems.
If I was dealing with this, I'd make sure I had a live / rescue boot disk (or
USB stick) on hand in case of trouble -- one can then boot the live / rescue
system and then edit grub.cfg as needed to repair things (in case you
mis-'guess' what will happen to the partition numbers). All of the
kernel/linux level mappings (eg /etc/fstab and the kernel's root= parameter)
can be done in advance (eg set to use UUID= or LABEL=).
>
> Colin
>
> Cheers
>
> Colin
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller at deepsoft.com -- Webhosting Services
More information about the ubuntu-users
mailing list