Resizing moving & deleting partitions

Resizing moving & deleting partitions

[Chris Jones]

Lately, I had to increase the size of the partition where grub-pc is
managed. Upon rebooting, the grub menu had become inaccessible, all
I could see was an "Error: file not found". As far as I can remember,
there was also a shell-like prompt with "rescue" or "grub rescue"
followed by the greater than ">" sign but I wasn't able to make much of
that.

I eventually managed to recreate a working grub environment (via
a graphical mini-app called "boot-repair" that I ran off the ubuntu live
CD) but now I appear to have lost my customizations, framebuffer console
with my favored fonts and screen resolution.

The tool I ended up using works.. automatically, but it doesn't tell you
much so that at this point, I don't even know on which partition the
active grub actually lives. 

Now, I have more than a handful of linux systems on this machine, and
I occasionally have to delete, move, or create new partitions for new
installs.

Backing up everything and reinstalling on top of LVM would probably make
it easier to move stuff around, but since grub.cfg config files appear
to point to bootable partitions via their ordinal numbers - i.e. msdos3,
msdos7, etc. - I doubt this would make much difference (?).

On such multi-system machines, what would be the better strategy to
avoid such situations?

I was thinking that a bootable USB key that supports my active custom
grub environment (and just that) might provide something a bit more
robust than my current setup.

Has anyone documented setting this up, or come up with a better
approach?

Will UEFI help solve the catch22 situation where you need to boot
a given system to fix a broken boot loader?

Thanks,

CJ

Re: Resizing moving & deleting partitions

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]

On 17.10.2011 00:40, Chris Jones wrote:
> Lately, I had to increase the size of the partition where grub-pc is
> managed. Upon rebooting, the grub menu had become inaccessible, all
> I could see was an "Error: file not found". As far as I can remember,
> there was also a shell-like prompt with "rescue" or "grub rescue"
> followed by the greater than ">" sign but I wasn't able to make much of
> that.
>
Unless the UUID was changed (in which case the partitioning tool is to
blame), number of /boot was changed, embed area was affected or it was a
blocklist install to begin with (in which case you've been warned) it
shouldn't happen. If you can provide a way to recreate it on loopback
(in preference a script), please file a bug report.
Using UUIDs to locate /boot is currently done only on cross-disk
installs as it eats valuable embedding space.
> Backing up everything and reinstalling on top of LVM would probably make
> it easier to move stuff around, but since grub.cfg config files appear
> to point to bootable partitions via their ordinal numbers - i.e. msdos3,
> msdos7, etc. - I doubt this would make much difference (?).
Read better. grub.cfg uses UUIDs, partition ids are only a fallback.
> Will UEFI help solve the catch22 situation where you need to boot
> a given system to fix a broken boot loader?
Nope. UEFI is useless in most senses. Its only advantage is that you
don't need embedding area to take special care of.



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Resizing moving & deleting partitions

[Chris Jones]

On Sun, Oct 16, 2011 at 06:52:40PM EDT, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 17.10.2011 00:40, Chris Jones wrote:

> > Lately, I had to increase the size of the partition where grub-pc is
> > managed. Upon rebooting, the grub menu had become inaccessible, all
> > I could see was an "Error: file not found". As far as I can
> > remember, there was also a shell-like prompt with "rescue" or "grub
> > rescue" followed by the greater than ">" sign but I wasn't able to
> > make much of that.
> >

> Unless the UUID was changed (in which case the partitioning tool is to
> blame), number of /boot was changed, embed area was affected or it was
> a blocklist install to begin with (in which case you've been warned)
> it shouldn't happen. If you can provide a way to recreate it on
> loopback (in preference a script), please file a bug report. Using
> UUIDs to locate /boot is currently done only on cross-disk installs as
> it eats valuable embedding space.

Apologies, I should've made it clear I wasn't reporting a bug, just
giving a general idea of the ‘context’.

This type of question should probably been asked on a grub user list,
anyway.

> > Backing up everything and reinstalling on top of LVM would probably
> > make it easier to move stuff around, but since grub.cfg config files
> > appear to point to bootable partitions via their ordinal numbers
> > - i.e. msdos3, msdos7, etc. - I doubt this would make much
> > difference (?).

> Read better. grub.cfg uses UUIDs, partition ids are only a fallback.

ibid.

[..]

Something that I could have put to excellent use is the internal SD
adapter on this laptop, so that I wouldn't have a silly USB key sticking
out like a sore thumb (more like an accident waiting to happen), but it
doesn't seem my BIOS allows booting off of whatever's in it.

If it did, I could then have my boot loader ‘on a chip’ so-to-speak.

I would always know where my boot loader lives, where it is managed, and
never have to worry about having a live CD handy to address situations
that require one - partition maintenance, reinstalling/repairing the
boot loader.. but also cold back ups, restores, replacing a hard drive,
etc. 

All the same, thanks for your comments.

CJ