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
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
|
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.
Thursday, 18 February 2016, 22:11 GMT
Reason for closing: Upstream
Additional comments about closing: nothing to do with archiso.
$ 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