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

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: parted; Reported by: Rod Smith <rodsmith@HIDDEN>; dated Mon, 14 Jul 2014 17:12:02 UTC; Maintainer for parted is bug-parted@HIDDEN.

Message received at 18019 <at> debbugs.gnu.org:


Received: (at 18019) by debbugs.gnu.org; 17 Jul 2014 00:45:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 16 20:45:20 2014
Received: from localhost ([127.0.0.1]:56967 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X7Zp1-0006dn-T2
	for submit <at> debbugs.gnu.org; Wed, 16 Jul 2014 20:45:20 -0400
Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.226]:49087
 helo=cdptpa-oedge-vip.email.rr.com)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <psusi@HIDDEN>) id 1X7Zox-0006dV-B0
 for 18019 <at> debbugs.gnu.org; Wed, 16 Jul 2014 20:45:15 -0400
Received: from [72.238.67.160] ([72.238.67.160:44828] helo=[192.168.1.102])
 by cdptpa-oedge01 (envelope-from <psusi@HIDDEN>)
 (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP
 id 4E/82-32691-59C17C35; Thu, 17 Jul 2014 00:45:09 +0000
Message-ID: <53C71C95.4030308@HIDDEN>
Date: Wed, 16 Jul 2014 20:45:09 -0400
From: Phillip Susi <psusi@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Brian C. Lane" <bcl@HIDDEN>, 18019 <at> debbugs.gnu.org
Subject: Re: bug#18019: bug-parted Digest, Vol 140, Issue 9
References: <mailman.155.1405353661.24831.bug-parted@HIDDEN>	<53C40F3E.2050709@HIDDEN>
 <20140714192817.GV14098@HIDDEN>
In-Reply-To: <20140714192817.GV14098@HIDDEN>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-RR-Connecting-IP: 107.14.168.118:25
X-Cloudmark-Score: 0
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 18019
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

-----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-----




Information forwarded to bug-parted@HIDDEN:
bug#18019; Package parted. Full text available.

Message received at 18019 <at> debbugs.gnu.org:


Received: (at 18019) by debbugs.gnu.org; 17 Jul 2014 00:31:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 16 20:31:31 2014
Received: from localhost ([127.0.0.1]:56956 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X7Zbf-0006H2-2z
	for submit <at> debbugs.gnu.org; Wed, 16 Jul 2014 20:31:31 -0400
Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.229]:61921
 helo=cdptpa-oedge-vip.email.rr.com)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <psusi@HIDDEN>) id 1X7Zbb-0006Gn-Kc
 for 18019 <at> debbugs.gnu.org; Wed, 16 Jul 2014 20:31:29 -0400
Received: from [72.238.67.160] ([72.238.67.160:44823] helo=[192.168.1.102])
 by cdptpa-oedge01 (envelope-from <psusi@HIDDEN>)
 (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP
 id AC/65-32691-E5917C35; Thu, 17 Jul 2014 00:31:27 +0000
Message-ID: <53C7195E.30206@HIDDEN>
Date: Wed, 16 Jul 2014 20:31:26 -0400
From: Phillip Susi <psusi@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Rod Smith <rodsmith@HIDDEN>, 18019 <at> debbugs.gnu.org
Subject: Re: bug#18019: bug-parted Digest, Vol 140, Issue 9
References: <mailman.155.1405353661.24831.bug-parted@HIDDEN>
 <53C40F3E.2050709@HIDDEN>
In-Reply-To: <53C40F3E.2050709@HIDDEN>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-RR-Connecting-IP: 107.14.168.118:25
X-Cloudmark-Score: 0
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 18019
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

-----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-----




Information forwarded to bug-parted@HIDDEN:
bug#18019; Package parted. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 14 Jul 2014 19:28:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 14 15:28:51 2014
Received: from localhost ([127.0.0.1]:54933 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6lvb-0005Ro-Cz
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 15:28:51 -0400
Received: from eggs.gnu.org ([208.118.235.92]:54067)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <bcl@HIDDEN>) id 1X6lvV-0005RY-ME
 for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 15:28:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6lvL-0008G1-Jk
 for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 15:28:36 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:57953)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6lvL-0008Fx-Hm
 for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 15:28:31 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55566)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6lvG-0005mr-Sx
 for bug-parted@HIDDEN; Mon, 14 Jul 2014 15:28:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6lvC-00088a-Cm
 for bug-parted@HIDDEN; Mon, 14 Jul 2014 15:28:26 -0400
