Nicolas George <geo...@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.