Re: Updated installation images for Debian Ports 2019-04-12
On 4/14/19 11:39 PM, John Paul Adrian Glaubitz wrote:
On 4/14/19 9:14 PM, Eero Tamminen wrote:
On 4/12/19 12:34 PM, John Paul Adrian Glaubitz wrote:
I just uploaded updated installation images 2019-04-12 for the
following Debian Ports architectures:
Is there any other change than
- choose-mirror 2.98 all
- choose-mirror-bin 2.98 m68k
+ choose-mirror 2.99 all
+ choose-mirror-bin 2.99 m68k
I cannot really answer that as that would mean having to parse the
changelogs for all packages found on the installation CDs which is
Debian installation media is assembled from existing packages from
the FTP mirrors and these packages are maintained by individual
maintainers within Debian and get regularly updated, albeit less
frequent during feature freeze which is the case for now.
If they change, their version number should also change.
=> it should be enough just to list version changes.
What I did is updating debian-cd - the CD building software - to the
latest version in git and pulling the latest debian-installer images
from the FTP archives instead of building them manually as there was
just a new release of debian-installer.
My point was just that: to test something (again), it's useful
to know what has changed from previous version, so that one can
pay special attention to those things.
Please test those images and report back over the mailing list for
the corresponding architecture.
Any comment on things I asked with previous m68k debian-installer:
* adding System.map along with kernel
(to help debugging installer issues)
System.map is part of the normal linux-image Debian package:
root@elgar:~> dpkg -L linux-image-4.2.0-1-m68k |grep System.map
Ok, so everything comes from regular debian packages, their
content is just re-arranged.
Kernel matches exactly the binary in the this debian package:
=> I can use that instead of the installer version.
(I.e. take just initrd from the installer.)
Since it's usually not required for installation, it's not shipped
on the installation media. It will get automatically installed by
Installation media is not really intended for debugging kernel or
emulator bugs, so I'm not sure the other maintainers of the debian-
installer project would accept such a change.
Maybe there could be a MANIFEST file for kernel, like there's one
for initrd content:
---- MANIFEST.deb ----
linux-image-4.19.0-4-m68k 4.19.28-2 m68k
(to speed up boot when one doesn't use inicall_blacklist=dh_init)
This change would have to be made to the linux-image package thus
filing a bug report to src:linux with that request is necessary.
But again, if you're solely interested in these changes for debugging
kernel or emulator bugs, it doesn't make much sense to implement these
It's not for debugging (for that I can just blacklist it),
it's for regular users who want to try Debian on m68k.
Initializing that module takes ~10 minutes at boot (on 16Mhz 030),
with nothing visible happening. I think most people would conclude
that boot had stuck.
I'm not generally opposed to changing this option from "built-in"
to "module" but we would have to make sure this change doesn't
break anything else. I haven't checked what CONFIG_CRYPTO_DH
is used for.
According to menuconfig:
│ Symbol: CRYPTO_DH [=n]
│ Type : tristate
│ Prompt: Diffie-Hellman algorithm
│ (1) -> Cryptographic API (CRYPTO [=y])
│ Defined at crypto/Kconfig:125
│ Depends on: CRYPTO [=y]
│ Selects: CRYPTO_KPP [=n] && MPILIB [=n]
│ Selected by [n]:
│ - KEY_DH_OPERATIONS [=n] && KEYS [=n]
│ - CRYPTO_DEV_QAT [=n] && CRYPTO [=y] && CRYPTO_HW [=n]
I.e. it's enabled when one has enabled crypto, but has no crypto HW.
Maybe it's needed if one has encrypted disks. I would think that to
be so slow on m68k that (almost) nobody bothers to encrypt them though.
Does anybody on the list use encrypted disks with m68k?
Please note that you can just create a chroot for m68k using debootstrap
without the need for using debian-installer. debootstrap has the parameters
"--foreign --arch=$ARCH" for that matter.
Thanks, that's really good to know!
While I want also to debug installer issues, I can't really
do an installation with Hatari .
=> I'll test boot-strapped Debian Sid install first.
How do you do normally do --second-stage? With Qemu / Aranym?
 Hatari doesn't emulate CD-ROM device, nor any ethernet devices
(original Atari devices didn't have ethernet). I have my doubts about
how well network installation would work through PLIP or SLIP. :-)