To come back to my incorrect sha256sum, I downloaded the iso yesterday. It was the image created on 7.11.2020. I checked against the shasums of the 'current' iso, thinking that the one of yesterday was the 'current' one. I did not know that there is a newly spinned iso, from the 8th of November in the meantime. So the iso I had was good, but from the 7th. I tried not both the 7th and 8th of November, both isos fail to be mounted.
On Sun, 8 Nov 2020 16:51:45 +0100 Jeroen Diederen <jjhdiede...@zonnet.nl> wrote: > Hi! > > I tried again, checksummed the iso, all correct. I burnt the iso on the usual > G5 iMac, also on a newer MacBook Pro. > I tried the CD-R's in my PowerBook G5 as well as in my iBook G4. Nothing > works. I always get the same error that it cannot mount the CDROM. > Can you guys try it please? I am lost here. > > Jeroen > > On Sun, 8 Nov 2020 16:15:40 +0100 > Jeroen Diederen <jjhdiede...@zonnet.nl> wrote: > > > 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" <scdbac...@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 <jjhdiede...@zonnet.nl> > > > > > -- > Jeroen Diederen <jjhdiede...@zonnet.nl> -- Jeroen Diederen <jjhdiede...@zonnet.nl>
