Re: Resizing moving & deleting partitions

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- 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 --]