Gecko/20101207 Thunderbird/3.1.7   
   s2.misc,comp.os.os2.setup.storage,comp.os.linux.setup   
   UTC)   
   .os.os2.ecomstation:852 comp.os.os2.misc:2886 comp.os.os2.setup.storage:364   
   comp.os.linux.setup:7755   
   From: Jonathan de Boyne Pollard    
      
   >>> This may be related: http://bugs.ecomstation.nl/view.php?id=2914   
   >>>   
   >> Seems that I can't view the bug without an eCS userid.   
   >>   
   > You don't have one? Well, most of the same info is available in the    
   > same user's Ubuntu bug report:   
   > https://bugs.launchpad.net/ubuntu/+bug/669459   
   >   
   > He also observes that it writes into the Windows partition as well...   
   >   
      
   I've identified two things being adjusted.   
      
   The secondary MBR in relative block #0 of an extended partition is being    
   modified.  The modifications are essentially twofold.  The IBM    
   extensions to the partition table, containing the 8-character partition    
   name and "bootable" flag, are being zeroed out wholesale.  And the start    
   block numbers of the contained partition entries are being reduced by 61    
   (0x3D), reducing the first, for example, from 63 to 2.  The added    
   information in block #1 that we can see from the diff is actually the    
   LVM information, moved from block #62 of the container to block #1.   
      
   The primary MBR in absolute block #0 is being modified.  The    
   modifications are to the fourth entry in the partition table.  Its start    
   position is being increased by 0x3D and its length is being decreased by    
   0x3D.  It's a fairly easy deduction that the fourth entry is the    
   extended (type 0x0F) container partition.   
      
   So what's essentially happening here is that something in Ubuntu's    
   installation procedure is reclaiming unused free space by resizing a    
   type 0x0F container, squeezing the secondary MBR right up against the    
   LVM information instead of leaving some 62 unallocated blocks in    
   between. This is actually a good thing.  The idea that partitions have    
   to be track aligned to the geometry used at the INT 13h interface,    
   whence this track's-worth of wasted space comes from, has been a    
   nonsense for almost two decades at this point.  Ubuntu's partitioning    
   utility is allowing the space that the bogus alignment wastes to be    
   potentially reclaimed.  Here are the holes comprising the wasted space    
   caused by this nonsense on one of my hard discs:   
      
   >  [C:\]dasdpart /c free /efi- 0   
   >  There are 12 areas of free space on the disc.   
   >   
   >                  5           62           58   29.0KiB   
   >              32131        32192           62   31.0KiB   
   >            4225096      4225157           62   31.0KiB   
   >           12627091     12627152           62   31.0KiB   
   >           21013021     21013082           62   31.0KiB   
   >           37800946     37801007           62   31.0KiB   
   >           54588871     54588932           62   31.0KiB   
   >           71376796     71376857           62   31.0KiB   
   >           88164721     88164782           62   31.0KiB   
   >          104952646    104952707           62   31.0KiB   
   >          121740571    121740632           62   31.0KiB   
   >          138528495    321669494    183141000   87.3GiB   
   >   
      
      
   (Yes, M. Hemsley, if you are reading:  That's the DASDPART that I just    
   pointed you to.)   
      
   The true culprit is really LVM.  It cannot find its metadata in block    
   #62 any longer, because, although it is at the same physical location on    
   the disc the container partition has been repositioned around it,    
   renumbering the relative blocks within the containers.  So block #62 is    
   now numbered block #1.  Clearly LVM doesn't look there.  (What the exact    
   algorithm it uses for locating its metadata is unknown.  I've seen    
   various educated guesses over the years, including "last sector on the    
   same track as the secondary MBR", which is probably really, in the code,    
   "add Geometry.SectorsPerTrack-1 to the block number", which is not    
   quite, in the modern age of non-aligned partitions, the same thing.  It    
   could also be "the block before the first block of the contained    
   secondary partition", but the fact that LVM is going wrong here when the    
   actual positions of the partitions and the positions and content of the    
   LVM data structure on disc have not changed, seems to rule that out.)     
   It's as I said before: IBM's LVM didn't follow in the wise footsteps of    
   IBM's BootManager (and various other people's dynamic disc management    
   data structures, including Microsoft's) and the chickens have now come    
   home to roost.  The wasted space is no longer present, there's no    
   unallocated 62 blocks to play with, and the idea that one can just go    
   ahead and use that space assuming a (non-existent) guarantee that it    
   will always be a specific number of sectors, breaks.   
      
   What's happening in the type 0x07 partitions is unknown.  The block    
   numbers supplied by M. Kluge are large and essentially meaningless.  For    
   all we know, that could be something benign, such as updating the last    
   accessed timestamp on the root directory MFT entry of an NTFS volume or    
   updating the last CHKDSK timestamp in the superblock of an HPFS volume.     
   Whatever it is, it is unrelated to the LVM problem, and possibly is a    
   side-effect of something completely different in the installation    
   process (such as the installation utility automatically mounting all    
   available disc volumes, for example).   
      
   You'll probably want to direct M. Kluge to this diagnosis.   
      
   --- Internet Rex 2.31   
    * Origin: virginmedia.com (1:261/20.999)