Received: from mx1.redhat.com ([209.132.183.28]:27808)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6lvC-00087o-37
 for bug-parted@HIDDEN; Mon, 14 Jul 2014 15:28:22 -0400
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
 (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6EJSJ5x012001
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
 for <bug-parted@HIDDEN>; Mon, 14 Jul 2014 15:28:20 -0400
Received: from lister.brianlane.com (ovpn-113-141.phx2.redhat.com
 [10.3.113.141])
 by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 s6EJSHV5012292
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO)
 for <bug-parted@HIDDEN>; Mon, 14 Jul 2014 15:28:19 -0400
Date: Mon, 14 Jul 2014 12:28:17 -0700
From: "Brian C. Lane" <bcl@HIDDEN>
To: bug-parted@HIDDEN
Subject: Re: bug#18019: bug-parted Digest, Vol 140, Issue 9
Message-ID: <20140714192817.GV14098@HIDDEN>
References: <mailman.155.1405353661.24831.bug-parted@HIDDEN>
 <53C40F3E.2050709@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53C40F3E.2050709@HIDDEN>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

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)




Information forwarded to bug-parted@HIDDEN:
bug#18019; Package parted. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 14 Jul 2014 17:12:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 14 13:12:01 2014
Received: from localhost ([127.0.0.1]:54880 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6jnB-0001xh-Iu
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 13:12:01 -0400
Received: from eggs.gnu.org ([208.118.235.92]:51965)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rodsmith@HIDDEN>) id 1X6jn5-0001xN-AM
 for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 13:11:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rodsmith@HIDDEN>) id 1X6jmu-0003fw-Fi
 for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 13:11:45 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:52332)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <rodsmith@HIDDEN>) id 1X6jmu-0003fp-D3
 for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 13:11:40 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53522)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <rodsmith@HIDDEN>) id 1X6jmo-0007Lg-HW
 for bug-parted@HIDDEN; Mon, 14 Jul 2014 13:11:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rodsmith@HIDDEN>) id 1X6jmj-0003am-09
 for bug-parted@HIDDEN; Mon, 14 Jul 2014 13:11:34 -0400
Received: from eastrmfepo202.cox.net ([68.230.241.217]:35152)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <rodsmith@HIDDEN>) id 1X6jmi-0003ab-R1
 for bug-parted@HIDDEN; Mon, 14 Jul 2014 13:11:28 -0400
Received: from eastrmimpo109 ([68.230.241.222]) by eastrmfepo202.cox.net
 (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP
 id <20140714171126.JYFG22448.eastrmfepo202.cox.net@eastrmimpo109>
 for <bug-parted@HIDDEN>; Mon, 14 Jul 2014 13:11:26 -0400
Received: from nessus.rodsbooks.com ([98.182.36.23]) by eastrmimpo109 with cox
 id SHBS1o0090Vxc5u01HBSBf; Mon, 14 Jul 2014 13:11:26 -0400
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A02020A.53C40F3E.010E,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=F4SJgNdN c=1 sm=1
 a=5/GQi7ztvdfnmBZvbhqgsw==:17 a=VQ02GByEDZYA:10 a=cvYP1zPsJcEA:10
 a=-oC7iYvNpoQA:10 a=8nJEP1OIZ-IA:10 a=28bguoTQAAAA:8 a=fxJcL_dCAAAA:8
 a=h-g04OPQAAAA:8 a=8pif782wAAAA:8 a=E8L_qvUqd6qIn3Dw_MYA:9 a=wPNLvfGTeEIA:10
 a=Y_VEDdgguPIA:10 a=2eKvNQJKnqYA:10 a=_YepGT1rgiMA:10
 a=5/GQi7ztvdfnmBZvbhqgsw==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Received: from [192.168.1.2] (nessus.rodsbooks.com [192.168.1.2])
 by nessus.rodsbooks.com (Postfix) with ESMTP id 21D092012F
 for <bug-parted@HIDDEN>; Mon, 14 Jul 2014 13:11:26 -0400 (EDT)
Message-ID: <53C40F3E.2050709@HIDDEN>
Date: Mon, 14 Jul 2014 13:11:26 -0400
From: Rod Smith <rodsmith@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: bug-parted@HIDDEN
Subject: Re: bug-parted Digest, Vol 140, Issue 9
References: <mailman.155.1405353661.24831.bug-parted@HIDDEN>
In-Reply-To: <mailman.155.1405353661.24831.bug-parted@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

On 07/14/2014 12:01 PM, Phillip Susi <psusi@HIDDEN> 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@HIDDEN
http://www.rodsbooks.com




Acknowledgement sent to Rod Smith <rodsmith@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-parted@HIDDEN. Full text available.
Report forwarded to bug-parted@HIDDEN:
bug#18019; Package parted. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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