FS#48234 - archlinux-2016.02.01-dual.iso fails to boot completely if on TAO CD

Attached to Project: Release Engineering
Opened by Thomas Schmitt (scdbackup) - Thursday, 18 February 2016, 10:37 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Thursday, 18 February 2016, 22:11 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

If archlinux-2016.02.01-dual.iso is burned to a CD with write type TAO,
then the boot procedure ends in a rescue prompt.

When the kernel is comming up, there are messages like

[ 10.004186] blk_update_request: I/O erro, dev sr0, sector 1436248
[ 15.950463] blk_update_request: I/O erro, dev sr0, sector 1436248
[ 15.950553] Buffer I/O error on dev sr0, logical block 179531, async page read

and finally

ERROR: '/dev/disk/by-label/ARCH_201602' device did not show up after 30 seconds...
Falling back to interactive prompt

(Texts copied from https://bbs.archlinux.org/viewtopic.php?id=195763
about ARCH_201504, numbers from own experiments with ARCH_201602.)

If the CD is burned with option -sao instead of -tao, then the boot
procedure succeeds.

The immediate reason for failure with TAO CD is an i/o error with
blkid /dev/sr0
which yields again i/o errors and no id strings.

It seems like kernel 4.3.3 is to blame, as dd runs throw i/o errors
at various block numbers near 359000 depending on where skip= begins
to read.

CD write type TAO writes the whole track as a single packet. At the end
of the packet there are two "run-out" blocks, which are not readable by
SCSI command READ.
They trigger the read-ahead bug of kernel 2.x, which was (nearly) fixed
in kernel 3.16. Now it is back - worse than ever.


Steps to reproduce:

Take a CD-R or CD-RW (not a DVD or USB stick) and burn the ISO image
by write type Track-At-Once:

$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed -eject -tao archlinux-2016.02.01-dual.iso

(One may use cdrecord, wodim, or cdrskin instead of "xorriso -as cdrecord".
Decisive is option -tao.)

Check the CD by READ commands via ioctl(SG_IO), i.e. not by the probably
buggy block device driver of kernel 4.3.3:

$ xorriso -indev /dev/sr0 -check_media --
...
xorriso : UPDATE : 359064 blocks read in 166 seconds = 28.8xC
Media checks : lba , size , quality
Media region : 0 , 359062 , + good
Media region : 359062 , 2 , 0 tao_end

(Or read 359062 blocks of 2048 bytes by dd on a Debian 8 system with
kernel 3.16.)

Put this CD into the optical drive of a x86-64 computer (in my case with
BIOS, not EFI) and let it boot.


I am developer of libburn and willing to help with further diagnosing
the problem on the level of SCSI commands. But this bug looks more like
a household problem of the kernel.

Have a nice day :)

Thomas
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Thursday, 18 February 2016, 22:11 GMT
Reason for closing:  Upstream
Additional comments about closing:  nothing to do with archiso.
Comment by Baeyens (berbae) - Thursday, 18 February 2016, 21:08 GMT
I had the same problem when burning a CD-RW just with:

$ wodim -v dev=/dev/sr0 archlinux-2016.02.01-dual.iso

But after burning with:

$ wodim -v dev=/dev/sr0 -dao archlinux-2016.02.01-dual.iso

the installation went well.

I precise that the sha1sums were good in both cases.

This solution came from https://bbs.archlinux.org/viewtopic.php?pid=1580655#p1580655

Loading...