Updated installation images for Debian Ports 2019-04-12

classic Classic list List threaded Threaded
6 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

Frank Scheiner
Hi Adrian,

much obliged for the ia64 ISOs. :-D

On 4/12/19 11:34, John Paul Adrian Glaubitz wrote:

> Hello!
>
> I just uploaded updated installation images 2019-04-12 for the
> following Debian Ports architectures:
> [...]
>   * ia64
> [...]
> Please test those images and report back over the mailing list for
> the corresponding architecture.
>
> Known issues:
> [...]
>   * ia64
>     - The kernel might be unstable during install
>       (try passing "hardened_usercopy=off" at the boot prompt,
>        e.g. "install hardened_usercopy=off"
>[...]
> 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/
>
I used the 2019-04-12 image ([1]) and tested a normal mode installation
on the following machines with mixed success:

[1]:
https://cdimage.debian.org/cdimage/ports/2019-04-12/debian-10.0-ia64-NETINST-1.iso

## rx2620 (w/2x Itanium 2 9020 (Montecito) and enabled Hyper-Threading,
HP zx1 chipset) ##

No luck so far

The machine produces a lot of "usercopy: Kernel memory overwrite attempt
detected" errors when the UDEBs are installed. Going back to the menu is
also not possible, as the installer screen exits afterwards. I therefore
also don't have a network connection to copy out the syslog. And I can't
even mount a FS on a USB stick, trying to load the ext3 module gives a
segfault, not sure if it is already available at the start of the
installation. I therefore manually "copied" information from the console
(see attached text file).

I can't continue with the installation from there on.

But as this machine worked well with older kernels, I assume it's either
the newer kernel that's problematic for this machine or the installer
environment or a combination. Though when using the same kernel version
(4.19.28) with a NFS root FS and the "hardened_usercopy=off" kernel
command line option, I don't see any problems even when upgrading nearly
two dozens of packages.

```
root@rx2620:~# uname -a
Linux rx2620 4.19.0-4-mckinley #1 SMP Debian 4.19.28-2 (2019-03-15) ia64
GNU/Linux

root@rx2620:~# cat /proc/cmdline
BOOT_IMAGE=net0:/AC100221.vmlinuz  root=/dev/nfs ip=:::::enp32s2f0:dhcp
modprobe.blacklist=radeon hardened_usercopy=off

root@rx2620:~# cat /etc/*release
PRETTY_NAME="Debian GNU/Linux buster/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
```

I therefore don't assume a hardware failure, even more as the machine
worked flawlessly with Debian GNU/Linux Sid on NFS root FS since about a
year or so.

## rx2660 (w/1x Itanium 2 9140M (Montvale) and enabled Hyper-Threading,
HP zx2 chipset) ##

On this machine I don't see any of these "usercopy: Kernel memory
overwrite attempt detected" as on the rx2620 neither with nor without
the "hardened_usercopy=off" kernel command line option active. Could be
related to the different hardware.

I could perform a successful installation on this machine - with some
manual "help":

* there is no need to load any firmware for the built-in tg3 driven
NICs, although a dialogue in the installer indicates differently

* To be sure to have enough space for two kernels and two initramfs
images on the EFI system partition, increase the sizes in your desired
partman-auto recipe. E.g. for everything on one partition (aka atomic)
change `/lib/partman/recipes-ia64/30atomic` as follows:
```
538 538 1075 fat16
         $primary{ }

         method{ efi }

         format{ } .
[...]
```

I'm preparing a patch for d-i/partman-auto to include these changes in
the future.

* "bootstrap-base" fails due to:
```
Apr 14 14:46:39 debootstrap: dpkg: dependency problems prevent
configuration of vim-tiny:
Apr 14 14:46:39 debootstrap:  vim-tiny depends on vim-common (=
2:8.1.0089-1); however:
Apr 14 14:46:39 debootstrap:   Version of vim-common on system is
2:8.1.0875-2.
Apr 14 14:46:39 debootstrap:
Apr 14 14:46:39 debootstrap: dpkg: error processing package vim-tiny
(--configure):
Apr 14 14:46:39 debootstrap:  dependency problems - leaving unconfigured
```
This can be worked around by modifying the file
`/var/lib/dpkg/info/bootstrap-base.postinst` and adding an
`--exclude=vim-tiny` to the debootstrap command starting at line 147
(see [2] for comparison). You should do this in a shell during the
partitioning step, as the installer will hold there for user input. Some
days earlier I had to also use "apt pinning" to prevent a retried
installation of that package - which also failed - later on in the
installation process. But today this wasn't needed any longer. I hence
assume that the 2019-04-12 installer image still contains the
"incompatible" vim-tiny and vim-common packages, but the ports mirror
does not. Hence I assume this issue will be gone with the next ISO image.

