sfdisk: -X option doesn't work

sfdisk: -X option doesn't work

[Constantine Kharlamov]

I've a disk that been GPT-formatted before, but now there's just MBR:

	$ sudo sfdisk -l /dev/sdc     
	Disk /dev/sdc: 14.9 GiB, 16025444352 bytes, 31299696 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: 0x79215d34

	Device     Boot Start      End  Sectors  Size Id Type
	/dev/sdc1        2048 31299695 31297648 14.9G 83 Linux

Fine, but magically, both "/dev/disk/by-label/" and lsblk shows names/labels that been there before the disk reformatted into MBR!

	$ sudo lsblk -o name,mountpoint,label,size,uuid /dev/sdc
	NAME   MOUNTPOINT LABEL               SIZE UUID
	sdc               Ubuntu 15.10 amd64 14.9G 2015-10-21-16-17-40-00
	└─sdc1            Ubuntu 15.10 amd64 14.9G 502229b0-6d02-46ee-8fd1-b3321f11e53f

It causes errors with grub-install like "Attempting to install GRUB to a disk with multiple partition labels.  This is not supported yet..". So I want to just remove those names. But "sgdisk" sees that GPT table is invalid, and tries to reconstruct it from MBR, whilst I'd need to force it into thinking like it is valid, so that it see the damn names.

Thankfully, there's sfdisk with -X option:

	$ sudo sfdisk -lX gpt /dev/sdc 
	Disk /dev/sdc: 14.9 GiB, 16025444352 bytes, 31299696 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: 0x79215d34

	Device     Boot Start      End  Sectors  Size Id Type
	/dev/sdc1        2048 31299695 31297648 14.9G 83 Linux

It worked… Or not? "Disklabel" says "dos", and most importantly, I see no partition names.

Turns out, sfdisk would print the same information for pretty much anything, i.e. even for "sfdisk -X foo", so the option just doesn't work.

Re: sfdisk: -X option doesn't work

[Karel Zak]

On Sat, Nov 19, 2016 at 01:58:30PM +0300, Constantine Kharlamov wrote:
> I've a disk that been GPT-formatted before, but now there's just MBR:
> 
> 	$ sudo sfdisk -l /dev/sdc     
> 	Disk /dev/sdc: 14.9 GiB, 16025444352 bytes, 31299696 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: 0x79215d34
> 
> 	Device     Boot Start      End  Sectors  Size Id Type
> 	/dev/sdc1        2048 31299695 31297648 14.9G 83 Linux
> 
> Fine, but magically, both "/dev/disk/by-label/" and lsblk shows
> names/labels that been there before the disk reformatted into MBR!

/dev/disk/by-label, LABEL and UUID are *filesystem* identifiers. The
filesystem (partition content) and partition table are two independent
things.

If the partition (after conversion from GPT to MBR) starts still on
the same offset that the filesystem is still valid and identifiers
still visible for the system.

> 
> 	$ sudo lsblk -o name,mountpoint,label,size,uuid /dev/sdc
> 	NAME   MOUNTPOINT LABEL               SIZE UUID
> 	sdc               Ubuntu 15.10 amd64 14.9G 2015-10-21-16-17-40-00
> 	└─sdc1            Ubuntu 15.10 amd64 14.9G 502229b0-6d02-46ee-8fd1-b3321f11e53f
> 
> It causes errors with grub-install like "Attempting to install GRUB
> to a disk with multiple partition labels.  This is not supported
> yet..". 

You can try wipefs(8) to see what is on the sdc and sdc1. (BTW, the LABEL
for sdc seems strange.)

