Re: hfsprogs: Removal of sys/sysctl.h
Hi all,
I burn the iso again as Thomas suggested with this command:
> xorriso -as cdrecord \
> -v dev=/dev/sr0 blank=as_needed -eject padsize=300k \
> -sao debian-10.0.0-powerpc-NETINST-1.iso
If I boot and try to mount the CDROM it fails again to mount the CDROM but I don't see the kernel messages as before. I mean, these ones:
> > kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Sense Key : Illegal Request
> > kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Illegal mode for
> > this track
> > ...
> > kernel: [timestamp] attempt to access beyond end device
> > kernel: [timestamp] sr0: rw=0, want 640412, limit 640408
So Thomas was right about that one. I tried several ways of burning this image now, always failing to be mounted.
I also tried an iBook G4, with the same result. So, I tried to do a sha512sum on the iso and it turned about the be incorrect.
Sorry to bother you guys, I will download the iso again and try again to see if it mounts now, with a correct iso.
Jeroen
On Sun, 08 Nov 2020 15:10:55 +0100
"Thomas Schmitt" <scdbackup@gmx.net> wrote:
> Hi,
>
> Jeroen Diederen wrote:
> > kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Sense Key : Illegal Request
> > kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Illegal mode for
> > this track
> > ...
> > kernel: [timestamp] attempt to access beyond end device
> > kernel: [timestamp] sr0: rw=0, want 640412, limit 640408
>
> This could be the TAO CD readahead bug with a drive which cooperates
> badly with an obscure remedy in the kernel.
> Preconditions for the bug are:
> - CD-R or CD-RW medium, not DVD, not BD.
> - Write type was Track-At-Once (which is default with cdrecord and wodim).
>
> The remedy, which only works beginning with the next read attempt, can be
> seen in
> https://github.com/torvalds/linux/blob/master/drivers/scsi/sr.c
> under the false statement
> * The SCSI specification allows for the value
> * returned by READ CAPACITY to be up to 75 2K
> * sectors past the last readable block.
> If it works well, then it reduces the registered size of the medium
> (ioctl(BLKGETSIZE), lsblk -o SIZE) by 4 KiB. It is know to work better
> if the number of 2K blocks of the readable range is divisible by 2.
>
> In our case we have 160103 2K blocks and it looks like overcorrection:
>
> debian-10.0.0-powerpc-NETINST-1.iso of yesterday (2020110715225600)
> has 327890944 bytes i.e. 640412 blocks of 512 bytes.
> So above "want" is already beyond the end of the ISO but "limit" is inside.
> "want" would match the initial perception mistake of the kernel, which
> would be with the TAO bug 640416 or 640420 blocks, and an overshooting
> correction to 640408 blocks.
> The read access to the very end usually happens when software lookings
> for a GPT backup block or for an UDF anchor block.
>
>
> There are various rumors around this bug, but mine is provable and backed
> by more optical drives than the others' together. >:]
>
> Normally it gets circumvented by a adding 300 KiB of padding at the end of
> the CD track. If my theory is right, then no padding was added to this CD.
> How exactly did you burn the it ?
>
> If the burn software offers write type Session-At-Once (SAO) then burn
> again using this option.
>
> E.g. xorriso with explicit SAO (it uses it by default if possible)
> and padding:
>
> xorriso -as cdrecord \
> -v dev=/dev/sr0 blank=as_needed -eject padsize=300k \
> -sao debian-10.0.0-powerpc-NETINST-1.iso
>
> The padding might lead to success even if my theory is wrong, because if
> the drive would systematically underestimate SAO CDs, then the padding
> would sacrifice itself to the mistake like a zinc anode does to salt water.
>
> So in case of success, it would be interesting to see whether a CD burnt
> without option
> padsize=300k
> is mountable too, and whether a CD burnt by TAO without padding fails:
>
> xorriso -as cdrecord \
> -v dev=/dev/sr0 blank=as_needed -eject \
> -tao debian-10.0.0-powerpc-NETINST-1.iso
>
> -------------------------------------------------------------------------
>
> If this all turns out to be really the old readahed bug, does anybody here
> have enough reputation in linux-scsi to get a fix committed, which i have
> ready as set of
> [PATCH 0/3] Fix the old CD read-ahead bug for media with a single TAO track
> [PATCH 1/3] cdrom: export cdrom_mmc3_profile()
> [PATCH 2/3] sr: provide a test for readability of sectors as data blocks
> [PATCH 3/3] sr: detect CD TAO Run-out blocks and correct device capacity
> if needed
> Currently based on 5.9-rc2. Works fine with various drives.
> Lengthy cover letter and commit messages. Like this mail. Sorry for that.
>
>
> Have a nice day :)
>
> Thomas
>
--
Jeroen Diederen <jjhdiederen@zonnet.nl>
Reply to: