Re: Updated Debian Ports installation images 2021-09-23
Hi Ulrich! On 10/13/21 13:04, John Paul Adrian Glaubitz wrote: > It just got merged: > >> https://salsa.debian.org/kernel-team/linux/-/commit/5c1572cf356ce31f1b8f9a3ffb26a8498617035e > > Will take some more days until I can provide new installation images, however. > > I will let you know, then you can try again. OK, an updated kernel was just uploaded today which contains the fix: > https://buildd.debian.org/status/package.php?p=linux&suite=sid Now we just have to wait until the alpha build server has picked up the package which can take some time as we don't have a lot of build capacity for alpha at the moment. FWIW, if you know anyone with a fast alpha server who would be willing to help, let me know. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated Debian Ports installation images 2021-09-23
Hi Ulrich! On 10/11/21 20:44, Ulrich Teichert wrote: >> FWIW, the change to re-enable EISA on alpha in the Debian kernel config has >> not been >> merged yet due to bike-shedding over the proper changelog entry ... [1]. > > Oh well, eventually, it will get merged ;-? It just got merged: > https://salsa.debian.org/kernel-team/linux/-/commit/5c1572cf356ce31f1b8f9a3ffb26a8498617035e Will take some more days until I can provide new installation images, however. I will let you know, then you can try again. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated Debian Ports installation images 2021-09-23
Hi, John Paul Adrian Glaubitz wrote: > https://salsa.debian.org/images-team/debian-cd/-/blob/master/tools/boot/bullseye/boot-alpha Ahum. Quite sparse set of options, compared with amd64. :)) That makes it easy to say that nothing suspicious is to see. Have a nice day :) Thomas
Re: Updated Debian Ports installation images 2021-09-23
Hi Thomas! On 10/11/21 22:17, Thomas Schmitt wrote: > @John Paul Adrian Glaubitz: > Where can i see the code with the xorriso run which produced the ISO ? mkisofs options are here: > https://salsa.debian.org/images-team/debian-cd/-/blob/master/tools/boot/bullseye/boot-alpha Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated Debian Ports installation images 2021-09-23
Hi,
i'm not subscribed, please Cc: me with replies.
John Paul Adrian Glaubitz wrote:
> Also, let's pull Thomas Schmitt from libburnia upstream who might know more.
I don't think that it is a problem with the structure of the ISO image.
The error happens early, when the superblock shall be loaded. Its position
and size is the same for xorriso and genisoimage.
More probable is a non-standard block size of the CDROM device. The
messages look like 1024 bytes per block.
But i fail to spot how this size triggers the "unaligned transfer" error.
All modern CD drives show block size 2048 for data CDs (with other sector
formats it may be up to 2352).
Are there hardware switches at the CDROM devices to set block size ?
@Ulrich Teichert:
Can the drives be tested with a running Linux system by
lsblk -o LOG-SEC,PHY-SEC /dev/sr0
If so: What sizes get reported ?
What kind of drives ? (Parallel external SCSI ? With screws at the plugs ?)
Do you see more info about the drive after
> > Oct 11 20:11:49 kernel: [ 28.706039] sr 0:0:4:0: Attached scsi CD-ROM sr0
@John Paul Adrian Glaubitz:
Where can i see the code with the xorriso run which produced the ISO ?
--
Insight so far:
> > Oct 11 20:15:32 kernel: [ 260.904163] sr 0:0:4:0: [sr0] tag#33 unaligned
> > transfer
Assumed that it comes from sr.c, i find the complaint "unaligned transfer"
only once, in
https://github.com/torvalds/linux/blob/master/drivers/scsi/sr.c
line 462 ff:
/*
* request doesn't start on hw block boundary, add scatter pads
*/
if (((unsigned int)blk_rq_pos(rq) % (s_size >> 9)) ||
(scsi_bufflen(SCpnt) % s_size)) {
scmd_printk(KERN_NOTICE, SCpnt, "unaligned transfer\n");
goto out;
}
The disappointed customer of the read operation tells:
> > Oct 11 20:15:32 kernel: [ 260.905139] isofs_fill_super: bread failed,
> > dev=sr0, iso_blknum=16, block=32
"iso_blknum=16" matches the normal attempt to read the Primary Volume
Descriptor. But "block=32" looks suspicious. (I'd expect 64.)
https://github.com/torvalds/linux/blob/master/fs/isofs/inode.c
line 1002 ff.:
out_no_read:
printk(KERN_WARNING "%s: bread failed, dev=%s, iso_blknum=%d,
block=%d\n",
__func__, s->s_id, iso_blknum, block);
The only bread() in that function is in line 673:
block = iso_blknum << (ISOFS_BLOCK_BITS - s->s_blocksize_bits);
if (!(bh = sb_bread(s, block)))
goto out_no_read;
ISOFS_BLOCK_BITS is 11. So to get to block=32 from iso_blknum=16 the
value of s->s_blocksize_bits has to be 10. I.e. 1024 bytes per block.
I understand that this is the device block size as recorded in the
super_block structure.
Why this triggers the error in line 465 ff. riddles me.
The code in sr.c is prepared for 1024 bytes per block.
https://github.com/torvalds/linux/blob/master/drivers/scsi/sr.c
line 425:
s_size = cd->device->sector_size;
if (s_size != 512 && s_size != 1024 && s_size != 2048) {
scmd_printk(KERN_ERR, SCpnt, "bad sector size %d\n", s_size);
goto out;
}
If i assume s_size=1024 then the test in line 465 becomes
if (((unsigned int)blk_rq_pos(rq) % 2)) ||
(scsi_bufflen(SCpnt) % 1024)) {
which with blk_rq_pos(rq)=32 and a normally sized transaction buffer
should be false.
Nevertheless we see the message indicationg that the outcome is true.
One would have to print the values of
blk_rq_pos(rq)
s_size
scsi_bufflen(SCpnt)
to find out which of my assumptions is wrong.
(Best guess is that scsi_bufflen(SCpnt) became 512 for some reason.)
Have a nice day :)
Thomas
Re: Updated Debian Ports installation images 2021-09-23
Hi Ulrich! On 10/11/21 20:44, Ulrich Teichert wrote: > That's why I used two different CD-ROM drives *and* burned two CD-ROMs on > different > types of blank CDs. I think that rules out hardware issues, as the error is > exactly > the same, even happens on the same sector, when I try to mount the CD-ROM from > a shell: > > With Liftec media: > Oct 11 20:15:08 main-menu[268]: INFO: Menu item 'di-utils-shell' selected > Oct 11 20:15:32 kernel: [ 260.904163] sr 0:0:4:0: [sr0] tag#33 unaligned > transfer > Oct 11 20:15:32 kernel: [ 260.905139] blk_update_request: I/O error, dev > sr0, sector 64 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 > Oct 11 20:15:32 kernel: [ 260.905139] isofs_fill_super: bread failed, > dev=sr0, iso_blknum=16, block=32 > > With Medion media: > Oct 11 20:34:10 main-menu[269]: INFO: Menu item 'di-utils-shell' selected > Oct 11 20:34:30 kernel: [ 258.741078] sr 0:0:4:0: [sr0] tag#380 unaligned > transfer > Oct 11 20:34:30 kernel: [ 258.742055] blk_update_request: I/O error, dev > sr0, sector 64 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 > Oct 11 20:34:30 kernel: [ 258.742055] isofs_fill_super: bread failed, > dev=sr0, iso_blknum=16, block=32 OK, I don't want to rule out a software problem. However, I would advise to use Taiyo Yuden media if you still can those. Those are usually those with the highest quality and reliability. > I am getting a lot of other messages for unaligned transfers on /dev/sr0, too: > > Oct 11 20:11:49 kernel: [ 28.658188] sr 0:0:4:0: [sr0] scsi-1 drive > Oct 11 20:11:49 kernel: [ 28.659165] cdrom: Uniform CD-ROM driver Revision: > 3.--More-- (32% of 53020 > Oct 11 20:11:49 kernel: [ 28.706039] sr 0:0:4:0: Attached scsi CD-ROM sr0 > ... > Oct 11 20:11:49 kernel: [ 30.755843] sr 0:0:4:0: [sr0] tag#20 unaligned > transfer > Oct 11 20:11:49 kernel: [ 30.756820] blk_update_request: I/O error, dev > sr0, sector 583127 op 0x0:(READ) flags 0x0 phys_seg 9 prio class 0 > Oct 11 20:11:49 kernel: [ 30.759749] Buffer I/O error on dev sr0, logical > block 583127, async page read > Oct 11 20:11:49 kernel: [ 30.760726] Buffer I/O error on dev sr0, logical > block 583128, async page read > ... etc.. > > Getting the full log would be a bit tedious, as I can't proceed to the network > configuration... I had another idea after I replied your last mail and I think one possible culprit could be xorrisofs which was used for building the ISO image instead of genisoimage which Debian used in the past. I can actually create an installation image with genisoimage instead and you can test it. Also, let's pull Thomas Schmitt from libburnia upstream who might know more. >> FWIW, the change to re-enable EISA on alpha in the Debian kernel config has >> not been >> merged yet due to bike-shedding over the proper changelog entry ... [1]. > > Oh well, eventually, it will get merged ;-? Yes, it will be merged. No worries. Hopefully later this week. I didn't have the time for a rebase yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated Debian Ports installation images 2021-09-23
Hi Ulrich! On 10/10/21 19:38, Ulrich Teichert wrote: > Just tested on a Alphastation 400 4/233. Booting went smooth (serial > console) but the CDROM (in a DEC RRD45) could not be mounted: > > > Oct 10 19:20:19 kernel: [ 324.340654] sr 0:0:4:0: [sr0] tag#265 unaligned > transfer > Oct 10 19:20:19 kernel: [ 324.340654] blk_update_request: I/O error, dev > sr0, sector 64 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 > Oct 10 19:20:19 kernel: [ 324.340654] isofs_fill_super: bread failed, > dev=sr0, iso_blknum=16, block=32 > ... > > I've burned another CD-ROM and tried booting from that one, but got the > same error, so I assume the unaligned transfer is the problem. Tried > a Plextor UltraPlex instead of the RRD45 as well, same problem, I have not seen this issue before on any machine and usually, reading problems are due to hardware issues. Maybe the CD was not correctly burned? FWIW, the change to re-enable EISA on alpha in the Debian kernel config has not been merged yet due to bike-shedding over the proper changelog entry ... [1]. Adrian > [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/402 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Updated Debian Ports installation images 2021-09-23
Hi! I have just built and uploaded updated Debian Ports installation images. These images contain an updated apt-setup package which fixes the APT problem that occurred during installation with the 2021-09-21 images. I have performed a successful test installation on sparc64 and will perform a test on ia64 on my RX2660 later as well. I will provide more images updates in the following days which will contain more fixes such as for the hd-media installation as well as improvements on Apple PowerMac. The images can be obtained from [1]. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2021-09-23/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
