GNU logs - #17994, boring messages

Message sent to bug-parted@HIDDEN:

Subject: bug#17994: Linux RAID MBR type code
Resent-From: Chris Murphy <lists@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Fri, 11 Jul 2014 00:43:02 +0000
Resent-Message-ID: <handler.17994.B.140503934431288 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 17994 <at> debbugs.gnu.org
From: Chris Murphy <lists@HIDDEN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
Date: Thu, 10 Jul 2014 17:58:26 -0600
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

This is in master branch.

libparted/labels/dos.c
98	#define PARTITION_LINUX_RAID	0xfd

This type code and metadata version 0.9 are long deprecated. Parted =
lacks support for the "non-fs data" partition type code 0xda, which is =
what should be used for mdadm metadata 1.x partitions.

man 8 mdadm:
"When  creating  a partition based array, using mdadm with version-1.x =
metadata, the partition type should be set to 0xDA (non fs-data).  This =
type selection allows for greater precision since using any other [RAID =
auto-detect (0xFD) or a GNU/Linux  partition (0x83)], might create =
problems in the event of array recovery through a live cdrom."

https://raid.wiki.kernel.org/index.php/Autodetect

Chris Murphy=

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Chris Murphy <lists@HIDDEN>
Subject: bug#17994: Acknowledgement (Linux RAID MBR type code)
Message-ID: <handler.17994.B.140503934431288.ack <at> debbugs.gnu.org>
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
X-Gnu-PR-Message: ack 17994
X-Gnu-PR-Package: parted
Reply-To: 17994 <at> debbugs.gnu.org
Date: Fri, 11 Jul 2014 00:43:03 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-parted@HIDDEN

If you wish to submit further information on this problem, please
send it to 17994 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
17994: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17994
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-parted@HIDDEN:

Subject: bug#17994: Linux RAID MBR type code
Resent-From: Phillip Susi <psusi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Sun, 13 Jul 2014 22:43:01 +0000
Resent-Message-ID: <handler.17994.B17994.140529132431712 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Chris Murphy <lists@HIDDEN>, 17994 <at> debbugs.gnu.org
Message-ID: <53C30B31.8080500@HIDDEN>
Date: Sun, 13 Jul 2014 18:41:53 -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
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
In-Reply-To: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

On 07/10/2014 07:58 PM, Chris Murphy wrote:
> This is in master branch.
> 
> libparted/labels/dos.c 98	#define PARTITION_LINUX_RAID	0xfd
> 
> 
> This type code and metadata version 0.9 are long deprecated.
> Parted lacks support for the "non-fs data" partition type code
> 0xda, which is what should be used for mdadm metadata 1.x
> partitions.
> 
> man 8 mdadm: "When  creating  a partition based array, using mdadm 
> with version-1.x metadata, the partition type should be set to
> 0xDA (non fs-data).  This type selection allows for greater
> precision since using any other [RAID auto-detect (0xFD) or a
> GNU/Linux partition (0x83)], might create problems in the event of
> array recovery through a live cdrom."

Why does it matter?  Linux doesn't pay attention to the partition type
code anyhow.  I've always just used 0x83.

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

iQEcBAEBCgAGBQJTwwsxAAoJEI5FoCIzSKrw+qYIAID8rG0Q7u1fdilQgAtK1n9x
sNuRVDbi1mGQiktMYTUcUUNNtd6sglau4XUpU/LX9jR50fHbbI4CtT/7pTEbptmC
URKWjA77ViChbf/6OJd4wevuQUhFN/WQgQTj2Tgqijr2zI6TKD5JPDyqqxaH/wz1
0A6SIF1j7dWId7Z2obzHU2vNTh/GIin50MOR+49MpBy03GwtYb+BpNXCypz0LEwk
E5QEGd1kW01RPLLF2FE0tuyjiYIqY74g95VWdFxghBGGW1ZuNHjLbq3G9b4ixthq
05Ph+FfwECqvgZr+xA9QtGbHZjEFsyHGLOf9xQH0NkRx+BZUGMQQDCiYAgkEJfU=
=T7uG
-----END PGP SIGNATURE-----

Message sent to bug-parted@HIDDEN:

Subject: bug#17994: Linux RAID MBR type code
Resent-From: Chris Murphy <lists@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 01:08:02 +0000
Resent-Message-ID: <handler.17994.B17994.140530005727229 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Phillip Susi <psusi@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Chris Murphy <lists@HIDDEN>
In-Reply-To: <53C30B31.8080500@HIDDEN>
Date: Sun, 13 Jul 2014 19:07:24 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
 
 Content preview:  On Jul 13, 2014, at 4:41 PM, Phillip Susi <psusi@HIDDEN>
    wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 07/10/2014
    07:58 PM, Chris Murphy wrote: >> This is in master branch. >> >> libparted/labels/dos.c
    98 #define PARTITION_LINUX_RAID 0xfd >> >> >> This type code and metadata
    version 0.9 are long deprecated. >> Parted lacks support for the "non-fs
   data" partition type code >> 0xda, which is what should be used for mdadm
   metadata 1.x >> partitions. >> >> man 8 mdadm: "When creating a partition
   based array, using mdadm >> with version-1.x metadata, the partition type
   should be set to >> 0xDA (non fs-data). This type selection allows for greater
    >> precision since using any other [RAID auto-detect (0xFD) or a >> GNU/Linux
    partition (0x83)], might create problems in the event of >> array recovery
    through a live cdrom." > > Why does it matter? Linux doesn't pay attention
    to the partition type > code anyhow. I've always just used 0x83. [...] 
 
 Content analysis details:   (1.3 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS


On Jul 13, 2014, at 4:41 PM, Phillip Susi <psusi@HIDDEN> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> On 07/10/2014 07:58 PM, Chris Murphy wrote:
>> This is in master branch.
>>=20
>> libparted/labels/dos.c 98	#define PARTITION_LINUX_RAID	0xfd
>>=20
>>=20
>> This type code and metadata version 0.9 are long deprecated.
>> Parted lacks support for the "non-fs data" partition type code
>> 0xda, which is what should be used for mdadm metadata 1.x
>> partitions.
>>=20
>> man 8 mdadm: "When  creating  a partition based array, using mdadm=20
>> with version-1.x metadata, the partition type should be set to
>> 0xDA (non fs-data).  This type selection allows for greater
>> precision since using any other [RAID auto-detect (0xFD) or a
>> GNU/Linux partition (0x83)], might create problems in the event of
>> array recovery through a live cdrom."
>=20
> Why does it matter?  Linux doesn't pay attention to the partition type
> code anyhow.  I've always just used 0x83.

https://bugzilla.redhat.com/show_bug.cgi?id=3D1118065#c5
https://bugzilla.redhat.com/show_bug.cgi?id=3D1118065#c8


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.

For example, 0x83 partition type, and mdadm metadata 1.0 on md raid1 =
suggests that the partition can be mounted stand alone rather than first =
assembling the raid. If something actually were to do this, the array =
would become inconsistent and unrepairable without rather knowledgable =
manual intervention. A partition with md metadata is in fact not a Linux =
filesystem, so really we shouldn't lie about what it is by using the =
wrong partition type code.


Chris Murphy

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Phillip Susi <psusi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 14:04:01 +0000
Resent-Message-ID: <handler.17994.B17994.140534663711951 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: Chris Murphy <lists@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.140534663711951
          (code B ref 17994); Mon, 14 Jul 2014 14:04:01 +0000
Received: (at 17994) by debbugs.gnu.org; 14 Jul 2014 14:03:57 +0000
Received: from localhost ([127.0.0.1]:54753 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6grE-00036g-Mp
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 10:03:57 -0400
Received: from mail-yh0-f49.google.com ([209.85.213.49]:40428)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <phillsusi@HIDDEN>) id 1X6grB-00036E-7a
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 10:03:54 -0400
Received: by mail-yh0-f49.google.com with SMTP id z6so1637123yhz.36
 for <17994 <at> debbugs.gnu.org>; Mon, 14 Jul 2014 07:03:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
 :references:in-reply-to:content-type:content-transfer-encoding;
 bh=/ZDGHlisrlUn+XnfkyreOexQ362osSB5BkbTGI1GAYs=;
 b=RfzuusDbiFCRIBabUotF0VOCD3MtZBXxfwfAAWSI4lgVtu7pfX/6QrajxuNTBx38ZW
 XhYZ9AZxj4RUJDDSc1B8OJkqw47vPr2YMqWyH1YvgWgwl6LewawMMUtrlH+GeOHP6dP5
 oA0DrNgi9y81vILc+z7C3yJ07g6tm7hxtCcUfNlXyPZTaJooLItgpWLv2zGZkuUMFtDn
 he3JBgVCsN/J2+TPo3PuhzT3GYd6hLbppINbnj0HkOjJGLmsy3UsSb1zk0KZxAWFlIp9
 LCCrzS+pnp4hy0UhbFJ8KrEseoS53tt9XEjNHaKFBTQaA3uKt4FJ9tFNquECSY0PgLaw
 eXsw==
X-Received: by 10.236.100.171 with SMTP id z31mr29675023yhf.70.1405346627438; 
 Mon, 14 Jul 2014 07:03:47 -0700 (PDT)
Received: from [10.1.1.202] (fl-71-55-178-50.dhcp.embarqhsd.net.
 [71.55.178.50])
 by mx.google.com with ESMTPSA id o50sm21495254yhm.0.2014.07.14.07.03.46
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Mon, 14 Jul 2014 07:03:46 -0700 (PDT)
Message-ID: <53C3E34E.6010201@HIDDEN>
Date: Mon, 14 Jul 2014 10:03:58 -0400
From: Phillip Susi <psusi@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
In-Reply-To: <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
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.7 (/)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/13/2014 9:07 PM, Chris Murphy wrote:
>> Why does it matter?  Linux doesn't pay attention to the
>> partition type code anyhow.  I've always just used 0x83.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c5 
> https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c8
> 
> 
> 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.

> For example, 0x83 partition type, and mdadm metadata 1.0 on md
> raid1 suggests that the partition can be mounted stand alone rather
> than first assembling the raid. If something actually were to do
> this, the array would become inconsistent and unrepairable without
> rather knowledgable manual intervention. A partition with md
> metadata is in fact not a Linux filesystem, so really we shouldn't
> lie about what it is by using the wrong partition type code.

Suggests?  Lieing?  To whom?  Nobody pays attention to the type codes.
 Also if you really want a different type code for raid, there already
is one: 0xFD.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTw+NOAAoJEI5FoCIzSKrw6vsH/Rxuwlqtw7Ef7KmBNMqWeZvz
6jGf4hxDUy176O6GRFMDlroJY4Gk5apSZdzyTGcIhprMYVe12DVZA5/rJOz1GmP7
/ArqaJoDtyRXP0/yuDqXxlwHoA0u8HaUGtXv2D1SEqw+dbi3Rb1f+D8E/tZ/TcXG
Y+Tcr9cyl0W2gvS9UrYrIgErscaUhJeGV7r1Njiv6GDmyExDm9zhtlafC+g9Z2ZZ
XK7MV3y2mReSiZOnZejZ+3ZT0Doiv2tPDlGkG73L+rZ4fJdN1/FS4L22UDEIhZtS
d36qKBPDWAuij9LR5Yz+1oK0c9f34cWn2mo8rDDZyU7USdiEA2eorevHwCaFHaI=
=gn+C
-----END PGP SIGNATURE-----

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: "Brian C. Lane" <bcl@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 15:42:01 +0000
Resent-Message-ID: <handler.17994.B.140535248221628 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: 17994 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-parted@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.140535248221628
          (code B ref -1); Mon, 14 Jul 2014 15:42:01 +0000
Received: (at submit) by debbugs.gnu.org; 14 Jul 2014 15:41:22 +0000
Received: from localhost ([127.0.0.1]:54804 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6iNW-0005cm-9E
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 11:41:22 -0400
Received: from eggs.gnu.org ([208.118.235.92]:49720)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <bcl@HIDDEN>) id 1X6iNT-0005cX-0A
 for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 11:41:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6iNE-0005Tj-Q9
 for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 11:41:13 -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]:35154)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6iNE-0005Te-NF
 for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 11:41:04 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51242)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6iN7-0005P5-4O
 for bug-parted@HIDDEN; Mon, 14 Jul 2014 11:41:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6iMz-0005NU-Em
 for bug-parted@HIDDEN; Mon, 14 Jul 2014 11:40:56 -0400
Received: from mx1.redhat.com ([209.132.183.28]:23891)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <bcl@HIDDEN>) id 1X6iMy-0005Mr-Sp
 for bug-parted@HIDDEN; Mon, 14 Jul 2014 11:40:49 -0400
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
 (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6EFejAi004350
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
 for <bug-parted@HIDDEN>; Mon, 14 Jul 2014 11:40:46 -0400
Received: from lister.brianlane.com (ovpn-113-141.phx2.redhat.com
 [10.3.113.141])
 by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 s6EFehBF014818
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO)
 for <bug-parted@HIDDEN>; Mon, 14 Jul 2014 11:40:45 -0400
Date: Mon, 14 Jul 2014 08:40:43 -0700
From: "Brian C. Lane" <bcl@HIDDEN>
Message-ID: <20140714154043.GS14098@HIDDEN>
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
 <53C3E34E.6010201@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53C3E34E.6010201@HIDDEN>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
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-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 10:03:58AM -0400, Phillip Susi wrote:
> On 7/13/2014 9:07 PM, Chris Murphy wrote:
> >> Why does it matter?  Linux doesn't pay attention to the
> >> partition type code anyhow.  I've always just used 0x83.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c5 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c8
> > 
> > 
> > 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.
> 
> > For example, 0x83 partition type, and mdadm metadata 1.0 on md
> > raid1 suggests that the partition can be mounted stand alone rather
> > than first assembling the raid. If something actually were to do
> > this, the array would become inconsistent and unrepairable without
> > rather knowledgable manual intervention. A partition with md
> > metadata is in fact not a Linux filesystem, so really we shouldn't
> > lie about what it is by using the wrong partition type code.
> 
> Suggests?  Lieing?  To whom?  Nobody pays attention to the type codes.
>  Also if you really want a different type code for raid, there already
> is one: 0xFD.

It ends up that 0xFD is only supposed to be used for mdraid 0.9
metadata. For 1.0 and later they want 0xDA so that it isn't auto
assembled and gets ignored by everything else.

I've been meaning to write a patch to allow setting arbitrary values for
partition id / guid since it is a bit of a pain to add new flags every
time someone comes up with something new.

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

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Phillip Susi <psusi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 16:02:02 +0000
Resent-Message-ID: <handler.17994.B17994.1405353706447 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: "Brian C. Lane" <bcl@HIDDEN>, 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.1405353706447
          (code B ref 17994); Mon, 14 Jul 2014 16:02:02 +0000
Received: (at 17994) by debbugs.gnu.org; 14 Jul 2014 16:01:46 +0000
Received: from localhost ([127.0.0.1]:54834 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6ihC-000072-6H
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 12:01:46 -0400
Received: from mail-yh0-f48.google.com ([209.85.213.48]:46000)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <phillsusi@HIDDEN>) id 1X6ih6-00006l-Ud
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 12:01:41 -0400
Received: by mail-yh0-f48.google.com with SMTP id b6so1863691yha.35
 for <17994 <at> debbugs.gnu.org>; Mon, 14 Jul 2014 09:01:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=sender:message-id:date:from:user-agent:mime-version:to:subject
 :references:in-reply-to:content-type:content-transfer-encoding;
 bh=8/IevkTCNZkNj7h3XAebff9DXP8NfEtQxUOMEJevt/A=;
 b=sfL8hiVJBDDmEMeLEtaHiWzGdXel1PSZyzKd6iLAQYi+AE/n+42hkgqNjayWEHTLIK
 1tRrsoFCLxBWWCJzvGaMzajkjkAy1iB8uKjdLIh9SWLqMSRh3xtDcEJlbWi5CPle1UMF
 6oh1PpLYW0VZJRliEGsBkzlAAUWBtAs6NLGPCIXAF47BtUIgB+d/yPupy5hFyUhh0+NI
 SzeACgFEKDs7BIhwz/7TTd4MWAcPZiD69WndXSwyfXQYHspH5sMn9l1cXz6PktVKIuMm
 LO+2Eb3bWSgpnzA7FHwJCY9lernmCVSewRQCxlr2VBaaPM6D7Yagaw2R8JU4XOpMgLnp
 fj3A==