And you can use wipefs to remove obsolete GPT signature if there is
still for example backup GPT label. (Be careful, you can lost data on
the disk, don't use wipefs -a)

> So I want to just remove those names. But "sgdisk" sees that GPT
> table is invalid, and tries to reconstruct it from MBR, whilst I'd
> need to force it into thinking like it is valid, so that it see the
> damn names.
> 
> Thankfully, there's sfdisk with -X option:

-X overrides default (MBR) or the current label type when you create
a new partition table, it has no effect for --list.

fdisk provides --type <name> that forces the util to use (e.g. print)
specified label, for example:

  fdisk --list --type dos /dev/sdc

> 	$ sudo sfdisk -lX gpt /dev/sdc 
> 	Disk /dev/sdc: 14.9 GiB, 16025444352 bytes, 31299696 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: 0x79215d34
> 
> 	Device     Boot Start      End  Sectors  Size Id Type
> 	/dev/sdc1        2048 31299695 31297648 14.9G 83 Linux
> 
> It worked… Or not? "Disklabel" says "dos", and most importantly, I see no partition names.

It is not partition name, but filesystem identifier. sfdisk does not
list this stuff. (See cfdisk, it reads filesystem stuff.)

    Karel

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

Re: sfdisk: -X option doesn't work

[Constantine Kharlamov]

02.12.2016, 15:19, "Karel Zak" <kzak@redhat.com>:
>   On Sat, Nov 19, 2016 at 01:58:30PM +0300, Constantine Kharlamov wrote:
>>    I've a disk that been GPT-formatted before, but now there's just MBR:
>>
>>            $ sudo sfdisk -l /dev/sdc
>>            Disk /dev/sdc: 14.9 GiB, 16025444352 bytes, 31299696 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: 0x79215d34
>>
>>            Device Boot Start End Sectors Size Id Type
>>            /dev/sdc1 2048 31299695 31297648 14.9G 83 Linux
>>
>>    Fine, but magically, both "/dev/disk/by-label/" and lsblk shows
>>    names/labels that been there before the disk reformatted into MBR!
>
>   /dev/disk/by-label, LABEL and UUID are *filesystem* identifiers. The
>   filesystem (partition content) and partition table are two independent
>   things.
>
>   If the partition (after conversion from GPT to MBR) starts still on
>   the same offset that the filesystem is still valid and identifiers
>   still visible for the system.
>
>>            $ sudo lsblk -o name,mountpoint,label,size,uuid /dev/sdc
>>            NAME MOUNTPOINT LABEL SIZE UUID
>>            sdc Ubuntu 15.10 amd64 14.9G 2015-10-21-16-17-40-00
>>            └─sdc1 Ubuntu 15.10 amd64 14.9G 502229b0-6d02-46ee-8fd1-b3321f11e53f
>>
>>    It causes errors with grub-install like "Attempting to install GRUB
>>    to a disk with multiple partition labels. This is not supported
>>    yet..".
>
>   You can try wipefs(8) to see what is on the sdc and sdc1. (BTW, the LABEL
>   for sdc seems strange.)
>
>   And you can use wipefs to remove obsolete GPT signature if there is
>   still for example backup GPT label. (Be careful, you can lost data on
>   the disk, don't use wipefs -a)


Beforehands, the problem have been solved by removing the iso9660 filesystem by offset. Back then the question have been asked on forum https://bbs.archlinux.org/viewtopic.php?pid=1670463 so I still have an output of wipefs's POV:

        $ sudo wipefs -n /dev/sdc
        offset type
        ----------------------------------------------------------------
        0x1fe PMBR [partition table]

        0x8001 iso9660 [filesystem]
                                                 LABEL: Ubuntu 15.10 amd64
                                                 UUID: 2015-10-21-16-17-40-00

I'm still curious about what happened though. α) iso9660 resides (offset 0x8001) faar inside the real (i.e. by MBR) filesystem (having offset 2048 ≅ 0x800). Hence, given the system shows the label of iso9660, the system (together with most partition utilities) assumed that sdc is using GPT. But β) I removed GPT completely with gdisk (expert command → wipe out GPT), so unless gdisk is buggy, it couldn't have happened!

To add even more confusion, there's γ) if the system assumed sdc is GPT formatted, the sdc1 should've been iso9660 rather than the actual ext4, and upon mounting sdc1 I should've been getting damaged iso9660 instead of absolutely fine ext4 with Archlinux.

>>    So I want to just remove those names. But "sgdisk" sees that GPT
>>    table is invalid, and tries to reconstruct it from MBR, whilst I'd
>>    need to force it into thinking like it is valid, so that it see the
>>    damn names.
>>
>>    Thankfully, there's sfdisk with -X option:
>
>   -X overrides default (MBR) or the current label type when you create
>   a new partition table, it has no effect for --list.
>
>   fdisk provides --type <name> that forces the util to use (e.g. print)
>   specified label, for example:
>
>     fdisk --list --type dos /dev/sdc

Ah, thank you, I see. It's not actually obvious that "disklabels" (from the manual) is a type of partition table (e.g. dos vs gpt). If you wouldn't say, I would've never guessed, even though I've read quite much for trying to fix the thing. Perhaps, would it be worth to change the wording in manual to mention partition table in some way. I don't know if it's fine, but e.g.:

	-t, --type type
				  Enable support only for disklabels (partition tables) of the specified type, and disable support for all other types.

"disklabels" alone sounds to me like, well, labels, which e.g. GPT allowed to have in a filesystem-independent way (though "dos" didn't, but that still does not reveal the purpose, rather confuses). I am not sure how widely the term is used, but I'd even remove it, or at least to try to diminish the significance of the word in the sentence, like "…partition tables (aka disklabels)…".

Re: sfdisk: -X option doesn't work

[Karel Zak]

On Sun, Dec 04, 2016 at 09:43:41AM +0300, Constantine Kharlamov wrote:
> Beforehands, the problem have been solved by removing the iso9660
> filesystem by offset. Back then the question have been asked on
> forum https://bbs.archlinux.org/viewtopic.php?pid=1670463 so I still
> have an output of wipefs's POV:
> 
>         $ sudo wipefs -n /dev/sdc
>         offset type
>         ----------------------------------------------------------------
>         0x1fe PMBR [partition table]
 
GPT is always

   (protective) MBR + GPT header

the MBR is there to keep the disk used and full for old partitioning
tools that do not have a clue about GPT. MBR in this case contains
one partition (type 0xee) for all disk. For example my disk:

        # fdisk -l /dev/sda
        Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 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: E471810B-5954-48E6-B4F0-5D369ADCC514

        Device         Start       End   Sectors   Size Type
        /dev/sda1       2048    411647    409600   200M EFI System
        /dev/sda2     411648    821247    409600   200M Linux filesystem
        /dev/sda3     821248 274087935 273266688 130.3G Linux filesystem
        /dev/sda4  274087936 378945535 104857600    50G Linux filesystem
        /dev/sda5  378945536 452476927  73531392  35.1G Linux filesystem
        /dev/sda6  452476928 468860927  16384000   7.8G Linux swap

but if you disable GPT and enable MBR only:

        # fdisk --type mbr -l /dev/sda
        Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 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   Sectors   Size Id Type
        /dev/sda1           1 468862127 468862127 223.6G ee GPT


>         0x8001 iso9660 [filesystem]
>                                                  LABEL: Ubuntu 15.10 amd64
>                                                  UUID: 2015-10-21-16-17-40-00
> 
> I'm still curious about what happened though. α) iso9660 resides
> (offset 0x8001) faar inside the real (i.e. by MBR) filesystem
> (having offset 2048 ≅ 0x800). Hence, given the system shows the
> label of iso9660, the system (together with most partition
> utilities) assumed that sdc is using GPT. But β) I removed GPT
> completely with gdisk (expert command → wipe out GPT), so unless
> gdisk is buggy, it couldn't have happened!

Seems like a crazy boot image that distros generate to be bootable on
all possible situations. If yes, then don't waste time to try
understand what the begin of the image means :-) It's almost always
total mess where multiple stuff (iso, MBR, etc.) share the area.

    Karel

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