Re: 93.2 GiB ISO creation, disc 1
Hi,
after writing the following lengthy text and suspecting that ISO 1
was not included in the merged ISO, i realize that your shown runs of
merge_debian_iso are missing a mandatory argument:
> ~/bin/merge_debian_isos debian-13.2-QLBD-1.iso
> debian-13.2.0-amd64-BD-{1..6}.iso
Between "debian-13.2-QLBD-1.iso" and "debian-13.2.0-amd64-BD-{1..6}.iso"
there needs to be "mount_template".
In the examples of the wiki and the script's help text it is
merge_mount/iso
which would become "merge_mount/iso1" to "merge_mount/iso6" in a run
with 6 input ISOs.
The help text says:
At least the parent directory of mount_template must already exist
or has to be given by a plain name without "/" so that it can be
created in the current directory. (I.e. without even "./".)
So above run probably created mount points
debian-13.2.0-amd64-BD-1.iso{1...5}
and merged ISOs 2 to 6.
This means that the resulting ISO is missing all boot equipment and
also the 23 GB of most popular .deb packages and firmware.
It would match the failure to boot, the result size of 97 GB instead
of the summed size 121 GB of the 6 ISOs, and the "2" in the mount
point name "/media/supaplex/Debian 13.2.0 amd64 2".
If adding the missing argument fixes bootability, then there is still
relevant information in the following text:
- Faster BD-R burning by Stream Recording (or by preventing growisofs
from formatting the medium).
- Testing the result ISO whether it works from kvm -hda in order to
emulate its use as USB stick.
Further we should investigate why loop devices of the input ISOs
persisted after the end of the script run.
-----------------------------------------------------------------------
The winded considerations before i noticed the missing directory path:
> Burning at 0.7x took 15h.
The slow speed was most probably due to Defect Management which
checkreads directly after writing a moderately sized chunk of data.
What is the nominal speed of the medium as printed on the box or
the upper side of the medium ?
I assume that K3B uses growisofs as burn backend. growisofs avoids
Defect Management only if the user prevents medium formatting by
option -use-the-force-luke=spare=none .
In Xfburn there is a check box "Stream recording", which disables
Defect Management. Further Xfburn does not format BD-R by default.
xorriso has command -stream_recording "on" . cdrskin and xorriso's
cdrecord emulation have option stream_recording=on . They don't format
BD-R by default.
E.g. for BD-RE or already formmatted BD-R:
xorriso -as cdrecord -v dev=/dev/sr0 stream_recording=on -eject debian-13.2-QLBD-1.iso
With yet unused BD-R "stream_recording=on" will have no visible effect,
but it won't harm if it is present.
Whatever, even at 2x speed a triple or quad layer BD will need 2 to 3
hours.
> (and it does not boot).
That's disappointing.
What messages do you get from inquiring the boot equipment by this
xorriso run:
xorriso -indev debian-13.2-QLBD-1.iso \
-toc -report_el_torito plain -report_system_area plain
> supaplex@wiseguy:~/public_html/iso-images-FOSS/debian/BD$ kvm -m 8G -cdrom debian-13.2-QLBD-1.iso
> Gtk-Message: 16:41:10.194: Failed to load module "xapp-gtk3-module"
> kvm: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
This does not give much clue about what did not work.
Does the original debian-13.2.0-amd64-BD-1.iso boot ?
With the combined ISO:
Does a graphics window show up with messages from virtual firmware and
from GRUB ?
(I would expect that the guest system wants gtk3 only after booting
went through BIOS, boot loader, and Linux kernel. So maybe it's kvm
which refuses to start ... ?)
> /dev/loop13 23419488 ...
> /dev/loop49 23391054 ...
> ...
> /dev/loop53 1449034 ...
This looks like the BD-sized ISOs are available as loop devices.
Did merge_debian_isos leave them running ?
Did you see a message
Cleaning up temporary files and mount points ...
The script creates the loop devices indirectly by mount(8) and in my
tests it removed them indirectly by umount(8).
Did you create loop devices for those ISOs manually or did you mount
them ?
> /dev/sr1 94869722 ... /media/supaplex/Debian 13.2.0 amd64 2
> Note, it's showing "2" as in disc 2 when I combined 1-4.
That's quite suspicious.
The Volume Id of the resulting ISO is supposed to be the same as with
the first input ISO. That's the ISO which gets loaded by xorriso -indev
in order to get all non-file properties of this ISO, like boot catalog,
MBR, EFI partition, and also the Volume Id.
If you see the Volume Id of ISO 2, then this looks as if not ISO 1 was
perceived as the first ISO in the input arguments.
> [... ]ran 1-6 again.
> 488 ~/bin/merge_debian_isos debian-13.2-QLBD-1.iso
> debian-13.2.0-amd64-BD-{1..6}.iso
> 97,146,595,328 bytes now.
That's suspisciously few.
When summing up the size of ISO 1 to 6 as shown in your mail, then
i get 121,154,166,784 bytes. 97 GB is roughly the sum if one out of
ISO 1 to 5 is missing.
The bulk of this sum is due to .deb packages. Reduction of overhead by
merging the ISO metadata is supposed to stay under 1 percent.
(I have an example from 2022 with DVD 1,2,3. The merged ISO is 16 MB
smaller than the summed size of 12 GB.)
You could make a few spot checks by mounting the merged ISO and each
of the single ISOs. Pick the path of some .deb package from each single
ISO and check whether it is in the merged ISO. (I expect one to be
missing. ISO 1 is the main suspect because of the Volume Id "2".)
> 491 kvm -m 8G -cdrom debian-13.2-QLBD-1.iso
You could submit the ISO as -hda or -hdb, too. That would be the
situation where it is presented on a USB stick.
Have a nice day :)
Thomas
Reply to: