public inbox for util-linux@vger.kernel.org
 help / color / mirror / Atom feed
* ***Urgent***!  Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :(
@ 2013-10-09 11:23 Craig
  2013-10-09 14:16 ` Karel Zak
  0 siblings, 1 reply; 8+ messages in thread
From: Craig @ 2013-10-09 11:23 UTC (permalink / raw)
  To: util-linux

Greetings,

Sorry if this isn't the place, but curiously, I could find no 
bug-reporting info in the documentation, and definitely I consider this 
one a bug!  Adding experimental GPT support to fdisk has completely broken 
its ability to read the MBR for a hybrid partitioning scheme.  To be 
blunt, I don't see the point in fdisk GPT support in any case; gdisk does 
a *vastly* better job, and appears to be mature.  At the least however, 
there needs urgently to be a means by which GPT can be disabled 
(command-line switch?) or by which fdisk can be forced to read an existing 
MBR under _any_ circumstances.

On a related note, fdisk cannot differentiate between lower and upper-case 
command input (e.g., `G' vs. `g' is rather pointless as things stand).

Cheerio,
Craig

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ***Urgent***!  Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :(
  2013-10-09 11:23 ***Urgent***! Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :( Craig
@ 2013-10-09 14:16 ` Karel Zak
  2013-10-10  0:39   ` Craig
  0 siblings, 1 reply; 8+ messages in thread
From: Karel Zak @ 2013-10-09 14:16 UTC (permalink / raw)
  To: Craig; +Cc: util-linux

On Wed, Oct 09, 2013 at 10:23:13PM +1100, Craig wrote:
> Sorry if this isn't the place, but curiously, I could find no bug-reporting
> info in the documentation, and definitely I consider this one a bug!  Adding
> experimental GPT support to fdisk has completely broken its ability to read
> the MBR for a hybrid partitioning scheme.  To be blunt, I don't see the

It's more generic problem, we ignore MBR for hybrid GPT on more
places (for example in kernel and libblkid).

(Just for the record, hybrid GPT is ugly non-standard hack.)

> point in fdisk GPT support in any case; gdisk does a *vastly* better job,
> and appears to be mature.  At the least however, there needs urgently to be
> a means by which GPT can be disabled (command-line switch?) or by which
> fdisk can be forced to read an existing MBR under _any_ circumstances.

Seems like a good idea to have a way how to modify protective or hybrid
MBR on GPR devices.
 
    	# fdisk -l /dev/sda
    
    	Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
    	Units: sectors of 1 * 512 = 512 bytes
    	Sector size (logical/physical): 512 bytes / 512 bytes
    	I/O size (minimum/optimal): 512 bytes / 512 bytes
    	Disklabel type: gpt
    	Disk identifier: 3549290F-417C-4941-8503-F7835109B821
    
    	Device           Start          End   Size Type
    	/dev/sda1         2048      2050047  1000M EFI System
    	/dev/sda2      2050048      6146047     2G Microsoft basic data
    	/dev/sda3      6146048     26462207   9.7G Linux swap
    	/dev/sda4     26462208     98142207  34.2G Microsoft basic data
    	/dev/sda5     98142208    230662143  63.2G Microsoft basic data
    	/dev/sda6    230662144    312580095  39.1G Microsoft basic data
    
but when GPT is disabled we can access PMBR:
    
    	# fdisk -l -t dos /dev/sda
    
    	Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
    	Units: sectors of 1 * 512 = 512 bytes
    	Sector size (logical/physical): 512 bytes / 512 bytes
    	I/O size (minimum/optimal): 512 bytes / 512 bytes
    	Disklabel type: dos
    	Disk identifier: 0x00000000
    
    	Device    Boot Start       End    Blocks  Id System
    	/dev/sda1          1 312581807 156290903+ ee GPT
    
> On a related note, fdisk cannot differentiate between lower and upper-case
> command input (e.g., `G' vs. `g' is rather pointless as things stand).

 This is already fixed in git tree.

 .. all will be in v2.24-rc2. Thanks.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ***Urgent***!  Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :(
  2013-10-09 14:16 ` Karel Zak
@ 2013-10-10  0:39   ` Craig
  2013-10-10 11:10     ` Karel Zak
  0 siblings, 1 reply; 8+ messages in thread
From: Craig @ 2013-10-10  0:39 UTC (permalink / raw)
  To: Karel Zak; +Cc: util-linux

On Wed, 9 Oct 2013, Karel Zak <kzak@redhat.com> wrote:

[...]

> It's more generic problem, we ignore MBR for hybrid GPT on more
> places (for example in kernel and libblkid).

That's fine and fair enough, but fdisk *really* does need to be able to 
bypass GPT when necessary.

> (Just for the record, hybrid GPT is ugly non-standard hack.)

Oh, I'm perfectly aware of that. :D I'm using it to force Win7 to 
dual-boot via BIOS (as opposed to UEFI) whilst having GPT partitioning for 
Linux and OSX.  Basically, GPT set up as it should be, and a hybrid MBR 
set up specifically to trick Micro$oft's garbage into booting, since it 
refuses to boot from GPT with UEFI disabled.

[...]

>    	# fdisk -l /dev/sda

>    	Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
>    	Units: sectors of 1 * 512 = 512 bytes
>    	Sector size (logical/physical): 512 bytes / 512 bytes
>    	I/O size (minimum/optimal): 512 bytes / 512 bytes
>    	Disklabel type: gpt
>    	Disk identifier: 3549290F-417C-4941-8503-F7835109B821

>    	Device           Start          End   Size Type
>    	/dev/sda1         2048      2050047  1000M EFI System
>    	/dev/sda2      2050048      6146047     2G Microsoft basic data
>    	/dev/sda3      6146048     26462207   9.7G Linux swap
>    	/dev/sda4     26462208     98142207  34.2G Microsoft basic data
>    	/dev/sda5     98142208    230662143  63.2G Microsoft basic data
>    	/dev/sda6    230662144    312580095  39.1G Microsoft basic data

> but when GPT is disabled we can access PMBR:

>    	# fdisk -l -t dos /dev/sda

>    	Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
>    	Units: sectors of 1 * 512 = 512 bytes
>    	Sector size (logical/physical): 512 bytes / 512 bytes
>    	I/O size (minimum/optimal): 512 bytes / 512 bytes
>    	Disklabel type: dos
>    	Disk identifier: 0x00000000

>    	Device    Boot Start       End    Blocks  Id System
>    	/dev/sda1          1 312581807 156290903+ ee GPT

Yes; _exactly_ what is needed, plus IMO a switch from within fdisk's menu 
system (Expert?) that would allow switching between GPT and MBR (or 
anything else that might be present).

Cheerio,
Craig

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ***Urgent***!  Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :(
  2013-10-10  0:39   ` Craig
@ 2013-10-10 11:10     ` Karel Zak
  2013-10-11  3:45       ` Craig
  0 siblings, 1 reply; 8+ messages in thread
From: Karel Zak @ 2013-10-10 11:10 UTC (permalink / raw)
  To: Craig; +Cc: util-linux

On Thu, Oct 10, 2013 at 11:39:36AM +1100, Craig wrote:
> Yes; _exactly_ what is needed, plus IMO a switch from within fdisk's menu
> system (Expert?) that would allow switching between GPT and MBR (or anything
> else that might be present).

 Yes, but now (for v2.24) it's too late. I'd like to have a more
 robust way to switch between GPT and MBR modification. (I already
 have some patches, but it still requires some work.)

 Note that in v2.24 the GPT code in fdisk does not allow to write hybrid
 GPT, the support is read-only.

   Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ***Urgent***!  Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :(
  2013-10-10 11:10     ` Karel Zak
@ 2013-10-11  3:45       ` Craig
  2013-10-11  9:04         ` Karel Zak
  0 siblings, 1 reply; 8+ messages in thread
From: Craig @ 2013-10-11  3:45 UTC (permalink / raw)
  To: Karel Zak; +Cc: util-linux

On Thu, 10 Oct 2013, Karel Zak <kzak@redhat.com> wrote:

> Note that in v2.24 the GPT code in fdisk does not allow to write hybrid
> GPT, the support is read-only.

Hmm; not good for the long term.  Although a hack and potentially 
disastrous if not handled carefully, hybrid MBR really is necessary under 
certain conditions.  Perhaps support should be read-only by default, with 
a means to switch to write, and dire warnings that one is likely severely 
to break things if one isn't careful?  Although it could be argued that 
those likely to be playing with fdisk (rather e.g. than Partid) might be 
expected to know what they're doing. :D To be honest, I'd like to see a 
means completely to separate GPT/MBR changes, so if necessary one could do 
absolutely anything to either without affecting the other.  If somebody is 
playing around with both, then really they should expect to understand 
what will happen if they're careless.

Craig

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ***Urgent***!  Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :(
  2013-10-11  3:45       ` Craig
@ 2013-10-11  9:04         ` Karel Zak
  2013-10-11 21:34           ` Craig
  2013-11-24 18:18           ` H. Peter Anvin
  0 siblings, 2 replies; 8+ messages in thread
From: Karel Zak @ 2013-10-11  9:04 UTC (permalink / raw)
  To: Craig; +Cc: util-linux

On Fri, Oct 11, 2013 at 02:45:57PM +1100, Craig wrote:
> On Thu, 10 Oct 2013, Karel Zak <kzak@redhat.com> wrote:
> 
> >Note that in v2.24 the GPT code in fdisk does not allow to write hybrid
> >GPT, the support is read-only.
> 
> Hmm; not good for the long term.  Although a hack and potentially disastrous

 It's temporary solution. 
 
 The long term goal is to support *manual* protective/hybrid MBR
 modification. 
 
 It means that user will be able in expert mode switch to MBR, modify and 
 write MBR to the device and then switch back to GPT. The GPT driver will 
 only print warning, but no overwrite the manually modified MBR.

> if not handled carefully, hybrid MBR really is necessary under certain
> conditions.  Perhaps support should be read-only by default, with a means to
> switch to write, and dire warnings that one is likely severely to break
> things if one isn't careful?  Although it could be argued that those likely
> to be playing with fdisk (rather e.g. than Partid) might be expected to know
> what they're doing. :D To be honest, I'd like to see a means completely to
> separate GPT/MBR changes, so if necessary one could do absolutely anything
> to either without affecting the other.  If somebody is playing around with
> both, then really they should expect to understand what will happen if
> they're careless.

 Yep. I don't want any "smart" solution there. All will be controlled
 by users. 
 
 (Well, in the default mode for non-expert users with standard PMBR we will 
  generate the MBR as expected by UEFI specification of course.)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ***Urgent***!  Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :(
  2013-10-11  9:04         ` Karel Zak
@ 2013-10-11 21:34           ` Craig
  2013-11-24 18:18           ` H. Peter Anvin
  1 sibling, 0 replies; 8+ messages in thread
From: Craig @ 2013-10-11 21:34 UTC (permalink / raw)
  To: Karel Zak; +Cc: util-linux

On Fri, 11 Oct 2013, Karel Zak <kzak@redhat.com> wrote:

[...]

> Yep. I don't want any "smart" solution there. All will be controlled
> by users.

> (Well, in the default mode for non-expert users with standard PMBR we will
>  generate the MBR as expected by UEFI specification of course.)

Ah, splendid; glad to hear that.  Then for the moment I'll simply make a 
temporary RPM package with the pre-GPT fdisk; that will do for my 
situation.  I'd rather not faff around with a custom util-linux RPM, 
either which would break updates or not get updated at all.  A separate 
fdisk RPM will do for the moment and will solve my hybrid MBR problem. :)

Cheerio,
Craig

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ***Urgent***!  Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :(
  2013-10-11  9:04         ` Karel Zak
  2013-10-11 21:34           ` Craig
@ 2013-11-24 18:18           ` H. Peter Anvin
  1 sibling, 0 replies; 8+ messages in thread
From: H. Peter Anvin @ 2013-11-24 18:18 UTC (permalink / raw)
  To: Karel Zak, Craig; +Cc: util-linux

On 10/11/2013 02:04 AM, Karel Zak wrote:
> 
>  Yep. I don't want any "smart" solution there. All will be controlled
>  by users. 
>  
>  (Well, in the default mode for non-expert users with standard PMBR we will 
>   generate the MBR as expected by UEFI specification of course.)
> 

There is one other useful mode for non-expert users, which is the one in
which the current (hybrid) boot partition is manifest in the MBR (as
well as as the GPT of course.)  Changing the hybrid boot partition would
change the MBR to match.  From a UI perspective this could very easily
be done by setting or removing a "hybrid" flag on a partition.

One could potentially allow more than one hybrid partition, but when one
then accounts for PMBR partitions, there is no guarantee that one can
fit more than one unless the layout is suitable.

In the worst case, one can always fit one:

MBR:	1. Leading PMBR partition
	2. Hybrid boot partition
	3. Tailing PMBR partition

In the best case, one can fit 3:

MBR:	1. Hybrid partition 1
	2. Hybrid partition 2
	3. Hybrid partition 3
	4. Tailing PMBR partition

	-hpa

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-11-24 18:18 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-09 11:23 ***Urgent***! Fdisk: GPT support utterly breaks hybrid MBR; *must* have disable option! :( Craig
2013-10-09 14:16 ` Karel Zak
2013-10-10  0:39   ` Craig
2013-10-10 11:10     ` Karel Zak
2013-10-11  3:45       ` Craig
2013-10-11  9:04         ` Karel Zak
2013-10-11 21:34           ` Craig
2013-11-24 18:18           ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox