798279ab   
   GMT)   
   posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui   
   .os.os2.setup.storage:366 comp.os.os2.misc:2892   
   From: rusi    
      
   On Feb 12, 7:48 pm, Jonathan de Boyne Pollard  wrote:   
   > >>> 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.   
      
      
   I asked a similar/related question on the grub list   
   Maybe some of the answers help?   
   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)