[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Te merging more than 9 disks
From: |
Thomas Schmitt |
Subject: |
Re: Te merging more than 9 disks |
Date: |
Fri, 14 Apr 2023 10:09:01 +0200 |
Hi,
(Cc-ing bug-xorriso@gnu.org. Please do the same if you reply.)
S Zhang wrote:
> I have just merged all the 12 DVDs with your instruction. Unfortunately, the
> resultant ISO does not work. Here is the output if I try to update:
> E: Failed to fetch
> file:/data/Jessie3/dists/jessie/main/binary-armel/Packages File not found -
> /data/Jessie3/dists/jessie/main/binary-armel/Packages (2: No such file or
> directory)
> [...]
> There is something in the merging process that does not work for this set.
I riddle for what differences between amd64 and armel ISOs of Jessie
i would have to look.
Regrettably we cannot expect much help from the Debian community about
this old version.
If you have time ans space to redo the merging, please send me the
complete message output of merge_debian_isos. Maybe it gives me ideas.
The download of debian-8.11.1-armel-DVD-1.iso has finished now.
There is no directory /data in this ISO. After mounting at /mnt/iso i see:
/mnt/iso/dists/jessie/contrib/binary-armel/Packages.gz
/mnt/iso/dists/jessie/local/binary-armel/Packages.gz
/mnt/iso/dists/jessie/main/binary-armel/Packages.gz
/mnt/iso/dists/jessie/main/debian-installer/binary-armel/Packages.gz
Maybe you can offer them to to "update" in a local tree under
/data/Jessie3 ?
Google does not give me matches for "/data/Jessie3/dists".
So the decisive question seems to be why your apt (or dpkg) comes to
the idea of looking for a local /data/Jessie3/dists.
Further: Do you have to update at all ?
The Packages lists of the ISOs should already match their packages.
----------------------------------------------------------------------
Slightly off topic:
> When I tried to write the resultant ISO or the DVD-1 using Rufus, it says it
> is not bootable etc.
Even in its "DD" mode ?
Maybe we should ask Pete Batard whether this is intentional.
(Maybe Balena Etcher or win32diskimager do it ?)
Inspecting the ISO yields that there really is no boot equipment:
xorriso -indev debian-8.11.1-armel-DVD-1.iso -report_system_area plain
-report_el_torito plain
yields
xorriso : NOTE : No System Area was loaded
xorriso : NOTE : No El Torito information was loaded
Looking into the recorded xorriso arguments (file /.disk/mkisofs)
there does not remain much after ignoring the jigdo-related ones:
xorriso -as mkisofs -r [...] -V 'Debian 8.11.1 armel 1'
-o [local address]/debian-8.11.1-armel-DVD-1.iso
[...] -J -joliet-long CD1
("CD1" was the local directory tree with the prepared files.)
So i downloaded debian-11.5.0-armel-DVD-1.iso to see whether it is
similarly poor with boot lures. (I'd expect some EFI partition or
EFI boot image.)
Same result:
No boot lures in the ISO and no boot related xorrisofs options in
/.disk/mkisofs:
xorriso -as mkisofs -r [...] -V 'Debian 11.5.0 armel 1'
-o [...]/debian-11.5.0-armel-DVD-1.iso
-J -joliet-long -cache-inodes CD1
This ISO would be on topic on debian-cd mailing list.
armel is an officially supported arch. So one could ask what's up with
its lack of boot lure.
------------------------------------------------------------------
More off topic:
> No update is possible as the security key has
> expired and will not be renewed by Bebian.
You also have to expect age problems with SSL certificates.
I had some with an amd64 Jessie. See
https://lists.debian.org/debian-user/2021/10/msg00012.html
and follow-ups.
I solved it by copying certificates from a Debian 10 installation.
https://lists.debian.org/debian-user/2021/10/msg00039.html
"The solution was to import to iceweasel the certificate file
/etc/ssl/certs/ISRG_Root_X1.pem"
There is also a bug about ignoring expired cerificates.
https://lists.debian.org/debian-user/2021/10/msg00044.html
I got this advise in
https://lists.debian.org/debian-user/2021/10/msg00113.html
"the final solution is:
-disable the certs with an ! before the cert name
(vi /etc/ca-certificates.conf: !DST_Root_CA_X3.crt)
-then, rebuild the cert directory (update-ca-certificates --fresh)"
Later i got a link from GNU savannah which explains it:
https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/
In the end i needed to make three fixes, summarized in
https://lists.debian.org/debian-user/2021/10/msg00229.html
Two of them were for Jessie
"- Debian 8 iceweasel (firefox) did not know the new certificate
ISRG_Root_X1 before i copied it from Debian (as of juli 2020).
I had to "import" this certificate by the browser's GUI.
[...]
- Debian 8 wget has the bug and lacked the ISRG_Root_X1 certificate.
So it needed that certificate file from Debian 10 in /etc/ssl/certs.
Because of the bug it needed DST_Root_CA_X3 to be hidden."
One was needed for Debian 10.
------------------------------------------------------------------
Have a nice day :)
Thomas