[2]:
https://salsa.debian.org/installer-team/base-installer/blob/master/debian/bootstrap-base.postinst#L147

* elilo installation fails as long as the EFI system partition is
mounted. So unmount it before the elilo installation, to make it succeed.

These manual changes should allow you to install Debian GNU/Linux Sid on
your rx2660 or possibly other Itanium machine.

**IMPORTANT:** When installing on an Integrity with MP iLO, before
restarting after the installation has finished, make sure to add
`modprobe.blacklist=radeon` to the kernel command line in the elilo
configuration file on the EFI system partition, i.e. add
`append="modprobe.blacklist=radeon"` to the respective stanza ther, as
otherwise the kernel/machine will hang during kernel boot. This is a
known problem with the MP of these machines and their older HPPA
counterparts.

## rx2800 i2 (w/1x Itanium 9320 (Tukwila) and enabled Hyper-Threading,
Intel Boxboro chipset) ##

No luck so far.

The firmware restarts when the kernel is started and there's no kernel
output. But that was sort of expected, as the only kernels that ever ran
on this machine were the ones based on Gentoo's kernel sources for 4.9.x
and 4.14.x. To be clear, this machine runs with the Debian userland (on
NFS root FS) and a Gentoo kernel - as do my other Integrities with
Debian kernel - the rx2800 i2 is just not installable at the moment.

## rx4640 (w/4 x Itanium 2 1.3 GHz (Madison), HP zx1 chipset) ##

I'll check the installer ISO on this machine tomorrow. Hopefully it
behaves differently than the rx2620.

Cheers,
Frank

rx2620-kernel-memory-overwrite-detected.txt.gz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Frank Scheiner
Update for rx4640, see below:

On 4/14/19 22:41, Frank Scheiner wrote:

> I used the 2019-04-12 image ([1]) and tested a normal mode installation
> on the following machines with mixed success:
>
> [1]:
> https://cdimage.debian.org/cdimage/ports/2019-04-12/debian-10.0-ia64-NETINST-1.iso
>
>
> ## rx2620 (w/2x Itanium 2 9020 (Montecito) and enabled Hyper-Threading,
> HP zx1 chipset) ##
>
> No luck so far
> [...]
 >
> ## rx2660 (w/1x Itanium 2 9140M (Montvale) and enabled Hyper-Threading,
> HP zx2 chipset) ##
> [...]
> I could perform a successful installation on this machine - with some
> manual "help":
> [...]
 >
> ## rx2800 i2 (w/1x Itanium 9320 (Tukwila) and enabled Hyper-Threading,
> Intel Boxboro chipset) ##
>
> No luck so far.
> [...]
 >
> ## rx4640 (w/4 x Itanium 2 1.3 GHz (Madison), HP zx1 chipset) ##
>
> I'll check the installer ISO on this machine tomorrow. Hopefully it
> behaves differently than the rx2620.

Indeed the rx4640 behaves differently than the rx2620, despite the same
chipset and the older Itanium processors. The installation works through
identically to the rx2660 (with the earlier mentioned manual "help"). No
error messages like on the rx2620. I'm not sure why this is like that,
though.

As an additional test I will try the resulting on-disk installation
performed on the rx4640 on the rx2620.

Cheers,
Frank

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 6:10 PM, Frank Scheiner <[hidden email]> wrote:
>
> Update for rx4640, see below:
>
> Indeed the rx4640 behaves differently than the rx2620, despite the same
> chipset and the older Itanium processors. The installation works through
> identically to the rx2660 (with the earlier mentioned manual "help"). No
> error messages like on the rx2620. I'm not sure why this is like that,
> though.
>
> As an additional test I will try the resulting on-disk installation
> performed on the rx4640 on the rx2620.

