Hi Christian,
please stop placing your replies underneath the previous mail's
signature separator. There are mail clients that won't copy such text
when composing a reply.
Am 02.07.2023 um 21:34 schrieb Christian Zigotzky:
On 2. Jul 2023, at 10:56, Christian Zigotzky <chzigotzky@xxxxxxxxxxx> wrote:
On 2. Jul 2023, at 09:55, Martin Steigerwald <martin@xxxxxxxxxxxx> wrote:
How many end users are you speaking of?
Back then I thought I was the only one using a hard disk with mixed
Amiga/Linux RDB setup.
Best,
Martin
A lot. I am speaking about the new A-EON machines.
The end users have to fix their RDBs if they want to use the new patched kernels.
So what you're saying is that you have let your end users use RDB
partitions on the old kernels that had a bug against them in the RDB
code for eleven years, and proposed bugfixes for as long, patches to
resolve the problem submitted to linux-block for the last five years,
and you never once stopped to investigate what the ramifications of this
bug were, and what the consequences of the proposed bugfix would be?
The discussion of this bug among Martin, Joanne and Geert didn't leave a
lot to imagination as regards data corruption potential.
But a normal user can’t edit the RDB manually. What can we do for the end users?
End users can use whatever tool they happened to use to partition the
disk in the first instance, and correct the partition table that way.
Leaving 8 GB unused at the end of the disk can't be some feature of
Amiga partition editors, leastways not one that can't be overridden?
But if you want to support your large userbase by a convenient solution,
may I suggest you write a small tool that gets the disks's end cylinder
from the RDB (field rdb_HiCylinder, offset 0x8c), then walk the
partition list starting from rdb_PartitionList for the first partition
block, then pb_Next for the next one, find the last valid partition
(where pb_Next is 0xffffffff), and check whether the partition size
calculation for that partition (in 32 bit arithmetic) would cause the
partition end to land beyond EOD. If that is the case, the old kernel
code would have truncated that partition to exactly EOD, and you have to
change the partition end cylinder value (offset 0xa8 from the start of
that partition block) to the value of rdb_HiCylinder. Adjust the
partition checksum (offset 0x8) by the difference of the old and new
values (i.e. add (old-new) to the checksum stored there) and you should
have a valid partition to the end of the disk.
Might be a bit tough in a shell script but not too hard in Perl or Python.
Putting that kind of fix in the kernel would be asking Jens and Linus
(and quite a few others) to yell at me and call me names, and for very
good reason (but of course you can always do that in kernels you
distribute to your end users).
Cheers,
Michael
