Gecko/20101207 Thunderbird/3.1.7   
   s2.misc,comp.os.os2.setup.storage,comp.os.linux.setup   
   UTC)   
   .os.os2.ecomstation:854 comp.os.os2.misc:2888 comp.os.os2.setup.storage:365   
   comp.os.linux.setup:7756   
   From: Jonathan de Boyne Pollard    
      
   >> 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 to http://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.  (-:   
      
      
   --- Internet Rex 2.31   
    * Origin: virginmedia.com (1:261/20.999)