GNU bug report logs - #18019
bug-parted Digest, Vol 140, Issue 9

Previous Next

To reply to this bug, email your comments to 18019 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rod Smith <rodsmith <at> rodsbooks.com>
To: bug-parted <at> gnu.org
Subject: Re: bug-parted Digest, Vol 140, Issue 9
Date: Mon, 14 Jul 2014 13:11:26 -0400

On 07/14/2014 12:01 PM, Phillip Susi <psusi <at> ubuntu.com> wrote:
>>
>> I find this logic troubling. It's rather similar to the logic that
>> lead to parted using the pre-existing Microsoft basic data GUID
>> when making Linux partitions on GPT disks; out of a pool of just
>> under infinite alternative GUIDs. "Oh it doesn't really matter" on
>> Linux, but meanwhile on dual boot systems, Windows recognizes its
>> partitiontype GUID, but not the contents of the partition, and
>> actively invites the user to reformat it.
>
> How is this at all related?  Windows already ignores 0x83.

It does with the default set of drivers. What if somebody loads a Linux 
filesystem driver, though? I don't happen to know what actually happens 
in this case, but that's (partly) the point: When you set inaccurate 
data, you can't predict what will happen with some random tool with 
which you're unfamiliar.

> Suggests?  Lieing?  To whom?  Nobody pays attention to the type codes.

The Linux kernel doesn't, but there are at least two other cases to 
consider:

* Non-kernel tools might care about the type code. In fact, Chris quoted
  the mdadm man page earlier in this thread, and it explicitly states
  that it DOES care about the type code!
* Other OSes do check the type code, and if some non-Linux driver or
  utility behaves in a particular way based on the type code, setting
  something inappropriate invites problems that we can't predict.

>   Also if you really want a different type code for raid, there already
> is one: 0xFD.

That's not what the modern version of mdadm wants, though.

In an ideal world, of course, the mdadm developers wouldn't have changed 
their tools' expectations from 0.9 to 1.0; but they did, and that means 
that the tools that actually set the partition type codes must adapt.

All that said, there is a further complication, and this one isn't 
parted's fault: The 0xDA type code that's suggested by the mdadm man 
page is NOT specific to Linux RAID. According to 
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html, it refers 
to "non-FS data"; and according to 
https://en.wikipedia.org/wiki/Partition_type, it can be that or a 
Powercopy backup. There may be other specific tools that use it, too. 
Thus, I'd be a little wary of just switching 0xFD to 0xDA as the MBR 
RAID flag in parted. IMHO, what's needed is some coordination between 
mdadm, parted, fdisk, and gdisk authors to settle on a standard for this.

-- 
Rod Smith
rodsmith <at> rodsbooks.com
http://www.rodsbooks.com

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Brian C. Lane" <bcl <at> redhat.com>
To: bug-parted <at> gnu.org
Subject: Re: bug#18019: bug-parted Digest, Vol 140, Issue 9
Date: Mon, 14 Jul 2014 12:28:17 -0700

On Mon, Jul 14, 2014 at 01:11:26PM -0400, Rod Smith wrote:
> All that said, there is a further complication, and this one isn't parted's
> fault: The 0xDA type code that's suggested by the mdadm man page is NOT
> specific to Linux RAID. According to
> http://www.win.tue.nl/~aeb/partitions/partition_types-1.html, it refers to
> "non-FS data"; and according to
> https://en.wikipedia.org/wiki/Partition_type, it can be that or a Powercopy
> backup. There may be other specific tools that use it, too. Thus, I'd be a
> little wary of just switching 0xFD to 0xDA as the MBR RAID flag in parted.
> IMHO, what's needed is some coordination between mdadm, parted, fdisk, and
> gdisk authors to settle on a standard for this.

I don't think anyone is suggesting a change to the raid flag. I was
planning on adding support for arbitrary values so that anything can be
set instead of playing whack-a-mole as things change.

The compelling reason for the change, other than just following mdadm's
suggestion is Doug's example scenario from the bz entry:

"It's possible, although it means you have a broken setup, that you
could have a version 1.1 or 1.2 superblock and a version 0.90 on the
same device, and kernel autodetect could assemble it as a version 0.90
device and corrupt the real device.  Likewise, if you use 0x83, then the
kernel filesystem and udev filesystem detection code might find
something you don't want found."

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

Message #11 received at 18019 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: Rod Smith <rodsmith <at> rodsbooks.com>, 18019 <at> debbugs.gnu.org
Subject: Re: bug#18019: bug-parted Digest, Vol 140, Issue 9
Date: Wed, 16 Jul 2014 20:31:26 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/14/2014 01:11 PM, Rod Smith wrote:
>> How is this at all related?  Windows already ignores 0x83.
> 
> It does with the default set of drivers. What if somebody loads a
> Linux filesystem driver, though? I don't happen to know what
> actually happens in this case, but that's (partly) the point: When
> you set inaccurate data, you can't predict what will happen with
> some random tool with which you're unfamiliar.

