Re: arm64 and isohybrid
Hi, i wrote back in february: > > I am still hunting a bug in the pending changeset to enable > > production of a UEFI compliant protective MBR plus GPT > > layout with -append_partition. > > [...] > > This proposal will look like > > xorriso-1.3.9 -as mkisofs \ > > -V 'Debian jessie-DI-b2 arm64 1' \ > > -r -o test.iso -J -joliet-long -cache-inodes \ > > -e boot/grub/efi.img -no-emul-boot \ > > -append_partition 2 0xef arm64-efi.img \ > > -appended_part_as_gpt \ > > -partition_offset 16 \ > > /mnt/iso Steve McIntyre wrote today: > Right. If you're still working on this I'd be very interested in > testing it! Well, the changesets are committed, meanwhile. But when i now tested above proposal (before bragging), it turned out that production of a true "protective MBR" partition table works only with isohybrid MBR. (I wonder what use case i tested 10 weeks ago ...) ... Now above sketch works. The risk of regression by my last minute change is low. Nevertheless have a sharp look at i386 and amd64 results when this version of xorriso produces them. I did not make any Jigdo tests with -append_partition yet. As said: -partition_offset 16 is essential for a mountable GPT partition 1 with the ISO filesystem. -- The current GNU xorriso development snapshot has the new -as mkisofs option -appended_part_as_gpt, which lets the ISO and the appended partition appear in GPT, with UEFI compliant "protective" MBR. http://www.gnu.org/software/xorriso/xorriso-1.3.9.tar.gz MD5 9577c69da2591c683ca2cf84d29e6191 Version timestamp : 2015.04.13.172501 (I finely mistyped the date when faking the timestamp.) -- We would have to change the CD FAQ about verification of ISOs, because this advises to determine the exact amount of image bytes from the ISO filesystem size. But with above layout there is a neat disk-like situation where the ISO filesystem ends before the EFI System Partition begins. So one will rather have to checksum up to the end of the second partition (as inquired by gdisk or alike). Best would be if the Debian checksum lists would be accompanied by length lists, which simply tell the original size of the images by which the MD5s were computed. -- > > The backup GPT makes mini.iso production postprocessing > > cumbersome. (This might be no problem with netinst.iso > > because no postprocessing shall happen in debian-cd anyway.) > Maybe not by us directly, but I think a fair number of Debian users > like the ability to extend/modify images later and we have docs > telling them how to add partitions once an image is written to a USB > stick, for example. As soon as the image is on a block device with inquirable size, the partition editors should offer an option to move the backup GPT to the end of the device. That would be the first step before installing further partitions. The docs need to be checked whether they are updated for GPT. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/31582562590819864...@scdbackup.webframe.org
Re: arm64 and isohybrid
Hi, > OK, I've just built and done a very quick test with an arm64 netinst > build. Does it boot ? Are the partitions mountable ? >3 313344 313343 0 bytes 0700 Gap1 This looks strange. What do you get from xorriso-1.3.9 -indev tmp.iso -report_system_area plain The name "Gap1" seems to stem from libisofs. These partitions are supposed to fill gaps in the partition layout of grub-mkrescue. But zero sized gaps are not really intended targets. > I've tried both with and without the "-partition_offset all" and it > (obviously) affects the partition alignments and the overall image > size, but otherwise the images produced *look* ok apart from the > odd-looking zero-sized 3rd partition. It's a cosmetic issue only, but > I'm curious why it's there. :-) I assume you mean -partition_cyl_align, not -partition_offset. It is a relict of MBR, its quirks, and its urban legends. SYSLINUX (resp. hpa) emphasizes that isohybrid images have their partitions aligned to full cylinders, preferrably to 64 heads of 32 sectors or to 255 heads of 63 sectors. It seems to be about assumptions made by older BIOSes. UEFI 2.4 does not have hard alignment requirements for partitions. But there are some "should" statements in 5.3.1 GPT Overview, which propose to align to physical block size (e.g. 4096) and state that alignment to 1 MiB fulfills this proposal with "most common physical block sizes and RAID stripe sizes". Currently the alignment granularity of xorriso -as mkisofs is controlled by -partition_hd_cyl and -partition_sec_hd which are subject to MBR restrictions. It has to be tested whether -partition_hd_cyl 64 -partition_sec_hd 32 keeps up the alignment for images larger than 1 GiB (1024 cylinders). Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1095563558780141...@scdbackup.webframe.org
Re: arm64 and isohybrid
Hi, the third, zero sized partition "Gap1" gets indeed produced by libisofs. xorriso command -report_system_area does not show it, though. I am investigating. You may assume that this partition will not be produced in future xorriso versions. If the "Gap1" partition entry is suspected to disturb anything, you may create the intended state of GPT by dd if=/dev/zero of=tmp.iso conv=notrunc bs=1 seek=1280 count=128 (Actually one would have to zeroize the entry in the backup GPT, too. Its position is 62 blocks before the backup header block + 256 bytes. The header block number is given by xorriso -report_system area as third number in line "GPT lba range". E.g with GPT lba range : 64 266240 266303 the backup entry of partition 3 is at byte (266303 - 62) * 512 + 256. ) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/32682563547280315...@scdbackup.webframe.org
Re: arm64 and isohybrid
Hi, i wrote: > > The name "Gap1" seems to stem from libisofs. The cause was found and a fix is being tested meanwhile. Steve McIntyre wrote: > The Gap1 partition doesn't seem to cause any problems on the one > device I've got handy for testing, anyway. In any case it looks clueless. (The stupid gap filler wanted to cover the backup GPT by a partition, whereas the less stupid partition writer truncated it to the permissible range.) Steve McIntyre wrote: > > > I've tried both with and without the "-partition_offset all" > > I assume you mean -partition_cyl_align, not -partition_offset. > No, explicitly -partition_offset. I'd added -partition_cyl_align > already as you said. -partition_offset expects a block number as argument. "all" is read as 0. Without -partition_offset 16, the first GPT partition is supposed to be not mountable. So some riddling remains on my side ... i wrote: > > It has to be tested whether > > -partition_hd_cyl 64 -partition_sec_hd 32 > > keeps up the alignment for images larger than 1 GiB (1024 > > cylinders). Currently libisofs enlarges the cylinder size if the number of cylinders exceeds 1024. But i am testing a change now, which allows an unlimited number of "cylinders" for GPT. So -partition_hd_cyl 64 -partition_sec_hd 32 -partition_cyl_align all will ensure alignment to 1 MiB, if desired. > I'll be honest, there's no rush for this for me. This will leave more time for my tests. My best wishes for Jessie's scheduled birth and all her proud parents. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9923563113283909...@scdbackup.webframe.org
Re: Doubts about Debian8.1 DVD ppc64el image
Hi,
> Our algorithm is
> failing to discover if this iso[1] is bootable.
I am curious to learn about the expectations of that algorithm.
The ISO looks like being bootable via CHRP.
>From my cheatsheet
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt
"CHRP is marked by an MBR partition entry of type 0x96 spanning the whole
ISO 9660 image."
I cannot spot "ppc64el" in
http://cdimage.debian.org/mirror/cdimage/archive/latest-oldstable/powerpc/iso-cd/
Old-stable "powerpc" was made by genisoimage rather than xorriso.
It has an Apple Partition Map additionally to the CHRP MBR,
probably pointing to a HFS filesystem.
So if your algorithm looks for magic number {'E','R'}
at the start of the file, that would be what's missing in "ppc64el"
ISOs. (Together with the HFS, of course.)
In case this does not yet explain the riddle:
What was the most recent ISO which passed your tests ?
Can you run GNU xorriso >= 1.3.8 on that ISO ?
(Debian's xorriso is still at 1.3.2, i fear.)
xorriso -indev ...iso \
-report_el_torito plain \
-report_system_area plain \
-pvd_info
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/17680568116488629...@scdbackup.webframe.org
Re: Doubts about Debian8.1 DVD ppc64el image
Hi,
> > debian-8.1.0-ppc64el-CD-1.iso
> debian-7.8.0-powerpc-CD-1.iso
So your algorithm is missing the Apple Partition Map and possibly
the HFS to which it points.
The bootability of debian-8.1.0-ppc64el-CD-1.iso is indicated by
fulfilling the CHRP demands:
- value 0x96 at byte offset 450 (MBR partition type)
- values {0,0,0,0} at byte offset 454 (partition 1 start LBA)
- values {0x55, 0xaa} at byte offset 510 (MBR signature)
- the four bytes at offset 458 as little endian number should tell
the size of the ISO image file divided by 512 (partition 1
block count).
The "powerpc" ISOs fulfill these criteria too. Overwrite their
first two bytes by zeros and check whether they still boot. If so
then your firmware does not need HFS.
My notes about CHRP say:
"The firmware looks up a file /ppc/bootinfo.txt which in SGML-ish tag
contains firmware commands.
E.g. to execute the binary /boot/grub/powerpc.elf as first stage of GRUB2:
boot &device;:\boot\grub\powerpc.elf
"
(Learned from Vladimir Serbinenko ,
http://stuff.mit.edu/afs/sipb/contrib/doc/specs/protocol/chrp/chrp1_7a.pdf ,
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550/page/PowerLinux%20Boot%20howto)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1704656831211298...@scdbackup.webframe.org
Re: Doubts about Debian8.1 DVD ppc64el image
Hi, inspection of the ISOs is not needed any more, since we now know that your algorithm expects "powerpc" bootable ISOs, not those for "ppc64el". Nevertheless, as we are at it: > Here is the output of xorriso: > ... > System area summary: MBR CHRP cyl-align-off > ISO image size/512 : 9162480 > ... > MBR partition table: N Status TypeStart Blocks > MBR partition : 1 0x80 0x960 9162480 > Drive current: -indev '/root/debian-8.1.0-ppc64el-DVD-1.iso' That's CHRP without HFS. > Preparer Id : XORRISO-1.3.6 2014.04.08.18, LIBISOBURN-1.3.6, > LIBISOFS-1.3.6, LIBBURN-1.3.6 Dear packagers: Version 1.4.0 is out :) The debian-7.8.0-powerpc-netinst.iso yields: System area summary: MBR CHRP cyl-align-off APM ISO image size/512 : 529812 ... MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x960 529212 APM: N Info APM block size : 512 APM gap fillers: 0 APM partition name : 1 Debian 7.8.0 ppc 1 APM partition type : 1 Apple_HFS APM start and size : 1 16 529196 Drive current: -indev 'debian-7.8.0-powerpc-netinst.iso' ... App Id : GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM The difference between ISO size and partition size probably comes from genisoimage default padding of 300 KiB. I think this is not fully CHRP compliant. Shrug. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16300568206108542...@scdbackup.webframe.org
Re: https://www.debian.org/CD/faq/#bootable
Hi, "myboyfri...@mail.ru" wrote: > >So maybe type that inf about iso - for stop misunderstanding humanoids? Steve McIntyre wrote: > I've just added some text for this, which will appear on the website > shortly. Thanks for the report! The Unix-centric part of https://www.debian.org/CD/faq/#write-usb could need some technical update too: - There are BD images meanwhile. So "CD/DVD" -> "CD/DVD/BD" ? - i386 and amd64 both support booting via EFI. So "BIOS" -> "BIOS or EFI" or "boot firmware" ? - The warning about "the right device name" should be more tangible. A while ago i wrote a multi-liner of which i hope that it is quite user safe: http://www.syslinux.org/wiki/index.php/Isohybrid#Verify_device_address_or_make_a_backup And maybe, just to keep the most inexperienced users from learning command line while being superuser, the hint for people who come from Windows should be placed before the "cp" command. Together with the deprecation of "unetbootin". Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/10242567950813952...@scdbackup.webframe.org
Single volume all-in-one ISOs for i386 and amd64 ?
Hi, has it been noticed that jigdo-dlbd has exceeded the size of a single medium ? http://cdimage.debian.org/debian-cd/8.1.0/amd64/jigdo-dlbd/ http://cdimage.debian.org/debian-cd/8.1.0/i386/jigdo-dlbd/ I dimly remember that it was supposed to also serve as all-in-one ISO for large USB sticks or surplus HDDs. The next optical media size would be BD-R XL/TL with nominally 100 GB and BD-R XL/QL with nominally 128 GB. Did not see them yet. If they get not formatted and have 100.0e9 bytes, then one may assume at least 93 GiB of usable capacity. Subtracting 5 percent for formatted media: 88 GiB. Formatting and resulting size is at discretion of the user. If somebody has such a rare and costly specimen (under glass in protective atmosphere) the i'd be interested to see the outcome of a run of xorriso -outdev /dev/srX -list_formats Have a nice day :) Thomas
What package is in charge for bugs in netboot/mini.iso ?
Hi, is it known that these two images do not boot on qemu of Jessie ? http://ftp.debian.org/debian/dists/unstable/main/installer-amd64/current/images/netboot/mini.iso http://ftp.debian.org/debian/dists/unstable/main/installer-i386/current/images/netboot/mini.iso The BIOS obviously finds isolinux.bin via El Torito or MBR but this immediately gets stuck after the first SYSLINUX message. Last word is "ETCD" or "EHDD", depending on qemu -cdrom or -hda. If not known: Towards which package to report ? Have a nice day :) Thomas
Re: What package is in charge for bugs in netboot/mini.iso ?
Hi, Ian Campbell wrote: > I've not heard of it but please check the > buglist first (reportbug will prompt you do to so anyway). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796470 I checked https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-boot%40lists.debian.org No "mini.iso" in the subjects. No similar problems in the subjects of this year's bugs. reportbug was of no help, because i have no debian-installer installed. I came to netboot/mini.iso from https://wiki.debian.org/InstallFAQ when setting up a sid VM. Have a nice day :) Thomas
Re: What package is in charge for bugs in netboot/mini.iso ?
Hi, i wrote: > http://ftp.debian.org/debian/dists/unstable/main/installer-amd64/current/images/netboot/mini.iso Cyril Brulebois wrote: > https://lists.debian.org/debian-boot/2015/08/msg00286.html I am daily looking for a new amd64 mini.iso to show up, in order to close the bug as soon as it boots. But today there is still the non-booting ISO of august 13. Have a nice day :) Thomas
Re: What package is in charge for bugs in netboot/mini.iso ?
Hi, Cyril Brulebois wrote: > Dailies are pushed here: > http://d-i.debian.org/daily-images/amd64/daily/ I can confirm that http://d-i.debian.org/daily-images/amd64/daily/netboot/mini.iso boots in qemu to the graphical screen. > You'll need a new debian-installer upload to unstable to get an updated > file here. Who can make it happen ? Have a nice day :) Thomas
Re: What package is in charge for bugs in netboot/mini.iso ?
Hi, > > > You'll need a new debian-installer upload to unstable > > Who can make it happen ? > Usually me. But we don't normally do that outside releases. If you don't > trust stuff on d-i.d.o (which is entirely reasonable), rebuilding the > debian-installer source package locally is easy enough. The broken mini is mentioned in https://wiki.debian.org/InstallFAQ as one of the ways to get a Sid installation: Use netboot "mini.iso" image. You will find it on any of the Debian mirrors under debian/dists/unstable/main/installer-*/current/images/netboot/mini.iso. During the installation choose "Advanced options" -> "Expert install". In the step "Choose a mirror of the Debian archive" choose version "sid - unstable". I got a Sid VM meanwhile via upgrade-dist from stable to testing to unstable. The statement from the FAQ turned out to be true: This method is the most sure to work of those presented here. Have a nice day :) Thomas
Re: Dropping CDs entirely?! (was: Stretch Alpha 3 images)
Hi,
Aurelien Jarno wrote:
> I have no idea if they support booting over a
> CD-ROM or USB image. Does someone known if we can do so on a Loongson 3
> or Octeon machine?
Maybe one should ask grub-de...@gnu.org mailing list or
Vladimir Serbinenko directly.
---
Option --format in
man grub-mkimage
shows several mips-ly names:
mipsel-yeeloong-flash, mipsel-fuloong2f-flash, mipsel-loongson-elf,
mips-arc, mipsel-arc
---
man grub-mkrescue
talks of "big-endian MIPS machines".
Some day i must learn how GRUB2 prepares itself for the
run of grub-mkrescue and defines which xorrisofs options
to use.
Among these options are
-mips-boot /boot/grub/mips-arc/sashARCS
-mips-boot /boot/grub/mips-arc/sash
-mips-boot /boot/grub/mips-arc/grub
which activate these files (=):
/boot/grub/mips-arc/grub=${iso9660_dir}/boot/grub/mips-arc/core.img
/boot/grub/mips-arc/sashARCS=${iso9660_dir}/boot/grub/mips-arc/core.img
/boot/grub/mips-arc/sash=${iso9660_dir}/boot/grub/mips-arc/core.img
Two years ago there was no option -mipsel-boot to see.
I.e. only big-endians were supported.
---
It may well be that the machines make no difference
between booting from CD and booting from hard disk.
At least the boot sectors of -mips-boot and -mipsel-boot
look much more like MBR than like El Torito.
So if we learn how grub-mkimage composes the image
for mipsel-loongson-elf, i could possibly teach libisofs
how to create the necessary boot record.
... if mipsel-loongson-elf is what boots Loongson 3.
Have a nice day :)
Thomas
Re: Summary of the Debian CD BoF at DC15
Hi,
Steve McIntyre wrote:
> I'm open to making more different-sized image types so long as they
> make sense - ask!
I think an all-in-one ISO image for large USB sticks or
old hard disks in old or new USB boxes is of interest.
Let the target devices grow with Debian's total size. :))
Users of such devices would benefit if debian-cd could
avoid creating nested partitions and illegal combination of
MBR partitioning with GPT partitioning.
An appended EFI System Partition marked in MBR seems to be
best digestible for partition editors.
Like the arm64 ISOs:
Volume id: 'Debian 8.1.0 arm64 1'
El Torito catalog : 918 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x 0x00768 919
El Torito img path : 1 /boot/grub/efi.img
System area options: 0x0b00
System area summary: MBR cyl-align-all
ISO image size/512 : 329728
Partition offset : 0
MBR heads per cyl : 64
MBR secs per head : 32
MBR partition table: N Status TypeStart Blocks
MBR partition : 1 0x00 0x830 329728
MBR partition : 2 0x00 0xef 329728 2048
In contrast to
Volume id: 'Debian 8.1.0 amd64 1'
El Torito catalog : 974 1
El Torito cat path : /isolinux/boot.cat
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x 0x00 4 975
El Torito boot img : 2 UEFI y none 0x 0x00832 995
El Torito img path : 1 /isolinux/isolinux.bin
El Torito img opts : 1 boot-info-table isohybrid-suitable
El Torito img path : 2 /boot/grub/efi.img
System area options: 0x0102
System area summary: MBR isohybrid cyl-align-on GPT APM
ISO image size/512 : 505856
Partition offset : 0
MBR heads per cyl : 64
MBR secs per head : 32
MBR partition table: N Status TypeStart Blocks
MBR partition : 1 0x80 0x000 505856
MBR partition : 2 0x00 0xef 3980 832
MBR partition path : 2 /boot/grub/efi.img
GPT: N Info
GPT disk GUID : 2fd7ea575eadc7469cef97fb6e7a7721
GPT entry array: 12 208 overlapping
GPT lba range : 64 505802 505855
GPT partition name : 1 490053004f00480079006200720069006400
GPT partname local : 1 ISOHybrid
GPT partition GUID : 1 2fd7ea575eadc7469ced97fb6e7a7721
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1001
GPT start and size : 1 0 505800
GPT partition name : 2 490053004f004800790062007200690064003100
GPT partname local : 2 ISOHybrid1
GPT partition GUID : 2 2fd7ea575eadc7469cec97fb6e7a7721
GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 2 0x1001
GPT start and size : 2 3980 832
GPT partition path : 2 /boot/grub/efi.img
APM: N Info
APM block size : 2048
APM gap fillers: 0
APM partition name : 1 EFI
APM partition type : 1 Apple_HFS
APM start and size : 1 995 208
APM partition path : 1 /boot/grub/efi.img
The BIOS El Torito and ISOLINUX isohybrid stuff would stay.
GPT and APM would be used only for images which strive for
outmost bootability via actually ill EFI implementations.
UEFI specs state that MBR partition type 0xef is fully
sufficient to mark a System Partition on HD.
The limit for MBR partitioning is 2 TiB.
If GPT is desired for getting larger sizes, then
libisoburn1-1.4.0-3.deb in testing offers xorrisofs option
-appended_part_as_gpt .
Pioneers wanted.
GPT imposes the problem of backup GPT, which is to be placed
at the end of the storage device. This concept does not play
well with the idea of a disk image that shall fit onto larger
disks. MBR partitioning has no such problem.
> UEFI (and SB) on kFreeBSD is an unknown quantity at this time.
Preparing to do a kFreeBSD VM install in the next days,
i already got me a mini.iso.
It obviously has GRUB2 BIOS equipment for CD and HD.
Volume id: 'ISOIMAGE'
El Torito catalog : 55 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x 0x00 45452
El Torito img path : 1 /boot/grub/i386-pc/eltorito.img
El Torito img opts : 1 boot-info-table
System area options: 0x0201
System area summary: MBR protective-msdos-label cyl-align-off
ISO image size/512 : 23512
Partition offset : 0
MBR heads per cyl : 64
MBR secs per head : 32
MBR partition table: N Status TypeStart Blocks
MBR partition : 1 0x80 0xcd123511
So possibly grub-mkrescue is a way to go for {BIOS,EFI}x{CD,HD}
or at least to learn how to do it with GRUB2.
On the other hand, the missing piece is just what the amd64 ISOs
implement by GRUB2 already.
xorriso-1.4.0 would r
Problem between priorities of libisofs6 and libjte1
Hi, trying to get in contact with Steve McIntyre about Debian bug #800130, libjte1: A few weeks ago i made packages of xorriso-1.4.0 et.al. which are now in Debian testing, thanks to Dominique Dumont. QA complains about libisofs6 having Priority "optional" but depending on libjte1 with Priority "extra": https://qa.debian.org/debcheck.php?dist=unstable&package=libisofs I wrote to Steve in septemnber and a few days later filed the bug. A new release of libisofs is planned to happen before the end of the year. My favorite solution would be to set libjte1 to "optional", too. I cannot see hard reasons in the policy description which would prevent this. libjte1 is for an exotic use case. But libisofs6 has a popcon rank around 1000. Less favorable would be to remove the dependency on libjte1 and to tell all Jigdo producers to use GNU xorriso or to modify the Debian source packages of libisofs, libisoburn, and xorriso. Quite unfavorable would be to set libisofs, libisoburn, and xorriso to "extra". libisofs is a dependency of xfburn which has priority "optional". Have a nice day :) Thomas
Re: Problem between priorities of libisofs6 and libjte1
Hi, Steve McIntyre wrote: > Apologies for not responding earlier - swamped with other stuff I hope i showed the appropriate patience, given the low urgency of the problem. > ACK. I'll sort out a dependency change for libjte* shortly. It may > take a few days to happen, as the priorities of packages are > *actually* set via ftpmaster overrides. (Now i have a new Debian term to look up. :)) Do you plan to promote libjte1 to "optional" ? I downgraded libisofs-dev to "extra" in package VCS meanwhile. http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libisofs To get into effect with the next release and sponsored package upload. But now i wonder why there is no complaint about mismatch of libisofs-dev and libjte-dev on https://qa.debian.org/debcheck.php?dist=unstable&package=libisofs Is it because in https://tracker.debian.org/media/packages/libi/libisofs/control-1.4.0-2 the package libisofs-dev has no libjte-dev in "Depends:" ? libjte-dev only shows up in the "Source:" section. Do i have to add libjte-dev to "Depends:" of libisofs-dev ? (If so: why does it work without this since oldstable ?) Have a nice day :) Thomas
Re: Problem between priorities of libisofs6 and libjte1
Hi,
> That depends, I guess - what are people going to be building with
> libisofs-dev?
Known to me are two GUI applications:
https://tracker.debian.org/media/packages/x/xfburn/control-0.5.4-1
https://tracker.debian.org/media/packages/b/brasero/control-3.12.1-1
and libisoburn, which also produces xorriso
https://tracker.debian.org/media/packages/libi/libisoburn/control-1.4.0-3
I did not find a global search tool for reverse build dependencies.
apt-rdepends -b --reverse libisofs-dev
would be nice, but says
E: Reverse build-dependencies are not supported
The GUI applications will hardly want to produce Jigdo.
But i begin to doubt whether any of the -dev packages is
appropriate as Dependency of libisofs-dev.
The dependencies on libjte, zlib, libacl, libattr get compiled
into libisofs6.so by the presence of their -dev packages when
the source package gets compiled by buildd.
The header file libisofs.h in libisofs-dev does not refer to
anything from libjte-dev, zlib1g-dev, libacl1-dev, libattr1-dev.
All those references are encapsulated in libisofs6.so.
Applications can use the related libisofs API calls regardless
whether the functionality is actually enabled.
The presence of -dev headers would enable the according
capabilities when compiling libisoburn and xorriso.
But this is a peculiarity of libisoburn, not of other users of
libisofs-dev.
> I'd be tempted to just add it as a Recommends: if so.
https://www.debian.org/doc/manuals/maint-guide/dreq.en.html
says this would make the installation depend on the package
management tool. Quite arbitrary, therefore.
How about this diff ?
In libisofs/control:
Package: libisofs-dev
...
Depends: ${shlibs:Depends},
${misc:Depends},
libisofs6 (= ${binary:Version}),
- zlib1g-dev,
- libacl1-dev,
- libattr1-dev
Suggests: libisofs-doc (= ${source:Version})
Which would then cause a need in libisoburn/control
Source: libisoburn
...
Build-Depends: dh-autoreconf,
pkg-config,
debhelper (>= 9),
libburn-dev (>= 1.4.0),
libisofs-dev (>= 1.4.0),
+ zlib1g-dev,
+ libacl1-dev,
+ libattr1-dev
libreadline-dev,
libjte-dev
Standards-Version: 3.9.6
This would put the dependency only where it is needed by the
configuration automat of libisoburn.
I believe xfburn and brasero do not make use of any of those
capabilities. But it would be nice to know whether there are
other customers of libisofs-dev.
So: Is there a possibility to find all reverse Build-Depends
of libisofs-dev ?
Have a nice day :)
Thomas
Re: Pondering experimenting using grub to replace isolinux
Hi, Steve McIntyre wrote: > I'm told > that Grub can do all the needed stuff to boot CDs as well, so I'm > curious to test it. Debian kfreebsd mini.iso already uses GRUB2 for BIOS. amd64 and i386 have about the same equipment: Volume id: 'ISOIMAGE' El Torito catalog : 55 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 45452 El Torito img path : 1 /boot/grub/i386-pc/eltorito.img El Torito img opts : 1 boot-info-table System area options: 0x0201 System area summary: MBR protective-msdos-label cyl-align-off ISO image size/512 : 23512 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0xcd123511 xorriso -as mkisofs options for reproduction: -V 'ISOIMAGE' --modification-date='2015090121223300' --protective-msdos-label -partition_cyl_align off -partition_offset 0 -partition_hd_cyl 64 -partition_sec_hd 32 -G --interval:local_fs:0s-15s:zero_mbrpt:'debian_kfreebsd_i386_mini.iso' -c '/boot.catalog' -b '/boot/grub/i386-pc/eltorito.img' -no-emul-boot -boot-load-size 4 -boot-info-table (The argument of -G is a novelty of xorriso-1.4.0. It cuts block 0 to 15 out of the original ISO and zeros the MBR partition table. Then this is used instead of the original GRUB2 payload of the System Area. xorriso-1.4.2 will have a command to replay such settings automatically. So one can modify a bootable ISO without having to deal with above -as mkisofs options.) The partiton generating options -isohybrid-gpt-basdat -isohybrid-apm-hfsplus will not be applicable any more. grub-mkrescue uses -as mkisofs option -efi-boot-part --efi-boot-image to expose the El Torito Boot Image as EFI System Partition. That boot image gets marked by -efi-boot /path/in/iso/efi.img Afaik GRUB2's grub-mkrescue produces only the "protective" MBR partition table. I.e. there is no mountable partition with the ISO filesystem. One has to mount the base device to get to the ISO. I dimly remember to have once proposed -partition_offset 16 to Vladimir Serbinenko for use in grub-mkrescue. He was not convinced then. For the sake of UEFI compliance i now repeat my proposal to let the EFI System Partition be an appended data blob rather than sharing the El Torito Boot Image file inside the ISO. This would avoid nested partitions, which UEFI 2.4 clearly forbids. (grub-mkrescue produces no nested partitions because it produces no mountable ISO partition around the EFI partition.) Have a nice day :) Thomas
Re: jigdo-lite for windows
Hi, Try asking at mailing list debian-user-fre...@lists.debian.org See https://lists.debian.org/debian-user-french/ Ask for help with https://www.debian.org/CD/jigdo-cd/#how As for sarge-amd64-1.jigdo ... was there Jigdo in Debian 3 ten years ago ? > la derniere distribution debian pour amd64. The newest stable release is Debian 8 "Jessie". http://cdimage.debian.org/debian-cd/8.3.0/amd64/ If the installation target machine has internet accesss, consider to use http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-cd/debian-8.3.0-amd64-netinst.iso instead of http://cdimage.debian.org/debian-cd/8.3.0/amd64/jigdo-dvd/ Have a nice day :) Thomas
Re: jigdo-lite for windows
Hi, i can only test on Debian GNU/Linux, not on MS-Windows. I ran $ jigdo-lite and was asked for the URL To start a new download, enter URL of .jigdo file. ... jigdo: I gave the one of CD 1 to keep the test small: http://cdimage.debian.org/debian-cd/8.3.0/amd64/jigdo-cd/debian-8.3.0-amd64-CD-1.jigdo You will probably begin by http://cdimage.debian.org/debian-cd/8.3.0/amd64/jigdo-dvd/debian-8.3.0-amd64-DVD-1.jigdo It then showed lots of messages and asked Alternatively, just press enter if you want to start downloading the remaining files. Files to scan: So i just pressed enter. It asked me for a Debian mirror Debian mirror [http://ftp.de.debian.org/debian/]: I just pressed enter again. Now i got internet traffic. jigdo-lite fetched the Debian packages which fit into the holes of the .template file. (At this point i have to re-iterate that netinst .iso CDs would fetch only what is needed when it is needed. So if internet is available at installation time in good quality ...) After a few minutes the CD image was complete OK: Checksums match, image is good! I am mistrusting and determine the MD5 checksum of the result file $ md5sum debian-8.3.0-amd64-CD-1.iso a3e289b886c43150431b05b091c51ad8 debian-8.3.0-amd64-CD-1.iso This matches the first line in http://cdimage.debian.org/debian-cd/8.3.0/amd64/jigdo-cd/MD5SUMS To get the complete collection of all Debian packages you will have to do this with each of the 13 DVD .jigdo files in http://cdimage.debian.org/debian-cd/8.3.0/amd64/jigdo-dvd/ (The two debian-update DVDs are not needed, afaik.) With Blu-ray, it would be only 3 media images. Have a nice day :) Thomas
Re: jigdo-lite for windows
Hi, i asked Florent Larose to move the thread over to debian-u...@lists.debian.org for now. Have a nice day :) Thomas
Re: UEFI support for mini.iso?
Hi, Wouter Verhelst wrote: > This image however does not support booting on a UEFI-only system. It does support EFI booting from CDROM. At least with qemu and OVMF as EFI firmware. > Is there anyone with the required knowledge who would be willing to > look into fixing that? I downloaded http://ftp.debian.org/debian/dists/sid/main/installer-amd64/current/images/netboot/mini.iso which bears this boot equipment: El Torito catalog : 59 1 El Torito cat path : /boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 4 268 El Torito boot img : 2 UEFI y none 0x 0x00832 60 El Torito img path : 1 /isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /boot/grub/efi.img MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x17051200 MBR partition : 2 0x00 0x015120012288 I.e. it has an EFI boot image for booting from CD, but no partition of MBR type 0xef which would point to that image file /boot/grub/efi.img. So expectably it boots by qemu-system-x86_64 -enable-kvm -m 512 -bios /usr/share/ovmf/OVMF.fd -cdrom mini.iso and does not boot by qemu-system-x86_64 -enable-kvm -m 512 -bios /usr/share/ovmf/OVMF.fd -hda mini.iso One could use xorriso to repack the ISO and apply options which would cause production of partition tables. But in this case we have the classical situation for SYSLINUX program "isohybrid". (We even have the repaired version in Sid, which does not write random chinese GPT partition names.) isohybrid -u mini.iso This yields a partition table layout similar to netinst: MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x00063488 MBR partition : 2 0x00 0xef 240 832 MBR partition path : 2 /boot/grub/efi.img GPT: N Info GPT disk GUID : 12f7657a83abeb4a8a7290afeb748d8d GPT entry array: 2 128 overlapping GPT lba range : 34 63454 63487 GPT partition name : 1 490053004f004800790062007200690064002000490053004f00 GPT partname local : 1 ISOHybrid ISO GPT partition GUID : 1 b028cc51ece2734982f7a619cd3b977a GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x GPT start and size : 1 0 50464 GPT partition name : 2 490053004f00480079006200720069006400 GPT partname local : 2 ISOHybrid GPT partition GUID : 2 3e7e8dac6a466b488fec85bd1f82f267 GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 2 0x GPT start and size : 2 240 832 GPT partition path : 2 /boot/grub/efi.img If i run again qemu-system-x86_64 -enable-kvm -m 512 -bios /usr/share/ovmf/OVMF.fd -hda mini.iso i see a few messages about failed attempts. But then i get to the GRUB2 menu. Actually the GPT is considered surplus. Any UEFI compliant firmware should follow the lure in MBR partition 0xef, because the GPT is not announced by MBR having a single partition of type 0xee. Have a nice day :) Thomas
Re: UEFI support for mini.iso?
Hi, Wouter Verhelst wrote: > http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/util/geniso_hybrid_plus_firmware_partition > I add a line isohybrid -u "$iso" This last isohybrid run replaces the partition which was crafted by the fdisk run. This is also the reason why fdisk does not succeed with the result of isohybrid -u. Partition 2 cannot be created because ist already exists. If the script would contain the ISO production run, then i would propose xorrisofs options like -isohybrid-gpt-basdat and -append_partition which would make runs isohybrid and fdisk unneeded. But since there is only the partition maker to see, i propose to just change partition number 2 to 3 in the fdisk run and to let it happen after the isohybrid -u run. I tested this with a result of isohybrid -u named mini-test.iso: - Because isohybrid -u expanded partition 1 to the end of the image file, i had to add once again bytes for the "Firmware Partition" like the script does in line 37 by cat "$firmware_volume_file" >> "$iso" My command was dd if=/dev/zero count=12288 >>mini-test.iso This waste is not necessary if the isohybrid -u run happens before the cat "$firmware_volume_file" >> "$iso" run. - Then i ran /sbin/fdisk with nearly the same input as in the script but with partition number 3 instead of 2: # Make new partition #3 echo n echo p echo 3 echo # use default start sector # Pedantically, set partition type to 1: FAT 16 echo t echo 3 echo 1 # Done! echo w /sbin/fdisk -lu reports about the result: Device Boot Start End Sectors Size Id Type mini-test.iso1 *0 63487 63488 31M 0 Empty mini-test.iso2240 1071 832 416K ef EFI (FAT-12/16/32) mini-test.iso3 63488 75775 122886M 1 FAT12 This boots by qemu-system-x86_64 -enable-kvm -m 512 -bios /usr/share/ovmf/OVMF.fd -hda mini-test.iso Have a nice day :) Thomas
Upcomming trouble with Sid kernel and TAO CDs
Hi,
how much is debian-cd concerned/interested that CDs written by write type
TAO stay readable for e.g. blkid ?
I ask because Archlinux ISOs already do not boot properly from such CDs
as they rely on /dev/disk/by-label/ links to mount the ISO.
https://bugs.archlinux.org/task/48234
The current amd64 mini.iso would suffer the same fate, if it did rely
on blkid for booting. I burned it to a CD-RW with option -tao and
booted it on real iron to rescue mode (without mounted root).
Same symptoms as with Archlinux:
- blkid does not work with /dev/sr0. dmesg shows i/o errors,
both at the first TAO run-out block.
- dd reports one i/o error at some random sector near the end,
and one i/o error at the first TAO run-out block.
On Archlinux uname says 4.3.3-3, on Debian it says 4.3.0-1.
So we are up to reports about strange behavior of some netinst CDs
as soon as kernel 4.3 hits the users.
If there is interest i could need help in understanding the block
device procedures which distinguish 4.3 from 3.16. A few months ago
i was glad to read in /usr/src/linux-{3.16,4.1.6}/drivers/scsi/sr.c
a quite mislead comment and remedy, which nevertheless causes nearly
flawless behavior in 3.16.
* The SCSI specification allows for the value
* returned by READ CAPACITY to be up to 75 2K
* sectors past the last readable block.
* Therefore, if we hit a medium error within the
* last 75 2K sectors, we decrease the saved size
* value.
It is actually about the last 2 sectors. The number 75 is unrelated
and probably a schily rumor. (I dare the world to show me that specs part.)
I also wonder where the SCSI specs promise this info:
error_sector = (SCpnt->sense_buffer[3] << 24) |
(SCpnt->sense_buffer[4] << 16) |
(SCpnt->sense_buffer[5] << 8) |
SCpnt->sense_buffer[6];
which seems to work the miracle of exact read amount in 3.16.
Is this artificial info from the drivers ?
Something must have changed with buffering and reading-ahead which
now devalues this effort. Maybe it's even about the miracle sense data.
If there is no interest in the kernel problem, then we should at least
begin to warn of TAO CD recording. Obviously Brasero does it by default.
Afaik, wodim does it by default.
Have a nice day :)
Thomas
Re: Upcomming trouble with Sid kernel and TAO CDs
Hi, Steve McIntyre wrote: > Oh, ugh. :-( The problem may well be a year old. First report is about Archlinux 2015.04. > Have you mentioned this on the linux kernel list? Not yet. I am still looking for allies or even better a mentor. (Will work for guidance.) Funny thing is that in october i began to prepare a petition to linux-scsi about the old TAO read-ahead bug. When making my case i discovered that it is nearly fixed in Jessie. Only ioctl(BLKGETSIZE) is still wrong by reporting 2 sectors too many. (And the comment is wrong, not to forget.) Have a nice day :) Thomas
Re: Archive changes
Hi,
Joerg Jaspert wrote:
> > > As of now, InRelease/Release files, Packages and Sources no longer
> > > provide MD5Sum and SHA1sums, only SHA256.
Steve McIntyre wrote:
> > We can't fix this easily in a short
> > timescale - current released jigdo clients (both in Debian and
> > externally) use md5 internally to reference files in the archive.
Joerg Jaspert wrote:
> Im not sure we *want* to support that, at least for sure not for more than
> stretch, but we could.
> > We need more time than that to fix things up.
> How much?
Currently Jigdo is produced by xorriso, libisofs, and libjte.
libjte upstream is Steve, with George Danchev and me as co-authors.
libisofs and xorriso upstream is me.
I only know of consumer jigit. Are there others (externals) ?
--
xorriso:
- Calls API function libjte_set_md5_path().
Either there needs to be a new call for the SHA256 list file path,
or we keep this function as half misnomer and let the MD5 file reader
of libjte recognize SHA256 automatically.
libisofs:
- Seems not to refer to the checksum type.
(Let's hope my assessment is true.)
libjte:
- Offers API call libjte_set_md5_path().
As mentioned above, one could let it recognize MD5 and SHA256 list
content so that the callers do not have to care for the change.
Only the runner of xorriso (debian-cd, i assume) would have to
submit a suitable SHA256 list file instead of the old MD5 list.
- Internal function parse_md5_list() and its subordinates read
the given list file and create a list of md5_list_entry_t.
typedef struct _md5_list_entry
{
struct _md5_list_entry *next;
unsigned char MD5[16];
uint64_t size;
char *filename;
} md5_list_entry_t;
This struct and the reader would have to be adapted to the new
checksum list format.
- The equipment for SHA256 computation seems already present.
At least there is a file sha256.c.
- Internal call list_file_in_jigdo() makes the decision, whether
a data file in the future output matches a listed file item by
basename and by MD5.
This function needs to learn to process SHA256.
- Some message texts talk of "MD5" hardcodedly. There we'd need a
variable text snippet.
- Internal function write_template_desc_entries() in one of its
cases writes a jigdo_file_entry_t to the .template file.
typedef struct _jigdo_file_entry
{
unsigned char type;
unsigned char fileLen[6];
unsigned char fileRsync[8];
unsigned char fileMD5[16];
} jigdo_file_entry_t;
This will cause a layout change in the .template file.
(Jigdo consumer jigit has Steve as upstrem.)
- Internal function add_file_entry() records a file_entry_t for
each matching file:
typedef struct _file_entry
{
unsigned char md5[16];
off_t file_length;
uint64_trsyncsum;
char *filename;
} file_entry_t;
Internal function write_jigdo_file() writes the MD5 of the .template
file and the MD5s of the file_entry_t (as union member of entry_t).
This will cause a layout change in the .jigdo file.
- The most probably unused "Traditional Data File API" deals with MD5
sums computed from data files:
int libjte_decide_file_jigdo(struct libjte_env *jte_handle,
char *filename, off_t size, char **mirror_name,
unsigned char md5[16]);
int libjte_write_match_record(struct libjte_env *jte_handle,
char *filename, char *mirror_name, int sector_size,
off_t size, unsigned char md5[16]);
One should consider to give up this API in favor of the
"Simplified Data File API" as used by libisofs.
There are many more occurences of [Mm][Dd]5 in jte.c and libjte.c.
They seem to be consequences of the gestures described above.
All of them have to be checked and adapted, of course.
--
Summary:
Program jigit and library libjte would need a thorough overhaul.
The higher levels inside xorriso could stay as they are.
The impact on external Jidgo tools has to be judged by their
maintainers.
The effort in libjte would be at least one week of dense work and
testing. A substantial part of this is the plight to analyze the
old code which none of us touched in the last 5 years.
Have a nice day :)
Thomas
Re: Debian images and USB sticks
Hi, > However, it's possible to allow the latter running isohybrid --partok > iso-name.iso (according to isohybrid's man page), and I have done so, and it > works. Interesting result. How did you make the MBR of the overall device which then hops onto the code at the start of the partition ? > I wonder if there is a good reason this doesn't come as a default option? I do not see (yet) how one could combine UEFI with a partition MBR in the same image. It seems to me that one would have to extract the EFI System Partition from the ISO and put it onto USB stick as separate partition of type 0xef. One would simply leave out GPT and rely on the middle legacy boot path of UEFI. (Younger than BIOS emulation but not as shiny as GPT.) If a partition MBR is desired, one would need to use a different MBR template file. According to http://www.syslinux.org/wiki/index.php?title=Isohybrid#MBR_selection this would be isohdppx.bin. (I wrote that table from existing SYSLINUX docs and am not aware that anybody ever tried whether it is correct. Your mileage may vary.) Have a nice day :) Thomas
Re: Debian images and USB sticks
Hi, Renato Bispo wrote: > -> I partitioned my USB stick using gparted, setting the boot flag on the > partition I wanted to put the image. Now i wonder whether the stick already contained MBR code which would jump on the marked partition or whether gparted installed such x86 machine code. See https://en.wikipedia.org/wiki/Master_boot_record#System_bootstrapping The third paragraph seems to describe what you experience. A small program which looks for the bootable/active flag and executes the code at the start of that partition. > (I think it's relevant to say that I > tried to do the partitioning and formatting of the stick using fdisk and > mkfs.fat, having the same result in the end of the process, according to > gparted, meaning everything there looked the same, but I couldn't boot from > the stick doing it that way, I would get stuck in the black screen with the > blinking cursor.) Looks like gparted installed the code. But i cannot find hints in the web. Please show the first 512 bytes of the working stick: dd if=/dev/sdX bs=512 count=1 | od od -t x1 Have a nice day :) Thomas
Re: Debian images and USB sticks
Hi, i wrote > > dd if=/dev/sdX bs=512 count=1 | od od -t x1 Renato Bispo wrote: > the command you sent didn't work: A copy+paste error indeed. A single "od" would have been right. > 000 b8fa 1000 d08e 00bc b8b0 d88e c08e A bit pattern widely known to the web. http://superuser.com/questions/317372/editing-mbr-for-flash-device advises to use "parted" and predicts that this code will be on the medium. Other than gparted, parted is in my scope. So i try dd if=/dev/zero bs=4M count=1 >test.img /sbin/parted test.img mklabel msdos dd if=test.img bs=512 count=1 | hexdump and get 000 b8fa 1000 d08e 00bc b8b0 d88e c08e 010 befb 7c00 00bf b906 0200 a4f3 21ea 0006 020 be00 07be 0438 0b75 c683 8110 fefe 7507 030 ebf3 b416 b002 bb01 7c00 80b2 748a 8b01 040 024c 13cd 00ea 007c eb00 00fe ... [empty partition table] ... 1f0 aa55 So the prescription would be to let parted (or frontends) install its MBR, to create a partition with boot flag, to re-isohybridize a Debian i386 or amd64 ISO image, and to put it into the partition. This is to be executed only once before any other partitions get created on the USB stick. end_megabyte minus start_megabyte must offer enough room to take the ISO image. dev=/dev/sdc start_megabyte=1 end_megabyte=316 image_path="$HOME/Downloads/debian-8.2.0-i386-netinst.iso" sudo /sbin/parted "$dev" mklabel msdos sudo /sbin/parted "$dev" mkpart primary $start_megabyte $end_megabyte sudo /sbin/parted "$dev" set 1 boot on isohybrid --partok "$image_path" dd if="$image_path" of="$dev" bs=1M This is expected to boot via BIOS but not via EFI (unless BIOS emulation). One may now create more partitions and populate them with filesystems, e.g. another isohybrid --partok ISO. One of those which contain bootable MBRs can be selected by part_number=3 sudo /sbin/parted "$dev" set $part_number boot on Now i wonder whether this procedure works for you, or whether i made a copy+paste mistake again. (I did not use /dev/sdc but rather test.img.) Have a nice day :) Thomas
Re: Debian images and USB sticks
Hi, i made a mistake, of course. This time when copying the ISO: Wrong: dd if="$image_path" of="$dev" bs=1M Right: dd if="$image_path" of="$dev"1 bs=1M If you perform the wrong command, then the parted MBR gets overwritten by the isohybrid MBR of the Debian ISO. Have a nice day :) Thomas
Re: Debian images and USB sticks
Hi, > Does the method described in the manual (copying to /dev/sdX) work under > UEFI? Or it's basically the same thing as copying to a partition? The main difference is that copying to /dev/sdX overwrites the MBR and the partition tables, while copying to /dev/sdXn keeps the partitioning (and the other partitions' content) unchanged. BIOS booting from MBR does not necessarily need a partition table. (It's the parted MBR code which looks for a partition marked as bootable, not the BIOS firmware which simply starts the MBR code as x86 program.) But UEFI wants to see a EFI System Partition announced by MBR or GPT. By copying the Debian ISO image to a partition you do not create a new EFI System Partition. By copying it to the base device, you give it the partition tables which are stored in the ISO. So if you put the Debian ISO into a partition, then for UEFI you'd need to extract the content of the EFI System Partition from the ISO and put it into a separate MBR partition of type 0xef. Debian i386 and amd64 netinst ISOs have their EFI System Partition content in file /boot/grub/efi.img . In general you can ask a partition editor to print the table $ /sbin/fdisk -lu debian-8.2.0-i386-netinst.iso ... Device Boot StartEnd Sectors Size Id Type debian-8.2.0-i386-netinst.iso1 *0 645119 645120 315M 0 Empty debian-8.2.0-i386-netinst.iso2 4020 4659 640 320K ef EFI (FAT-12/16 and use dd to cut out the content of the partition with id "ef": dd if=debian-8.2.0-i386-netinst.iso bs=512 skip=4020 count=640 of=my_esp.img The next problem might be that the starting system software normally expects to wake up on /dev/srY or /dev/sdX, not on /dev/sdX1. That's the realm of the debian-cd project. My scope ends when the boot loader has started. (It is the most interesting part of your adventure that the system boots from /dev/sdX1 via BIOS. There is some hope it will do for UEFI, too.) Have a nice day :) Thomas
Re: Debian images and USB sticks
Hi, Renato Bispo wrote: > * Under BIOS at least More we cannot expect from this setup. The next experiment would be to create a new partition of type 0xef (1MiB, with no filesystem on it, should be ok) and to copy the file /boot/grub/efi.img, which is actually a FAT filesystem image. Then one would try with an EFI system where legacy BIOS emulation is disabled or by a qemu with OVMF as firmware qemu-system-x86_64 -enable-kvm -bios /usr/share/ovmf/OVMF.fd -hda /dev/sdc > PS - I'm curious about this: when I opened the images with an archive > manager (more specifically with the one that comes with the MATE desktop), I > saw a directory named "[BOOT]" that contained files with a name along the > lines of "...no-emulation...". The date of creation was 1969. Pretty weird, > haha. Do you have any idea about what it is? Probably a synthetic directory which represents the El Torito boot images. "...no-emulation..." applies to both, the binary /isolinux/isolinux.bin, and the FAT image /boot/grub/efi.img. The boot catalog does not contain file names but only some info fields like intended firmware platform, bootability, floppy-or-disk emulation, x86 load address, size, block address. Compare the sizes of /isolinux/isolinux.bin and /boot/grub/efi.img with the ones reported by the archive manager in the [BOOT] directory. 1969 is a strange date for a Unix-ly system. The lowest possible file date is supposed to be 1 Jan 1970. Well, if my theory about synthetic files is true, then the date is purely synthetic, too. Have a nice day :) Thomas
Re: cd 8.4 xfce
Hi, Weber wrote: > I cannot verify the /dev/sr2 > after i tried this there appears a new cdrom /dev/sr3 Looks like the device was abandoned and newly acquired by the operating system. Do you see error messages in the system log after this happened ? Have a nice day :) Thomas
Re: verify CD
Hi, Weber wrote: > > $ dd if=/dev/cdrom | \ > > head -c `stat --format=%s debian-testing-i386-netinst.iso` | \ > > md5sum > > its not working on wheezy. What are the exact failure symptoms ? > md5sum with Brasero seems to have an bug(?): > the "ok" messsage comes up without any testing. At what occasion does Brasero confirm an MD5 ? Please give the sequence of menu items by which you reach that check. > this works: > dd if=/dev/sr3 | md5sum debian-8.4.0-i386-xfce-CD-1.iso Only with CD which were written by write type SAO or with DVD-R[W] written by type DAO. No padding may be applied by the burn program. (By what program and which of its features did you burn your medium ?) Have a nice day :) Thomas
Re: Does Debian use implemented MD5 sums ?
Hi, Alexey Eromenko wrote: > implantisomd5 [...] > Basically it implants the MD5sum into a secret portion of ISO 9660 > filesystem Not so secret. At least if it stems from https://github.com/rhinstaller/isomd5sum/blob/master/libimplantisomd5.c The MD5 gets written into a field of the ISO 9660 Primary Volume Descriptor which begins at byte offset 32768. From there 883 bytes up, ECMA-119 specifies: 8.4.32 Application Use (BP 884 to 1395) This field shall be reserved for application use. Its content is not specified by this Standard. (BP counting starts at 1) I understand that implantisomd5 divides the ISO in 20 "fragments" of which it computes separate checksum. From those it takes three bytes each and converts them to 120 hex digits. Then it prints the overall MD5, some other info, and the 120 digit "fragment md5sums string" into the Application Use field. This all has to fit into 512 bytes. I wonder why it wastes lots of them by a hex representation. > Does Debian has something similar ? It could easily have: xorriso -as mkisofs ... --md5 ... This records an MD5 for the extended superblock (System Area, PVD, El Torito Boot Record, Joliet Supplementary Volume Descriptor), plus one for the image up to the end of the directory tree, plus one for the overall ISO image. Additionally it records an MD5 for each data file in the ISO. These MD5 get stored as compact array at the very end of the ISO. Thus they can be produced as stream without the need for revisiting the ISO image after production. They can be checked on any random access storage medium by commands like xorriso -md5 on -indev stdio:/dev/sdc -check_media -- which checks the three image checksums, or xorriso -md5 on -indev /dev/sr0 -check_md5_r sorry / -- which checks the individual MD5s of the data files in the image. Have a nice day :) Thomas
Do the file timestamps in ISOs matter ?
Hi, do the file timestamps matter in ISOs of debian-cd, debian-live, or in other Debian ISOs ? I ask this because xorriso-1.4.6 will obey environment variable SOURCE_DATE_EPOCH of reproducible-builds. I then plan to propose to debian ISO producers to use xorriso-1.4.6 with new original ISOs and to do the equivalent of shell command export SOURCE_DATE_EPOCH=$(date '+%s') before running xorriso. It is decided that SOURCE_DATE_EPOCH will override the defaults of the volume timestamps and of some id data which normally get derived from the time of the ISO production. xorrisofs options like --modification-date= will still be able to override the default set by SOURCE_DATE_EPOCH. Still undecided is whether it shall by default override all timestamps inside the ISO, or whether it shall only copy each file's mtime to the same file's ctime and atime (to ease reproduction of input file trees). Obviously there are three ideas of reproducible ISO content: - All three file timestamps do matter. - mtime does matter. atime and ctime are harder to influence in the input tree and thus should get overwritten by mtime. - File timestamps do not matter. After all, the files all got copied from some disk tree into the ISO at the same time. xorriso will support all three models by allowing to override SOURCE_DATE_EPOCH by one of three parameters to a new program option: --set_all_file_dates default --set_all_file_dates set_to_mtime --set_all_file_dates ="$SOURCE_DATE_EPOCH" (The latter depends on shell variable evaluation. "=" tells xorriso that the date value is seconds since 1970. xorriso wants to see a number like 1472115709 then.) All affected producers of Debian ISOs and reproducible-builds are invited to discuss and decide what default to choose from SOURCE_DATE_EPOCH. Have a nice day :) Thomas
Re: Do the file timestamps in ISOs matter ?
Hi, i wrote: > > new program option: --set_all_file_dates [...] Chris Lamb wrote: > I believe this option is entirely unnecessary. No need to > complicate things. It is architecturally needed, because if SOURCE_DATE_EPOCH sets the default, there must be some option to set non-default values, especially the value which is default without SOURCE_DATE_EPOCH. I decided to let SOURCE_DATE_EPOCH only set the defaults of existing and new options, in order to protect ISO producers like grub-mkrescue from negative effects by overriding their program options. (grub-mkrescue uses --modification-date= to set the text in ISO 9660 field Volume Modification Date, so that GRUB command search --fs-uuid --set -MM-DD-hh-mm-ss-cc can look it up.) Not to forget that it offers those users a workaround, who do not agree with the final decision about the question posed here, but want to use SOURCE_DATE_EPOCH nevertheless. Have a nice day :) Thomas
Re: Do the file timestamps in ISOs matter ?
Hi,
Chris Lamb wrote:
> I just don't see this usecase of being "partly" reproducible being remotely
> useful to anyone, ever. I'm probably misunderstanding something, however.
All three possible behaviors lead to reproducibility if the input trees
of the ISO production runs are sufficiently similar.
The undecided question is, as the subject says, how much similarity is
most likely needed. The more - the harder to reproduce.
- If ctime and/or atime of files in the input tree matter, then they
should not be overridden by SOURCE_DATE_EPOCH.
I.e.: --set_all_file_dates "default"
Reproducibility would break quite easily unless the input filesystem
is read-only.
- If mtime stamps of input tree matter, then they should not be overridden
by SOURCE_DATE_EPOCH.
I.e.: --set_all_file_dates "set_to_mtime"
Reproducibility would survive input tree operations like cp -a.
- File timestamps in the ISO do not matter and rather are just a potential
obstacle for reproducibility, then SOURCE_DATE_EPOCH should override them.
I.e.: --set_all_file_dates ="$SOURCE_DATE_EPOCH"
Reproducibility would survive any operation that preserves name tree,
ownership, permissions, and file content.
(Ownership and permissions could be flattened by xorrisofs option -r.)
The latter two are what i would consider reasonable for general purposes.
I myself with my purpose of repacking existing ISOs and checking for
regressions could even live with the first one.
> Therefore folding it all into inheriting {a,c}time from mtime iff S_D_E
> is the logical conclusion,
If "iff" means "if and only if", then i have to contradict:
SOURCE_DATE_EPOCH is not the only way to achieve mtime to ctime,atime copying.
That's a consequence of how i implement it.
So it's only "if", not "iff".
> there is need to for people who "just"
> want a reproducible ISO to tediously scour the documentation to discover
> they need to set --set_all_file_dates.
No. SOURCE_DATE_EPOCH makes the ISO reproducible if it does not get
overriden by non-constant parameters of the program options which one
would have to look for (after man page section ENVIRONMENT listed them
as explanation of SOURCE_DATE_EPOCH).
Another precondition is that the input trees are sufficiently similar,
of course.
The proposal to set all file timestamps to SOURCE_DATE_EPOCH would actually
"just" ease the production of reproducible ISOs.
> > grub-mkrescue
> They won't be run with SOURCE_DATE_EPOCH exported.
When xorriso-1.4.6 is out i plan to ask grub-devel to introduce an option
in grub-mkrescue which overrides the "now" time when the argument for
xorrisofs option --modification-date= is determined.
Maybe i can talk them into deducing the --modification-date= string from
SOURCE_DATE_EPOCH.
(If "set_to_mtime" wins the election, then the actual time value of
SOURCE_DATE_EPOCH will get overridden by --modification-date= completely.)
Have a nice day :)
Thomas
Re: Do the file timestamps in ISOs matter ?
Hi, i wrote: > > All three possible behaviors lead to reproducibility if the > > input trees of the ISO production runs are sufficiently > > similar. Sam Hartman wrote: > So, are you using a definition of reproducible different than the > resulting iso will have the same SHA-1 hash? I mean identical results. Bit by bit. The question to decide is: What is considered a sufficiently similar input tree in respect to timestamps ? Or in the context of ISO producers: How much flattening (non-injectivity) is tolerable. How much fidelity (non-aliasing) is needed ? The answer depends on the expectations of the programs inside the ISO or expectations of programs and informations which get imported from elsewhere by the programs in the ISO. (The expectations of already installed software on the target system are restricted to those of boot firmware, i assume.) For example, assume that "make" is supposed to act on ISO content. In that case, high timestamp fidelity would be needed. Have a nice day :) Thomas
Re: Do the file timestamps in ISOs matter ?
Hi, by the narrow margin of one vote, the proposal "set_to_mtime" wins. Committed as http://libburnia-project.org/changeset/5757 man 1 xorrisofs of the next release will state: SOURCE_DATE_EPOCH belongs to the specs of reproducible-builds.org. It is supposed to be either undefined or to contain a decimal number which tells the seconds since january 1st 1970. If it contains a number, then it is used as time value to set the default of --modification-date= and --gpt_disk_guid.The default of --set_all_file_dates is then "set_to_mtime". Startup files and program options can override the effect of SOURCE_DATE_EPOCH. This refers to the description of two new options: --gpt_disk_guid value Control whether an emerging GPT shall get a randomly generated disk GUID or whether the GUID is supplied by the user. Value "random" is default. Value "modification-date" produces a low quality GUID from the value set by option --modification-date=. [...] --set_all_file_dates timestring [...] If the timestring is "set_to_mtime", then the atime and ctime of each file and directory get set to the value found in their mtime. [...] I am now beginning final regression tests for the release of xorriso-1.4.6. Have a nice day :) Thomas
Re: The Three Requests
Hi, Alexey Eromenko wrote: > 1. Hybridize ISO images The amd64 and i386 ISOs are equipped with isohybrid functionality. In which ISOs are you missing this feature ? > 2. Please "implantisomd5" I assume this will meet the same obstacles as the wish for isohybrid a few years ago: Changing the ISO by postprocessimg would spoil jigdo. xorriso -as mkisofs offers option --md5. It equips the superblock, the directory tree, and the whole session with MD5. Each data file gets an own MD5. They can later be checked by xorriso commands -check_media or -check_md5_r. xorriso -md5 on -indev debian...iso -check_media -- Inquiry of the MD5s and their covered size is not yet implemented, but could be done, if desired. Have a nice day :) Thomas
Re: Probably problem with ISO image debian-8.6.0-arm64-netinst.iso
Hi, Anders Thulin wrote: > Looking at debian-8.6.0-arm64-netinst.iso using ISOBuster. > In the Primary Volume Descriptor file hierarchy, there's a file > /FIRMWARE/FIRMWARE.DEB;1 (size 0). That's a symbolic link. firmware-linux-free_3.3_all.deb -> ../pool/main/f/firmware-free/firmware-linux-free_3.3_all.deb Useful mostly with Rock Ridge. > In the Supplementary Volume Descriptor (Joliet), that file isn't there. > The directory /firmware is present, but it is empty. Joliet (and plain ISO 9660) do not represent symbolic links. Because Rock Ridge is an add-on to the ISO 9660 tree, there is an empty file in that tree, of which the Rock Ridge attributes tell the story. I wonder why the Debian installation ISOs contain Joliet at all. Are there use cases on MS-Windows for which one would want to unpack files ? Is it certain that all names are short enough for being represented in Joliet without mangling ? (103 characters by -joliet-long.) > So ... Debian CD production may have some kind of problem. If it is a problem, then of program xorriso, of which i am the developer. For now i see none, except the inavoidable confusion caused by empty or missing file, where Rock Ridge mounted on a Unix-ly system shows a working symbolic link. Have a nice day :) Thomas
Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7
Hi, schatzclan wrote: > unexpectedly larger > actual file size (642M) vs reported size (613M) for the “i386 8.x.0 LXDE > CD#1” iso. This is explainable from the difference of programmer's MiB and IEC's MB: 642.0 / 1024 / 1024 * 1000 * 1000 = 612.2589111328125 > The “i386 8.5.0 XFCE CD#1” ISO image mounted cleanly on the mac laptop Is this the "1997-vintage" machine ? (Or is it a third machine standing by ?) > "i386 8.6.0 DVD 1" ISO image - iso was damaged although checked OK via MD5, Most probably not by transport. After all it is very unlikely to get the same MD5 by accident. > nor would it mount on a Mac Laptop [...] > Could it be that the hybrid CD/USB iso is causing problems? A while ago, there was a discussion here https://lists.debian.org/debian-cd/2011/04/msg00029.html Start of thread https://lists.debian.org/debian-cd/2011/04/msg00038.html "snow leopard [...] The following disk image could not be opened: debian-6.0.1a-i386-DVD-1.iso - no mountable file systems" https://lists.debian.org/debian-cd/2011/04/msg00042.html "I do confirm that after removing the isohybrid of the image, I am able to mount it." The mountable ISO was made from the not mountable one by: dd if=/dev/zero bs=2K count=16 >test_image.iso dd if=/dvdbuffer/debian-6.0.1a-i386-DVD-1.iso bs=2K skip=16 >>test_image.iso (The result won't boot from USB stick, of course.) - The only difference i can spot between isohybrid equipment of debian-8.5.0-i386-lxde-CD-1.iso.1 and debian-8.6.0-i386-DVD-1.iso is the size of the ISOs and the fact that the DVD image has no consistent Cylinder/Head/Sectors geometry. I now repacked debian-8.6.0-i386-DVD-1.iso by xorriso-1.4.6 (as of Sid) and got consistent CHS geometry (238 heads/cyl, 32 secs/head). Repacking to "test.iso" was done by: mount debian-8.6.0-i386-DVD-1.iso /mnt/iso xorriso -as mkisofs \ -o test.iso \ -V 'Debian 8.6.0 i386 1' \ --modification-date='2016091713290100' \ -isohybrid-mbr --interval:local_fs:0s-15s:zero_mbrpt,zero_gpt,zero_apm:'debian-8.6.0-i386-DVD-1.iso' \ -partition_cyl_align off \ -partition_offset 0 \ -apm-block-size \ -c '/isolinux/boot.cat' \ -b '/isolinux/isolinux.bin' \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -eltorito-alt-boot \ -e '/boot/grub/efi.img' \ -no-emul-boot -isohybrid-gpt-basdat -isohybrid-apm-hfsplus \ /mnt/iso Have a nice day :) Thomas
Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7
Hi, i made a copy + paste error with the repacking command. Option -apm-block-size lacks its parameter "2048". Correct would be: mount debian-8.6.0-i386-DVD-1.iso /mnt/iso xorriso -as mkisofs \ -o test.iso \ -V 'Debian 8.6.0 i386 1' \ --modification-date='2016091713290100' \ -isohybrid-mbr --interval:local_fs:0s-15s:zero_mbrpt,zero_gpt,zero_apm:'debian-8.6.0-i386-DVD-1.iso' \ -partition_cyl_align off \ -partition_offset 0 \ -apm-block-size 2048 \ -c '/isolinux/boot.cat' \ -b '/isolinux/isolinux.bin' \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -eltorito-alt-boot \ -e '/boot/grub/efi.img' \ -no-emul-boot -isohybrid-gpt-basdat -isohybrid-apm-hfsplus \ /mnt/iso If this ISO does not mount on Mac, it would be interesting to see whether omitting option -isohybrid-apm-hfsplus yields a better result. Have a nice day :) Thomas
Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7
Hi, (This is about the aspect Mac mountability, not about the aspect of suitable performance during or after installation..) Shirish Agarwal wrote: > Would it be possible to upload the image to someplace where the OP > could download and use it and see if that works for him. It is nearly 4 GB of size. The first experiment to do is quite simple: dd if=/dev/zero bs=2K count=16 >test.iso dd if=debian-8.6.0-i386-DVD-1.iso bs=2K skip=16 >>test.iso If this does not help with mountability of "test.iso", then the other experiments are futile. In case of mountability after above experiment, the xorriso runs would be of interest because the CD ISO is mountable on Mac despite having the nearly same isohybrid equipment as the DVD ISO. The old theory was that some Macs dislike isohybrid. This does not hold in this case. Maybe this Mac dislikes some finer details of Debian isohybrid ISOs. Have a nice day :) Thomas
Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7
Hi, Sam Hartman wrote: > Why do we care if it mounts on a third mac? I care in my role as upstream of xorriso. As for debian-cd, any oddity of installation ISOs should be inspected and judged whether it demands action. I see i forgot to Cc: the bug reporter. Hi ! There are replies to see at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851628 including a wish of mine to do experiments. Have a nice day :) Thomas
Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7
Hi, Sam Hartman wrote: > I'd ask that when interacting with end users, you be more clear about > what you're trying to do. I am trying to answer this question from the bug report: > > Could it be that the hybrid CD/USB iso is causing problems? The answer is for now: It might be a problem with MacOS which i do not fully understand yet. It should be no problem with a Linux kernel, regardless of hardware. Have a nice day :) Thomas
Re: Anfrage
Hi,
Wolfgang Schindler wrote:
> sorry, mein Englisch ist nicht so gut.
Google translation delivers a quite understandable translation of your
text to english language.
(= Der Google Uebersetzer bringt es einigermassen verstaendlich nach
Englisch.)
There is a german language debian-user mailing list:
(= Es gibt eine deutschsprachige debian-user Mailingliste:)
https://lists.debian.org/debian-user-german/
> Ich bin auf der Suche nach einer Debian ISO CD oder DVD 8.7.1 in KDE.
> (= I am looking for a Debian ISO CD or DVD 8.7.1 in KDE.)
You may try to buy a CD or DVD from a german vendor:
(= Du kannst versuchen, CDs oder DVDs von einen Verkaeufer in
Deutschland zu kaufen:)
https://www.debian.org/CD/vendors/index.de.html#de
You will need to tell whether you have a PC with 32 bit CPU ("i386")
or with 64 bit CPU ("amd64"). Whether Intel or AMD does not matter.
(= Du wirst dich entscheiden muessen, ob es fuer eine 32 bit CPU sein
soll ("i386") oder eine 64 bit CPU ("amd64") sein soll.
Egal ob von Intel oder AMD.)
> Im Internet habe ich schon versucht etwas zu downloaden
> (= I already tried to download from the internet)
German language download site:
(= Deutschsprachiger Download:)
https://www.debian.org/CD/http-ftp/index.de.html
The links lead to english language pages.
(= Die Links gehen dann aber auf englische Seiten.)
For an old machine with 32 bit Intel or AMD CPU:
(= Fuer einen alten PC mit 32 bit Intel oder AMD CPU:)
http://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-8.7.1-i386-kde-CD-1.iso
For 64 bit AMD or Intel CPU:
(= Fuer einen PC mit 64 bit AMD oder Intel CPU:)
http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-8.7.1-amd64-kde-CD-1.iso
Put it on a CD, DVD, or on an USB stick.
(= Das ISO muss dann auf CD, DVD oder einen USB Stick.)
Have a nice day :)
Thomas
Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, > How do I talk to the syslinux developers? Subscribe on http://www.zytor.com/mailman/listinfo/syslinux to sysli...@zytor.com and post your report. Have a nice day :) Thomas
Bug#857597: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, David Christensen wrote: > http://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-8.7.1-i386-xfce-CD-1.iso Background info: This is an isohybrid made by xorriso, equivalent to a run of isohybrid --uefi There is a probably useless Apple Partition Map pointing to the UEFI System Partition. The whole UEFI aspect is to be ignored by a BIOS from 2003, i suppose. The block address pointer from MBR to isolinux.bin looks ok. Confirmed by xorriso analysis and by newer BIOSes which boot. > isolinux.bin missing or corrupt Somehow the MBR code, when run on the old BIOS, seems not to like isolinux.bin and thus refuses to hop on it. If i get http://git.zytor.com/syslinux/syslinux.git/tree/mbr/isohdpfx.S#n201 right, then the error message is emitted if reading succeeds but does not yield the expected values in bytes 64 to 67, which serve as magic number to identify an isohybrid-ready El Torito boot image. (I could need a reference document for the assembler language in isohdpfx.S. Does anybody know a good one ?) Have a nice day :) Thomas
Bug#857597: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, intermediate report: We found a bug in isohdpfx.bin which spoils the C/H/S address conversion for BIOSes which do not support LBA addressing. http://www.syslinux.org/archives/2017-March/025692.html It turned out that David Christensen's BIOS does not support INT 13 AH 41 which causes isohdpfx.bin to use C/H/S addressing. If one forces this C/H/S addressing on qemu-system-i386, then the MBR reads the wrong blocks because it confuses heads-per-cylinder and sectors-per-head. Martin Str|mberg posted a patch: --- --- a/mbr/isohdpfx.S +++ b/mbr/isohdpfx.S @@ -48,8 +48,8 @@ isolinux_start_hybrid = 0x7c00+64+4 stack = 0x7c00 partoffset = (stack-8) driveno= (stack-14) -heads = (stack-16) -sectors= (stack-18) +sectors= (stack-16) +heads = (stack-18) ebios_flag = (stack-20) secpercyl = (stack-24) --- which with his qemu BIOS repairs C/H/S addressing. Regrettably this patch did not reach David Christensen, because he unsubscribed at sysli...@zytor.com before the bug was found. It is not sure whether this really fixes the problem with David's BIOS because other than qemu's BIOS it did not read a wrong block content out of the test image but rather a block with all zeros. (The test image has its blocks filled with their address number. All zero is not among them, because at block 0 sits the MBR.) I am Cc-ing David with this mail in the hope that he will test the patch and report its outcome. --- David: If it is the decisive trick, then patching the fixed MBR into the first 432 bytes of the ISO should make it bootable. If it is patched onto the start of the block_seq image on stick, then it should report block content that is not all zero, but rather 00 00 20 FC ... 00 00 20 FC If it does not solve the problem, then i would be interested in learning which block content is read after the patch. I.e. in this case please try again with Martin's diagnostic MBR with the patch applied and let me know the diagnostic output. Have a nice day :) Thomas
Bug#857597: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, more update for Bug#857597: Correcting the wrong stack address of sectors/head yielded progress on David's old BIOS. The MBR code now correctly addresses and loads the first 4 blocks of boot image file /isolinux/isolinux.bin . Nevertheless, the stack interface between MBR and loaded isolinux.bin has a similar bug as the LBA-to-CHS conversion had in the MBR code. So again, addressing fails when the code in block 0 to 3 of isolinux.bin tries to load its blocks 4 to 79 via C/H/S addressing. Failure symptom is this message: ISOLINUX 6.03 20150819 CHDDisolinux: Image checksum error, sorry... Now a new MBR change by Martin Str|mberg is ready for testing, which adapts the PUSH stack operations of the MBR code to the POP stack operations of the isolinux.bin code. (This makes the previous correction unnecessary, as the old wrong memory addresses become valid by the changed stack order.) diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S index 17e1efe..14eca14 100644 --- a/mbr/isohdpfx.S +++ b/mbr/isohdpfx.S @@ -151,7 +151,7 @@ next: /* Check to see if we have EBIOS */ pushw %dx /* drive number */ - movb$0x41, %ah /* %al == 0 already */ + movb$0x41, %ah movw$0x55aa, %bx xorw%cx, %cx xorb%dh, %dh @@ -167,20 +167,22 @@ next: read_sector_cbios: movb $0x42, %ah ; jmp read_common */ movl$0xeb42b4+((read_common-read_sector_cbios-4) << 24), \ (read_sector_cbios) - jmp 1f + jmp 2f 1: + xor %cx, %cx/* Clear EBIOS flag. */ +2: popw%dx pushw %cx /* EBIOS flag */ /* Get (C)HS geometry */ movb$0x08, %ah int $0x13 - andw$0x3f, %cx /* Sector count */ popw%bx /* EBIOS flag */ - pushw %cx /* -16: Save sectors on the stack */ movzbw %dh, %ax/* dh = max head */ incw%ax /* From 0-based max to count */ - pushw %ax /* -18: Save heads on the stack */ + pushw %ax /* -16: Save heads on the stack */ + andw$0x3f, %cx /* Sector count */ + pushw %cx /* -18: Save sectors on the stack */ mulw%cx /* Heads*sectors -> sectors per cylinder */ pushw %bx /* -20: EBIOS flag */ - The binary MBR code http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324 is supposed to fix C/H/S addressing in Debian ISOs if copied to their first block: iso=debian-8.7.1-i386-xfce-CD-1.iso dd conv=notrunc bs=1 count=432 if=isohdpfx.bin.170324 of="$iso" The ISO then still boots for me by -hda of qemu-system-i386. But that's not a C/H/S needy BIOS. So please cross fingers everybody ... - The all-zero block content read by the buggy address conversion on David's BIOS is explainable by the two possible disk geometries of the now known conversion 8444 -> 1/6/3: H/C= 128 S/H= 63 H/C= 195 S/H= 42 In both cases the wrongly computed sector numbers of 1/2/125 or 1/1/60 exceed the respective sectors/head parameters. (Conversion hand computed. Bear with me.) - Have a nice day :) Thomas
Bug#857597: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, David Christensen confirmed that above fixed MBR enabled isohybrid booting on his legacy system. Time for a summary of findings. How to reproduce the bug: Any BIOS which does not announce "Device Access using the packet structure" by the reply to INT 13 AH 41 will fail to boot by the old MBR, if the numbers for heads/cylinder and for sectors/head do not happen to be identical. The drive geometry numbers are handed out by the BIOS on INT 13 AH 8 depending on its perception of the drive. I never saw both being the same. See also: https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D41h:_Check_Extensions_Present https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D41h:_Check_Extensions_Present How to work around: Overwrite the old MBR by the fixed one. wget http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324 iso=debian-8.7.1-i386-xfce-CD-1.iso or iso=/dev/sdc dd conv=notrunc bs=1 count=432 if=isohdpfx.bin.170324 of="$iso" According to https://git.kernel.org/pub/scm/boot/syslinux/syslinux.git/log/mbr/isohdpfx.S the fix should apply to ISOLINUX versions since 3.82. The most recent touching of the code part in question was on 2009-05-31. Proposals for debian-cd and syslinux package: Martin Str|mberg has announced that http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324 will exist only a limited time. (I have a copy.) I propose that Debian gets it too and offers it for download together with a description what problem it might fix and how to apply it. If it gets a Debian URL and if i get pointed to an empty wiki page, i would volunteer to write the description. Next, one will have to decide whether to use the fixed MBR with future Debian ISOs and whether to put the patch into Debian's syslinux source package. We got no comment by hpa yet. Any review by a skilled assembler programmer is welcome. Especially one will have to check for any inadverted side effects caused by changing the stack push sequence to the expectations of isolinux.bin. Have a nice day :) Thomas
Bug#857597: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, the following patch has been committed to SYSLINUX to fix the C/H/S addressing problems in isohybrid MBR and isolinux.bin : http://git.zytor.com/syslinux/syslinux.git/commit/?id=32c09027423f61c305e2423e52f5f69ecad8e2c0 diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S index 17e1efe..f9e9691 100644 --- a/mbr/isohdpfx.S +++ b/mbr/isohdpfx.S @@ -175,12 +175,12 @@ next: /* Get (C)HS geometry */ movb$0x08, %ah int $0x13 - andw$0x3f, %cx /* Sector count */ popw%bx /* EBIOS flag */ - pushw %cx /* -16: Save sectors on the stack */ movzbw %dh, %ax/* dh = max head */ incw%ax /* From 0-based max to count */ - pushw %ax /* -18: Save heads on the stack */ + pushw %ax /* -16: Save heads on the stack */ + andw$0x3f, %cx /* Sector count */ + pushw %cx /* -18: Save sectors on the stack */ mulw%cx /* Heads*sectors -> sectors per cylinder */ pushw %bx /* -20: EBIOS flag */ The other part of the changeset proposed on 25 Mar 2017 is now committed as http://git.zytor.com/syslinux/syslinux.git/commit/?id=8739e2ff9ba3f92652c8df846924fd00e1ce2753 It fixes the problem that an early decision against LBA addressing after INT 13 AH 41 could push a non-zero CX value to the stack, which isolinux.bin would pop and interpret as instruction to use LBA addressing. (isolinux.bin is wrong here. It should only use LBA if bit 0 of the popped CX is set. But even that could be wrongly sent from MBR if not the "Clear EBIOS flag" fix is applied.) Have a nice day :) Thomas
Bug#858031: Please make volume id for netinst different from DVD
Hi, Guido Günther wrote: > > Volume id: Debian stretch-DI-rc2 amd64 1 > > [...] > > >If the netinst variant would contain netinst or similar Steve McIntyre wrote: > I understand, yes. The problem we have is that the volume ID is very > limited in space available. We've run out... :-/ How about replacing the volume number "1" by "n" ? Debian stretch-DI-rc2 amd64 n Above volume id leaves room for three more characters (the Joliet limit has been exceeded by 13, already). If the architecture name gets longer than 8 characters or the Toystory name gets longer than 10, then the naming scheme does not fit into the Volume Id field of the PVD. The kfreebsd-amd64 ISOs have an abbreviated arch name in their volume id: Debian 7.9.0 f-amd64 1 Mr. Pricklepants is still waiting to get chosen as release name. An obvious possibility to densify the id text is to give up the cute names and to use release numbers instead. Like: Debian 9-DI-rc2 amd64 n Have a nice day :) Thomas
Bug#858031: Please make volume id for netinst different from DVD
Hi, i wrote: > >> How about replacing the volume number "1" by "n" ? Guido Günther wrote: > >That would be great! Steve McIntyre wrote: > Date: Thu, 18 May 2017 23:40:40 +0100 > I've just committed code to do that, let's see how it looks on the > next daily/weekly builds. Seems not to be in effect with daily-builds. $ wget https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso ... $ xorriso -indev debian-testing-amd64-netinst.iso -pvd_info ... Volume Id: Debian testing amd64 1 ... Creation Time: 2017051916481400 ... Have a nice day :) Thomas
Bug#858031: Please make volume id for netinst different from DVD
Hi, Steve McIntyre wrote: > *Now* fixed... :-) The latest debian-testing-amd64-netinst.iso has indeed: Volume Id: Debian testing amd64 n ... Creation Time: 2017052004084000 (Now we have to brace for protests from people or software relying on the volume number 1.) Have a nice day :) Thomas
Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, if we wait much longer then the machines have died out which need the fix. How about offering the corrected 432 bytes for download and have an item in CD FAQ which points to the binary and explains how to put it onto the first 432 bytes of the USB stick or .iso image ? Have a nice day :) Thomas
Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, Steve McIntyre wrote: > Do you have suggested text we can use? Modulo english language, URL of the binary file, and clarity of mind. $$...$$ means that properties of the download offer have to be inserted. The answer is intended to be put after "How do I write a CD/DVD/BD image to a USB flash drive?" I hope to have used the same terms as in that answer. Q: What if booting a USB flash drive says "isolinux.bin missing or corrupt" ? A: Old PCs might encounter this bug within the isohybrid MBR code at the very start of the Debian image. It affects BIOS firmware from about 2005 or older which announces to only support C/H/S addressing of blocks on the flash drive. Because the bug is exotic and the affected MBR code has proven to work with most PCs since many years, the fix is not yet included in the Debian and Debian Live images. If your PC shows the message "isolinux.bin missing or corrupt" then you may try whether the fixed MBR code brings better results. * Download it from $$ URL of copy of binary file with 432 bytes from http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324 or of a isohdpfx.bin assembled from newest SYSLINUX git $$ * Optionally check the sha512sum of the download: $$ f0883df5094575480dd7d1c31ac03c68f26a346d31c172b077964450594eec447992327d1bee3cbf3fff652e1787f61c49123481b46f82471bac457c2d38 or the SHA512 of the SYSLINUX git based binary $$ * Put it onto the first 432 bytes of the USB flash drive like in the previous answer "How do I write a CD/DVD/BD image to a USB flash drive?": cp <$$filename.from.URL$$> or dd if=<$$filename.from.URL$$> of= bs=1 count=432 conv=notrunc; sync The "cp" example is only suitable for being a device file. If you want to put the fixed MBR into a Debian image data file then you must use the "dd" command with "conv=notrunc" or else you will lose the complete image data. In this case shall be the name of the Debian image file. The file http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324 is still available and shows the same SHA512 as the file which i downloaded march 26, when David Christensen confirmed that it works for him. I leave it to Debian policy whether we can use that binary or need to assemble a new one from SYSLINUX source. If the SHAs differ, we would have to ask David to test again. Both proposed copy commands have been tested with a USB stick. dd was tested with a data file, too. I prescribe a size restriction by "count=" just in case the download yields more than 432 bytes. If so, then dd will not spoil the ISO and one can later try again with a better download. Have a nice day :) Thomas
Re: Stretch release testing - up to and including Saturday 17th June
Hi, Jimmy Johnson wrote: > Tried both installs and they failed on finding the dvd. Did your BIOS or EFI not notice the presence of a bootable DVD and instead just does what is usual when no DVD is inserted at boot time ? If you do not get boot messages from ISOLINUX or GRUB to finally get to the Debian menu which offers installation, then we have a problem with boot entry points. I'd need to know the exact URL of the problematic ISO in this case, in order to examine its initial boot entries. It would then help if you can tell whether the boot firmware of the machines is EFI or BIOS. Have a nice day :) Thomas
Re: Stretch release testing - up to and including Saturday 17th June
Hi, Jimmy Johnson wrote: > the dvd boots and runs live to > desktop, it's when I click to install and it gets to finding the dvd is when > it loop unable to find the dvd. Well, that's one or two DVD finds after the one for which my program would be responsible. Have a nice day :) Thomas
Why is a xorriso development snapshot used in debian-cd production ?
Hi, while comparing a KALI ISO with debian-9.1.0-amd64-netinst.iso i noticed that debian-cd uses a development snapshot of GNU xorriso: Preparer Id : XORRISO-1.4.7 2017.06.29.211523, ... Not that i would deem it bad in any way, but i wonder why not the Debian package with xorriso-1.4.6 or the release tarball of GNU xorriso-1.4.6 is installed on the ISO producing machine. Is any of the development changes needed urgently ? Have a nice day :) Thomas
Re: Adoption of syslinux
Hi, good to know that the SYSLINUX/ISOLINUX packages are maintained again. Please consider to also adopt bug #857597 from package debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC which is actually an old bug in the ISOLINUX isohybrid MBR. It hits old BIOS which announces to be able only of C/H/S addressing and not of LBA addressing. (I.e. the fix now races against the natural demise of such machines.) Fixed upstream in march 2017 by http://git.zytor.com/syslinux/syslinux.git/commit/?id=32c09027423f61c305e2423e52f5f69ecad8e2c0 and further hardened by http://git.zytor.com/syslinux/syslinux.git/commit/?id=8739e2ff9ba3f92652c8df846924fd00e1ce2753 It looks like debian-cd and debian-live both still use the buggy MBR: $ dd if=debian-8.1.0-amd64-netinst.iso bs=1 count=432 of=8.1.0.mbr ... $ dd if=debian-9.1.0-amd64-netinst.iso bs=1 count=432 of=9.1.0.mbr ... $ diff 8.1.0.mbr 9.1.0.mbr $ (debian-8.1.0-*.iso was made before the bug was diagnosed and fixed.) My copy of debian-live-testing-amd64-kde.iso bears Creation Time: 2017061205495400 Its MBR code differs from netinst only by the first 32 bytes which have not been overwritten by an Apple Partition Map block0. The beef is in the higher bytes, where i see no difference. (I see heavy difference when comparing to the fixed isohdpfx.bin.170324.) Have a nice day :) Thomas
Re: syslinux progress & reviews
Hi, Lukas Schwaighofer wrote: > * added patches from upstream to fix: > - boot problems for pre-2005 BIOS computers, see #857597 [1] Applause. I wonder whether the new binary isohdpfx.bin is byte-identical to the tested MBR with the fix: http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324 Else we'd need to find a tester with an old PC, which does not boot with some Debian i386 or amd64 installation ISO from USB stick but rather says: isolinux.bin missing or corrupt It would suffice to copy the new isohdpfx.bin to the first 432 bytes of the USB stick with the failing ISO and to check whether it then boots up to the first menu. Another question is whether the repaired MBR should be offered for separate download and whether repairing of older ISOs should be advertised in https://www.debian.org/CD/faq/ as sketched in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857597#90 > My plan now is to test a few boot scenarios with this package myself If it fails to boot via EFI from CD-ROM, that's normal. It cannot break out of the EFI System Partition into the CD-ROM device of the ISO 9660 filesystem. debian-cd uses GRUB as EFI boot equipment. The only known production ISO which boots on EFI by SYSLINUX is Knoppix 8. It's trick is to have a complete GNU/Linux in the EFI System Partition. So there is enough brain when it comes to exploring the CD-ROM device. Have a nice day :) Thomas
Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, now that a new set of SYSLINUX packages is announced by https://lists.debian.org/debian-cd/2017/10/msg00025.html with changelog entry * Add patch from upstream to fix boot problem for old BIOS firmware from around 2005 by correcting the C/H/S order (thanks Thomas Schmitt). what to do with this bug report ? Re-assign to package "syslinux" and then close it ? Further: Shall the debian-cd FAQ advertise the file /usr/lib/ISOLINUX/isohdpfx.bin from binary package "isolinux" of Sid as remedy for older Debian isohybrid ISOs ? Is there a way to obtain that package and extract the file with vanilla tools which are not debian-specific ? Have a nice day :) Thomas
Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, > thanks for pushing this forward :) . You wrote my name on its item in the changelog. And somehow i became the drover of this bug, anyway. > Well, that bug is only solved once we have CD images that are no longer > affected by this bug. Given its usual speed of movement i just wanted to give it a little prod. > If I understand the CD build process > correctly, the images for the next point release will only get the fix > if we also update syslinux in stretch. Since it is a bug fix: Steve, please consider fast track. E.g. by transplanting /usr/lib/ISOLINUX/isohdpfx.bin from the current "isolinux" package of Sid to the local file which is syslinux/usr/lib/ISOLINUX/isohdpfx.bin when xorriso gets run. (At least /.disk/mkisofs of 9.1.0-amd64-netinst.iso tells this is the name.) > > Is there a way to obtain that package and extract the file with > > vanilla tools which are not debian-specific ? > ar p isolinux_6.03+dfsg1-1_all.deb data.tar.xz | \ >tar xJOf - ./usr/lib/ISOLINUX/isohdpfx.bin > isohdpfx.bin If the debian-cd FAQ shall mention the opportunity to fix older ISOs, then we will have to offer a simpler way for not-yet Debian users to get the fixed MBR. The oldest isohybrid Debian ISO i have is debian-6.0.5-amd64-businesscard.iso of may 2012. A copy of it still boots fine with qemu -hda after i replaced the original MBR by the fixed MBR from "apt-get install isolinux" on my Sid VM yesterday. (By zeroing the MBR and subsequent boot failure i checked that the virtual BIOS indeed uses the MBR and not the EL Torito catalog.) Have a nice day :) Thomas
Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, the weekly testing ISOs for i386 and amd64 are now equipped with the new MBR: https://cdimage.debian.org/mirror/cdimage/weekly-builds/i386/iso-cd/debian-testing-i386-netinst.iso https://cdimage.debian.org/mirror/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso Testers wanted for booting this ISO from USB stick. One can recognize the new MBR by the MD5 of bytes 32 to 431: $ dd if=debian-testing-i386-netinst.iso bs=1 skip=32 count=400 2>/dev/null | md5sum 1705df1b3dee9b725432e099ecc63eaf - $ dd if=isohdpfx.bin.170324 bs=1 skip=32 count=400 2>/dev/null | md5sum 1705df1b3dee9b725432e099ecc63eaf - The old MBR, which caused this bug report, yields 2b1369901086845791f595a9aa8b1a16 Have a nice day :) Thomas
Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, David Christensen wrote: > This will restore Debian (and > derivatives) as a viable option for many millions of older computers. :-) At least they can now have some good final years. (Let's be nice to the elderly. We will join their ranks soon enough.) Have a nice day :) Thomas
Please add a Debian install instruction for jigdo-file to www.debian.org/CD/jigdo-cd
Hi, in https://www.debian.org/CD/jigdo-cd/ the "How to download an image with jigdo" paragraph sends potential downloaders to http://atterer.org/jigdo/ which then has a semi-obvious link to https://packages.debian.org/search?keywords=jigdo-file How about giving a tangible example for Debian users directly on https://www.debian.org/CD/jigdo-cd/ ? Like: apt-get install jigdo-file I write because of https://lists.debian.org/debian-user/2017/12/msg00461.html which is caused by sloppy reading with the excuse that the detour via atterer.org is more demanding than a clear instruction for Debian users. Have a nice day :) Thomas
What mirror to use with archived jigdo DVD images ?
Hi, on occasion of a discussion at debian-user i tried to reproduce the jigdo-lite problem reported by Nicholas Geovanis in https://lists.debian.org/debian-user/2017/12/msg00467.html My attempt yields better results than for him. Nevertheless using http://cdimage.debian.org/cdimage/archive/6.0.7/amd64/jigdo-dvd/debian-6.0.7-amd64-DVD-1.jigdo with no "Files to scan" and default mirror http://ftp.de.debian.org/debian/ i get in the end: Aaargh - 7 files could not be downloaded. This should not happen! Depending on the problem, it may help to retry downloading the missing files. I then retried with mirror http://archive.debian.org/debian/ and got Aaargh - 2 files could not be downloaded. ... Of course the checksum of the .iso.tmp file does not match the one in http://cdimage.debian.org/cdimage/archive/6.0.7/amd64/jigdo-dvd/SHA256SUMS A download attempt from scratch with mirror http://archive.debian.org/debian/ still reports in the end Aaargh - 2 files could not be downloaded. ... Further runs with the same mirror fetch always the same two packages gnupg-udeb_1.4.10-4+squeeze1_amd64.udeb texlive-pstricks-doc_2009-10_all.deb but do not tell what's wrong with them in the end. I have the output of stdout and stderr of the complete run and a follow-up run: 4 lines. If you have proposals for searches in that heap, tell me. Have a nice day :) Thomas
Re: What mirror to use with archived jigdo DVD images ?
Hi, Brian Potkin wrote: > That's the link given by Nicholas Geovanis. It works for me for starting > downloading. I didn't want this image so stopped it after five minutes. It works for me except 7 or 2 packages in the end. > I used http://deb.debian.org/debian and got debian-9.3.0-i386-DVD-1.iso > without any retrying. This matches the comments on debian-user. jigdo-lite as program seems to be ok. But the package mirrors, or the template file, or the jigdo file of debian-6.0.7-amd64-DVD-1.jigdo have a problem. The fact that different mirrors yield different counts of missing files lets me suspect that it is about a property of the mirrors or the packages they offer. Philip Hands wrote: > Is this the file you're looking for? > > http://non-us.cdimage.debian.org/snapshot/pool/main/g/gnupg/gnupg-udeb_1.4.10-4+squeeze1_amd64.udeb Probably. But my attempt to use mirrors, of which Google reports that file, did not yield final success with jigdo-lite. Whatever i do, it downloads two files without immediate error indication: --2017-12-15 08:06:50-- http://us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/g/gnupg/gnupg-udeb_1.4.10-4+squeeze1_amd64.udeb Resolving us.cdimage.debian.org (us.cdimage.debian.org)... 2001:1b40:5600:ff80:f8ee::1, 78.129.164.123 Connecting to us.cdimage.debian.org (us.cdimage.debian.org)|2001:1b40:5600:ff80:f8ee::1|:80... failed: No route to host. Connecting to us.cdimage.debian.org (us.cdimage.debian.org)|78.129.164.123|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 413368 (404K) [application/octet-stream] Saving to: ‘debian-6.0.7-amd64-DVD-1.iso.tmpdir/us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/g/gnupg/gnupg-udeb_1.4.10-4+squeeze1_amd64.udeb’ 0K .. 100% 3.69M=0.1s 2017-12-15 08:06:50 (3.69 MB/s) - ‘debian-6.0.7-amd64-DVD-1.iso.tmpdir/us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/g/gnupg/gnupg-udeb_1.4.10-4+squeeze1_amd64.udeb’ saved [413368/413368] --2017-12-15 08:06:50-- http://us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/t/texlive-extra/texlive-pstricks-doc_2009-10_all.deb Reusing existing connection to us.cdimage.debian.org:80. HTTP request sent, awaiting response... 200 OK ... 2017-12-15 08:07:00 (5.77 MB/s) - ‘debian-6.0.7-amd64-DVD-1.iso.tmpdir/us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/t/texlive-extra/texlive-pstricks-doc_2009-10_all.deb’ saved [57978642/57978642] FINISHED --2017-12-15 08:07:00-- Total wall clock time: 10s Downloaded: 2 files, 56M in 9.7s (5.75 MB/s) 31% 128k/403k scanning `debian-6.0.7-amd64-DVD-1.iso.tmpdir/us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/g/gnupg/gnupg-udeb_1.4.10-4+squeeze1_amd64.udeb b'^M 95% 384^M100% 403^M 0% 128k/56619k scanning `debi an-6.0.7-amd64-DVD-1.iso.tmpdir/us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/t/texlive-extra/texlive-pstricks-doc_2009-10_all.deb' ... Found 0 of the 2 files required by the template Copied input files to temporary file `debian-6.0.7-amd64-DVD-1.iso.tmp' - repeat command and supply more files to continue - Aaargh - 2 files could not be downloaded. This should not ... It seems not to be about a missing package of the desired name but about something else. > Actually, I note that the jigdo file ends with: > > [Servers] > Debian=http://us.cdimage.debian.org/cdimage/snapshot/Debian/ --try-last This explains why i see this server address with most of the wget runs. Nevertheless, the choice of "Debian mirror" by the third input prompt of jigdo-lite can make a difference in the number of missing files. Have a nice day :) Thomas
Re: What mirror to use with archived jigdo DVD images ?
Hi, Philip Hands wrote: > Ah, right -- you seem to have discovered some corrupt files on my > server. Thanks :-) I had a similar suspicion but failed yet to write a reverse function to decode the MD5s in the .jigdo file. It's a 6-bit format but not base64. An encoder is in libjte/jte.c as base64_dump(). A decoder should be in jigdo-file, but i cannot find it. > I've overwritten them now, which should fix the immediate issue. Yep. The next jigdo-lite run yields: Found 2 of the 2 files required by the template Successfully created `debian-6.0.7-amd64-DVD-1.iso' - Finished! The fact that you got this far is a strong indication that `debian-6.0.7-amd64-DVD-1.iso' was generated correctly. I will perform an additional, final check, which you can interrupt safely with Ctrl-C if you do not want to wait. OK: Checksums match, image is good! sha256sum too yields the correct checksum from the .jigdo download site. To understand what was going on: Is this theory correct ? - Regardless which mirror URL i told jigdo-lite, it tried to fetch the problematic packages from your server. - jigdo-lite (or rather its backend jigdo-file) did not tell that the MD5 of the downloaded packages are wrong. But why did my first attempt yesterday yield 7 missing files, when i used Debian mirror http://ftp.de.debian.org/debian/ ? Another glitch somewhere else ? That mirror has not many of the desired files, but i can see in the log that missing files get later found on us.cdimage.debian.org/cdimage/snapshot. The next try with mirror archive.debian.org/debian/ fetched from there gnome-user-share_2.30.1-1_amd64.deb ipolish_20100612-1_amd64.deb myspell-en-gb_3.2.1-2_all.deb debian-keyring_2010.12.29_all.deb openoffice.org-l10n-en-gb_3.2.1-11+squeeze8_all.deb The two offending files yielded 404 and were then fetched from us.cdimage.debian.org : gnupg-udeb_1.4.10-4+squeeze1_amd64.udeb texlive-pstricks-doc_2009-10_all.deb In the log i see that ialready the first try got all 7 files from us.cdimage.debian.org but somehow did not graft them into the ISO. Like: 2017-12-14 23:13:15 (5.85 MB/s) - ‘debian-6.0.7-amd64-DVD-1.iso.tmpdir/us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/g/gnome-user-share/gnome-user-share_2.30.1-1_amd64.deb’ saved [691802/691802] Whatever, i will now ask Nicholas Geovanis on debian-user to try again. Have a nice day :) Thomas
Re: What mirror to use with archived jigdo DVD images ?
Hi, after some pondering: Can it be that these five packages are damaged too on us.cdimage.debian.org ? gnome-user-share_2.30.1-1_amd64.deb ipolish_20100612-1_amd64.deb myspell-en-gb_3.2.1-2_all.deb debian-keyring_2010.12.29_all.deb openoffice.org-l10n-en-gb_3.2.1-11+squeeze8_all.deb Reasoning: When using the default mirror, these files came from us.cdimage.debian.org and then were not grafted into the ISO template. When using archive.debian.org the five files came from there and then got grafted into the template. The two remaining files were again fetched from us.cdimage.debian.org and then did not get grafted. Have a nice day :) Thomas
Re: What mirror to use with archived jigdo DVD images ?
Hi, not graftable into debian-6.0.7-amd64-DVD-2 : extremetuxracer-data_0.4-4_all.deb openclipart-png_0.18+dfsg-10_all.deb ko.tex-extra-hlfont_0.1.0-1_all.deb lilypond-doc_2.12.3-7_all.deb libboost1.42-doc_1.42.0-4_all.deb I used http://us.cdimage.debian.org/cdimage/snapshot/Debian/ as user chosen mirror in order to get no sane files from other sources. All files were found on first try. But the five above get downloaded again in the second pass of the jidgo-lite run. Wenn i press Return on the prompt Press Return to retry downloading the missing files. i get them downloaded twice again and then still not grafted in. I did not test DVD-1 yet with us.cdimage.debian.org as user chosen mirror. So there might be packages damaged which were found on the default mirror with my first attempt. Have a nice day :) Thomas
Re: when i use jigdo to download old version debian i got this problem.
Hi, Cabal Cabal wrote: > 23:05:19 (103.64 KB/s) - > `debian-6.0.5-amd64-DVD-1.iso.tmpdir/us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/g/ghostscript/ghostscript-cups_8.71~dfsg2-9_amd64.deb' > saved [61234/61234] > ... > Aaargh - 1 files could not be downloaded. ... If this is 23:05:19+8000 today, then again a file on us.cdimage.debian.org went bad. We had this only a few days ago, when at least 12 did not match the expected MD5s. us.cdimage.debian.org is the fallback server for debian-6.0.5-amd64-DVD-1.jigdo Normally it provides what other servers don't have any more. So now you need to find a different mirror server which has package ghostscript-cups_8.71~dfsg2-9_amd64.deb Google finds me https://mirrors.reflected.net/debian.old https://distros-repository.usharesoft.com/debian/squeeze/mirror/ftp.fr.debian.org/debian which offer this package in their pool/main/g/ghostscript/ directories. Have a nice day :) Thomas
Re: when i use jigdo to download old version debian i got this problem.
Hi, Philip Hands wrote: > There are four jigdo files that were also corrupt: Google finds me candidates at ftp.riken.go.jp but also the ones at cdimage.debian.org/mirror seem to be good. What i don't find are the expected MD5s of .jigdo files. Shouldn't they be in files like http://cdimage.debian.org/mirror/cdimage/archive/5.0.1/amd64/jigdo-bd/MD5SUMS ? > debian-501-amd64-BD-1.jigdo http://ftp.riken.go.jp/Linux/debian/debian-cdimage/archive/5.0.1/amd64/jigdo-bd/debian-501-amd64-BD-1.jigdo http://cdimage.debian.org/mirror/cdimage/archive/5.0.1/amd64/jigdo-bd/debian-501-amd64-BD-1.jigdo MD5 after download: d3f8ed459b94be24f7add174eb9d6e20 > debian-502-arm-CD-1.jigdo http://ftp.riken.go.jp/Linux/debian/debian-cdimage/archive/5.0.2/arm/jigdo-cd/debian-502-arm-CD-1.jigdo http://cdimage.debian.org/mirror/cdimage/archive/5.0.2/arm/jigdo-cd/debian-502-arm-CD-1.jigdo MD5 after download: 171b317091e74c1689a51cb3d83f52c1 I ran jigdo-lite with it (mirror: us.cdimage.debian.org) and got the correct ISO: $ md5sum debian-502-arm-CD-1.iso f1a533070903105ec08ac00fbdfbdec2 debian-502-arm-CD-1.iso $ sha1sum debian-502-arm-CD-1.iso 441e6f4e35132dd58db04074009b35bcb67979db debian-502-arm-CD-1.iso $ sha256sum debian-502-arm-CD-1.iso 3c2cbf4c23d2a003aba6fdacb39795fd0825d7d4059fd55d64bba80e0be4d6e6 debian-502-arm-CD-1.iso $ sha512sum debian-502-arm-CD-1.iso 0ea63ade6d6baf20f5446ec5a806c9c2e5e720c04fa489a13c5cec9060e3d11202682056fe4461221de0c1ba3e71727f814f381f836ef99a674dfea1399cccd2 debian-502-arm-CD-1.iso > debian-7.5.0-sparc-CD-56.jigdo http://ftp.riken.go.jp/Linux/debian/debian-cdimage/archive/7.5.0/sparc/jigdo-cd/debian-7.5.0-sparc-CD-56.jigdo MD5 after download: 66737f7eb3d080c826baa1d455d321cc > debian-stretch-DI-alpha5-source-DLBD-1.jigdo http://ftp.riken.go.jp/Linux/debian/debian-cdimage/archive/stretch_di_alpha5/source/jigdo-dlbd/debian-stretch-DI-alpha5-source-DLBD-1.jigdo MD5 after download: ed32e7e8776a008515c02adcd686ce17 In each case the .template MD5s in the .jigdo files match the downloaded .template files. I keep the .jigdo files on my disk for a while. Just in case my internet is better than yours. Have a nice day :) Thomas
Re: jigdo-file: Does not report package rejections because checksum mismatch
Hi,
i Cc: debian-cd with this follow-up to bug 884526 in the hope to get
some review for the endeavor to detect damaged downloaded package files
during a run of jigdo-lite.
Some disputable aspects remain (plus a possible bug in current jigdo-lite,
which will vanish by my proposal). I put them behind my changeset, which is
based on Sid of today.
How it works:
Currently and in my proposal jigdo-lite asks jigdo-file for a list of files
yet missing in the emerging image. It downloads them in groups of 10 and
submits each group to jigdo-file for grafting them into the image.
The list consists of text blocks of the form:
URL of package
Alternative URL of same package
... more alternative URLs ...
MD5Sum:...
One of the URLs from each block gets picked by a loop with variable "pass",
but currently jigdo-file ignores the MD5Sum lines.
My proposal collects the MD5s and submits them to function fetchAndMerge
which currently only gets the 10 URLs.
I had to re-arrange the entrails of the list reading loop in imageDownload.
It currently ends when the 10th URL is found and thus would not have yet
reached the 10th checksum line. My proposal uses the empty line as trigger
to append the picked URL and the MD5 to the argument list.
Tested with Jessie's jigdo-file and these three input lines:
http://cdimage.debian.org/mirror/cdimage/archive/6.0.7/amd64/jigdo-cd/debian-6.0.7-amd64-businesscard.jigdo
http://us.cdimage.debian.org/cdimage/snapshot/Debian/
--- /usr/bin/jigdo-lite.sid 2017-12-28 14:20:23.882643023 +0100
+++ /home/thomas/projekte/jigdo_dir/jigdo-lite.sid.with_md5_check
2017-12-28 15:12:37.738654856 +0100
@@ -75,10 +75,61 @@ fetch() {
}
#__
-# Given URLs, fetch them into $imageTmp, then merge them into image
+# Simulated MD5 mismatch:
+simulateMD5Mismatch="partman-reiserfs_50_all.udeb"
+# simulateMD5Mismatch="NOT_A_PACKAGE_NAME"
+
+# Given URLs and MD5s, fetch them into $imageTmp and verify,
+# then merge them into image
fetchAndMerge() {
+
+ # The other arguments are URLs in the same sequence as the words in md5List
+ md5List="$1"
+ shift 1
+
if test "$#" -eq 0; then return 0; fi
fetch --force-directories --directory-prefix="$imageTmp" -- "$@"
+
+ # Try to verify downloaded files
+ for md5 in $md5List
+ do
+url="$1"
+shift 1
+test "$md5" = ".no.MD5.known." && continue
+
+# Simulated MD5 mismatch
+if echo "$url" | grep '/'"$simulateMD5Mismatch"'$' >/dev/null 2>&1
+then
+ echo "ATTENTION : Faking a checksum mismatch with package
$simulateMD5Mismatch" >&2
+ md5="*INVALIDATED*CHECKSUM*"
+fi
+
+localPath="$imageTmp"/`echo "$url" | \
+sed -e 's/^[hH][tT][tT][pP]:\/\///' \
+-e 's/^[hH][tT][tT][pP][sS]:\/\///' \
+-e 's/^[fF][tT][pP]:\/\///' \
+-e 's/^[fF][iI][lL][eE]:\/\///'`
+if test -e "$localPath"
+then
+ fileMD5=`$jigdoFile md5 "$localPath" 2>/dev/null | awk '{print $1}'`
+ if test "$md5" != "$fileMD5"
+ then
+echo >&2
+echo "WARNING: Downloaded file does not match expected MD5:" >&2
+echo " $url" >&2
+echo " $localPath" >&2
+echo " expected: $md5 | $fileMD5 :downloaded" >&2
+echo >&2
+ fi
+else
+ echo >&2
+ echo "WARNING: File not fot found after download:" >&2
+ echo " $url" >&2
+ echo " $localPath" >&2
+ echo >&2
+fi
+ done
+
# Merge into the image
$jigdoFile $jigdoOpts --no-cache make-image --image="$image" \
--jigdo="$jigdoF" --template="$template" "$imageTmp"
@@ -596,31 +647,56 @@ imageDownload() {
for pass in x xx xxx x xx xxx ; do
$jigdoFile print-missing-all --image="$image" --jigdo="$jigdoF" \
--template="$template" $jigdoOpts $uriOpts \
- | egrep -i '^(http:|ftp:|$)' >"$list"
+ >"$list"
+ # This counts the empty lines
missingCount=`egrep '^$' <"$list" | wc -l | sed -e 's/ *//g'`
# Accumulate URLs in $@, pass them to fetchAndMerge in batches
shift "$#" # Solaris /bin/sh doesn't understand "set --"
count=""
exec 3<"$list"
+ useUrl="."
+ md5=".no.MD5.known."
+ md5List=""
while $readLine url <&3; do
count="x$count"
-if strEmpty "$url"; then count=""; continue; fi
-if test "$count" != "$pass"; then continue; fi
-if $noMorePasses; then
- hrule
- echo "$missingCount files not found in previous pass, trying"
- echo "alternative download locations:"
- echo
-fi
-noMorePasses=false
-set -- "$@" "$url"
-if test "$#" -ge "$filesPerFetch"; then
- if fetchAndMerge "$@"; then true;
Re: jigdo-file: Does not report package rejections because checksum mismatch
Hi,
first a correction of my proposal:
The else-case with
echo "WARNING: File not found after download:" >&2
is not good.
It floods the log if one uses a mirror with few matching files.
Not finding a file after the download is a normal situation.
---
I wrote:
> >sed -e 's/^[hH][tT][tT][pP]:\/\///' \
> >-e 's/^[hH][tT][tT][pP][sS]:\/\///' \
> >-e 's/^[fF][tT][pP]:\/\///' \
> >-e 's/^[fF][iI][lL][eE]:\/\///'`
Philip Hands wrote:
> sed -e 's,^\(https\?\|ftp\|file\)://,,i'
> ...
> "$imageTmp/${url#[[:alpha:]]*://}"
Are these widely portable enough ?
Mine can be justified by S.R.Bourne's "The Unix System", i guess,
and it is coordinated with function isURI.
Well, my scruples are mainly about what wget guarantees to use as
local disk path. I understand that jigdo-file would be quite tolerant
as long as the file is somewhere in the "$imageTmp" tree.
Maybe i should invest a "find" run in case of missing file. The tree is small.
I wrote:
> > fileMD5=`$jigdoFile md5 "$localPath" 2>/dev/null | awk '{print $1}'`
> The way it's done elsewhere in the script (which I happen to think is
> pretty horrible, but that's what is already there) is using set, thus:
> set -- `$jigdoFile md5sum --report=quiet "$localPath"`
Option "--report=quiet" instead of "2>/dev/null" is a good point.
One would have to wrap the "set --" into a sub-shell, because fetchAndMerge
already tampers with its own arguments.
Like:
answer=`$jigdoFile md5sum --report=quiet "$localPath"`
fileMD5=`(set -- $answer ; echo "$1")`
Now that's really ugly.
If direct objections emerge against "awk", i'd consider some helper
function which echos "$1".
> I also happen to think that using `` rather than $() is pretty horrible
> in this day and age, but that's what's currently there throughout the
Yep. Not to speak of the headless camelBack variable names.
I strive to be minimally intrusive for the purpose and to be as
conservative as in an autotools script.
An alternative to changing the code would still be to tell the user with
the "Aaargh" text that repeated download and subsequent "Aaargh" could
indicate damaged files on the mirror. In this case the user shall search
the web for other mirrors which offer the repeatedly downloaded packages.
But that would be embarrassing for the involved programmers.
(Having script jigdo-lite instead of doing the job inside jigdo-file is
also not overly glorious ...)
Have a nice day :)
Thomas
Re: jigdo-file: Does not report package rejections because checksum mismatch
Hi,
I wrote:
> > > > sed -e 's/^[hH][tT][tT][pP]:\/\///' \
> > > >... more -e for https, ftp, and file ...
Philip Hands wrote:
> > > sed -e 's,^\(https\?\|ftp\|file\)://,,i'
> > > ...
> > > "$imageTmp/${url#[[:alpha:]]*://}"
> > Are these widely portable enough ?
> [Philip Hands analyzed portability with positive result]
I still think that the long explicit sed is clearer. But in the end it will
be up to Steve to decide which one to use.
I tested both proposals of yours and have put them as comments into my
evolving changeset.
The importance of this expression has decreased by my decision to run "find"
if the guessed local path does not lead to an existing file:
localPath=... guessed from URL ...
if test ! -e "$localPath"
then
# Maybe above guess was wrong
baseName=`basename "$url"`
localPath=`find "$imageTmp" -name "$baseName" | head -1`
fi
if test -n "$localPath" -a -e "$localPath"
then
... checksum verification ...
The use of "head" and "find" will be new in the script. But the increased
ruggedness makes it worthwhile in my opinion.
I made mini benchmarks with guessed names and found names. No significant
differences were to see.
(The tree is really small because fetchAndMerge() deletes it when the 10
files are processed.)
The effective throughput of roughly 1.5 to 2.5 MB/s is still much slower
than wget's speed report of about 5.5 MB/s.
I tried with 100 files per run of wget and "jigdo-file make-image".
No significant difference to see. It's all about mirror server latency
with each single file, i guess.
us.cdimage.debian.org is a quick one.
I wrote:
> > > > fileMD5=`$jigdoFile md5 "$localPath" 2>/dev/null | awk '{print $1}'`
Philip Hands wrote:
> `$jigdoFile md5sum --report=quiet "$localPath" | sed 's/ .*$//'`
I'll take this one.
Next development step will be to issue a correct "Aaargh" message and to
tell at least some of the mismatching files in that message.
Have a nice day :)
Thomas
Re: jigdo-file: Does not report package rejections because checksum mismatch
Hi,
i wrote:
> > us.cdimage.debian.org is a quick one.
Nicholas Geovanis wrote:
> From which location? Germany?
Ja.
How about this final message in case that files are missing and that
mismatching downloads were detected ?
(The mismatches shown are fake and recorded twice to get more than 2.)
== begin of example
-
Aaargh - 1 files remain missing. This should not happen!
4 download attempts yielded files with mismatching MD5 checksums:
http://archive.debian.org/debian/pool/main/p/partman-reiserfs/partman-reiserfs_50_all.udeb
http://archive.debian.org/debian/pool/main/p/partman-reiserfs/partman-reiserfs_50_all.udeb
http://us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/p/partman-reiserfs/partman-reiserfs_50_all.udeb
... the WARNING messages of this run report more ...
After a retry with the same mirror consider to search the web
for the names of remaining mismatching packages. As mirror name
use the found URL up to the "/" before the directory name "pool".
Press Return to retry downloading the missing files.
Press Ctrl-C to abort. (If you re-run jigdo-lite later, it will
resume from here, the downloaded data is not lost if you press
Ctrl-C now.)
:
== end of example
Is the advise understandable ?
I propose one repetition to remove any warnings from the user defined mirror
which were resolved by the fallback mirror. In the second run only messages
about the problematic files should emerge, hopefully making it easier to
spot the checksum warnings.
The list of URLs must be restricted to 3 and the usual messages must be
omitted in order to keep the text below 24 lines if the URLs are longer
than two lines.
The usual message appears if no mismatches were detected but still files
are missing.
I changed the old message
Aaargh - 1 files could not be downloaded. This should not
happen! ...
in both cases to
Aaargh - 1 files remain missing. This should not happen!
because it matches better the spectrum of potential problem causes.
--- /usr/bin/jigdo-lite.sid 2017-12-28 14:20:23.882643023 +0100
+++ /home/thomas/projekte/jigdo_dir/jigdo-lite.sid.with_md5_check
2017-12-29 20:09:34.055048360 +0100
@@ -29,6 +29,13 @@ else
windows=false
nl='\n'
fi
+
+# Counter of MD5 mismatches after download
+fileMismatchCount=0
+# Short list of URLs which yielded mismatch
+fileMismatchList=""
+# Very few mismatching URLs shall be shown at the end. They can be long.
+fileMismatchMaxRec=3
#__
# read with readline, only if running bash >=2.03 (-e gives error on POSIX)
@@ -75,10 +82,84 @@ fetch() {
}
#__
-# Given URLs, fetch them into $imageTmp, then merge them into image
+# DEVELOPMENT TEST:
+# Set to a package name of the ISO to get simulated MD5 mismatch
+# simulateMD5Mismatch="partman-reiserfs_50_all.udeb"
+simulateMD5Mismatch="NOT_A_PACKAGE_NAME"
+
+# Given URLs and MD5s, fetch them into $imageTmp and verify,
+# then merge them into image
fetchAndMerge() {
+
+ # The other arguments are URLs in the same sequence as the words in md5List
+ md5List="$1"
+ shift 1
+
if test "$#" -eq 0; then return 0; fi
fetch --force-directories --directory-prefix="$imageTmp" -- "$@"
+
+ # Try to verify downloaded files
+ for md5 in $md5List
+ do
+url="$1"
+shift 1
+test "$md5" = ".no.MD5.known." && continue
+
+# Simulated MD5 mismatch
+if echo "$url" | grep '/'"$simulateMD5Mismatch"'$' >/dev/null 2>&1
+then
+ echo "DEVELOPMENT TEST: Faking a checksum mismatch with package
$simulateMD5Mismatch" >&2
+ md5="*INVALIDATED*CHECKSUM*"
+fi
+
+# Alternative proposals by Philip Hands:
+# localPath="$imageTmp"/`echo "$url" | sed -e
's,^\(https\?\|ftp\|file\)://,,i'`
+# localPath="$imageTmp/${url#[[:alpha:]]*://}"
+
+localPath="$imageTmp"/`echo "$url" | \
+sed -e 's/^[hH][tT][tT][pP]:\/\///' \
+-e 's/^[hH][tT][tT][pP][sS]:\/\///' \
+-e 's/^[fF][tT][pP]:\/\///' \
+-e 's/^[fF][iI][lL][eE]:\/\///'`
+
+if test ! -e "$localPath"
+then
+ # Maybe the file was downloaded but above guess was wrong
+ baseName=`basename "$url"`
+ localPath=`find "$imageTmp" -name "$baseName" | head -1`
+fi
+
+if test -n "$localPath" -a -e "$localPath"
+then
+ fileMD5=`$jigdoFile md5sum --report=quiet "$localPath" | sed 's/ .*$//'`
+ if test "$md5" != "$fileMD5"
+ then
+echo >&2
+echo "WARNING: Downloaded file does not match expected MD5:" >&2
+echo " $url" >&2
+echo "
Re: Distribution and sales with preinstalled Linux on computers
Hi,
Lars Henrik Jensen wrote:
> Our customers want to buy computer with preinstalled Linux and I wish to
> know how I can do it right and devilery with a recovery DVD/CD or USB stick
> or a recovery partition on harddrive.
With questions about installation of Debian you are probably better off at
debian-u...@lists.debian.org
If you install systems from a netinst ISO
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/
then give a copy of it on CD to the customer. Some printed instructions might
help the user to get started with re-installation if ever necessary.
To comply with the software licences you should prepare yourself to answer
the question where to find the source code of software which you install.
(There must be better answers than downloading all source DVD images from
https://cdimage.debian.org/debian-cd/current/source/iso-dvd/
or
https://cdimage.debian.org/debian-cd/current/source/jigdo-dlbd/
in order to be able years later to give some lawyer a copy of them.
)
In any case you should give the customer a Debian Live DVD with the graphical
desktop which you make default on your computers. There are several for
choice at
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
Debian Live will bring up quite some usable GNU/Linux without the need for
a permanent installation.
The Live images are referred to as "Live Install", but installing Debian from
them to hard disk is said to be error prone. (Testers are wanted, i guess.)
In order to enable re-installation without access to the internet, you
could do your installation from downloaded DVD or BD size ISOs and give
the customers copies of the needed media.
The first three DVD images are at
https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/
and usually suffice for an initial installation.
More DVD and BD sized ISOs are at
https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd/
https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/
https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dlbd/
The first "DLBD" ISO should really contain all that is needed and fit on a
64 GB USB stick.
All bootable Debian ISOs for 32-bit x86 ("i386") and 64-bit x86 ("amd64")
can be put on USB stick and will boot from there:
https://www.debian.org/CD/faq/#write-usb
(Program "Rufus" in its plain image copying mode "dd" is said to yield a
usable result on MS-Windows, too.)
> I have equipment to make cd's but no advanced to made with logo in colors
> and inlays and covers with nice colors at this moment.
At work i use a cheap Canon iP7250 printer to put text and graphics on
printable white media and to print double-sided booklets for the jewel cases.
It's not really photo quality on the media. So one should print lightly
colored graphics or restrict oneself to some lines of neatly printed text.
But it looks much more professional than hand writing with a marker pen.
Said this, there are graphic designs for CDs and booklets at
https://www.debian.org/CD/artwork/
Have a nice day :)
Thomas
Re: Blueray Disk image
Hi, Luca wrote: > Windows host=no jigdo There is a link to http://atterer.org/sites/atterer/files/2009-08/jigdo/jigdo-win-0.7.2.zip on http://atterer.org/jigdo/ Vague alternative ideas: - Install a small Debian in a virtual machine on some MS-Windows with network access and use it to assemble the ISOs by help of "jigdo-lite" from package "jigdo-file". - Boot a Debian Live system, check for jigdo-lite being present, install "jigdo-file" if needed, mount a disk partition, and assemble the ISO there. > Otherwise is there a sort of "online jigdo" in order to build a custom > installation ISO with needed packages and related dependencies? That would be the debian-cd software itself, i guess. Somebody would have to donate the resources to create large ISOs on demand. That's even more a load than offering a few BD sized static ISOs. (And then one would have to make it ready to be operated remotely by possibly greedy users ...) Have a nice day :) Thomas
Re: Blueray Disk image
Hi, Luca Biella wrote: > I thought Jigdo for windows where obsolete. I have no experience about how fast bit rot invalidates an MS-Windows binary. It would be interesting to know whether it still works and whether it can build the BD sized images. > I will try the Debian live hint on my home PC. If the command "jido-lite" is not available by default, then please report together with the exact Live ISO image name. We could then ask "debian-live" to include it in future releases. Have a nice day :) Thomas
Debian Live CD as platform for debian-cd Jigdo download
Hi, on occasion of a user question on debian-cd "Blueray Disk image" https://lists.debian.org/debian-cd/2018/01/msg00010.html i exercised the whole procedure of Jigdo download by help of Debian LiveCD: debian-live-9.3.0-amd64-xfce.iso It is bumpy. (But at least there is a terminal starter icon.) I Cc Luca Biella who initially asked the question. Maybe my ride helps him with his endeavor and maybe he can report about his experience with Live CD and MS-Windows hard disk. As was already noticed by Rick Thomas in above thread, jigdo-lite is not pre-installed. So the first step is to do: sudo apt-get update apt-get install jigdo-file The "processing triggers" part lasted nearly a minute. (The system was booted from an old 2 GB USB stick at USB-2. Reads with about 5 MB/s, writes with about 3 MB/s.) The filemanager mounted me the 230 GB partition of my olde test Lenny and so i could learn its device address from command "mount". Out of stubborn tradition i mounted it via sudo as /mnt/lenny and went to its traditional DVD storage cd /mnt/lenny/dvdbuffer Then i used the web browser (from starter icon) and Google "debian jigdo-bd" to locate the download site. I copied the URL and ran jigdo-lite with input https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/debian-9.3.0-amd64-BD-1.jigdo Here i had to circumvent the allergy of jigdo-lite against https which has been fixed in december by jigdo 0.7.3-5: * jigdo-lite: Cope with https URLs. Closes: #865864. The installed jigdo-lite silently skips the attempt to download and then says File `https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/debian-9.3.0-amd64-BD-1.jigdo' does not exist! The workaround is simple. Fetch the files to simulate the situation after an interrupted run (it is quite rugged with resuming): wget https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/debian-9.3.0-amd64-BD-1.jigdo wget https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/debian-9.3.0-amd64-BD-1.template Now jigdo-lite gets to the question about "files" and mirrors. I used as input: http://ftp.de.debian.org/debian/ Regrettably there is no overall progress indication. I could not even find a network throughput monitor in the XFCE desktop. So i installed xosview. Now it is fetching packages. 5.5 MB/s throughput. Sometimes long latency. Sorry mirror. For once you have to stand my giant suckling. Half an hour later, i stand in front of a screen locker and have to google on my workstation for login and password https://stackoverflow.com/questions/30842216/debian-8-live-cd-what-is-the-standard-login-and-password proposes "user" "live" which works. Ok. The download still runs. But since the template was already inflated to .iso.tmp with full image size, i have few means to see how far it is. With 2.5 MB/s effectively it should be done in barely 3 hours ... 2 hours 28 minutes later it is complete and the ISO is verified. I run xfburn & which recognizes the DVD burner and also that the BD image will not fit on the inserted DVD+RW. Because i am too lazy to carry a BD burner to the test machine i burn a smaller DVD image instead. (If xfburn would for some reason not work with BD media: sudo apt-get install xorriso xorriso -as cdrecord -v dev=/dev/sr0 -eject debian-9.3.0-amd64-BD-1.iso ) -- I deem it desirable that Debian Live gets advertised for this task. The MS-Windows version of Jigdo download software is very old meanwhile http://atterer.org/sites/atterer/files/2009-08/jigdo/jigdo-win-0.7.2.zip It lasted several hours yesterday until wget finally succeeded to connect and to download it. Further, at least debian-cd does not seem to have the experience to advise about MS-Windows or MacOS. A Debian GNU/Linux based opportunity would be much better supportable. How about a wiki page to which the debian-cd Jigdo download pages could point ? - Maybe somebody with more XFCE experience could streamline my above method to get write access to a hard disk partition. One would have to test this with partitions of MS-Windows and MacOS. - Some tangible advise should be given for the mirrors. E.g. to look at https://www.debian.org/mirror/list (I learned mine from entering "de" into the "mirror" question of jigdo-lite. So i got a list of .de mirrors. But that's quite rough for the normal GUI addict.) - The best known version of jigdo-file/jigdo-lite should be pre-installed in DVD sized Live ISOs, unless Live suffers from extreme space shortage. Opinions ? Wiki snippets ? Have a nice day :) Thomas
Re: Debian Live CD as platform for debian-cd Jigdo download
Hi, i started a wiki page "Downloading Debian Jigdo ISOs by a Debian Live system" https://wiki.debian.org/JigdoOnLive and filled in my experiences about this task. Help is needed to put some tangible info or examples into https://wiki.debian.org/JigdoOnLive#Get_access_to_a_writable_disk_filesystem I can only guess how a MS-Windows owner would make available the storage for download. Strangely i was not able to find any wiki pages which cover what i wrote in the range of https://wiki.debian.org/JigdoOnLive#Obtain_a_Debian_Live_medium to https://wiki.debian.org/JigdoOnLive#Boot_Debian_Live It would shorten JigdoOnLive if i could point to a guide about getting Debian Live, putting it on medium, and booting it. I'd appreciate proof-reading, additions, criticism, streamlining, and especially testing of the prescriptions i give (maybe with a CD image instead of BD). Please give me a note by mail if you make changes. Have a nice day :) Thomas
Should not .jigdo files be in SHA512SUMS ?
Hi, while working on my JigdoOnLive wiki page i got pointed by Paul Wise to the fact that the "https:" URLs of cdimage.debian.org files do not really protect their file content against tampering. I am quite sure that the .jigdo files get not verified by jigdo-lite beyond (possibly) the gzip checksum. There is no entry in the *SUMS files which accompany the .jigdo files at cdimage.debian.org/debian-cd/current/*/jigdo-*/. The files do not even bear an inner checksum to surely protect them against transmission errors (gzip CRC is 32 bit, afaik). Some undesirable aspects: - Manipulated .jidgo and .template file could lure jigdo-lite into letting wget download arbitrary URLs. - The .iso.tmp file could inflate to arbitrary size. - jigdo-lite's affirmative final statement about matching checksum could lure people into omitting the *SUMS/*SUMS.sign verification. If the .jigdo files would be listed in the *SUMS files, then we could at least rely on the "Template Hex MD5Sum" inside .jigdo. Better would be if .template would be listed in *SUMS, too, and if we add a line # Template Hex SHA512Sum ... to the .jigdo file. We should check whether jigdo-lite or jigdo-file really make use of the Template and Image checksums in the .jigdo file. (I suspect that its only MD5, at best.) --- Putting new files into *SUMS would have to be done by debian-cd et.al. The additional SHA512 line in .jigdo would have to done in libjte. I'd volunteer if Steve McIntyre gives his OK to the plan. Auditing of jigdo-lite in respect to checksums is in my reach, too. I will report if i find something especially worrying. But: The more eyes, the better. Have a nice day :) Thomas
Re: Should not .jigdo files be in SHA512SUMS ?
Hi,
i looked into jigdo-file about the safety of the final jigdo-lite statement
"OK: Checksums match, image is good!"
The message stems from
src/jigdo-file-cmd.cc
where i read
MD5Sum md; // MD5Sum of image
md.updateFromStream(*image, info->size(), readAmount, *optReporter);
md.finish();
if (*image) {
image->get();
if (image->eof() && md == info->md5()) {
optReporter->info(_("OK: Checksums match, image is good!"));
return 0;
So probably jigdo-file has to learn other checksumming algorithms like
SHA512 in order to get sufficient safety against intentional manipulation.
Until then, it should not be that much affirmative in its message, but
rather tell that it's only tested by a (yet untrusted) MD5 and that the
usual verification procedure for downloaded ISOs is still needed.
Have a nice day :)
Thomas
Re: Debian Live CD as platform for debian-cd Jigdo download
Hi, Lou Poppler wrote on debian-cd@lists.debian.org: > I would note that debian-live stable versions are also available via > bittorrent, which probably has more peers available, and is easier on the > mirrors. I myself have no clue of bittorrent. So this part would need an author other than me. > Here is a guide in general about getting/writing/using debian-live: > http://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html Thanks for the pointer. I missed to take notice of the paragraphs 4.5 and 4.6 among the other stuff that mainly deals with making a Live system. Let's see whether i can flatly point to them: "4.2 Downloading prebuilt images" is too sparse and also points to more adventurous places than https://www.debian.org/CD/live/. Current state in JigdoOnLive: https://wiki.debian.org/JigdoOnLive#Download_Debian_Live There are no verification instructions. One could use paragraph "Using GPG to Verify the Authenticity of Live CD Images" from wiki.debian.org/DebianLive A macro <> in that page would create a linkable URL of that paragraph. But i think that the indicator sentences gpg: Signature made Wed 21 Jun 2017 03:45:45 AM CDT gpg:using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B are not very good. Not all gpg versions tell the full key fingerprin that way. gpg 1.4.18 says gpg: Signature made Sun 05 Jun 2016 05:59:09 PM CEST using RSA key ID 6294BE9B Worse: Both versions of gpg says this with good and bad SHA512SUMS alike. In JigdoOnLive i propose to look for gpg: Good signature from "Debian CD signing key " ... Primary key fingerprint: DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B See https://wiki.debian.org/JigdoOnLive#Verify_the_Debian_Live_download "4.5.1 Burning an ISO image to a physical medium" and "4.5.2 Copying an ISO hybrid image to a USB stick" are Unix-only. As proud as i am of xorriso, it cannot burn optical media on MS-Windows or MacOS. Also i wonder whether Cygwin or WSL would support that "cp" command. In JigdoOnLive i point to four paragraphs of the debian-cd FAQ: https://wiki.debian.org/JigdoOnLive#Put_Debian_Live_onto_medium Have a nice day :) Thomas
Bug#887619: mount: no medium found on /dev/sr0
Hi, shivgupta wrote: > > mount: no medium found on /dev/sr0 Steve McIntyre wrote: > * Did you have a disc in drive sr0? > * Was it spun up? The first question was my first thought, too. But it's not about the drive spinning up, but rather the 10 to 15 seconds it normally needs to inspect the medium. So: Was the medium already loaded and the drive stopped blinking ? If the drive cannot blink: Did you wait 30 seconds after loading ? If the tray had to be loaded by the mount command, then the affected package is the Linux kernel. The regression that automatic tray loading shows not enough patience was introduced somewhere between 2.6.18 and 3.16. (My theory is that in drivers/scsi/scsi_lib.c the loop under /* try to eat the UNIT_ATTENTION if there are enough retries */ once had some own sleep action but now quickly performs three SCSI commands TEST UNIT READY and then gives up. Or maybe the code in drivers/scsi/sr.c under /* let's see whether the media is there with TUR */ once was a loop which retried if the was "not ready".) Have a nice day :) Thomas
Bug#887830: debian-cd: *.jigdo files should be listed in the *SUMS files
Package: debian-cd Severity: normal Tags: upstream Dear Maintainer, as described in https://lists.debian.org/debian-cd/2018/01/msg00019.html the *.jigdo files are not listed in the checksum files *SUMS. There is no way provided to check the authenticity of *.jigdo before downloading by jigdo-lite begins. The *.jigdo file provides package file paths, the URLs of fallback mirrors, and the cheksum of the *.template file. So *.template can inflate to an image of arbitrary size and jigdo-lite can be lured into downloading arbitrary URLs. Have a nice day :) Thomas
Re: Debianinstallation auf einem Laptop
Hi, debian-cd muss man auf englisch ansprechen. Vielleicht kann auch die deutschsprachige Liste https://lists.debian.org/debian-user-german/ weiterhelfen. (debian-cd needs to be addressed in english language. Maybe this german language list can help too: https://lists.debian.org/debian-user-german/ ) Translation (never trust the automats): - Hello list, i have installed Debian version 9.3 on the laptop. Regrettably the laptop is now inactive with the message "Sent SIGKILL to all processes Requesting system reboot" What is the reason and how to proceed for success ? The system is not started yet. Thanks Wolfgang - Have a nice day :) Thomas
Joliet name length in amd64 netinst versus DVD-2
Hi, debian-9.3.0-amd64-netinst.iso was made with xorrisofs option -joliet-long, which enable Joliet names longer than 64 characters. But production of debian-9.3.0-amd64-DVD-2.iso did not use it. Whatever setting is finally desirable, it should be the same with all Debian ISOs which get a Joliet filesystem tree by option -J. I stumbled over this by https://lists.debian.org/debian-user/2018/02/msg00388.html: > From: Serge LAOT > Date: Fri, 9 Feb 2018 18:22:56 +0100 > [...] > I have found some discrepencies between filenames in './pool/main/' and > the filenames in 'md5sum.txt'. > [...] > ./pool/main/m/mono/libmono-compilerservices-symbolwriter4.0-cil_4.6.2.7+dfsg-1_all.deb > ./pool/main/m/mono/libmono-compilerservices-symbolwriter4.0-cil_4.6.2.7+dfsg-1_a.deb -- Details: If i download https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-9.3.0-amd64-DVD-2.iso and mount it without disabling Rock Ridge, i see the longer name /mnt/iso/pool/main/m/mono/libmono-compilerservices-symbolwriter4.0-cil_4.6.2.7+dfsg-1_all.deb If i mount the Joliet tree by "-o norock", i see the truncated name /mnt/iso/pool/main/m/mono/libmono-compilerservices-symbolwriter4.0-cil_4.6.2.7+dfsg-1_a.deb This truncation is caused by xorrisofs option -J without a specs relaxation option like -joliet-long. The truncated length of 65 is correct, because Joliet prescribes 128 bytes which suffices for 64 UTF-16 characters. The dot in the name does not count for that limit. Looking at the files .disk/mkisofs of debian-9.3.0-amd64-DVD-2.iso and debian-9.3.0-amd64-netinst.iso reveils that netinst had -joliet-long whereas DVD-2 had not. Have a nice day :) Thomas
Re: Joliet name length in amd64 netinst versus DVD-2
Hi, Steve McIntyre wrote: > Fixing it right now, thanks for the clear report! I did not want to open a bug without knowing more background. As you are in fixing mode, could you please look whether https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887830 "debian-cd: *.jigdo files should be listed in the *SUMS files" could be solved, too ? The charm of this problem is that a fix is very unlikely to disturb any other part of the download and installation procedure. Testing would be straight forward. Have a nice day :) Thomas
Re: cdbuilder log files moved
Hi,
Steve McIntyre wrote:
> I think you're the main person who might be using the logs published
> from cdbuilder.
I did not even know that such logs exist.
> https://cdbuilder-logs.debian.org/
Ahum. What's the meaning of the number prefixes of the file names ?
("3sidamd64", "4amd64")
I always love to see xorriso doing sincere work.
This here in 3sidamd64 might cause user complaints like the one of yesterday
about truncated Joliet names:
> libisofs: WARNING : Cannot add /debian to Joliet tree. Symlinks can only be
> added to a Rock Ridge tree.
> libisofs: WARNING : Cannot add /dists/testing to Joliet tree. Symlinks can
> only be added to a Rock Ridge tree.
> libisofs: WARNING : Cannot add
> /firmware/expeyes-firmware-dev_4.3.6+dfsg-6_all.deb to Joliet tree. Symlinks
> can only be added to a Rock Ridge tree.
Maybe we should write something in
https://www.debian.org/CD/faq/
about mounting Debian ISOs by MS-Windows and what to expect from the
Joliet tree inside Debian ISOs,
---
The part which would need augmentation for bug 887830 (yada yada) is at
the very end of the log. This would give good clues about its position
in the code ... if the code was not a Makefile.
Well, it sends me to tools/imagesums. (But other than README.devel promises,
this is not self-documented. I need my background knowledge about Jigdo.)
I understand:
- If a .jigdo file is found, then the checksum of the corresponding .iso
file is read from inside the .jigdo file. In
https://sources.debian.org/src/debian-cd/3.1.21/tools/imagesums/#L55
to line 57.
- If successfully read, the .iso checksum is written to the *SUMS file.
If it was missing in the .jigdo file, it gets computed by e.g. md5sum
from the .iso file.
So (modulo ugly interlaced sequence of .iso and .jigdo) it should suffice
to insert at line 68 after the "fi" of "if [ $? -ne 0 ] ; then" :
if [ "$JIGDO" == 1 ] ; then
$CMD $file >> $FILE
grep $file $FILE
fi
Right ?
---
Have a nice day :)
Thomas
Re: Joliet name length in amd64 netinst versus DVD-2
Hi, looking at https://salsa.debian.org/images-team/debian-cd/commit/6112370e0abf29018a5346467aaf27cf7cb8ba91 "Ensure that in all places where we use -J we also use --joliet-long" i wonder whether it is wise to rely on the undocumented double-dash tolerance of xorrisofs and genisoimage. Both manuals have the option with a single dash. As for xorrisofs, you can indeed rely on the effect of an internal function in xorriso/emulators.c : /* Strip surplus dash from known single-dash long options */ int Xorriso_genisofs_strip_dash(... As for genisoimage, you are the expert yourself. Have a nice day :) Thomas
Re: Joliet name length in amd64 netinst versus DVD-2
Hi, Steve McIntyre wrote: > I've got too used to the relaxed handling in xorriso. IIRC the tolerance of xorrisofs exists because genisoimage and mkisofs show it. It's contageous and each adoption possibly widens it. E.g. i did not check whether genisoimage refuses on some double-dash options but simply tolerate double-dashes with all known long options. It is worth to mention that the zero-to-many-dash tolerance of the xorriso native command interpreter is documented and part of the CLI. So in live-wrapper you may prefix as many dashes as you deem good looking. But lwr/xorriso.py of live-wrapper has no command -joliet on and no -compliance joliet_long_paths:joliet_long_names which is what the emulator executes when getting option -joliet-long. Have a nice day :) Thomas
Re: bug 887830, was: Joliet name length in amd64 netinst versus DVD-2
Hi,
i wrote:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887830
> > "debian-cd: *.jigdo files should be listed in the *SUMS files"
Steve McIntyre:
> ACK, it's a fairly simple fix to the debian-cd setup. I've pushed the
> changes and if you check today's daily/weekly builds you'll see that
> the jigdo and template files are listed in the checksums files too!
That's good news. Especially for users of old jigdo-lite who download
the .template files manually because of the old "https" inability
(see fixed bug 865864).
I tested with
https://cdimage.debian.org/mirror/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.{jigdo,template}
MD5, SHA256, and SHA512 match nicely.
-
Now the next weakest point in Jigdo download is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887831
"jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5"
jigdo-lite after fix of bug 865864 downloads the .template if it yet
missing in the local directory. Verification is done by line
"Template-MD5Sum" of the .jigdo file, not by *SUMS.
jigdo-lite could now make automatic use of the *SUMS via the according
*sum programs.
Or jigdo-lite could expect better .template checksums in the .jigdo file
and jigdo-file could learn to compute such sums.
libjte can, so jigdo-file could learn from there.
Have a nice day :)
Thomas
Re: bug 887830
Hi, i wrote: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887831 > "jigdo-file: Jigdo .template file and resulting ISO are only verified > by MD5" > [...] > jigdo-lite could now make automatic use of the *SUMS via the according > *sum programs. It comes to me that jigdo-lite would first have to make use of a verified SHA512SUMS file in order to verify the .jigdo file before using it. Only after that verification, bug 887831 will be of real importance. Have a nice day :) Thomas
