Re: Updated Debian Ports installation images 2022-03-28
Hi, Dennis Clarke wrote: > # dd if=/cdrom/test/debian_20220328/debian-11.0.0-sparc64-NETINST-1.iso > of=/dev/rdsk/c0t1d0s0 bs=2048 count=189529 > dd: unexpected short write, wrote 1536 bytes, expected 2048 > 65725+0 records in > 65725+0 records out > So that is strange. Perhaps the iso image file is a sparse file with a > hole in it. Hardly. Some automat would have to have converted the file to a be sparse one. I would rather expect "short write" to be caused by the return value of a write(2) call being less than the number of submitted bytes. (It should not happen with a healthy disk device except at the very end of its capacity.) The disk address /dev/rdsk/c0t1d0s0 looks like Solaris. So it is no wonder that i fail to find the dd message in Debian's coreutils. Maybe it works better or fails with other diagnostic messages if you use bs=512 and adjust or omit the count= argument. Have a nice day :) Thomas
Re: Updated installation images for Debian Ports 2019-05-09
Hi, Jan Engelhardt wrote: > https://oss.oracle.com/linux-sparc/isos/ I downloaded https://oss.oracle.com/linux-sparc/isos/linux-sparc-1.0-DVD.iso It was made by genisoimage in 2015 and has a Sun disk label like debian-10.0-sparc64-grub-NETINST-1.iso of 27 Apr 2019. Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, John Paul Adrian Glaubitz wrote: > You are very welcome to create a guest account for Debian Salsa I already have one for xorriso related package preparation. > and open > merge requests for the debian-installer and debian-cd projects [1]. It is more about weighing the options and their consequences. Showing shell command results. Convincing the maintainer. The proposed changes themselves are quite artless. > Note: The ia64 stuff for debian-cd was copied verbatim from arm64 (boot-ia64 > is copied from boot-arm64 in debian-cd). UEFI: Five CPU architectures in one specification. Maybe if i convince you of my proposal i can use the result as lure for the other four EFI arches of debian-cd. :)) In another mail, Mark Cave-Ayland wrote: > I've had a break because I got married :) Congratulations ! Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, John Paul Adrian Glaubitz wrote: > there is also a test image for ia64 with GRUB > https://cdimage.debian.org/cdimage/ports/grub-test/ Interesting. I never had an ISO for Itanium. Looks very similar to the Debian arm64 ISOs. Much neater MBR partition table than i386 and amd64 ISOs. I still see room for improvements (for arm64 too): - Use xorrisofs option -partition_offset 16 to get the full image size including the appended partition from commands like /sbin/isosize. - Use argument --interval:appended_partition_2:all:: to option -e, in order to point El Torito to the appended partition. The image file ./CD1/boot/grub/efi.img may then be moved out of ./CD1 so that it does not eat room in the ISO filesystem. Where to motivate and discuss these ? Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, > PS: You can fetch the image from the known location to test Looks good. Viewing xorriso arguments in /mnt/iso/.disk/mkisofs ... looks good too. The ISO is now added to my collection of bootable ISOs for regression test. My test loop checks whether the ISOs which are repacked from existing ISOs still show the same boot equipment and file tree content. (Happens when i change boot related program parts and before releases. 2 hours of 3.5 GHz Xeon shoveling forth and back on about 150 GB.) May i assume that the old debian-10.0-sparc64-NETINST-1.iso is in retirement for now ? (Please announce on debian-sparc if the genisoimage style gets revived.) > boots with GRUB on CD. SUN disk label is actually a hard disk thing. Are there machines which boot from USB attached disk storage ? Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, i wrote: > grub-mkrescue copies stuff to bytes 512 to 767 of its -G image. It's 512 to 1023, of course. Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, there is a copy of the -G image file in the ISO: /boot/grub/sparc64-ieee1275/cdboot.img It has only 512 bytes. Very non-zero. But block 0 is for the SUN disk label (partition table). libisofs overwrites it completely at ISO production time. See https://sources.debian.org/src/libisofs/1.5.0-1/libisofs/system_area.c/#L776 grub-mkrescue copies stuff to bytes 512 to 767 of its -G image. Maybe you should prepend 512 0-bytes to your cdboot.img. Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, xorriso-wise, the debian-10.0-sparc64-grub-NETINST-1.iso looks ok: $ xorriso -indev debian-10.0-sparc64-grub-NETINST-1.iso \ -report_system_area plain ... Volume id: 'Debian 10.0 sparc64 n' System area options: 0x000c System area summary: SUN-SPARC-Disk-Label ISO image size/512 : 443640 SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs SUN SPARC secs/head: 640 SUN SPARC heads/cyl: 1 SUN SPARC partmap : N IdTag PermsStartCyl NumBlocks SUN SPARC partition: 1 0x0004 0x0010 0 443640 SUN SPARC partition: 2 0x0002 0x0010 0 443640 SUN SPARC partition: 3 0x0002 0x0010 0 443640 SUN SPARC partition: 4 0x0002 0x0010 0 443640 SUN SPARC partition: 5 0x0002 0x0010 0 443640 SUN SPARC partition: 6 0x0002 0x0010 0 443640 SUN SPARC partition: 7 0x0002 0x0010 0 443640 SUN SPARC partition: 8 0x0002 0x0010 0 443640 SPARC GRUB2 core : 1748992 453104 SPARC GRUB2 path : /boot/core.img xorriso reports /boot/core.img as "SPARC GRUB2 path", because it was recognized as comming from the same disk inode as /boot/grub/core.img and thus shares the content blocks with it: $ xorriso -indev debian-10.0-sparc64-grub-NETINST-1.iso \ -find /boot/core.img -exec report_lba -- \ -find /boot/grub/core.img -exec report_lba -- ... Report layout: xt , Startlba , Blocks , Filesize , ISO image path File data lba: 0 , 854 , 222 , 453104 , '/boot/core.img' Report layout: xt , Startlba , Blocks , Filesize , ISO image path File data lba: 0 , 854 , 222 , 453104 , '/boot/grub/core.img' So all is well. Except the nearly zero content of bytes 512 to 767 of the ISO. Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi,
John Paul Adrian Glaubitz:
> xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1
> -V 'Debian 10.0 sparc64 n'
> -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso
> -J -joliet-long -cache-inodes
> -G /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img
> -B '...'
> --grub2-sparc-core /boot/grub/core.img
> -graft-points
> /boot/core.img=/home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img
> CD1
Now you first insert .../core.img as /boot/core.img.
Then you insert it again by its role as sub-file of "CD1" as
ISO file /boot/grub/core.img.
To the latter you refer by --grub2-sparc-core .
So this is without much effect (except adding a file copy to the ISO):
-graft-points
/boot/core.img=/home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img
> {0} ok boot cdrom
> Boot device: /virtual-devices@100/channel-devices@200/disk@1 File and args:
> WARNING: Unsupported bootblk image, can not extract fcode
> WARNING: Bootblk fcode extraction failed
> The file just loaded does not appear to be executable.
Is this the SUN firmware speaking ?
Google "sun bootblk" yields
https://www.thegeekdiary.com/howto-verify-if-a-bootblk-is-installed-on-the-boot-disk-sparc/?PageSpeed=noscript
where block 1 (i.e. byte 512 ff.) is inspected for "Bootblk".
So it would be about block 1 of your disk file for -G
/home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img
That's where --grub2-sparc-core inserts its numbers.
But i guess it is about the other bytes in there.
Have a nice day :)
Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, > xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 > -V 'Debian 10.0 sparc64 n' > -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso > -J -joliet-long -cache-inodes > -G /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img > -B ... > --grub2-sparc-core /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img > CD1 Try --grub2-sparc-core /boot/grub/core.img Reasoning: You obviously give it the path on the source disk. But the option wants the path in the ISO. The disk path and the pathspec "CD1" give the impression that there is a disk file CD1/boot/grub/core.img which by the sparse form of the pathspec will be mapped to ISO path /boot/grub/core.img Later mail: I wrote: > > -graft-points \ > > /boot/grub/core.img=./dummy_for_core > What is missing and what I am testing now is the > "-graft-points" > option which matches the core.img in the ISO with the one outside the ISO. Not needed. This is not a matcher but rather an enabler and a file (or tree) insertion. Option -graft-points enables the pathspec format iso_rr_path=disk_path . The following pathspec makes use of this: /boot/grub/core.img=./dummy_for_core It inserts the disk file ./dummy_for_core into the ISO as /boot/grub/core.img . Your "CD1" inserts the disk tree ./CD1 into the ISO as /-directory. (Actually it merges the content of ./CD1 with the content of /, which at that time is still empty. You may merge-in more disk trees.) (That's all classical mkisofs operation. I am not happy about everything there, but it enables swift transition from mkisofs or genisoimage.) The option -checksum_algorithm_iso md5,sha1 is without effect if you do not produce Jigdo files by option -jigdo-jigdo et.al. It does not harm, though. Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, John Paul Adrian Glaubitz wrote: > -J -joliet-long -cache-inodes -l > -G $CDDIR/../CD1/boot/grub/sparc64-ieee1275/cdboot.img -B ... > > Would it be enough to just switch to xorriso here? I think you forgot -o result.o and -V Volume_Id. They are all in the list of emulated options (xorriso -as mkisofs -help man xorrisofs) A test: $ dd if=/dev/zero bs=512 count=2 of=dummy_for_G $ dd if=/dev/zero bs=512 count=10 of=dummy_for_core $ xorriso -as mkisofs \ -o test.iso \ -V 'FAKE_SPARC_64_ISO' \ -J -joliet-long -cache-inodes -l \ -G ./dummy_for_G \ -B '...' \ --grub2-sparc-core /boot/grub/core.img \ -graft-points \ /boot/grub/core.img=./dummy_for_core ... Written to medium : 186 sectors at LBA 0 Writing to 'stdio:test.iso' completed successfully. $ xorriso -indev test.iso -report_system_area plain ... Volume id: 'FAKE_SPARC_64_ISO' System area options: 0x000c System area summary: SUN-SPARC-Disk-Label ISO image size/512 : 744 SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs SUN SPARC secs/head: 640 SUN SPARC heads/cyl: 1 SUN SPARC partmap : N IdTag PermsStartCyl NumBlocks SUN SPARC partition: 1 0x0004 0x0010 0 744 SUN SPARC partition: 2 0x0002 0x0010 0 744 SUN SPARC partition: 3 0x0002 0x0010 0 744 SUN SPARC partition: 4 0x0002 0x0010 0 744 SUN SPARC partition: 5 0x0002 0x0010 0 744 SUN SPARC partition: 6 0x0002 0x0010 0 744 SUN SPARC partition: 7 0x0002 0x0010 0 744 SUN SPARC partition: 8 0x0002 0x0010 0 744 SPARC GRUB2 core : 67584 5120 SPARC GRUB2 path : /boot/grub/core.img The fact that the file core.img is named as "SPARC GRUB2 path" indicates that its start LBA was written to the right place in the -G image. (Numbers shown as "SPARC GRUB2 core".) Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, Mark Cave-Ayland wrote: > In that case I think the change for Adrian's second patch should in fact be > this: > add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ... > --grub2-sparc-core /boot/grub/core.img" > > Does that look better? If /boot/grub/core.img is the path of the next stage boot file in the ISO filesystem, then yes. grub-mkrescue names it similarly: /boot/grub/sparc64-ieee1275/core.img . Note: It won't work with genisoimage. Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi, > - the first 32K of an ISO9660 is undefined That's such a negative word. :)) It is "reserved for system use" and "not specified" by ISO 9660 / ECMA-119. > - boot.S and diskboot.S get built into cdboot.img grub-mkrescue opens cdboot.img for reading and the image file for -G for writing and truncates it to 0 length. Then it writes 512 zero bytes, reads 512 bytes from cdboot.img and writes them to the -G image file. > - grub should run xorisso with the following parameters: > -G cdboot.img -B "..." --grub2-sparc-core > /boot/grub/sparc64-ieee1275/core.img Actually these are for the mkisofs emulation of xorriso. xorriso -as mkisofs ...options.and.pathspecs... (See man xorrisofs for options.) Note that -B ',' as of grub-mkrescue is not totally equivalent to your -B '...' Digging in libisoburn's xorriso/emulators.c i see that "," orders two appended partitions with empty disk source paths. This will cause no partitions to be appended. "..." causes 7 partitions copying the partition entry data of the entry before them. That would be the entry describing the ISO image as a whole. Again no partitions images get appended. One should test both and inspect by SUN tools or xorriso -indev $ISOIMAGE -report_system_area plain Probably "..." will produce a partition table with 8 entries, and "," will produce a table with only one entry. > - what this effectively does is: > - Install a sun partition disk label to sector 0 of the ISO image > - Add the ISO9660 image as the first partition (slice) > - Create all 7 remaining partitions after the ISO9660 image I expect this too. > - These partitions are all small and just contain cdboot.img I expect what can be seen in debian-10.0-sparc64-NETINST-1.iso Volume id: 'Debian 10.0 sparc64 n' ... System area summary: SUN-SPARC-Disk-Label ISO image size/512 : 284760 SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by genisoimage SUN SPARC secs/head: 640 SUN SPARC heads/cyl: 1 SUN SPARC partmap : N IdTag PermsStartCyl NumBlocks SUN SPARC partition: 1 0x0004 0x0010 0 284160 SUN SPARC partition: 2 0x0002 0x0010 0 284160 SUN SPARC partition: 3 0x0002 0x0010 0 284160 SUN SPARC partition: 4 0x0002 0x0010 0 284160 SUN SPARC partition: 5 0x0002 0x0010 0 284160 SUN SPARC partition: 6 0x0002 0x0010 0 284160 SUN SPARC partition: 7 0x0002 0x0010 0 284160 SUN SPARC partition: 8 0x0002 0x0010 0 284160 xorriso command -pvd_info says: App Id : GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM ... Creation Time: 2019012014210500 You could put cdboot.img in there by naming it in the comma separated list of paths after -B. But i guess you should not. -- The following topics are out of my normal scope. So i can only throw in text snippets which may be related: > 1) How does boot.S/diskboot.S locate core.img? man xorrisofs says about -B: The pseudo disk_path "..." causes that all empty partition entries become copies of the last non-empty entry. If no other disk_path is given before "..." then all partitions describe the ISO image. In this case, the boot loader code has to be imported by option -G. So having no boot images in the partition table is ok, in principle. > This means that when the PROM opens the disk in boot.S, it is directly > opening the partition containing cdboot.img rather than the start of the > whole disk It looks like all partitions lead to CD-ROM (where Nero burns). > 2) How to launch xorisso with the correct parameters? With two "r" and only one "s". :)) (xorriso = X/Open on Rock Ridge enhanced ISO 9660) > grub-mkinstall To what package does this belong ? Google proposes to search for "grub-install". But i don't think that this is for ISO 9600 production. Have a nice day :) Thomas
Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
Hi,
John Paul Adrian Glaubitz wrote:
> I have read the genisoimage manpage and I have to admit, I haven't fully
> understood
> yet how it is supposed to work. It seems we have to specify the bootloader
> code
> with -G, thus -G cdboot.img. But -B is apparently used to pass a whole
> directory
> name which means I don't understand how genisoimage knows which is the second
> stage bootloader.
Dumping here what i learned when Vladimir Serbinko told me how to
do it with xorriso underneath grub-mkrescue:
libisofs/doc/boot_sectors.txt has:
=
GRUB2 SUN SPARC Core File Address
Sources:
Mail conversations with Vladimir Serbinenko.
GRUB2 lets libisofs write after the disk label block the address and size of a
data file in the ISO image. E.g. of /boot/grub/sparc64-ieee1275/core.img.
This is combined with a SUN Disk Label which exposes only the single partition
describing the overall ISO filesystem size.
Byte Range | Value | Meaning
| -- | --
512 - 551 | opaque | Code and data provided by GRUB2
||
552 - 559 | offset | Start byte number of the file. 64-bit big-endian.
||
560 - 563 | size | Number of bytes in the file. 32-bit big-endian.
||
564 - 32767 | opaque | Code and data provided by GRUB2
||
| -- | --
=
(There is a section "SUN Disk Label and boot images for SUN SPARC" before
that special GRUB description.)
man xorrisofs:
=
-B disk_path[,disk_path ...]
Cause one or more data files on disk to be written after the end
of the ISO image. A SUN Disk Label will be written into the
first 512 bytes of the ISO image which lists this image as
partition 1 and the given disk_paths as partition 2 up to 8.
The disk files should contain suitable boot images for SUN SPARC
systems.
The pseudo disk_path "..." causes that all empty partition
entries become copies of the last non-empty entry. If no other
disk_path is given before "..." then all partitions describe the
ISO image. In this case, the boot loader code has to be imported
by option -G.
=
util/grub-mkrescue.c does
=
if (source_dirs[GRUB_INSTALL_PLATFORM_SPARC64_IEEE1275]
&& system_area == SYS_AREA_SPARC)
{
...
xorriso_push ("-G");
xorriso_push (sysarea_img);
xorriso_push ("-B");
xorriso_push (",");
xorriso_push ("--grub2-sparc-core");
xorriso_push ("/boot/grub/sparc64-ieee1275/core.img");
=
The mkisofs emulation option --grub2-sparc-core does the stuff described
in boot_sectors.txt.
(And i see nice examples of grub_util_fopen() and fwrite(3) by which
grub-mkrescue could zero the EFI partition's partition table after
mformat did its work ...)
I hope this helps to get more insight. More background might be known
to Vladimir.
Have a nice day :)
Thomas
Re: Latest netinst iso
Hi, Fred wrote: > It appears the HP DVD drive is defective. It now doesn't work with Wheezy > either. Oh yeah. Age sucks. I assume you already checked with a different cable. So there remains only the duty to submit it to an environmentally conscious recycling system. Have a nice day :) Thomas
Re: Latest netinst iso
Hi,
Fred wrote:
> [ 21.343237] ata2.00: ATAPI: HL-DT-ST RW/DVD GCC-H20N, C805, max UDMA/44
Aha. An LG CD burner and DVD reader ("combo" drive). A dozen years old,
at least.
> [ 21.367287] ata2.00: configured for MWDMA2
> [ 42.175653] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
> [ 42.176013] ata2.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0 dma 96
> in
>Inquiry 12 00 00 00 60 00res
> 40/00:02:00:24:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
I recognize an SCSI command INQUIRY (code 0x12) which requests 0x0060 = 96
bytes from the drive. That's quite some bytes more than libburn asks for in
the first contact (0x0024 = 36 bytes).
Nothing happens for 20.8 seconds and then a timeout is reported.
This could be a mis-coordination with the lower drivers. I remember that
about 10 years ago, we burn programmers had to change our SG_IO strategy.
Commands with variable length reply needed to be executed first with
minimum reply length and then again with the reply length that is
announced by the reply to the first command execution.
If we requested too much on the first try, the transaction did not end.
> [ 42.380290] scsi 1:0:0:0: scsi scan: 96 byte inquiry failed. Consider
> BLIST_INQUIRY_36 for this device
> [ 42.381094] scsi 1:0:0:0: CD-ROMHL-DT-ST RW/DVD GCC-H20N C805
> PQ: 0 ANSI: 5
Looks like it tries again with less bytes and gets to sr and cdrom drivers:
> [ 42.509234] sr 1:0:0:0: [sr0] scsi3-mmc drive: 8x/59x cd/rw xa/form2 cdda
> [ 42.509258] cdrom: Uniform CD-ROM driver Revision: 3.20
> [ 42.515251] sr 1:0:0:0: Attached scsi CD-ROM sr0
So far so good. /dev/sr0 should exist now.
> [ 42.661390] ata_id[97]: unable to open '/dev/sr0'
> [ 42.893291] ata_id[99]: unable to open '/dev/sr0'
But why ?
> [ 55.968323] sr 1:0:0:0: Attached scsi generic sg1 type 5
Looks like /dev/sr0 is not totally dead.
So what do you get when trying to read the first MB from it ?
dd if=/dev/sr0 bs=2048 count=512 of=/dev/null
Is it mounted when the installer does not find it ? (As /cdrom ?)
Well, if it is readable, then we could ask at debian-boot list how
CDROM detection is supposed to work and how to debug it.
A first guess for the source would be
https://salsa.debian.org/installer-team/cdrom-detect/blob/master/debian/cdrom-detect.postinst
I was in an amd64 ISO initrd a few months ago
https://lists.debian.org/debian-user/2018/05/msg01076.html
It contains a script which shall list all CD drives when called with
argument "cd". On my running system it lists /dev/sr0 to /dev/sr4.
It inquires the device type by /bin/udevadm.
What do you get from
/bin/list-devices cd
If no /dev/sr* is listed, what do you get from
/bin/udevadm info -q env -p /sys/block/sr0
Have a nice day :)
Thomas
Re: Latest netinst iso
Hi, Frank Scheiner wrote: > as my Ultra 10 has a CDROM drive installed > instead of a DVDROM drive I was mislead to write "CDROM drive" "DVD" gives a hint of the age of the drive. Everything from this century should be driven by SCSI commands (volumes SPC, SBC, MMC). There must have been old days when cdrecord needed special "drivers" for particular CD burners (see man cdrecord, option driver=) and libcdio was founded to unify the access to CD reader models on GNU/Linux. > But interestingly the assumed same controller driver works well for Gregor's > and my Ultra 10 and it also works well when Fred uses a CDROM drive. > What could be the reason for that? Oops. While lurking i missed that report from Fred. (I am here because my libisofs packs up the ISOs. But this thread i watch with my libburn hat on.) About twenty to fifteen years ago, when DVD drives came up for PCs, there was no problem to attach them where CD drives were plugged before. The fact that it works for the firmware and GRUB (i assume) quite outrules that the controller would be unwilling to talk to the drive. Fred wrote: > The HP DVD drive was in use on a U5 running Wheezy and worked fine. At least Jessie's kernel 3.16 looks much like https://github.com/torvalds/linux in respect to optical drives. So i doubt that it is about a kernel change. What kernel version does the Wheezy machine have ? Can it be the DVD drive is at the edge of failure ? Does it still work in the U5 ? Is the plug loose or dusty ? When it is in the problem machine and the installer was exited to a shell prompt, is there a device file /dev/sr0 ? I flatly assumed that there is none. Better check. Is a system log availabe of the installer system ? Does it tell anything about the DVD drive or its IDE socket ? Frank Scheiner wrote: > [ 36.327225] ata2.00: ATAPI: SAMSUNG DVD-ROM SD-616Q, F401, max UDMA/33 > [ 36.465435] scsi 1:0:0:0: CD-ROMSAMSUNG DVD-ROM SD-616Q F401 PQ: 0 ANSI: 5 > [ 36.926295] sr 1:0:0:0: [sr0] scsi3-mmc drive: 16x/48x cd/rw xa/form2 cdda tray > [ 37.023810] cdrom: Uniform CD-ROM driver Revision: 3.20 > [ 37.098287] sr 1:0:0:0: Attached scsi CD-ROM sr0 That's what to look for in Fred's system log. IDE, ATA, ATAPI specific drivers are out of my knowledge scope, i fear. I only work on SCSI transaction level. The first "scsi" message stems probably from Linux source file drivers/scsi/scsi_scan.c and reports parts of the reply data of SCSI command INQUIRY. This command reply is supposed to identify the device as Peripheral Device Type 5 "MMC". drivers/scsi/scsi.c array scsi_device_types[5] bears the text "CD-ROM". This selects the "sr" driver to take care of the device. The "sr" message stems from drivers/scsi/sr.c. It reports the content of Mode Page 0x2A "CD/DVD Capabilities and Mechanical Status Page". If this inquiry fails, the kernel is supposed to report "scsi-1 drive" and to go on with registering the drive, nevertheless. The "cdrom" message stems from drivers/cdrom/cdrom.c function register_cdrom(), probably called from sr.c function sr_probe(), which finally reports the line about "Attached scsi CD-ROM". It would be interesting to see when Fred's machine and DVD drive deviate from this successful path. > So actually any support for UltraDMA in the DVDROM or CDROM drive does not > seem to make a difference. I dimly remember that PIO was too lame for early DVD drives on PCs. "hdparm -d" was needed in the init scripts. But the (IIRC hardcoded) drive device files were usable. Just slow and choking the HDD at the other IDE master socket. (2 x 2 IDE was normal for a PC back then.) Have a nice day :) Thomas
Re: Latest netinst iso
Hi, Fred wrote: > > [...] DVD drive [...] Frank Scheiner wrote: > if a specific CDROM drive and > the assumed "compatible" driver don't work together, this results in a > situation like yours All DVD capable drives at IDE are supposed to work by the SCSI/MMC protocol via ATAPI. So there is few chance that the drive itself is not matched by the kernel's sr driver. If the drive does not show up as Linux device, i would rather bet on a driver mismatch with the IDE/ATAPI controller of the machine. Have a nice day :) Thomas
Re: customize iso image
Hi, sacarde wrote: > I try to customize "debian-9.0-sparc-netinst" iso > what suggest me to use? The ISO production command line is recorded in many Debian ISOs as file /.disk/mkisofs Google did not find me a "9.0-sparc" ISO, but only debian-9.0-sparc64-NETINST-1.iso In its file /.disk/mkisofs i read xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V 'Debian 9.0 sparc64 1' -o /srv/debian-cd-test/debian-9.0-sparc64-NETINST-1.iso -G boot1/boot/isofs.b -B ... boot1 CD1 The file boot1/boot/isofs.b is not in the ISO. There is /boot/isofs.b Its content matches quite well the start of the ISO image (modulo the effect of option -B "..."). If it was not overwritten by a file from directory CD1, it should really be the same file that was used with option -G. So the re-pack command line would be something like this xorriso -as mkisofs \ -r \ -V 'Debian 9.0 sparc64 1' \ -o my_image.iso \ -G /path/to/extracted/iso/tree/boot/isofs.b \ -B "..." \ /path/to/extracted/iso/tree (Option -G expects a disk file path, not a file path inside the ISO. "..." is really a valid parameter for option -B.) If the clues about isofs.b were not available, i would rather cut the first 32 KiB from the ISO: dd if=debian-9.0-sparc64-NETINST-1.iso bs=1K count=32 of=/tmp/my_isofs.b and use that file with option -G: -G /tmp/my_isofs.b \ --- Option "-checksum_algorithm_iso md5,sha1" is actually surplus, because it makes a setting for Jigdo file production which is not triggered by the overall command line. (See /.disk/mkisofs in a "i386" ISO for the many and lengthy options needed for that. See man xorrisofs for explanantions.) If MD5 checksums for the overall image and the individual data files are desired, use xorrisofs option: --md5 Its checksums can later be verified in the ISO file or after copying to the installation medium. For the superblock, the directory tree and the overall ISO: xorriso -md5 on -indev /dev/sr0 -check_media -- If the directory tree is ok but the overall ISO is not, then one can scan for the addresses of damaged data files by: xorriso -md5 on -indev /dev/sr0 -check_md5_r sorry / -- (The checksums are for ensuring data integrity in non-hostile environments. Their cryptographic strength is not sufficient to protect against skilled intentional manipulations.) Have a nice day :) Thomas
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, Sébastien Bernard: Cheers to team work. Special cheers to Patrick Baggett ! And thanks to all who cared for this problem. I'd need more users who don't shrug but complain and tell me that i'm wrong. The bug fix is now committed as http://libburnia-project.org/changeset/5324 (We still did not find any alignment problem. Does that mean we did not test hard enough ?) The real function is in sysdeps/sparc/sparc64/strcmp.S . So complicated that I'm not surprised a bug came inside. I found a medium complicated one in the libc code which you provided for me in /home/thomas eglibc-2.18/string/bits/string2.h Already too bloated for me to spot any mistake or correctness. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/30925670721203172...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi,
I may provide you access to a shell account on my machines if needed.
Yes, please.
Plus a directory tree
./tmp/miniiso/cd_tree
which can cause the xorriso crash.
Sparc architecture is extremely picky about alignement. Bad alignement,
yields SIGSEGV whereas intel only do it in the less efficient way.
I would suspect the habit of my libisofs predecessor developer
to use structs as access frame for byte arrays read from file.
But why then was it possible to produce
debian-7.4.0-sparc-netinst.iso
by xorriso-1.2.6 as can be read from its Preparer Id:
XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6,
LIBBURN-1.2.6
Does debian-cd pull sparc trees onto a non-sparc machine ?
[genisoimage]
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (strcmp(rpnt, lpnt) == 0) {
Both values match the prescribed names for . and .. in ECMA-119
(aka ISO 9660), 6.8.2.2 Identification of directories:
Single byte 0x00 is ., single byte 0x01 is ...
So, strcmp shouldn't have yielded 0 when comparing the strings.
Can this be caused by alignment problems ?
Hum, unfortunately, valgrind is not available for sparc.
Then gdb will have to do.
xorriso is the one compiled from isoburn. I tried with the one from the
archive, and the one rebuild from source with a debbuild.
Same problem on both.
If you also built libisofs and libburn from source, then this burries
my theory of a binary incompatibility between two SPARC machines.
I'm compiling at this moment the vanilla xorriso from gnu.
Let's see what it yields.
It has the same source as the three library tarballs used as input
for Debian's xorriso. Only difference is that GNU xorriso brings
own copies of the library source code and links it statically with
the xorriso main program.
So it can be easily tested without interfering with installations
of the libraries. (And with no need for superuser privileges.)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/22916707656401032...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi,
Sébastien Bernard:
result from strcmp('\','\0001' is 0)
result from strcmp('\','\0001' is -1)
Typicaly, an endianness error.
But one in strcmp(), not in your code or the one of genisoimage.
You compare an empty string with a string that contains one
character 0x01.
This is under no endianness allowed to strcmp() == 0.
Endianness would only be of interest if you compare characters
of more than one byte each. (I.e. sizeof(char) == 2)
But that would be quite an odd environment for a C program.
char is neither guaranteed to be signed nor to be 8 bit.
Nevertheless programs would break in large numbers if that
assumption was not fulfilled.
-if (strcmp(rpnt, lpnt) == 0) {
+if (strcmp(rpnt, lpnt) == 0 rpnt[0] == lpnt[0]) {
Are you sure that it does not miscompare other strings too ?
I think that genisoimage with that test is
unable to generated any iso at all on big endian machines.
I cannot agree with this diagnosis.
Not having a big-endian machine at hand now, i can confirm from
my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
a non-zero result with your example char arrays.
strcmp() may well be implemented by word comparisons. But then it
is the duty of the implementation to properly handle the ends of
the strings even if those are not word aligned.
I filed a bug with xorriso. Waiting for the number to show up.
I will hopefully get a notification via the pkg-libburnia-devel
list. Else i will bother you.
Steve McIntyre:
We build all the release images on an amd64 machine, pettersson.d.o
Ok. That explains why there are sparc-bootable ISOs from xorriso.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21777670788974871...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, sorry for mis-posting the first reply for bug 746254 to this bug 731806. Meanwhile it turned out that the SIGBUS vanishes if i do not compile with -O2 or if i replace a-u = by memcpy(). So it seems worth to check whether genisoimage resp. strcmp() work properly if not compiled with -O2. A test with Sebastiens genisoimage options succeeded without error. /home/thomas/xorriso-1.3.7/xorriso/xorriso -as mkisofs \ -r -J -o test.iso -G ~/boot/isofs.b -B ... tmp-iso/miniiso/cd_tree It looks ok, SPARC-boot-wise. SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs SUN SPARC secs/head: 640 SUN SPARC heads/cyl: 1 SUN SPARC partmap : N IdTag PermsStartCyl NumBlocks SUN SPARC partition: 1 0x0004 0x0010 0 16940 SUN SPARC partition: 2 0x0002 0x0010 0 16940 ... SUN SPARC partition: 8 0x0002 0x0010 0 16940 An additional option --md5 enabled confirmation that the ISO stream of libisofs was written flawlessly by libburn into the file test.iso. /home/thomas/xorriso-1.3.7/xorriso/xorriso \ -for_backup -indev test.iso -check_media -- xorriso is willing to load the ISO metadata and to compare it with the hard disk tree. /home/thomas/xorriso-1.3.7/xorriso/xorriso \ -indev test.iso -compare_r tmp-iso/miniiso/cd_tree / It only detects the consequences of option -r with directories (see man genisoimage / mkisofs): Permissions are set to r-xr-xr-x, owned by 0, group is 0. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/18128670805771551...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi,
Patrick Baggett:
Could you explain the context around this code? Perhaps the source is
not really alignment safe and could use some patching upstream? I'd
be happy to provide advice or code samples.
The context was misposted to bug report 731806 as message #87:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731806#87
(but not with Cc to debian-sparc list).
Upstream is myself. :))
The code in question is by my unreachable libburn predecessors, though.
It belongs to the preparation of a thread start for one of five
occasions in libburn. SIGBUS happens at
http://libburnia-project.org/browser/libburn/trunk/libburn/async.c#L149
The caller has a local struct (i.e. on stack) like (#L592, #L692):
struct write_opts write;
...
add_worker(Burnworker_type_writE, d,
(WorkerFunc) write_disc_worker_func, o);
The called function gets its address as parameter data (#L135):
static void add_worker(int w_type, struct burn_drive *d,
WorkerFunc f, void *data)
has a struct on heap (#L102, #L138, #L146):
struct w_list{
...
union w_list_data
{
...
struct write_opts write;
...
} u;
}
...
struct w_list *a;
...
a = calloc(1, sizeof(struct w_list));
The gesture which causes the SIGBUS is (#L149)
a-u = *(union w_list_data *)data;
which is not what i personally would use, but should be fully legal
nevertheless.
The SIGBUS vanishes if i compile without gcc -O2, or if i replace
the a-u = gesture by
memcpy((a-u), data, sizeof(union w_list_data));
which i deem equivalent (and more my personal style).
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20365670802973806...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, i wrote: struct write_opts write; ... add_worker(Burnworker_type_writE, d, (WorkerFunc) write_disc_worker_func, o); Urgh. I copied the wrong struct definition. Line 592 bears of course: struct write_opts o; which is used in the call of add_worker(). Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9919670809032917...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, I really need a disassembly and to be able to probe the runtime stack a bit, so that really means that I need to build the code. :) The current example would be a bit too opulent, i guess: -rwxr-xr-x 1 thomas thomas 3753398 avril 28 17:49 xorriso/xorriso (wget http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz untar, cd xorriso-1.3.2, ./configure, make, ls -l xorriso/xorriso, crash by: xorriso/xorriso -outdev stdio:/dev/null -map ./xorriso / ) I'll try to reproduce by a smaller program on Sebastien's system. I think as a more meta-problem is this: the code's logic for how much to copy is wrong. It copies too many bytes on many cases and violates the C contract that you'll only copy like objects using =. [...] you're copying unlike objects of different sizes and that's never safe. It's the job of a C union to provide a common hull around objects of different size. One may dispute whether using union is a good idea (like overloading in the OO paradigm). But unions are part of C since KR and they are supposed to be safe. http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions As for the cost: The threads are running big operations of libburn. Even a full MB of copying would not make much difference. Elsewise i agree with you. I would have written it differently, too. But i will try to keep the necessary changes as small as possible. So the union approach will most probably stay unless i get convinced that it is faulty C language. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5941670806243473...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, No, it's plain wrong. Unions are fine, if used properly. You aren't using them properly. Duh. You convinced me. The callers do it wrong, indeed. They would have to use local union variables instead of their actual structs. The parameter of add_worker() should be a pointer to the union, not a pointer to void. Obviously the bug normally stays withing populated stack area. Three cheers for the picky systems ! I'll stop the attempt to reproduce the problem in a smaller program and rather fix libburn. (That will result in some testing plight on the less picky systems.) Thank you for pointing me to this bug. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16290670797627595...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, Sebastien's machine now has a xorriso-1.3.7 (the current development snapshot) with changed libburn/async.c. The callers of add_worker() now declare: union w_list_data o; rather than struct union_member o; The type of the fourth parameter of add_worker has been changed from (void *) to (union w_list_data *). The formerly SIGBUSsing statement became quite elegant a-u = *data; Given that it is a good bug catcher on Debian sparc, and more concise than e.g. memcpy((a-u), data, sizeof(union w_list_data)); i tend to keep it. To Sebastien: Please give /home/thomas/xorriso-1.3.7/xorriso/xorriso a thorough testing with your debian-cd setup. (make dist should even pack it up to a usable tarball) Whatever the outcome will be with that strange strcmp() bug, your original alternatives 1 and 2 have small chances to succeed unless we declare surrender on 3. 1- It has been publicly stated in the past that Debian will not accept a package with original mkisofs. Stated reason was social incompatibility with its author. 2- Steve McIntyre prefers xorriso to take over genisoimage tasks rather than changing genisoimage code. From his view, xorriso is comfortably self-maintaining. :)) I try to give him few reason to regret this strategy. 3- A xorriso candidate (rather stack sanitized than alignment corrected) has now been beamed onto your machine. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1987567089955...@scdbackup.webframe.org
