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.martins...@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 <b...@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
> >



Reply via email to