I think we should get the bootloader installation sorted out first so users don’t get stuck in the end once elilo gets installed.

Is there any chance you could test-install GRUB on any of your machines so we can find out what modifications are necessary to get grub-installer work on ia64?

I assume we don’t need to change much as the environment behaves very similar to x86_64.

If we’re lucky, it’s just a matter of enabling the grub-installer package on ia64 and add “ia64” to the architecture matching for “amd64-efi”.

Adrian
Reply | Threaded
Open this post in threaded view
|

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

Frank Scheiner
On 4/15/19 18:21, John Paul Adrian Glaubitz wrote:

>> On Apr 15, 2019, at 6:10 PM, Frank Scheiner <[hidden email]> wrote:
>>
>> Update for rx4640, see below:
>>
>> Indeed the rx4640 behaves differently than the rx2620, despite the same
>> chipset and the older Itanium processors. The installation works through
>> identically to the rx2660 (with the earlier mentioned manual "help"). No
>> error messages like on the rx2620. I'm not sure why this is like that,
>> though.
>>
>> As an additional test I will try the resulting on-disk installation
>> performed on the rx4640 on the rx2620.
>
> I think we should get the bootloader installation sorted out first so users don’t get stuck in the end once elilo gets installed.

I'll have a look, though I think the best way would be to not mount the
EFI system partition (ESP) at all. There's no need to mount the
partition all the time, if it only gets changed on elilo upgrades (sure,
      won't happen anymore) or kernel upgrades and is then mounted
automatically by elilo - at least that's my impression.

I need to check what happens on kernel updates.

UPDATE: On second thought, most likely GRUB needs this partition mounted
all the time, like the HFS bootstrap partition for powerpc/ppc64. Then
elilo-installer should handle that and (u)mount it as needed.

> Is there any chance you could test-install GRUB on any of your machines so we can find out what modifications are necessary to get grub-installer work on ia64?

I'll try on the rx2660 and report back.

>
> I assume we don’t need to change much as the environment behaves very similar to x86_64.
>
> If we’re lucky, it’s just a matter of enabling the grub-installer package on ia64 and add “ia64” to the architecture matching for “amd64-efi”.

That would be cool. Let's hope for the best. :-D

Cheers,
Frank

Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
On 4/15/19 6:46 PM, Frank Scheiner wrote:
>> If we’re lucky, it’s just a matter of enabling the grub-installer package on ia64 and add “ia64” to the architecture matching for “amd64-efi”.
>
> That would be cool. Let's hope for the best. :-D
I think, the following patch should be enough as the installation
process for grub-efi-* is standardized and the code for grub-efi-amd64
in grub-installer should also work

>From 3ca3836ba6f409bd3b4a445b3db5fedc95ea1198 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz <[hidden email]>
Date: Tue, 16 Apr 2019 08:15:12 +0200
Subject: [PATCH] Add ia64 support

---
 debian/control | 2 +-
 grub-installer | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index fbc6728e..bbeb85ae 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Vcs-Browser: https://salsa.debian.org/installer-team/grub-installer
 Vcs-Git: https://salsa.debian.org/installer-team/grub-installer.git
 
 Package: grub-installer
-Architecture: i386 hurd-i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc ppc64 ppc64el sparc sparc64 mipsel arm64 armhf
+Architecture: i386 ia64 hurd-i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc ppc64 ppc64el sparc sparc64 mipsel arm64 armhf
 XB-Subarchitecture: ${subarch}
 Provides: bootable-system
 Depends: ${shlibs:Depends}, ${misc:Depends}, kernel-installer, created-fstab, di-utils (>= 1.15), di-utils-mapdevfs, os-prober, partman-utils
diff --git a/grub-installer b/grub-installer
index ef64fdce..c168989c 100755
--- a/grub-installer
+++ b/grub-installer
@@ -373,6 +373,9 @@ case $ARCH in
                grub_package="grub-pc"
        fi
        ;;
+    ia64/*)
+       grub_package="grub-efi-ia64"
+       ;;
     powerpc/*|ppc64/*)
        grub_package="grub-ieee1275"
        ;;
--
2.20.1

I have manually built a grub-installer with that patch now and uploaded
it. It should be pulled in automatically during the next image build.

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