X-Received: by 10.236.128.111 with SMTP id e75mr30872152yhi.78.1405353691096; 
 Mon, 14 Jul 2014 09:01:31 -0700 (PDT)
Received: from [10.1.1.202] (fl-71-55-178-50.dhcp.embarqhsd.net.
 [71.55.178.50])
 by mx.google.com with ESMTPSA id o69sm21966437yho.19.2014.07.14.09.01.30
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Mon, 14 Jul 2014 09:01:30 -0700 (PDT)
Message-ID: <53C3FEE9.1030005@HIDDEN>
Date: Mon, 14 Jul 2014 12:01:45 -0400
From: Phillip Susi <psusi@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>	<53C30B31.8080500@HIDDEN>	<B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>	<53C3E34E.6010201@HIDDEN>
 <20140714154043.GS14098@HIDDEN>
In-Reply-To: <20140714154043.GS14098@HIDDEN>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
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.7 (/)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/2014 11:40 AM, Brian C. Lane wrote:
> It ends up that 0xFD is only supposed to be used for mdraid 0.9 
> metadata. For 1.0 and later they want 0xDA so that it isn't auto 
> assembled and gets ignored by everything else.

Says who?  1.x won't be auto assembled no matter what the type code
says.  Why introduce this 0xDA instead of keeping the existing code?
Also what about gpt?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTw/7pAAoJEI5FoCIzSKrwAJoH/jKMgdhKKziwCpg1az2z5gnb
pnQwkgOKlCpHtpvj0K4qqaZPiR2SVmEOp8eX2ljVkQVLv/0T3fVR8JmzdakIGCnD
eTGt5JGc8skQs4sfxtyCa+VXy26dKT1vySbrDIHq3Ocu74uzcLrxv30lR5FyuX0V
5WXOgjhElxWQ1Fb9lT7PiNr98s+3M+63U3OvFKqlcM1TOiP5t/g3sO5JhR4b/avX
++xOBVHqbHQAd0wwX4G6ecv4PlS2L/3bXkzQfKba7R4thXy2VtIpkGqcXf2WlyRw
e+/RC0g5NFyYgWqmkjJ7P0/6pdL99ilRRVtJNRILFcltL9b4RlcenoZcUsDQ0cE=
=SlVM
-----END PGP SIGNATURE-----

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Chris Murphy <lists@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 16:27:01 +0000
Resent-Message-ID: <handler.17994.B17994.14053552123037 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: Phillip Susi <psusi@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.14053552123037
          (code B ref 17994); Mon, 14 Jul 2014 16:27:01 +0000
Received: (at 17994) by debbugs.gnu.org; 14 Jul 2014 16:26:52 +0000
Received: from localhost ([127.0.0.1]:54868 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6j5U-0000mq-2r
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 12:26:52 -0400
Received: from [50.115.112.57] (port=39555 helo=slmp-550-94.slc.westdc.net)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <lists@HIDDEN>) id 1X6j5N-0000mQ-Pm
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 12:26:46 -0400
Received: from c-75-70-18-61.hsd1.co.comcast.net ([75.70.18.61]:56616
 helo=[192.168.1.145])
 by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128)
 (Exim 4.82) (envelope-from <lists@HIDDEN>)
 id 1X6j5G-002Xp6-10; Mon, 14 Jul 2014 10:26:34 -0600
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Chris Murphy <lists@HIDDEN>
In-Reply-To: <53C3E34E.6010201@HIDDEN>
Date: Mon, 14 Jul 2014 10:26:31 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <99BA9570-6751-4449-B202-52F057083D1B@HIDDEN>
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
 <53C3E34E.6010201@HIDDEN>
