d765f14   
   GMT)   
   posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui   
   .os.os2.setup.storage:367 comp.os.os2.misc:2897   
   From: rusi    
      
   On Feb 12, 9:48 pm, Jonathan de Boyne Pollard  wrote:   
   > >> Ah. You wrote "partition tables". OS/2's LVM information is a quite   
   > >> different kettle of fish. I can understand how that might have become   
   > >> damaged by a Linux distribution. It doesn't reside in the partition   
   > >> table proper. It resides in unallocated space. And everyone should,   
   > >> after all of these years, know the principle of not relying on being   
   > >> able to freely use unallocated disc space for one's own purposes, or   
   > >> even relying upon its existence in the first place given how some of   
   > >> the world doesn't even use the MBR partitioning scheme any more.   
   > >> (It's a pity that IBM's LVM didn't follow in the wise footsteps of   
   > >> IBM's BootManager, and claim the space it uses with an actual   
   > >> partition. Microsoft's dynamic disc management gets that right. So   
   > >> does Linux LVM, albeit in a different way.) Ironically, there's   
   > >> probably something in Ubuntu making the same foolish and selfish   
   > >> assumption. (This is, of course, one of the reasons WHY one cannot   
   > >> rely upon unallocated space. Everyone else selfishly had the same   
   > >> wrongheaded idea, and they all conflict.)   
   >   
   > > I think your guess is right. Ubuntu uses grub2 as a bootloader and   
   > > does exactly this on BIOS-based systems if the space before the first   
   > > partition is large enough.   
   >   
   > It's not so much of a guess, now.  M. Taylor has pointed at something   
   > readable, where there's a fairly extensive set of data dumps.  You   
   > should have read my diagnosis, based upon the data provided there,   
   > earlier in this thread.   
   >   
   > One thing that I thought of adding, but also thought it unnecessary to   
   > add, was that what the "something" is could be many things.  Yes, it may   
   > well be GRUB's installer that's adjusting the partition table.  It's   
   > just as likely to be whatever Ubuntu's "choose/create the partition to   
   > install to" utility is, doing that, however.  In fact, it's more likely   
   > to be the latter than the former, given that the partition table is   
   > being, essentially, tidied up (albeit imperfectly, as it is erasing the   
   > partition name information).   
   >   
   > > A couple of releveant links:   
   >   
   > Colin Watson, in your second WWW page, says one thing that needs comment:   
   >   
   > > Maybe in ten years we'll all be using GPT and won't have to worry   
   > > about it.   
   >   
   > That's actually backwards.  The GRUB problem that he is talking about   
   > (which is the usual one of it installing as an MBR virus) is actually   
   > exacerbated and revealed by the EFI partitioning scheme, rather than   
   > ameliorated.  The EFI partitioning scheme explicitly allows any part of   
   > the partitionable area of the disc to be allocated to a partition.     
   > There is *no* wasted space that just so happens never to be allocated   
   > (Apple and MacOS repeating history, aside) on EFI partitioned discs.     
   > Installing as a MBR virus is broken by the EFI partitioning scheme, both   
   > practically and conceptually.  Practically, the area that MBR viruses   
   > reside is the partition table on EFI partitioned discs; so GRUB   
   > installed as an MBR virus wipes the partition table.  Conceptually, the   
   > idea of wasted space that one can secretly hide in goes completely out   
   > of the window with the EFI partitioning scheme.   
   >   
   > Ironically, GRUB has long since addressed this.  There's an EFI   
   > partition type, misleadingly known by the misnomer "BIOS Boot   
   > partition", defined for holding GRUB boot images.  (GRUB has followed in   
   > the wise footsteps of IBM's BootManager in this respect.)  Ironically,   
   > the people who picked its GUID revealed themselves to be rather foolish   
   > on two counts.  First, the hidden message in the GUID is   
   > self-contradicted by the fact that it is, after all, an EFI partition   
   > type GUID.  Second, there's no such thing as a version 6 GUID, and the   
   > GUID is ill-formed, not least because it patently hasn't been formed by   
   > a GUID generation algorithm, version 6 or otherwise.  (I picked a GUID   
   > for IBM BootManager partitions converted from the MBR partition table to   
   > the EFI partition table.  It's on my WWW site.  I didn't try to encode   
   > hidden messages.  I just went tohttp://guidgen.com./and had it   
   > generate a version 4 GUID for me.)   
   >   
   > It's not the EFI partition table that makes the issue go away.  It's   
   > actual EFI firmware that makes it go away.  EFI firmware has a boot   
   > manager and (FAT) filesystem driver built in, and bootstraps by loading   
   > boot loaders from ordinary disc files in (FAT) disc volumes, so the   
   > whole idea of bootstrapping by loading a boot record from a fixed   
   > postition on a disc goes away.  *That* is when we stop worrying about   
   > GRUB and its MBR virus behaviour.  Ironically, however, it's also when   
   > we stop worrying about having add-on boot managers like GRUB in the   
   > first place.  (-:   
      
   Some answers to some similar questions I asked on the grub list   
   http://lists.gnu.org/archive/html/help-grub/2011-01/msg00017.html   
      
   --- Internet Rex 2.31   
    * Origin: http://groups.google.com (1:261/20.999)