Re: Updated installation images for Debian Ports
> > I have done that myself just today. Works without issues. > Same here. No issues on my Montvale rx2660. > > I'm just using a KVM virtual machine running Windows XP with Internet > Explorer ;-). > Gotta bite the bullet then… Thanks.
Re: Updated installation images for Debian Ports
Hi Pedro! On Sat, 2023-06-17 at 22:30 +, Pedro Miguel Justo wrote: > > > I’ll give it a try on Monday. I have done that myself just today. Works without issues. > Slightly related question: Is there any way to reliably use Remote > Media using today's OSes, Browsers and Java Runtime? I'm just using a KVM virtual machine running Windows XP with Internet Explorer ;-). > That would avoid me having to physically burn and insert a CD in loco. Agreed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installation images for Debian Ports
> On Jun 17, 2023, at 03:01, John Paul Adrian Glaubitz > wrote: > > Hi! > > Does anyone have the time to verify this image installs fine on an RX2660 > again? > Thanks Adrian. I’ll give it a try on Monday.
Re: Updated installation images for Debian Ports
> I’ll give it a try on Monday. Slightly related question: Is there any way to reliably use Remote Media using today's OSes, Browsers and Java Runtime? That would avoid me having to physically burn and insert a CD in loco.
Re: Updated installation images for Debian Ports
Hi! On Wed, 2023-06-14 at 15:07 +0200, John Paul Adrian Glaubitz wrote: > I have created updated installation images for Debian Ports. > > These can be found here: > > - https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-14/ > > On ia64, these images should be usable on all machines again since > the previous regression in kernel 6.1 has been fixed in 6.3 which > is now the kernel version that the installer uses. Does anyone have the time to verify this image installs fine on an RX2660 again? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
RE: Updated installation images for Debian Ports 2020-04-19
The Itanium image installed smoothly on my Montvale-based RX2660. The only note is that "modprobe_blacklist=radeon nomodeset” is still required. Glad to see GDB working . GIT seems to have a dependency problem. _ Pedro From: John Paul Adrian Glaubitz Sent: Sunday, April 19, 2020 11:30 To: debian-ia64 Subject: Updated installation images for Debian Ports 2020-04-19 Hi! I just uploaded updated installation images 2020-04-19 for the following Debian Ports architectures [1]: * alpha * hppa * ia64 * m68k * powerpc * ppc64 * sparc64 These images should finally fix the installation process on Apple PowerMacs and PowerBooks compatible with GRUB, so basically every Macintosh using the New World ROM [2]. One user already reported a successful installation on his PowerMac G5 and I expect installations to work fine on 32-bit machines, i.e. G3 and G4 as well. But I'm looking forward to more feedback. Another important improvement to debian-installer is that the mirror setup now allows to select the preferred mirror from a list instead having to enter that information manually. Unfortunately, there are only a few mirrors, namely in Germany and South Korea which can be chosen from. So don't be surprised that the list is short. Otherwise, the images contain the usual improvements like a new kernel and a fresh base system. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/2020-04-19/ > [2] https://en.wikipedia.org/wiki/New_World_ROM -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installation images for Debian Ports 2019-07-04
On 7/6/19 10:39 PM, William ML Leslie wrote: > I had the same issue that Frank Scheiner had regarding vim-tiny on the > rx2660 (thank you Frank for the detailed explanation of your > experience). The problem is the vim package which failed to build from source on ia64 again [1]. If I build installation images after the vim package has failed to build, the issue you are describing occurs. The explanation why a vim package that fails to build blocks the installation is explained in [2]. I will build the vim package manually now with the testsuite disabled but someone needs to have a look at vim on alpha and ia64 and fix the package. Adrian > [1] https://buildd.debian.org/status/package.php?p=vim=unstable > [2] https://lists.debian.org/debian-sparc/2017/12/msg00060.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installation images for Debian Ports 2019-07-04
On Fri, 5 Jul 2019 at 01:03, John Paul Adrian Glaubitz wrote: > > Hello! > > I just uploaded updated installation images 2019-07-04 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. > Thank you for producing these! I'm new today to hardware ports (though I have been a debian hurd-i386 user for many years). I have successfully used this ia64 image to install to my stylish combination slim-line space heater and secure ambient noise generator. It's an HP Integrity rx2620 with iLO MP and a single mckinley at 1.4 GHz and 6 GiB of RAM. I had the same issue that Frank Scheiner had regarding vim-tiny on the rx2660 (thank you Frank for the detailed explanation of your experience). This one was supremely frustrating as editing bootstrap-base.postinst after the first install attempt and retrying the install leads to failing to extract a .tar (file exists!) wheras performing the partitioning step again would lead to the cdrom becoming unmounted; and d-i would not give me the option to remount the cdrom before continuing onto the next step until I restarted the install in expert mode. Editing the file before detecting disks seemed to work however. I have not tested running without the radeon module blacklisted; I will do once I have the machine configured for use. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement.
Re: Updated installation images for Debian Ports 2019-04-12
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
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 - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installation images for Debian Ports 2019-04-12
On 4/15/19 18:21, John Paul Adrian Glaubitz wrote: On Apr 15, 2019, at 6:10 PM, Frank Scheiner 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
Re: Updated installation images for Debian Ports 2019-04-12
> On Apr 15, 2019, at 6:10 PM, Frank Scheiner 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
Re: Updated installation images for Debian Ports 2019-04-12
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
Re: Updated installation images for Debian Ports 2019-04-12
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
+ for normal installations or ++
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
