Text 2763, 95 rader
Skriven 2011-02-12 16:48:15 av Jonathan de Boyne Pollard
Ärende: Re: Ubuntu installation modifies the partition table rendering IBM LVM 
===============================================================================
Gecko/20101207 Thunderbird/3.1.7
comp.os.linux.misc,comp.os.os2.ecomstation,comp.os.os2.misc,comp.os.os2.setup.storage,comp.os.linux.setup

UTC)
comp.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 <J.deBoynePollard-newsgroups@NTLWorld.COM>

>> 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)