That is a possible ( though unlikely and easily fixed and knowable by
such a future hypothetical program ) problem with 0x83, but not 0xFD
since that already means "raid, not normal filesystem".

> * Non-kernel tools might care about the type code. In fact, Chris
> quoted the mdadm man page earlier in this thread, and it explicitly
> states that it DOES care about the type code!

Only in the one special case of the deprecated auto assembly feature.

> * Other OSes do check the type code, and if some non-Linux driver
> or utility behaves in a particular way based on the type code,
> setting something inappropriate invites problems that we can't
> predict.

They only use it as a binary "mine" or "not mine", and treat 0x83 and
0xFD, and 0xDA the same.

> That's not what the modern version of mdadm wants, though.

It doesn't "want" anything.  It is quite happy with any type code, or
not even having a partition table at all.

> In an ideal world, of course, the mdadm developers wouldn't have
> changed their tools' expectations from 0.9 to 1.0; but they did,
> and that means that the tools that actually set the partition type
> codes must adapt.

Again, the tools don't know or care about the type code.

> All that said, there is a further complication, and this one isn't 
> parted's fault: The 0xDA type code that's suggested by the mdadm
> man page is NOT specific to Linux RAID. According to 
> http://www.win.tue.nl/~aeb/partitions/partition_types-1.html, it
> refers to "non-FS data"; and according to 
> https://en.wikipedia.org/wiki/Partition_type, it can be that or a 
> Powercopy backup. There may be other specific tools that use it,
> too. Thus, I'd be a little wary of just switching 0xFD to 0xDA as
> the MBR RAID flag in parted. IMHO, what's needed is some
> coordination between mdadm, parted, fdisk, and gdisk authors to
> settle on a standard for this.

That's another good reason against it.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTxxleAAoJEI5FoCIzSKrwYsAH/2c5zPxITX/SS35coII5kzWw
pE4a2SxDdn9fS+JIXCly2GWzWeGCznJpXBEkMMoYoicMzoVDBGZ8TzV+QM4nD2/u
PtlONGFD8MpkG3PknnCYNqIVJFra3ZnA63aF0E1i77PTFt6mlu5dNkxLLk8NF4QM
2XoQCt/HkS/VkvFqmdLcqu7Adh/NHma1n4/jiQHrcTdlzu2iFgXP7qKWf/NFX8lh
0LhU/9AKw1g3dIRAAIvjUwMPL0/Jg6eyzfbNTyuw5wYdnepyBfMvYnz0hCAVq92V
A4Cd0mWCb9VNyc0qQrgBOpoSiabviepnpq054K5MYJIbAN6UcuZnYEng/Z+3ZrA=
=78ZZ
-----END PGP SIGNATURE-----

Message #14 received at 18019 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: "Brian C. Lane" <bcl <at> redhat.com>, 18019 <at> debbugs.gnu.org
Subject: Re: bug#18019: bug-parted Digest, Vol 140, Issue 9
Date: Wed, 16 Jul 2014 20:45:09 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/14/2014 03:28 PM, Brian C. Lane wrote:
> The compelling reason for the change, other than just following
> mdadm's suggestion is Doug's example scenario from the bz entry:
> 
> "It's possible, although it means you have a broken setup, that
> you could have a version 1.1 or 1.2 superblock and a version 0.90
> on the same device, and kernel autodetect could assemble it as a
> version 0.90 device and corrupt the real device.  Likewise, if you
> use 0x83, then the kernel filesystem and udev filesystem detection
> code might find something you don't want found."

If you are using 1.1 or 1.2, then the filesystem won't be detected
anyhow since it does not start at sector zero.  Udev scripts also pay
no attention to the partition type code, and so if they were broken
enough to detect the fs and not the 1.0 superblock, they would do so
no matter what the partition type is, so 0xDA doesn't help you there.
 Finally a broken setup with both superblocks present would face the
same problem when mdadm goes to assemble the device instead of the
kernel auto assembler.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTxxyVAAoJEI5FoCIzSKrw6asH/A7jTelYRqjcNSIYIFk+lxHe
kIllhpaP7RhRcoAGHbu+OcbQqVJ7XdoAEYgGFvLJoLtYIC7mrbsDRzSWQv04ehRl
gWKdjXnsCVrdwkdG0j2ECwWsxgGjJ/g5IotZkopi++2vSl4OH6jzE9m+G7XBpUI9
KbygMt7QC9b2fEDLI8kvb7sRV/LVqqMHmTONlrFcfPCUuzMo97Q8s+k0IYSKl0xN
XFhbOt5BKB57rs36qpgMkOHQqTCpmCGNOwuQRvOXt5W5qpECihdOngdQMMUekMLg
68skgNhc6WVGbwEnETPC7aMtqBALZKppwMin36eHr9JPs9aDmLWRGBjP+cCN6MQ=
=/LVk
-----END PGP SIGNATURE-----

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.