Re: Attempt to Move Root
Nicolas George <george@nsup.org> wrote:
> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
>> In ye olde days (pre-Windowsm 98) some programs (I think Photoshop
>> did it.) wrote licence data into that space, because it was unused.
>> The copy protection scheme of some games also tried to hide
>> information there.
>>
>> So "nobody" is not quite right. "nobody with the right mind" would be
>> a better description.
> I did not know that, it is simply disgusting. Well, if you have to
> deal with bad-behaved proprietary programs that fancy themselves more
> powerful than the operating system, then you can not use that feature
> of GRUB. That means you have to put its second stage in a partition;
> obviously, this is possible too.
> But when dealing with that level of stupidity, really there is nothing
> to do: we can not trust these proprietary programs will not decide to
> write anywhere on the disk just because they have decided they have
> the right to do so, or because they have a bug.
And this is why I love the GPT. There is a defined space for the
bootloader to be and no nether region of swirly unknowness between the
MBR and the start of the first partition.
Also this: Sit back kids, Uncle Sven tells a story from the trenches of
the 1st GRUB war.
I was upgrading a remote server from Squeeze to Wheezy. This server uses
LVM on top of an MD-RAID1, /boot is included in / which is a LV. so GRUB
needs to know about MD and LVM (and the filesystem of / of course).
With Squeeze everything was fine and dandy.
But after upgrading to Wheezy, GRUB would no longer install into the
31744 byte-sized space after the MBR. Its core.img with all needed
componenents was 12 bytes to large, about 60 bytes bigger than the one
from Squeeze!
What to do? Using the old one from Squeeze? Psshht, needing to hold the
old package for ever, maybe making the system unbootable in the worst
moment? Not an option!
But we have a MD-RAID! I removed one disk from the RAID, repartitioned
it as GPT, added a bios_grub partition of the right (and future-proof!)
size before the data partition, readded this to the running half of the
RAID, let the RAID resync, repeated the whole procedure with the other
disk, installed GRUB to its new home, rebooted while hoping/praying and
... tadaaa ... the system came right up.
This of course was only possible because the MD-RAID code allows for a
slight variation on the partition size so I had to be careful to stay
inside that margin but in the end it worked out fine with only 3 minutes
of downtime for the reboot.
And because of that experience I use only the GPT for physical servers,
even when booting in legacy mode. Because I have a known place of a
known size for the boot loader.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
Reply to: