Text 2772, 94 rader
Skriven 2011-02-12 20:29:19 av rusi
Ärende: Re: Ubuntu installation modifies the partition table rendering IBM LVM 
===============================================================================
d765f14
GMT)
posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui
comp.os.os2.setup.storage:367 comp.os.os2.misc:2897
From: rusi <rustompmody@gmail.com>

On Feb 12, 9:48 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
newsgro...@NTLWorld.COM> 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)