Package: parted;
Reported by: Frédéric Martinsons <frederic.martinsons <at> gmail.com>
Date: Thu, 26 Jan 2023 14:16:01 UTC
Severity: normal
Done: "Brian C. Lane" <bcl <at> redhat.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61076 in the body.
You can then email your comments to 61076 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-parted <at> gnu.org
:bug#61076
; Package parted
.
(Thu, 26 Jan 2023 14:16:01 GMT) Full text and rfc822 format available.Frédéric Martinsons <frederic.martinsons <at> gmail.com>
:bug-parted <at> gnu.org
.
(Thu, 26 Jan 2023 14:16:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Frédéric Martinsons <frederic.martinsons <at> gmail.com> To: bug-parted <at> gnu.org Subject: Change in MBR between parted 3.2 and 3.3 Date: Thu, 26 Jan 2023 11:52:36 +0100
Hello, I have an arm based board with an eMMC card for storage. I cross compil an GNU/Linux OS (with yocto) for this boardand and I came across an issue after updating parted to 3.3 and above. Below are my commands to partition the 4GB storage (2 partitions of 1.8GB, 1 bootable partition of 400MB) : :~# parted /dev/mmcblk0 mklabel msdos :~# parted -a none /dev/mmcblk0 unit s mkpart primary ext4 2048 3474431 :~# parted -a none /dev/mmcblk0 unit s mkpart primary ext4 3474432 6946815 :~# parted -a none /dev/mmcblk0 unit s mkpart primary ext4 6946816 7733247 :~# parted /dev/mmcblk0 set 3 boot on With parted 3.2, I have the following MBR: :~# hexdump -n 1024 -C /dev/mmcblk0 00000000 fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |................| 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..| 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u| 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..| 00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 34 15 3b 6e 00 00 00 20 |........4.;n... | 000001c0 21 00 83 45 2d d8 00 08 00 00 00 fc 34 00 00 45 |!..E-.......4..E| 000001d0 2e d8 83 6a 7a b0 00 04 35 00 00 fc 34 00 80 6a |...jz...5...4..j| 000001e0 7b b0 83 5e 7d e1 00 00 6a 00 00 00 0c 00 00 00 |{..^}...j.......| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 With parted 3.3, I have that: :~# hexdump -n 1024 -C /dev/mmcblk0 00000000 fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |................| 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..| 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u| 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..| 00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 85 1a 7c 02 00 00 00 04 |..........|.....| 000001c0 01 04 83 fe c2 ff 00 08 00 00 00 fc 34 00 00 fe |............4...| 000001d0 c2 ff 83 fe c2 ff 00 04 35 00 00 fc 34 00 80 fe |........5...4...| 000001e0 c2 ff 83 fe c2 ff 00 00 6a 00 00 00 0c 00 00 00 |........j.......| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 The first and last CHS address of the partition entries are completely different and for the entry 2 and 3, first address is equal to the last ! Below is more information by parted 3.2: :~# parted /dev/mmcblk0 print unit s print unit chs print Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 3959MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 1779MB 1778MB primary 2 1779MB 3557MB 1778MB primary 3 3557MB 3959MB 403MB primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 7733248s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 2048s 3474431s 3472384s primary 2 3474432s 6946815s 3472384s primary 3 6946816s 7733247s 786432s primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 481,94,60 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 481,255,63. Each cylinder is 8225kB. Partition Table: msdos Disk Flags: Number Start End Type File system Flags 1 0,32,32 216,69,44 primary 2 216,69,45 432,106,57 primary 3 432,106,58 481,94,60 primary ext4 boot And the same with parted 3.3: :~# parted /dev/mmcblk0 print unit s print unit chs print Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 3959MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 1779MB 1778MB primary 2 1779MB 3557MB 1778MB primary 3 3557MB 3959MB 403MB primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 7733248s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 2048s 3474431s 3472384s primary 2 3474432s 6946815s 3472384s primary 3 6946816s 7733247s 786432s primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 15163,58,1 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 15163,255,2. Each cylinder is 261kB. Partition Table: msdos Disk Flags: Number Start End Type File system Flags 1 4,4,0 6812,155,1 primary 2 6812,156,0 13621,52,1 primary 3 13621,53,0 15163,58,1 primary ext4 boot The main difference I spotted is the BIOS geometry: - parted 3.2: 481 cylinder, 255 head, 63 sector (cylinder size 8225 kB) - parted 3.3: 15163 cylinder, 255 head, 2 sector (cylinder size 261 kB) I also tested parted 3.4 and parted 3.5 with the same result. Nevertheless, the partition table created by parted 3.3 and above is perfectly usable from what I see. Long story short, do you know the origin of this discrepancy (I didn't see nothing in release not that could explain that though I obviously don't understan all the mechanics) and if it is possible to come back to the same kind of MBR generated by parted 3.2 ? One additional question arises for my understanding though, how come a partition with CHS address of the first sector equal to the last one is usable ? Thanks in advance for all insights/advices you can bring to my issue.
"Brian C. Lane" <bcl <at> redhat.com>
:Frédéric Martinsons <frederic.martinsons <at> gmail.com>
:Message #10 received at 61076-close <at> debbugs.gnu.org (full text, mbox):
From: "Brian C. Lane" <bcl <at> redhat.com> To: Frédéric Martinsons <frederic.martinsons <at> gmail.com> Cc: 61076-close <at> debbugs.gnu.org Subject: Re: bug#61076: Change in MBR between parted 3.2 and 3.3 Date: Thu, 26 Jan 2023 08:28:18 -0800
On Thu, Jan 26, 2023 at 11:52:36AM +0100, Frédéric Martinsons wrote: > Hello, > > I have an arm based board with an eMMC card for storage. > I cross compil an GNU/Linux OS (with yocto) for this boardand and I came > across an issue after updating parted to 3.3 and above. [snip] > > The main difference I spotted is the BIOS geometry: > - parted 3.2: 481 cylinder, 255 head, 63 sector (cylinder size 8225 kB) > - parted 3.3: 15163 cylinder, 255 head, 2 sector (cylinder size 261 kB) > > I also tested parted 3.4 and parted 3.5 with the same result. > Nevertheless, the partition table created by parted 3.3 and above is > perfectly usable from what I see. > > Long story short, do you know the origin of this discrepancy (I didn't > see nothing > in release not that could explain that though I obviously don't understan all > the mechanics) and if it is possible to come back to the same kind of > MBR generated > by parted 3.2 ? This change was introduced by commit 61dd3d4c5eb782eb43caa95342e63727db3f8281, it was needed to fix problems growing partitions when using SD cards on the Raspberry Pi. > One additional question arises for my understanding though, how come a partition > with CHS address of the first sector equal to the last one is usable ? Well, nothing should be actually using the CHS values these days. So it's possible that's a bug that doesn't matter in practice, but I'll have to look into that. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
bug-parted <at> gnu.org
:bug#61076
; Package parted
.
(Thu, 26 Jan 2023 16:54:01 GMT) Full text and rfc822 format available.Message #13 received at 61076 <at> debbugs.gnu.org (full text, mbox):
From: Frédéric Martinsons <frederic.martinsons <at> gmail.com> To: 61076 <at> debbugs.gnu.org Subject: Re: Change in MBR between parted 3.2 and 3.3 Date: Thu, 26 Jan 2023 17:39:24 +0100
> This change was introduced by commit > 61dd3d4c5eb782eb43caa95342e63727db3f8281, it was needed to fix problems > growing partitions when using SD cards on the Raspberry Pi. OK , thank you very much for the explanation. Since I don't use raspberry Pi among my targets, do you think I can safely run a custom parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > Well, nothing should be actually using the CHS values these days. So > it's possible that's a bug that doesn't matter in practice, but I'll > have to look into that. OK I understand, since you close the present bug, do you know where I can have your conclusion when you'll have time to look at it ? Thanks again for the quick answer by the way.
bug-parted <at> gnu.org
:bug#61076
; Package parted
.
(Fri, 27 Jan 2023 09:54:01 GMT) Full text and rfc822 format available.Message #16 received at 61076 <at> debbugs.gnu.org (full text, mbox):
From: Frédéric Martinsons <frederic.martinsons <at> gmail.com> To: "Brian C. Lane" <bcl <at> redhat.com>, 61076 <at> debbugs.gnu.org Subject: Re: bug#61076: Change in MBR between parted 3.2 and 3.3 Date: Fri, 27 Jan 2023 09:14:01 +0100
[Message part 1 (text/plain, inline)]
> > OK , thank you very much for the explanation. Since I don't use > > raspberry Pi among my targets, do you think I can safely run a custom > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > That's probably fine, as long as you know what you are doing ;) Ok I'll go this way, thanks. > > OK I understand, since you close the present bug, do you know where I > > can have your conclusion when you'll have time to look at it ? > > > > Thanks again for the quick answer by the way. > I'm *hoping* to get a new parted release ready sometime soon, but I'm > not yet sure when. I have a few other things to review and I'll take a > look at this at the same time to make sure it's not a bug. Fine, I'll keep a look to the parted release then ;) By the way, I come up with a patch (joined) which is a mix of revert 61dd3d4c5eb782eb43caa95342e63727db3f8281 and taken into account 52360db2f5397b7842d2ed90bf946c5e8fa91750 (which mention some kind of regression too): Have a nice day On Thu, 26 Jan 2023 at 19:50, Brian C. Lane <bcl <at> redhat.com> wrote: > > On Thu, Jan 26, 2023 at 05:39:24PM +0100, Frédéric Martinsons wrote: > > > This change was introduced by commit > > > 61dd3d4c5eb782eb43caa95342e63727db3f8281, it was needed to fix problems > > > growing partitions when using SD cards on the Raspberry Pi. > > > > OK , thank you very much for the explanation. Since I don't use > > raspberry Pi among my targets, do you think I can safely run a custom > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > > That's probably fine, as long as you know what you are doing ;) > > > > > > Well, nothing should be actually using the CHS values these days. So > > > it's possible that's a bug that doesn't matter in practice, but I'll > > > have to look into that. > > > > OK I understand, since you close the present bug, do you know where I > > can have your conclusion when you'll have time to look at it ? > > > > Thanks again for the quick answer by the way. > > I'm *hoping* to get a new parted release ready sometime soon, but I'm > not yet sure when. I have a few other things to review and I'll take a > look at this at the same time to make sure it's not a bug. > > Brian > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart >
[0001-Get-back-the-old-way-of-getting-device-geometry-info.patch (text/x-patch, attachment)]
bug-parted <at> gnu.org
:bug#61076
; Package parted
.
(Fri, 27 Jan 2023 14:29:01 GMT) Full text and rfc822 format available.Message #19 received at 61076 <at> debbugs.gnu.org (full text, mbox):
From: Frédéric Martinsons <frederic.martinsons <at> gmail.com> To: "Brian C. Lane" <bcl <at> redhat.com>, 61076 <at> debbugs.gnu.org Subject: Re: bug#61076: Change in MBR between parted 3.2 and 3.3 Date: Fri, 27 Jan 2023 11:58:22 +0100
After more testing with the mentioned patch applied on parted 3.3, I still have differences on the MBR toward parted 3.2, below is what I got now: :~# hexdump -n 1024 -C /dev/mmcblk0 00000000 fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |................| 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..| 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u| 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..| 00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 11 95 8b 42 00 00 00 00 |...........B....| 000001c0 01 20 83 03 d0 ff 00 08 00 00 00 fc 34 00 00 03 |. ..........4...| 000001d0 d0 ff 83 03 d0 ff 00 04 35 00 00 fc 34 00 80 03 |........5...4...| 000001e0 d0 ff 83 03 d0 ff 00 00 6a 00 00 00 0c 00 00 00 |........j.......| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| And the partition table info: :~# parted /dev/mmcblk0 print unit s print unit chs print Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 3959MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 1779MB 1778MB primary 2 1779MB 3557MB 1778MB primary 3 3557MB 3959MB 403MB primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 7733248s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 2048s 3474431s 3472384s primary 2 3474432s 6946815s 3472384s primary 3 6946816s 7733247s 786432s primary ext4 boot Model: MMC 004GA0 (sd/mmc) Disk /dev/mmcblk0: 120831,3,15 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 120832,4,16. Each cylinder is 32.8kB. Partition Table: msdos Disk Flags: Number Start End Type File system Flags 1 32,0,0 54287,3,15 primary 2 54288,0,0 108543,3,15 primary 3 108544,0,0 120831,3,15 primary ext4 boot In parted 3.2, I had the following geometry: BIOS cylinder,head,sector geometry: 481,255,63. Each cylinder is 8225kB. In 3.3 vanilla: BIOS cylinder,head,sector geometry: 15163,255,2. Each cylinder is 261kB. In 3.3 patched: BIOS cylinder,head,sector geometry: 120832,4,16. Each cylinder is 32.8kB. Like you said earlier "nothing should be actually using the CHS values these days", and indeed my system could be bootable with these changes, but my problem is that I have a TPM chip which check the content of the MBR and refuses to continue booting process if the content of it is not what is expected. Do you see other changes that have been made in parted 3.3 which impact the MBR content in such a way ? On Fri, 27 Jan 2023 at 09:14, Frédéric Martinsons <frederic.martinsons <at> gmail.com> wrote: > > > > OK , thank you very much for the explanation. Since I don't use > > > raspberry Pi among my targets, do you think I can safely run a custom > > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > > > That's probably fine, as long as you know what you are doing ;) > > Ok I'll go this way, thanks. > > > > OK I understand, since you close the present bug, do you know where I > > > can have your conclusion when you'll have time to look at it ? > > > > > > Thanks again for the quick answer by the way. > > > I'm *hoping* to get a new parted release ready sometime soon, but I'm > > not yet sure when. I have a few other things to review and I'll take a > > look at this at the same time to make sure it's not a bug. > > Fine, I'll keep a look to the parted release then ;) > By the way, I come up with a patch (joined) which is a mix of revert > 61dd3d4c5eb782eb43caa95342e63727db3f8281 and > taken into account 52360db2f5397b7842d2ed90bf946c5e8fa91750 > (which mention some kind of regression too): > > Have a nice day > > On Thu, 26 Jan 2023 at 19:50, Brian C. Lane <bcl <at> redhat.com> wrote: > > > > On Thu, Jan 26, 2023 at 05:39:24PM +0100, Frédéric Martinsons wrote: > > > > This change was introduced by commit > > > > 61dd3d4c5eb782eb43caa95342e63727db3f8281, it was needed to fix problems > > > > growing partitions when using SD cards on the Raspberry Pi. > > > > > > OK , thank you very much for the explanation. Since I don't use > > > raspberry Pi among my targets, do you think I can safely run a custom > > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > > > > That's probably fine, as long as you know what you are doing ;) > > > > > > > > > Well, nothing should be actually using the CHS values these days. So > > > > it's possible that's a bug that doesn't matter in practice, but I'll > > > > have to look into that. > > > > > > OK I understand, since you close the present bug, do you know where I > > > can have your conclusion when you'll have time to look at it ? > > > > > > Thanks again for the quick answer by the way. > > > > I'm *hoping* to get a new parted release ready sometime soon, but I'm > > not yet sure when. I have a few other things to review and I'll take a > > look at this at the same time to make sure it's not a bug. > > > > Brian > > > > -- > > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > >
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Sat, 25 Feb 2023 12:24:13 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.