Updated installation images for Debian Ports 2019-04-12

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Updated installation images for Debian Ports 2019-04-12

John Paul Adrian Glaubitz


Hello!

I just uploaded updated installation images 2019-04-12 for the
following Debian Ports architectures:

 * alpha
 * hppa
 * ia64
 * m68k
 * powerpc
 * ppc64
 * sh4
 * sparc64

I uploaded both CD images [1] as well as netboot images [2].

Please test those images and report back over the mailing list for
the corresponding architecture.

Known issues:

 * alpha
   - No known issues
 * hppa
   - There have been reports about missing GPG keys during installation.
     If you are seeing this issue, please provide me with the syslog,
     information on your hardware, information on the image used and
     a rough recap of what was done during install (normal vs. expert
     mode etc).
 * ia64
   - The kernel might be unstable during install
     (try passing "hardened_usercopy=off" at the boot prompt,
      e.g. "install hardened_usercopy=off"
 * m68k
   - The drivers for IDE hardware may have to be loaded manually, e.g.:
     + modprobe pata_gayle
     + modprobe pata_falcon
   - There is no automatic installation of the bootloader yet,
     users have to boot the kernel and initrd manually after
     installation.
 * powerpc/ppc64
   - The bootloader installation still defaults to Yaboot and
     is being switched to GRUB for IBM POWER and PowerMacs,
     please report any issues you find.
   - On some machines, the fans might produce a lot of noise,
     this can be addressed by manually the windfarm kernel
     modules:
     + modprobe windfarm_core
 * sh4
   - There is no CD image, installation has to be performed
     using the debian-installer images.
   - Currently supported targets are Renesas SH-7785LCR and
     SH-7751R, the latter should be identical to qemu-sh4.
   - debian-installer for sh4 is completely untested, please
     test with QEMU and report back.
   - The filenames for kernel and initrd still contain an
      old 2.6.32.5 kernel version. This can be ignored.
 * sparc64
   - Installation over a serial console is currently broken
     on sparc64 due to a bug in the rootskel package
     (can also be considered a kernel bug), see: #926539.
     Use any image before 2019-04-06 as workaround.

Important:

When reporting issues or bugs, please include the syslog
from your installation in the bug report/mail. The log
file can be access when switching to another console using
<Alt>+<Cursor> for normal installations or <Ctrl>+<a>+<n>
when installing over a serial console. I also need to know
what hardware was used, which installation steps (normal
vs. expert) and which image was used.

Thanks,
Adrian

> [1] https://cdimage.debian.org/cdimage/ports/2019-04-12/
> [2] https://cdimage.debian.org/cdimage/ports/debian-installer/

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Updated installation images for Debian Ports 2019-04-12

Eero Tamminen
Hi,

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

for nativehd/initrd.gz?


>   * alpha
>   * hppa
>   * ia64
>   * m68k
>   * powerpc
>   * ppc64
>   * sh4
>   * sparc64
>
> I uploaded both CD images [1] as well as netboot images [2].
>
> 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)

* s/CONFIG_CRYPTO_DH=y/CONFIG_CRYPTO_DH=m/
   (to speed up boot when one doesn't use inicall_blacklist=dh_init)

?


        - Eero


> Known issues:
>
>   * alpha
>     - No known issues
>   * hppa
>     - There have been reports about missing GPG keys during installation.
>       If you are seeing this issue, please provide me with the syslog,
>       information on your hardware, information on the image used and
>       a rough recap of what was done during install (normal vs. expert
>       mode etc).
>   * ia64
>     - The kernel might be unstable during install
>       (try passing "hardened_usercopy=off" at the boot prompt,
>        e.g. "install hardened_usercopy=off"
>   * m68k
>     - The drivers for IDE hardware may have to be loaded manually, e.g.:
>       + modprobe pata_gayle
>       + modprobe pata_falcon
>     - There is no automatic installation of the bootloader yet,
>       users have to boot the kernel and initrd manually after
>       installation.
>   * powerpc/ppc64
>     - The bootloader installation still defaults to Yaboot and
>       is being switched to GRUB for IBM POWER and PowerMacs,
>       please report any issues you find.
>     - On some machines, the fans might produce a lot of noise,
>       this can be addressed by manually the windfarm kernel
>       modules:
>       + modprobe windfarm_core
>   * sh4
>     - There is no CD image, installation has to be performed
>       using the debian-installer images.
>     - Currently supported targets are Renesas SH-7785LCR and
>       SH-7751R, the latter should be identical to qemu-sh4.
>     - debian-installer for sh4 is completely untested, please
>       test with QEMU and report back.
>     - The filenames for kernel and initrd still contain an
>        old 2.6.32.5 kernel version. This can be ignored.
>   * sparc64
>     - Installation over a serial console is currently broken
>       on sparc64 due to a bug in the rootskel package
>       (can also be considered a kernel bug), see: #926539.
>       Use any image before 2019-04-06 as workaround.
>
> Important:
>
> When reporting issues or bugs, please include the syslog
> from your installation in the bug report/mail. The log
> file can be access when switching to another console using
> <Alt>+<Cursor> for normal installations or <Ctrl>+<a>+<n>
> when installing over a serial console. I also need to know
> what hardware was used, which installation steps (normal
> vs. expert) and which image was used.
>
> Thanks,
> Adrian
>
>> [1] https://cdimage.debian.org/cdimage/ports/2019-04-12/
>> [2] https://cdimage.debian.org/cdimage/ports/debian-installer/
>

Reply | Threaded
Open this post in threaded view
|

Re: Updated installation images for Debian Ports 2019-04-12

John Paul Adrian Glaubitz
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
>
> for nativehd/initrd.gz?

I cannot really answer that as that would mean having to parse the
changelogs for all packages found on the installation CDs which is
not feasible.

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.

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.

>> 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:~>

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.

> * 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.

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.

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,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Updated installation images for Debian Ports 2019-04-12

Eero Tamminen
Hi,

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
>>
>> for nativehd/initrd.gz?
>
> I cannot really answer that as that would mean having to parse the
> changelogs for all packages found on the installation CDs which is
> not feasible.
>
> 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.

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.


>>> 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.

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.

(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
----------------------
?


>> * 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.


> 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?


> 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?



        - 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. :-)

Reply | Threaded
Open this post in threaded view
|

Re: Updated installation images for Debian Ports 2019-04-12

John Paul Adrian Glaubitz


> On Apr 15, 2019, at 12:15 AM, Eero Tamminen <[hidden email]> 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. :-)