Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sfdisk -A /dev/disk reports wrong partition number and ignores GPT/MBR inconsistencies #699

Closed
aruiz opened this issue Oct 2, 2018 · 14 comments

Comments

Projects
None yet
2 participants
@aruiz
Copy link

commented Oct 2, 2018

Say we have a hybrid GPT/MBR setup:
The GPT has only one partition.
The MBR has two partitions, one that maps the GPT block and a second one that maps to an actual GPT partition geometry and is marked as bootable/active.

This would look like /dev/loop0 and /dev/loop0p1 in /dev

However if you do sfdisk -A /dev/loop0 to list active/bootable partitions you'd get:
/dev/loop0p2

As a user I would expect sfdisk would return the actual existing partition from the GPT rather than the hidden MBR one (and fail if the MBR partition has an inconsistent geometry with the GPT one).

@aruiz aruiz changed the title sfdisk -A /dev/disk reports wrong partition number sfdisk -A /dev/disk reports wrong partition number and ignores GPT/MBR inconsistencies Oct 3, 2018

@aruiz

This comment has been minimized.

Copy link
Author

commented Oct 3, 2018

I'm attaching two sample disk images you can dump to a usb drive or attach as raw images to a VM:

The first one is a valid hybrid GPT/MBR setup that shows the problem above.

hybrid.zip

The second has an invalid MBR with an active partition that does not map to the GPT, however it still shows the active GPT partition as the output for sfdisk -A even though the MBR table is invalid.
brokenhybrid.zip

karelzak added a commit that referenced this issue Oct 4, 2018

sfdisk: be more verbose about PMBR on --activate
Addresses: #699
Signed-off-by: Karel Zak <kzak@redhat.com>
@karelzak

This comment has been minimized.

Copy link
Owner

commented Oct 4, 2018

It's feature. The command --activate works with MBR and pMBR only. If GPT is detected then it enters nested pMBR and do activation on this PT.

It seems we need to be more verbose about it in the man page and --help output. I'll improve it.

Note that fdisks do not care about hybrid MBR and GPT mapping, you have to do it manually in fdisk ('M' command) or by sfdisk --label-nested. It is not planned anything more for hybrid MBR as it's broken by design.

@karelzak karelzak closed this Oct 4, 2018

@karelzak

This comment has been minimized.

Copy link
Owner

commented Oct 4, 2018

Improved version:

# sfdisk -A /dev/loop0
Activation is unsupported for GPT -- entering nested PMBR.
/dev/loop0p2
@aruiz

This comment has been minimized.

Copy link
Author

commented Oct 4, 2018

If hybrid it's not suported I think it should fail. Problem with a warning is that in scripts those go to stderr and sfdisk would still return 0 and a /dev device in stdout which might not exists, or worse, map to a device that the user might not want to mess with (for example, windows partitions are the ones marked as active, your windows partition might be /dev/sda1 and linux data in /dev/sdb2 and sfdisk will report /dev/sdb2 which might lead to users wiping data in the wrong partition). I honestly think we should fail (return != 0) on unsupported scenarios rather than report potentially wrong data. Falling back to PMBR will almost always report the wrong /dev/ entry

karelzak added a commit that referenced this issue Oct 4, 2018

sfdisk: disable --activate for Hybrid GPT/MBR
Addresses: #699
Signed-off-by: Karel Zak <kzak@redhat.com>
@karelzak

This comment has been minimized.

Copy link
Owner

commented Oct 4, 2018

Set boot flag (activation) on PMBR is supported and expected scenario.

The problem is that sfdisk does not differentiate between Protective MBR or Hybrid MBR. You're right that for Hybrid MBR it would be better to return error and do nothing.

@karelzak

This comment has been minimized.

Copy link
Owner

commented Oct 4, 2018

For your use-case:

# sfdisk -A /dev/loop0; echo $?
sfdisk: toggle boot flags is unsupported for Hybrid GPT/MBR
1
@karelzak

This comment has been minimized.

Copy link
Owner

commented Oct 4, 2018

Note that in fdisk you can do manually what you want with PMBR or HybridMBR.

@aruiz

This comment has been minimized.

Copy link
Author

commented Oct 4, 2018

Note that in fdisk you can do manually what you want with PMBR or HybridMBR.

Can I do that using a script or calling it from Python or would I need to ccreate a chat script to get to what I want? I need parseable output

@aruiz

This comment has been minimized.

Copy link
Author

commented Oct 4, 2018

For your use-case:

# sfdisk -A /dev/loop0; echo $?
sfdisk: toggle boot flags is unsupported for Hybrid GPT/MBR
1

Is this the result of a fix or the current behaviour?

@aruiz

This comment has been minimized.

Copy link
Author

commented Oct 4, 2018

Is this the result of a fix or the current behaviour?

Nevermind, I just saw commit a77bd80.

I'm sorry to ask, but would it be so bad to add support to check that partition is not of mbr type 0xee and has a matching geometry in the GPT?

The reason I insist is because I'm really left with no choice but to write my own partial MBR and GPT parser in Python.

I'm trying to replace os-prober with something faster and more robust that does not mount volumes and uses userland tools in read only mode to retrieve content (ntfsls and mdir to probe Windows, and e2ls...) For Windows probing I need to know which MBR partitions are boot enabled to the BIOS. I have not found a way to reliably do this from a scripting POV. I'd use libfdisk myself but no bindings for python.

@karelzak

This comment has been minimized.

Copy link
Owner

commented Oct 8, 2018

I'm sorry to ask, but would it be so bad to add support to check that partition is not of mbr type 0xee and has a matching geometry in the GPT?

The question is what should be semantic and output of the feature. I'd like to keep things as generic as possible. Do you mean something like "sfdisk --check-hybrid-gpt" and return list of matching devices?

Anyway, I can imagine simple python+json script where you will call

 # sfdisk --label-nested mbr --json  /dev/sda
 # sfdisk --json  /dev/sda

and then all you need to compare the partitions and the mapping. It should be simple and you do not need to care about PT details.

@aruiz

This comment has been minimized.

Copy link
Author

commented Oct 11, 2018

this is exactly what I was looking for, thanks a lot!

@karelzak

This comment has been minimized.

Copy link
Owner

commented Oct 15, 2018

this is exactly what I was looking for, thanks a lot!

Do you reply to "sfdisk --json" idea or to "sfdisk --check-hybrid-gpt"? :-)

@aruiz

This comment has been minimized.

Copy link
Author

commented Oct 15, 2018

The idea of using --label-nested. I was not aware that such option did that as protective/hybrid gpt isn't exactly "nested". I was assuming that was mostly useful for extended partitions and mbr(bsd).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.