Re: RFC: future size of embed area in partition labels
On Mon, Nov 22, 2010 at 01:59:36PM +0100, Robert Millan wrote:
> 2010/11/18 Colin Watson <cjwatson@debian.org>:
> > (Obviously, we can only control the size of the embedding area when
> > we're creating the partition table from scratch; trying to move existing
> > operating systems around transparently is bad karma. I trust you're not
> > talking about situations where the partition table already exists.)
>
> Yes and no. ISTR if the partition table already exists, BUT user
> requested to use "the whole disk" for installation, the result is
> still a small embed area. I'll recheck.
That's definitely not as expected.
> > Windows' policy, as I understand it, is to support GPT only when booting
> > from UEFI, which is only supported in Windows 64.
>
> A huge mistake if you ask me, but well, it's their problem. It
> just bothers me that this will artificially push EFI after it failed
> to gain acceptance by its own merit during the last 10 years.
I agree it's a mistake in Windows, but regarding UEFI acceptance, it
does depend on how you look at it. My understanding is that well over
half [1] the systems distributed over the last couple of years use UEFI
with a compatibility layer to implement their BIOS (so UEFI is more
often than not there but invisible), and that traditional BIOS
implementations are well on their way to dying out. Of course I'm sure
the answers depend on whom you talk to, since it seems as though nobody
keeps very authoritative track of the numbers.
[1] I forget the exact numbers and can't find the reference, so take
this as you will, but it was something along those lines.
> > Let's just dig into the reason why the embedding area is small in the
> > cases you've seen. I suspect that it may just be a simple bug, and
> > won't require policy changes to fix.
>
> I'm short on time currently but I'll hopefully be able to do this
> before the release.
Aren't we all :-) Thanks.
--
Colin Watson [cjwatson@debian.org]
Reply to: