> On Apr 15, 2019, at 12:15 AM, Eero Tamminen <o...@helsinkinet.fi> wrote:
>
> If they change, their version number should also change.
> => it should be enough just to list version changes.
I don’t want to. It takes additional effort for no real gain. The package list
is still long.
If anyone else wants to go through the effort though, more power to them.
>
>> 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.
>
> Ok, thanks!
>
> 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.
Yes, but that’s not how Linux distributions work. It’s not that I make Debian,
it’s an effort of a lot of people and computers building packages
automatically. It’s actually insane that this all works with so many pieces of
a puzzle.
>>>> 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
>> /boot/System.map-4.2.0-1-m68k
>> root@elgar:~>
>
> Ok, so everything comes from regular debian packages, their
> content is just re-arranged.
Yes. Some Debian packages like the kernel package include special packages for
debian-installer (so-called udebs).
> Kernel matches exactly the binary in the this debian package:
> http://ftp.kr.debian.org/debian-ports//pool-m68k/main/l/linux/linux-image-4.19.0-4-m68k_4.19.28-2_m68k.deb
>
> => I can use that instead of the installer version.
Yes.
> (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
>> debian-installer though.
>> 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
> ----------------------
> ?
What would be the purpose? I didn’t even know that this exists in the initrd,
but again, the large work is done by the community so I cannot know all that.
It’s more a generic question which should be asked on the development list for
debian-installer as there are people with more experience on d-i than me.
>>> * s/CONFIG_CRYPTO_DH=y/CONFIG_CRYPTO_DH=m/
>>> (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
>> changes.
>
> 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.
Well, running a modern kernel on a 16 MHz CPU is a bit exceptional anyway as
people usually use accelerators but I see your point.
I have just never run into this problem as my 68k machines are usually faster.
>> 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
> │ Location:
> │ (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?
We need to research the reasoning of enabling this. If that option is useless
for us and not required for anything like SSH or similar, we can disable it, of
course.
>> 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 [1].
>
> => I'll test boot-strapped Debian Sid install first.
>
>
> How do you do normally do --second-stage? With Qemu / Aranym?
On the target system after booting with init=/bin/bash or with qemu-user. Using
Aranym for that is too tedious.
Adrian
> - Eero
>
> [1] 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. :-)