X-Mailer: Apple Mail (2.1510)
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net
X-AntiAbuse: Original Domain - debbugs.gnu.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - colorremedies.com
X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id:
 whatever@HIDDEN
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On Jul 14, 2014, at 8:03 AM, Phillip Susi <psusi@HIDDEN>
 wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/13/2014
 9:07 PM,
 Chris Murphy wrote: >>> Why does it matter? Linux doesn't pay attention
 to the >>> partition type code anyhow. I've always just used 0x83. >> >>
 https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c5 >>
 https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c8
 >> >> >> 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. [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
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: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  On Jul 14, 2014, at 8:03 AM, Phillip Susi <psusi@HIDDEN>
    wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/13/2014
    9:07 PM, Chris Murphy wrote: >>> Why does it matter? Linux doesn't pay attention
    to the >>> partition type code anyhow. I've always just used 0x83. >> >>
   https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c5 >> https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c8
    >> >> >> 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. [...] 
 
 Content analysis details:   (1.3 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS


On Jul 14, 2014, at 8:03 AM, Phillip Susi <psusi@HIDDEN> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 7/13/2014 9:07 PM, Chris Murphy wrote:
>>> Why does it matter?  Linux doesn't pay attention to the
>>> partition type code anyhow.  I've always just used 0x83.
>>=20
>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1118065#c5=20
>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1118065#c8
>>=20
>>=20
>> I find this logic troubling. It's rather similar to the logic that=20
>> 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=20
>> partitiontype GUID, but not the contents of the partition, and=20
>> actively invites the user to reformat it.
>=20
> How is this at all related?  Windows already ignores 0x83.

It does not ignore EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 on GPT disks. =
Yet parted for *years* has wrongly used this type code by default for =
Linux partitions.

And this relates here because it's the same preposterously flawed logic =
being demonstrated in your responses about this bug, which is that only =
Linux behavior matters. And complete ignorance about how the rest of the =
world does consider partition type codes important.


>=20
>> For example, 0x83 partition type, and mdadm metadata 1.0 on md
>> raid1 suggests that the partition can be mounted stand alone rather
>> than first assembling the raid. If something actually were to do
>> this, the array would become inconsistent and unrepairable without
>> rather knowledgable manual intervention. A partition with md
>> metadata is in fact not a Linux filesystem, so really we shouldn't
>> lie about what it is by using the wrong partition type code.
>=20
> Suggests?  Lieing?  To whom?

The kernel for one, 0xfd applies to 0.9 metadata, not 1.x. The detection =
and assembly methods are different. Since metadata 0.9 is deprecated, in =
effect type code 0xfd is deprecated since they go together.

And for two, anything else in the world that understands Linux =
filesystems but not Linux RAID. For example, FUSE supporting ext on OS X =
or Windows. The 0x83 type code tells them this is a Linux *filesystem*. =
Yet it isn't. It's a RAID member. If the partition is an mdadm RAID1 =
member, such software will mount the filesystem as if it's a stand alone =
filesystem, and now the RAID is corrupt. So if you care to protect the =
array it needs to be properly set to 0xfd when mdadm 0.9 metadata is =
used, and 0xda when mdadm 1.x metadata is used. Using 0x83 is the wrong =
type code for Linux software RAID.


> Nobody pays attention to the type codes.

Right, there's no outside world at all. You're familiar with the =
behavior of 100% of the world's code, open source and proprietary, and =
you've personally determined nobody pays attention to type codes.


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

That contradicts md developers' recommendations.

https://raid.wiki.kernel.org/index.php/Partition_Types
https://raid.wiki.kernel.org/index.php/Autodetect


Chris Murphy=

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Phillip Susi <psusi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 18:09:02 +0000
Resent-Message-ID: <handler.17994.B17994.140536133213095 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: Chris Murphy <lists@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.140536133213095
          (code B ref 17994); Mon, 14 Jul 2014 18:09:02 +0000
Received: (at 17994) by debbugs.gnu.org; 14 Jul 2014 18:08:52 +0000
Received: from localhost ([127.0.0.1]:54903 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6kgF-0003P8-RO
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 14:08:52 -0400
Received: from mail-yh0-f51.google.com ([209.85.213.51]:50679)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <phillsusi@HIDDEN>) id 1X6kgD-0003Ou-BR
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 14:08:50 -0400
Received: by mail-yh0-f51.google.com with SMTP id f73so1781880yha.24
 for <17994 <at> debbugs.gnu.org>; Mon, 14 Jul 2014 11:08:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
 :references:in-reply-to:content-type:content-transfer-encoding;
 bh=XjwqIqgD/DVdJBUn1Kxov+5S0RoayIqgJhwfy+tPTtU=;
 b=kxVBgL0gTnZ66NoAza7+8c8zS+llHNSL3RvKQXoVAtMzW3bGHsCiluZir4fPYvy2Oz
 x4shdqLM3lPbd8PxLX1yAQnONJWdax+mhAJkmNh44e0LFFlwgek9LGgvFLq4GcbjgWaR
 kynKGLkPrJWSpJEpbVHDFbhl7Pnt5JH4XORTAMAsjuZARIEklN7k56Z66TvxIHPHELlR
 ezmU+ht6MmdKiGIYpDeH7935DYtWd2ft3MD268F2pVwLS6GYUG9J/nZ7IIFFQUd/Rtf+
 FVJCN2uQGuyBoDGZjZxG3jbg7YGdx9WQz1aWkzCGW9wRYnib9QBPur+L88tQj+g+KlZH
 jYzQ==
X-Received: by 10.236.150.70 with SMTP id y46mr32091981yhj.52.1405361323667;
 Mon, 14 Jul 2014 11:08:43 -0700 (PDT)
Received: from [10.1.1.202] (fl-71-55-178-50.dhcp.embarqhsd.net.
 [71.55.178.50])
 by mx.google.com with ESMTPSA id v43sm3950310yhj.18.2014.07.14.11.08.42
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Mon, 14 Jul 2014 11:08:43 -0700 (PDT)
Message-ID: <53C41CB9.3040906@HIDDEN>
Date: Mon, 14 Jul 2014 14:08:57 -0400
From: Phillip Susi <psusi@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
 <53C3E34E.6010201@HIDDEN>
 <99BA9570-6751-4449-B202-52F057083D1B@HIDDEN>
In-Reply-To: <99BA9570-6751-4449-B202-52F057083D1B@HIDDEN>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
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.7 (/)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/2014 12:26 PM, Chris Murphy wrote:
>> How is this at all related?  Windows already ignores 0x83.
> 
> It does not ignore EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 on GPT
> disks. Yet parted for *years* has wrongly used this type code by
> default for Linux partitions.
> 
> And this relates here because it's the same preposterously flawed 
> logic being demonstrated in your responses about this bug, which
> is that only Linux behavior matters. And complete ignorance about
> how the rest of the world does consider partition type codes
> important.

That is why we fixed that mistake, and it still has absolutely nothing
to do with this issue since Windows does not try to use 0x83 *or* 0xFD.

> The kernel for one, 0xfd applies to 0.9 metadata, not 1.x. The 
> detection and assembly methods are different. Since metadata 0.9
> is deprecated, in effect type code 0xfd is deprecated since they
> go together.

The kernel only uses 0xfd as a hint that it should look for 0.9
metadata, and only if the md driver is build in ( not a module ) and
has CONFIG_MD_AUTODETECT set.  It reads no meaning into it beyond
that.  Using 0xfd for 1.x metadata has no ill effects, and since it is
the original type code for linux raid, there does not appear to be any
reason to add yet another one.

> And for two, anything else in the world that understands Linux 
> filesystems but not Linux RAID. For example, FUSE supporting ext
> on OS X or Windows. The 0x83 type code tells them this is a Linux 
> *filesystem*. Yet it isn't. It's a RAID member. If the partition
> is an mdadm RAID1 member, such software will mount the filesystem
> as if it's a stand alone filesystem, and now the RAID is corrupt.
> So if you care to protect the array it needs to be properly set to
> 0xfd when mdadm 0.9 metadata is used, and 0xda when mdadm 1.x
> metadata is used. Using 0x83 is the wrong type code for Linux
> software RAID.

I've never tried the ext2 driver on Windows or used OSX.  I thought
they required an explicit mount command.  Are you sure that these two
OSes will automatically ( i.e. without being explicitly given a mount
command ) try to mount an md 1.x partition that has a type code of
0x83?  Even if it does, they certainly already must leave 0xFD alone,
so stick with that.

> That contradicts md developers' recommendations.
> 
> https://raid.wiki.kernel.org/index.php/Partition_Types 
> https://raid.wiki.kernel.org/index.php/Autodetect

That page starts off by saying "There is no right answer - you can
choose. "

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxBy5AAoJEI5FoCIzSKrw1h4IAJZaNQMT+k7YzLSabREaFOlf
AgJuwIj24BoN2by5Ao+9LAnV9Dh/qNJd4eDLurJqfGkLIgEejPTdBuhhFEpveWmX
jhorxKNks72Z1N3Slk5WT4avg0vUV1EvwCGdc4MHu9+2GSqhHPrySOjWN6iAakpA
92SRjFDtTOa81Dml9iG7UFV4n7C72XcCyr9Lnu70sm775bo6KhE7+HBFC7LVpPVc
rSxV8a7d7JFdf7aU75TjP8IeywUProPHLn1mka4dGdFVFJhYyH7JLVM2Kh0Ox56t
jYX/94YziGWlZEHV34TGkPp5l45xwvlpfOF/MWra93DoRP5MDUqU4fyscTDx8vo=
=br7j
-----END PGP SIGNATURE-----

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Chris Murphy <lists@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 18:34:01 +0000
Resent-Message-ID: <handler.17994.B17994.140536284015622 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: Phillip Susi <psusi@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.140536284015622
          (code B ref 17994); Mon, 14 Jul 2014 18:34:01 +0000
Received: (at 17994) by debbugs.gnu.org; 14 Jul 2014 18:34:00 +0000
Received: from localhost ([127.0.0.1]:54909 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6l4Z-00043t-LP
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 14:33:59 -0400
Received: from [50.115.112.57] (port=58755 helo=slmp-550-94.slc.westdc.net)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <lists@HIDDEN>) id 1X6l4T-00043Z-5a
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 14:33:57 -0400
Received: from c-75-70-18-61.hsd1.co.comcast.net ([75.70.18.61]:58249
 helo=[192.168.1.145])
 by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128)
 (Exim 4.82) (envelope-from <lists@HIDDEN>)
 id 1X6l4K-004EK3-Py; Mon, 14 Jul 2014 12:33:44 -0600
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Chris Murphy <lists@HIDDEN>
In-Reply-To: <53C41CB9.3040906@HIDDEN>
Date: Mon, 14 Jul 2014 12:33:43 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <32C06FEE-E1C9-435B-925D-231359AC85F5@HIDDEN>
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
 <53C3E34E.6010201@HIDDEN>
 <99BA9570-6751-4449-B202-52F057083D1B@HIDDEN>
 <53C41CB9.3040906@HIDDEN>
X-Mailer: Apple Mail (2.1510)
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net
X-AntiAbuse: Original Domain - debbugs.gnu.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - colorremedies.com
X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id:
 whatever@HIDDEN
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On Jul 14, 2014, at 12:08 PM, Phillip Susi <psusi@HIDDEN>
 wrote: > > I've never tried the ext2 driver on Windows or used OSX. I thought
 > they required an explicit mount command. Are you sure that these two >
 OSes will automatically ( i.e. without being explicitly given a mount >
 command
 ) try to mount an md 1.x partition that has a type code of > 0x83? [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
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: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  On Jul 14, 2014, at 12:08 PM, Phillip Susi <psusi@HIDDEN>
    wrote: > > I've never tried the ext2 driver on Windows or used OSX. I thought
    > they required an explicit mount command. Are you sure that these two >
   OSes will automatically ( i.e. without being explicitly given a mount > command
    ) try to mount an md 1.x partition that has a type code of > 0x83? [...] 
 
 Content analysis details:   (1.3 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS


On Jul 14, 2014, at 12:08 PM, Phillip Susi <psusi@HIDDEN> wrote:
>=20
> I've never tried the ext2 driver on Windows or used OSX.  I thought
> they required an explicit mount command.  Are you sure that these two
> OSes will automatically ( i.e. without being explicitly given a mount
> command ) try to mount an md 1.x partition that has a type code of
> 0x83?

I haven't test it, but as Apple long ago deprecated fstab in favor of =
automounting anything it recognizes, I'd expect it would automount this =
configuration. But what does happen isn't as important as what =
legitimately can happen now or in the future which is automounting =
because this is invited due to the use of the wrong type code.

>  Even if it does, they certainly already must leave 0xFD alone,
> so stick with that.
>=20
>> That contradicts md developers' recommendations.
>>=20
>> https://raid.wiki.kernel.org/index.php/Partition_Types=20
>> https://raid.wiki.kernel.org/index.php/Autodetect
>=20
> That page starts off by saying "There is no right answer - you can
> choose. "

That is a completely disingenuous reading. If you take the entire page =
as a whole, it's saying you can choose 0xfd with 0.9 metadata, or you =
can choose 0xda with 1.x metadata. It is not suggesting use of 0xfd with =
1.x metadata.

And this has sufficiently explained the conflict with using either 0xfd =
or 0x83, even on Linux.


Chris Murphy=

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Phillip Susi <psusi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 18:56:02 +0000
Resent-Message-ID: <handler.17994.B17994.140536411317729 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: Chris Murphy <lists@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.140536411317729
          (code B ref 17994); Mon, 14 Jul 2014 18:56:02 +0000
Received: (at 17994) by debbugs.gnu.org; 14 Jul 2014 18:55:13 +0000
Received: from localhost ([127.0.0.1]:54917 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6lP5-0004bs-St
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 14:55:12 -0400
Received: from mail-yh0-f52.google.com ([209.85.213.52]:65117)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <phillsusi@HIDDEN>) id 1X6lP1-0004bV-NJ
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 14:55:09 -0400
Received: by mail-yh0-f52.google.com with SMTP id t59so889754yho.11
 for <17994 <at> debbugs.gnu.org>; Mon, 14 Jul 2014 11:55:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
 :references:in-reply-to:content-type:content-transfer-encoding;
 bh=2pQwTiYJzRdlfWM5doKyb0rYZLv+KnT2Uivwnut59Cw=;
 b=0FrNZREI5fItuxOgI73g7nF6qmyFOs8rq0BA3tPsuGMAowXxRqycte/GDU2bnxnezE
 3pq4Jy5iU1WGbr3mViuIeImfGtem9rRq/O2f6ePfvjVvpcP+zAY2BB9XgV0C4DmaZ7g8
 poeisiutBme+b3/HWuhGD9CCK+2vXLYXFLpYKx556OoukSEY/sLy/V8WXiyLCQqXDLQw
 iuRUrLZ/b/RdoxLBi9z1SOrjiAzNSKqnmydJhcqtmNT1yvY+8dGBVA+dEZMJXtODVgXY
 QFxZA/3L6lyYQ/ts3IxB89sFPAtQHivHpComQBVDiVBAi4VFGam+k7XR3TWov9MmHWRj
 e80A==
X-Received: by 10.236.199.45 with SMTP id w33mr7533757yhn.122.1405364102009;
 Mon, 14 Jul 2014 11:55:02 -0700 (PDT)
Received: from [10.1.1.202] (fl-71-55-178-50.dhcp.embarqhsd.net.
 [71.55.178.50])
 by mx.google.com with ESMTPSA id e32sm22666356yhq.43.2014.07.14.11.55.01
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Mon, 14 Jul 2014 11:55:01 -0700 (PDT)
Message-ID: <53C42794.90002@HIDDEN>
Date: Mon, 14 Jul 2014 14:55:16 -0400
From: Phillip Susi <psusi@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
 <53C3E34E.6010201@HIDDEN>
 <99BA9570-6751-4449-B202-52F057083D1B@HIDDEN>
 <53C41CB9.3040906@HIDDEN>
 <32C06FEE-E1C9-435B-925D-231359AC85F5@HIDDEN>
In-Reply-To: <32C06FEE-E1C9-435B-925D-231359AC85F5@HIDDEN>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
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.7 (/)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/2014 2:33 PM, Chris Murphy wrote:
> I haven't test it, but as Apple long ago deprecated fstab in favor
> of automounting anything it recognizes, I'd expect it would
> automount this configuration. But what does happen isn't as
> important as what legitimately can happen now or in the future
> which is automounting because this is invited due to the use of the
> wrong type code.

What can legitimately happen now or in the future is anything and
everything since partition type codes are not standardized.  The
question is, does apple actually look at the type code, or do they
work like Linux does and probe the actual contents?  Since the windows
ext2 driver was written by the Linux community, I would at least
expect it to work like Linux does, and not give a hoot about the
partition type code.  In any case, if they already deal with 0xfd
correctly, why change?

> That is a completely disingenuous reading. If you take the entire 
> page as a whole, it's saying you can choose 0xfd with 0.9
> metadata, or you can choose 0xda with 1.x metadata. It is not
> suggesting use of 0xfd with 1.x metadata.

It is pretty clear to me that it is simply a suggestion and they make
it clear that it really doesn't matter.  Since it doesn't really
matter, and there appears to be no reason to add a new code instead of
sticking with 0xfd, I'm disinclined to needlessly complicate the
partitioning process any further for no gain.

> And this has sufficiently explained the conflict with using either 
> 0xfd or 0x83, even on Linux.

What conflict?  The only conflict I am aware of is user confusion over
which one to use, which will only be made worse by adding yet another
code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxCeUAAoJEI5FoCIzSKrwa0gIAKb8dZAM0it66Qt93bvRFxqW
hwCmXODFdysma1KfRPf2R2H9BCznllXhJa9MaVuTqaAH/9jzg46c8ZJeVktc5ULB
pn71qsVTbZq7FV6H1KLrt/01vAV/4Um9P23g6UH0tbZ/TS+leKe6SC1air8kb1pK
NakVg06iOWkgbJU7E0eZyjoz5dWmJ6gMBFrtE/BsagKFvkQIn/z39U9EY5DytNvf
woU18fuGeM6tWV7vnk/ug1bIBs1/zlhH/1e9CVTdcxXDvI/kOLcsRkHlMl+bNbhP
6ka6X6RusQaVNz5mX3exLl+aqVa2Y99WsiIKV4opIshxEdY1QmNuNbhLQcLHd9c=
=JB8g
-----END PGP SIGNATURE-----

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Chris Murphy <lists@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 20:04:01 +0000
Resent-Message-ID: <handler.17994.B17994.140536819928943 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: Phillip Susi <psusi@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.140536819928943
          (code B ref 17994); Mon, 14 Jul 2014 20:04:01 +0000
Received: (at 17994) by debbugs.gnu.org; 14 Jul 2014 20:03:19 +0000
Received: from localhost ([127.0.0.1]:54961 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6mSz-0007Wk-ME
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 16:03:18 -0400
Received: from [50.115.112.57] (port=48439 helo=slmp-550-94.slc.westdc.net)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <lists@HIDDEN>) id 1X6mSw-0007WP-0h
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 16:03:15 -0400
Received: from c-75-70-18-61.hsd1.co.comcast.net ([75.70.18.61]:58874
 helo=[192.168.1.145])
 by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128)
 (Exim 4.82) (envelope-from <lists@HIDDEN>)
 id 1X6mSo-00147G-DO; Mon, 14 Jul 2014 14:03:06 -0600
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Chris Murphy <lists@HIDDEN>
In-Reply-To: <53C42794.90002@HIDDEN>
Date: Mon, 14 Jul 2014 14:03:04 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <F11E17C1-1542-4AB4-9126-37267E40479B@HIDDEN>
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
 <53C3E34E.6010201@HIDDEN>
 <99BA9570-6751-4449-B202-52F057083D1B@HIDDEN>
 <53C41CB9.3040906@HIDDEN>
 <32C06FEE-E1C9-435B-925D-231359AC85F5@HIDDEN>
 <53C42794.90002@HIDDEN>
X-Mailer: Apple Mail (2.1510)
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net
X-AntiAbuse: Original Domain - debbugs.gnu.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - colorremedies.com
X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id:
 whatever@HIDDEN
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On Jul 14, 2014, at 12:55 PM, Phillip Susi <psusi@HIDDEN>
 wrote: > > What can legitimately happen now or in the future is anything
 and > everything since partition type codes are not standardized. The >
 question
 is, does apple actually look at the type code, or do they > work like Linux
 does and probe the actual contents? [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
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: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  On Jul 14, 2014, at 12:55 PM, Phillip Susi <psusi@HIDDEN>
    wrote: > > What can legitimately happen now or in the future is anything
   and > everything since partition type codes are not standardized. The > question
    is, does apple actually look at the type code, or do they > work like Linux
    does and probe the actual contents? [...] 
 
 Content analysis details:   (1.3 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS


On Jul 14, 2014, at 12:55 PM, Phillip Susi <psusi@HIDDEN> wrote:
>=20
> What can legitimately happen now or in the future is anything and
> everything since partition type codes are not standardized.  The
> question is, does apple actually look at the type code, or do they
> work like Linux does and probe the actual contents?

They look at the type code first. If it's a type code they support, but =
the partition isn't something they expect, they actively suggest the =
user initialize the partition. It's similar for Windows.




> In any case, if they already deal with 0xfd
> correctly, why change?

This is made clear in the mdadm page page, as well as the previously =
cited bug comment by Doug Ledford who is an md raid kernel developer.



>> That is a completely disingenuous reading. If you take the entire=20
>> page as a whole, it's saying you can choose 0xfd with 0.9
>> metadata, or you can choose 0xda with 1.x metadata. It is not
>> suggesting use of 0xfd with 1.x metadata.
>=20
> It is pretty clear to me that it is simply a suggestion and they make
> it clear that it really doesn't matter.

man 8 mdadm
"the partition type should be set to 0xDA"

Oxford American English:
should |SHo=CD=9Dod|
modalverb ( 3rd sing. should )
1 used to indicate obligation, duty, or correctness,

The man page goes on to explain the problem with using 0xfd or 0x83 for =
1.x metadata arrays.


>  Since it doesn't really
> matter, and there appears to be no reason to add a new code instead of
> sticking with 0xfd, I'm disinclined to needlessly complicate the
> partitioning process any further for no gain.

Right, let's wait for problems to happen rather than avoid them in the =
first place.


>=20
>> And this has sufficiently explained the conflict with using either=20
>> 0xfd or 0x83, even on Linux.
>=20
> What conflict?  The only conflict I am aware of is user confusion over
> which one to use, which will only be made worse by adding yet another
> code.

All the official documentation on mdadm explicitly recommends metadata =
v1.2 and type code 0xda. There is no confusion on this point. Saying =
there is doesn't make it true.

0xfd is defined as "Linux raid autodetect" which is what parted also =
calls it. But mdadm metadata 1.x is not autodetect. And you're saying =
calling it the wrong thing is nevertheless still OK because it doesn't =
matter. It's fingers in the ears lalala logic.


Chris Murphy

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Phillip Susi <psusi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 21:03:02 +0000
Resent-Message-ID: <handler.17994.B17994.14053717602603 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: Chris Murphy <lists@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.14053717602603
          (code B ref 17994); Mon, 14 Jul 2014 21:03:02 +0000
Received: (at 17994) by debbugs.gnu.org; 14 Jul 2014 21:02:40 +0000
Received: from localhost ([127.0.0.1]:55029 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6nOR-0000fu-2D
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 17:02:39 -0400
Received: from mail-yk0-f173.google.com ([209.85.160.173]:48436)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <phillsusi@HIDDEN>) id 1X6nON-0000ff-VH
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 17:02:37 -0400
Received: by mail-yk0-f173.google.com with SMTP id q200so1710055ykb.32
 for <17994 <at> debbugs.gnu.org>; Mon, 14 Jul 2014 14:02:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
 :references:in-reply-to:content-type:content-transfer-encoding;
 bh=iSyk+X+U6OX6Q8YLvVWjREouuDJWTY65xNxuDod7u0Y=;
 b=oFYYnVxKbQLikfgB97mPQ63Cy0NvW8Xf0Dyc30NT13wDqugDg90awxoAEz2hA3p6mk
 EEjqm9Nj7TzO0r5kX1UeomFxpdB8O9y0i35rlaVIe0cTiVXHQhpn1PqebLjckiEJHmt+
 4ipIiIj5Tnto1vx9N0GnuyHKJomYFSfaaES4HPZxnhLx4eySOtypQWToHg88tThPVpE4
 CxiIRg2o/WBH8eAzet4pO5zDV+fGSENzG0pFtCOvMMJZeGp7li1vBI1UxyoKYm2BC1r4
 q6Um6cl5HI7apR7N8f9mHWUodSb6jNxLjhy/QvC4lUuvpZonOEXbf/hMiW1hfOtbFahQ
 ImjQ==
X-Received: by 10.236.1.36 with SMTP id 24mr33254286yhc.45.1405371750225;
 Mon, 14 Jul 2014 14:02:30 -0700 (PDT)
Received: from [10.1.1.202] (fl-67-77-88-12.sta.embarqhsd.net. [67.77.88.12])
 by mx.google.com with ESMTPSA id
 d66sm23220760yhd.41.2014.07.14.14.02.29 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Mon, 14 Jul 2014 14:02:29 -0700 (PDT)
Message-ID: <53C44574.2040809@HIDDEN>
Date: Mon, 14 Jul 2014 17:02:44 -0400
From: Phillip Susi <psusi@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
 <53C3E34E.6010201@HIDDEN>
 <99BA9570-6751-4449-B202-52F057083D1B@HIDDEN>
 <53C41CB9.3040906@HIDDEN>
 <32C06FEE-E1C9-435B-925D-231359AC85F5@HIDDEN>
 <53C42794.90002@HIDDEN>
 <F11E17C1-1542-4AB4-9126-37267E40479B@HIDDEN>
In-Reply-To: <F11E17C1-1542-4AB4-9126-37267E40479B@HIDDEN>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
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.7 (/)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/2014 4:03 PM, Chris Murphy wrote:
> They look at the type code first. If it's a type code they support,
> but the partition isn't something they expect, they actively
> suggest the user initialize the partition. It's similar for
> Windows.

Right, so they look for their own type code and ignore everything else,
including 0x83 and 0xfd.

>> In any case, if they already deal with 0xfd correctly, why 
>> change?
> 
> This is made clear in the mdadm page page, as well as the 
> previously cited bug comment by Doug Ledford who is an md raid 
> kernel developer.

No, it isn't... the only thing it says about it is that it "might create
problems in the event of array recovery through a live cdrom" which is
hand waving.

> man 8 mdadm "the partition type should be set to 0xDA"
> 
> Oxford American English: should |SHo͝od| modalverb ( 3rd sing. 
> should ) 1 used to indicate obligation, duty, or correctness,
> 
> The man page goes on to explain the problem with using 0xfd or 0x83
> for 1.x metadata arrays.

Previously you referred to the wiki page which made it clear that it
doesn't matter.  Now you point to the man page, which yes, does say to
use 0xda, but fails to explain why beyond hand waving.

> Right, let's wait for problems to happen rather than avoid them in
>  the first place.

Right, let's needlessly complicate users lives' over hypothetical
hand waving.

0xfd already tells all who care to keep their mitts off unless they
understand mdadm.  I have yet to see any concrete reason, even a
hypothetical one, for adding a new type to differentiate between 0.9 and
1.x.

> 0xfd is defined as "Linux raid autodetect" which is what parted 
> also calls it. But mdadm metadata 1.x is not autodetect. And
> you're saying calling it the wrong thing is nevertheless still OK
> because it doesn't matter. It's fingers in the ears lalala logic.

So remove the word "autodetect" if you don't like it.  What difference
does it make?  Most people see the word raid and figure that's what
they should use.  "But it isn't really autodetect!" or other semantic
arguments is not a good reason to add yet another code.

Are we also supposed to allocate a new GUID for GPT partitions?  The
man page is mum on that subject.  That, combined with the hand waving
explanation given, indicates that this was not well thought out when
it was added to the man page.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxEV0AAoJEI5FoCIzSKrw/QYH/2kXm3BOmoI85jvfBzGGankR
RDmcEtfQ/NX6wOR6vnUJS5gbLam5IuO6bSwVI9kn8PmYKI9RtKAaqwd0AAClp4oC
KxnRyJAVjnsdjSEIckeAcbGuJzwJAsKHso0ucMznXcqfmLZxdeNLeJg+yF3MBd9T
GVcnuE4PJ4t5my1QkUsHQ4wR5tO0kOrKLygTHq/2zlI/n2dl6hMrwtsG3AkkwdXG
Tcnc1/v9aFUZIir86jPV8GK1eGKdDjq1u749/2/6NE0q+z8JHAF6K0Pv97+d4wbO
iGIuEKpITKyNMq0ncetWTq8gUBZ0H26kwFXyL/NzXr3iZW/l5cT5N+Bhs17Xj6I=
=KE9o
-----END PGP SIGNATURE-----

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Chris Murphy <lists@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Mon, 14 Jul 2014 22:59:02 +0000
Resent-Message-ID: <handler.17994.B17994.140537870913839 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: Phillip Susi <psusi@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.140537870913839
          (code B ref 17994); Mon, 14 Jul 2014 22:59:02 +0000
Received: (at 17994) by debbugs.gnu.org; 14 Jul 2014 22:58:29 +0000
Received: from localhost ([127.0.0.1]:55073 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6pCW-0003b8-Iq
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 18:58:29 -0400
Received: from [50.115.112.57] (port=33185 helo=slmp-550-94.slc.westdc.net)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <lists@HIDDEN>) id 1X6pCT-0003an-DX
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 18:58:26 -0400
Received: from c-75-70-18-61.hsd1.co.comcast.net ([75.70.18.61]:61360
 helo=[192.168.1.145])
 by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128)
 (Exim 4.82) (envelope-from <lists@HIDDEN>)
 id 1X6pCL-003d0S-7z; Mon, 14 Jul 2014 16:58:17 -0600
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Chris Murphy <lists@HIDDEN>
In-Reply-To: <53C44574.2040809@HIDDEN>
Date: Mon, 14 Jul 2014 16:58:15 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <B8E2DC90-788F-4670-9177-52311275A35B@HIDDEN>
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
 <53C3E34E.6010201@HIDDEN>
 <99BA9570-6751-4449-B202-52F057083D1B@HIDDEN>
 <53C41CB9.3040906@HIDDEN>
 <32C06FEE-E1C9-435B-925D-231359AC85F5@HIDDEN>
 <53C42794.90002@HIDDEN>
 <F11E17C1-1542-4AB4-9126-37267E40479B@HIDDEN>
 <53C44574.2040809@HIDDEN>
X-Mailer: Apple Mail (2.1510)
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net
X-AntiAbuse: Original Domain - debbugs.gnu.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - colorremedies.com
X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id:
 whatever@HIDDEN
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On Jul 14, 2014, at 3:02 PM, Phillip Susi <psusi@HIDDEN>
 wrote: >>> In any case, if they already deal with 0xfd correctly, why >>>
 change? >> >> This is made clear in the mdadm page page, as well as the >>
 previously cited bug comment by Doug Ledford who is an md raid >> kernel
 developer. > > No, it isn't... the only thing it says about it is that it
 "might create > problems in the event of array recovery through a live cdrom"
 which is > hand waving. [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
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: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  On Jul 14, 2014, at 3:02 PM, Phillip Susi <psusi@HIDDEN>
    wrote: >>> In any case, if they already deal with 0xfd correctly, why >>>
    change? >> >> This is made clear in the mdadm page page, as well as the >>
    previously cited bug comment by Doug Ledford who is an md raid >> kernel
   developer. > > No, it isn't... the only thing it says about it is that it
   "might create > problems in the event of array recovery through a live cdrom"
    which is > hand waving. [...] 
 
 Content analysis details:   (1.3 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS


On Jul 14, 2014, at 3:02 PM, Phillip Susi <psusi@HIDDEN> wrote:


>>> In any case, if they already deal with 0xfd correctly, why=20
>>> change?
>>=20
>> This is made clear in the mdadm page page, as well as the=20
>> previously cited bug comment by Doug Ledford who is an md raid=20
>> kernel developer.
>=20
> No, it isn't... the only thing it says about it is that it "might =
create
> problems in the event of array recovery through a live cdrom" which is
> hand waving.

This is just changing the goal posts. You asked why change, I provided =
several reasons, you come back with "hand waving" for only one of those =
reasons, and ignore the three comments in the bug report. The type code =
exists whether parted supports it or not, it's what the md kernel =
developers decided on. And fdisk supports it.



>=20
>> man 8 mdadm "the partition type should be set to 0xDA"
>>=20
>> Oxford American English: should |SHo=CD=9Dod| modalverb ( 3rd sing.=20=

>> should ) 1 used to indicate obligation, duty, or correctness,
>>=20
>> The man page goes on to explain the problem with using 0xfd or 0x83
>> for 1.x metadata arrays.
>=20
> Previously you referred to the wiki page which made it clear that it
> doesn't matter.  Now you point to the man page, which yes, does say to
> use 0xda, but fails to explain why beyond hand waving.

No you've only dismissed their explanations by citing opinion, i.e. =
actual hand waving without explanation. There's a difference.

>=20
>> Right, let's wait for problems to happen rather than avoid them in
>> the first place.
>=20
> Right, let's needlessly complicate users lives' over hypothetical
> hand waving.

And appealing to users is rather ridiculous, because if you cared about =
users even remotely experiencing data loss/corruption, which is the =
proposed concern, you'd have have done an "oops yeah we should add this" =
rather than protect a piece of petrified dog crap.

>=20
> 0xfd already tells all who care to keep their mitts off unless they
> understand mdadm.  I have yet to see any concrete reason, even a
> hypothetical one, for adding a new type to differentiate between 0.9 =
and
> 1.x.

Considering several have been hypothesized, you've labeled them hand =
waving, and now they're dismissed entirely is=E2=80=A6 more weird than =
amusing.



>=20
>> 0xfd is defined as "Linux raid autodetect" which is what parted=20
>> also calls it. But mdadm metadata 1.x is not autodetect. And
>> you're saying calling it the wrong thing is nevertheless still OK
>> because it doesn't matter. It's fingers in the ears lalala logic.
>=20
> So remove the word "autodetect" if you don't like it.  What difference
> does it make?

Because words should have meaning. What's the point of labeling things =
incorrectly when it's not difficult to name them correctly?

>  Most people see the word raid and figure that's what
> they should use.  "But it isn't really autodetect!" or other semantic
> arguments is not a good reason to add yet another code.

That's exactly backwards for two reasons: forcing usage of inapplicable =
semantics is wrong because it causes confusion; and the other is that =
it's not only a semantic difference but the Linux kernel in fact behaves =
differently based on the two partition types.

> Are we also supposed to allocate a new GUID for GPT partitions?

To comply with the UEFI spec, yes. Technically every filesystem must =
have its own partitiontype GUID.=20

But seeing as the kernel apparently doesn't look for the Linux RAID =
partitiontype GUID, RAID autodetect (version 0.9 mdadm metadata) is not =
supported on GPT disks, and in any case is considered deprecated so the =
lack of a GPT equivalent for 0xfd seems inconsequential.


>  The
> man page is mum on that subject.  That, combined with the hand waving
> explanation given, indicates that this was not well thought out when
> it was added to the man page.

Right, the kernel developers attempting to avoid, as much as practical, =
the possibility of confusion down the road were thoughtless; rather than =
the person who's arguing in favor of not thinking or doing anything =
about it until there's an actual manifested problem.=20


Chris Murphy=

Message sent to bug-parted@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17994: Linux RAID MBR type code
Resent-From: Phillip Susi <psusi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-parted@HIDDEN
Resent-Date: Tue, 15 Jul 2014 03:21:02 +0000
Resent-Message-ID: <handler.17994.B17994.14053944177565 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17994
X-GNU-PR-Package: parted
X-GNU-PR-Keywords: 
To: Chris Murphy <lists@HIDDEN>
Cc: 17994 <at> debbugs.gnu.org
Received: via spool by 17994-submit <at> debbugs.gnu.org id=B17994.14053944177565
          (code B ref 17994); Tue, 15 Jul 2014 03:21:02 +0000
Received: (at 17994) by debbugs.gnu.org; 15 Jul 2014 03:20:17 +0000
Received: from localhost ([127.0.0.1]:55177 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1X6tHs-0001xv-38
	for submit <at> debbugs.gnu.org; Mon, 14 Jul 2014 23:20:16 -0400
Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.227]:13936
 helo=cdptpa-oedge-vip.email.rr.com)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <psusi@HIDDEN>) id 1X6tHp-0001xg-Ab
 for 17994 <at> debbugs.gnu.org; Mon, 14 Jul 2014 23:20:14 -0400
Received: from [72.238.67.160] ([72.238.67.160:43503] helo=[192.168.1.102])
 by cdptpa-oedge01 (envelope-from <psusi@HIDDEN>)
 (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP
 id B1/1C-14952-7ED94C35; Tue, 15 Jul 2014 03:20:07 +0000
Message-ID: <53C49DE7.6010804@HIDDEN>
Date: Mon, 14 Jul 2014 23:20:07 -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
References: <F4909400-A44D-45EA-A08D-12D95ED23E81@HIDDEN>
 <53C30B31.8080500@HIDDEN>
 <B5D2617B-2DFC-4C62-BF87-8DA229ED3C98@HIDDEN>
 <53C3E34E.6010201@HIDDEN>
 <99BA9570-6751-4449-B202-52F057083D1B@HIDDEN>
 <53C41CB9.3040906@HIDDEN>
 <32C06FEE-E1C9-435B-925D-231359AC85F5@HIDDEN>
 <53C42794.90002@HIDDEN>
 <F11E17C1-1542-4AB4-9126-37267E40479B@HIDDEN>
 <53C44574.2040809@HIDDEN>
 <B8E2DC90-788F-4670-9177-52311275A35B@HIDDEN>
In-Reply-To: <B8E2DC90-788F-4670-9177-52311275A35B@HIDDEN>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-RR-Connecting-IP: 107.14.168.118:25
X-Cloudmark-Score: 0
X-Spam-Score: 0.0 (/)
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 06:58 PM, Chris Murphy wrote:
> This is just changing the goal posts. You asked why change, I 
> provided several reasons, you come back with "hand waving" for
> only one of those reasons, and ignore the three comments in the
> bug report. The type code exists whether parted supports it or not,
> it's what the md kernel developers decided on. And fdisk supports
> it.

You have provided only one reason: the mdadm man page says to.  I
don't see anything in the comments of the bug or your responses in
this thread beyond that.

> No you've only dismissed their explanations by citing opinion,
> i.e. actual hand waving without explanation. There's a difference.

I haven't cited anything; only called for an explanation.  The man
page explanation is vague to the point of being meaningless.

> And appealing to users is rather ridiculous, because if you cared 
> about users even remotely experiencing data loss/corruption, which
> is the proposed concern, you'd have have done an "oops yeah we
> should add this" rather than protect a piece of petrified dog
> crap.

Only if there is a viable way that not adding it could be harmful,
which so far, you have yet to demonstrate.

> Considering several have been hypothesized, you've labeled them
> hand waving, and now they're dismissed entirely is… more weird
> than amusing.

Where?  The single thing I have seen so far is "recovery from a live
cd may ( how? ) be a problem.

> Because words should have meaning. What's the point of labeling 
> things incorrectly when it's not difficult to name them correctly?

Because arguing semantics is a pointless waste of time.  If the name
of the existing type does not quite apply, then clarify the name --
don't create a whole new type code instead.  Especially since the
previous "autodetect" use is deprecated and therefore is ripe for
reuse, especially in a wholly compatible and orthogonal way.

> That's exactly backwards for two reasons: forcing usage of 
> inapplicable semantics is wrong because it causes confusion; and
> the other is that it's not only a semantic difference but the
> Linux kernel in fact behaves differently based on the two partition
> types.

It does not behave any differently.  As long as you are using metadata
1.x, you get the same results whether you use 0xFD or 0xDA ( or any
other code ).  The only time you get different results is if you use
metadata 0.9, boot with a kernel that has md built in, the deprecated
auto assemble option enabled, and no initramfs.

> To comply with the UEFI spec, yes. Technically every filesystem
> must have its own partitiontype GUID.

That would have been nice but unfortunately the ship has already
sailed on that: the Linux community is not going to do this.  For that
matter Microsoft uses a single code for the two filesystems they support.

> But seeing as the kernel apparently doesn't look for the Linux
> RAID partitiontype GUID, RAID autodetect (version 0.9 mdadm
> metadata) is not supported on GPT disks, and in any case is
> considered deprecated so the lack of a GPT equivalent for 0xfd
> seems inconsequential.

The argument wasn't about whether Linux will auto assemble, but
whether another OS will auto mount without understanding the mdadm
metadata.  If you need to use a special type code to prevent non linux
OSes from mounting the partition, then that should apply under both
MBR and GPT.

For that matter, the whole reason for using format 1.0 on a mirror (
instead of the default 1.2, or 1.1 ) is so that you can mount the
volume in a non mdadm aware OS for recovery.  If that is what you
desire, why would you defeat it with the type code ( and why yet
another type code instead of the existing 0xFD, which already
accomplishes that? ).

> Right, the kernel developers attempting to avoid, as much as 
> practical, the possibility of confusion down the road were 
> thoughtless; rather than the person who's arguing in favor of not 
> thinking or doing anything about it until there's an actual 
> manifested problem.

I'm open to a hypothetical problem too, provided that it is actually
thought out and described instead of left to vague statements like
"maybe something with a livecd".

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

iQEcBAEBCgAGBQJTxJ3nAAoJEI5FoCIzSKrwcOYIAJs1CLCdrR1Bnv19+/QCenEe
SM1qdFoDqCYnEafUn9V4Z2liJbB+OUN6z5rFWBqP/MNILmv/A0cv4HwagKoWPExO
ciU51D1pqQbQH+m6tSmhevAzH3rLpHdQKk6xxt4pPAkHcVCfyyn5Brz55nc0bxIF
2TI6GcqtJ8WMqu5YuHGe6CV0uYCrJFzC0C1YLcm1zWR7THaaVg2AIN20+Qi4z1n3
xDh4Mgfb5k6Yqc2urMiHmaRfw8Af6tJXFQW+JXejTnHixk3+AE/9dTmv2cGpHbmT
2YXIdVr0+RKZJSUg51NlMjC1TAOwgIe0CRPhPQTtwZCMTtCpWcs8PLfrRj1k5FU=
=xtnj
-----END PGP SIGNATURE-----

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.