Bug#825931: s390-netdevice virtio interface choice misleading
Package: s390-netdevice Version: 0.0.44 Severity: normal Tags: d-i patch X-Debbugs-CC: debian-s390@lists.debian.org, brueck...@linux.vnet.ibm.com Dear Maintainer, if an installation is attempted on a system with a PCI network interface only, it is necessary to select virtio as network interface to continue with the installation. This works because the virtio choice is effectively a NOP and both PCI and virtio interfaces don't need additional configuration. But it's also confusing. I'd like to suggest to replace the 'virtio' choice with 'other' for a better user experience (see attached patch). This has of course an impact on existing preseed configurations with s390-netdevice/choose_networktype=virtio but in the long run it might be better to accept the migration pain than to live with a multitude of semantically equivalent choices (kvm, pci, ...). -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 >From f7150c9d0c57f918b7f627423846bd43f2b964bc Mon Sep 17 00:00:00 2001 From: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> Date: Mon, 30 May 2016 15:33:50 +0200 Subject: [PATCH] s390-netdevice: replace "virtio" by "other" With the advent of PCI network device in z Systems a certain shortcoming of the s390-netdevice module shows: 1. There's no PCI choice 2. A PCI choice doesn't exactly make sense, as nothing needs to be done for PCI. 3. Same thing for virtio This change replaces the "virtio" selection with "other" in order to support all kinds of network interfaces not needing configuration in s390 environments, e.g. because a different d-i module is configuring the interface. Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> Acked-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com> --- debian/s390-netdevice.templates | 8 +--- netdevice.c | 8 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/debian/s390-netdevice.templates b/debian/s390-netdevice.templates index 39fc0b7..04db5bf 100644 --- a/debian/s390-netdevice.templates +++ b/debian/s390-netdevice.templates @@ -1,16 +1,18 @@ Template: s390-netdevice/choose_networktype Type: select -Choices-C: ctc, qeth, iucv, virtio +Choices-C: ctc, qeth, iucv, other # Note to translators : Please keep your translations of the choices # below a 65 columns limit (which means 65 characters # in single-byte languages) including the initial path # :sl5: -__Choices: ctc: Channel to Channel (CTC) or ESCON connection, qeth: OSA-Express in QDIO mode / HiperSockets, iucv: Inter-User Communication Vehicle - available for VM guests only, virtio: KVM VirtIO +__Choices: ctc: Channel to Channel (CTC) or ESCON connection, qeth: OSA-Express in QDIO mode / HiperSockets, iucv: Inter-User Communication Vehicle - available for VM guests only, other: other interface types like PCI or virtio # :sl5: _Description: Network device type: Please choose the type of your primary network interface that you will need for installing the Debian system (via NFS or HTTP). Only - the listed devices are supported. + the listed devices are supported. If you chose "other", the interface + must not require additional configuration (i.e., it is configured + by a different installer module). Template: s390-netdevice/ctc/choose_read Type: select diff --git a/netdevice.c b/netdevice.c index c886170..64ec72e 100644 --- a/netdevice.c +++ b/netdevice.c @@ -97,7 +97,7 @@ enum TYPE_CTC, TYPE_IUCV, TYPE_QETH, - TYPE_VIRTIO, + TYPE_OTHER, } type = TYPE_NONE; @@ -308,8 +308,8 @@ static enum state_wanted get_networktype (void) type = TYPE_CTC; else if (!strncmp (ptr, "iucv", 4)) type = TYPE_IUCV; - else if (!strncmp (ptr, "virtio", 6)) - type = TYPE_VIRTIO; + else if (!strncmp (ptr, "other", 5)) + type = TYPE_OTHER; else return WANT_ERROR; @@ -884,7 +884,7 @@ int main (int argc __attribute__ ((unused)), char *argv[] __attribute__ ((unused case TYPE_IUCV: state = GET_IUCV_DEVICE; break; - case TYPE_VIRTIO: + case TYPE_OTHER: // no further configuration needed state = FINISH; break; -- 1.9.1
Bug#685134: [s390-tools] please add patch from qemu
On 02.02.2016 01:01, Dimitri John Ledkov wrote: > On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES > <roucaries.bast...@gmail.com> wrote: >> Package: s390-tools >> Severity: important >> Tags: patch >> >> Please add http://repo.or.cz/w/s390-tools.git for booting s390 from qemu. it >> port virtio. >> >> I have ported the pach queue to recent s390-tools. Not tested only merge >> without conflict. >> >> Thanks >> >> Bastien > > Hello, > > Is this still required? I see that qemu-2.5 has support for booting El > Torito .iso images, and it boots Debian off virtio block drives just > fine. > > Granted, it looks like debian packaging strips the s390 firmware file, > and doesn't rebuild it. Maybe that should simply be fixed and that's > it? > > Regards, > > Dimitri. > Right, including the firmware file would be the proper way to enable QEMU for booting on s390. -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Bug#815916: Failure to create empty partition table on s390 DASD
Package: partman-partitioning
Version: 111
Severity: important
Tags: d-i patch
X-Debbugs-CC: debian-s390@lists.debian.org, brueck...@linux.vnet.ibm.com
Dear Maintainer,
when I try to create an empty partition table on a DASD, the
partitioning code instructs parted to write an msdos label instead of a
dasd label to the disk. This is effectively destroying the volume
metadata rendering the disk unusable. The disk can only be recovered by
low level formatting.
This is caused by the default label determination logic in
partman-partitioning/lib/disk-label.sh which only uses the architecture
to decide which default label to use.
We can't switch that unconditionally to dasd, because we would break
SCSI (and most of virtio) partitioning.
The suggested patches make sure the disk type is respected and the
appropriate label type is used:
Patch 1 is for d-i/partman-base and stores the disk label type in
/var/lib/partman/devices//label, which will be dasd for natively
attached DASDs as well as virtio attached DASDs in KVM.
Patch 2 is a change in d-i/partman-partitioning and uses the stored
label type to determine the proper partition table format (only when
executing on s390).
Thanks for your consideration.
--
Kind Regards
Viktor Mihajlovski
>From 6d71c4fb3eb679a5df4e1aa3028f0e6d6ec5df19 Mon Sep 17 00:00:00 2001
From: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
Date: Tue, 23 Feb 2016 15:23:21 +0100
Subject: [PATCH] parted_devices: Add disk label type to device directory
At least for s390 the default disk label type is device
dependent. We record the current disk label type in the
/var/lib/partman/devices/ for later retrieval.
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
init.d/parted| 2 ++
parted_devices.c | 7 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/init.d/parted b/init.d/parted
index 81cdafc..6f96b07 100755
--- a/init.d/parted
+++ b/init.d/parted
@@ -87,6 +87,7 @@ if [ ! -f /var/run/parted_server.pid ]; then
device=$1
size=$2
model=$3
+ label=$4
# Skip mtd (not supported by parted) and mmcblk odities
case "${device#/dev/}" in
@@ -130,6 +131,7 @@ if [ ! -f /var/run/parted_server.pid ]; then
printf "%s" "$device" >$dev/device
printf "%s" "$size" >$dev/size
printf "%s" "$model" >$dev/model
+ printf "%s" "$label" >$dev/label
# Set the sataraid flag for dmraid arrays.
if type dmraid >/dev/null 2>&1 && \
diff --git a/parted_devices.c b/parted_devices.c
index de15355..4fc64c7 100644
--- a/parted_devices.c
+++ b/parted_devices.c
@@ -76,6 +76,7 @@ is_floppy(const char *path)
void
process_device(PedDevice *dev)
{
+ PedDisk *disk;
if (dev->read_only)
return;
if (is_cdrom(dev->path) || is_floppy(dev->path))
@@ -84,10 +85,12 @@ process_device(PedDevice *dev)
if (strstr(dev->path, "/dev/ramzswap") != NULL ||
strstr(dev->path, "/dev/zram") != NULL)
return;
- printf("%s\t%lli\t%s\n",
+ disk = ped_disk_new(dev);
+ printf("%s\t%lli\t%s\t%s\n",
dev->path,
dev->length * dev->sector_size,
- dev->model);
+ dev->model,
+ disk->type->name ? disk->type->name : "unknown");
}
int
--
1.9.1
>From 38daa8b0d78607139aa66b225ae9c4ab04daf3be Mon Sep 17 00:00:00 2001
From: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
Date: Tue, 23 Feb 2016 15:33:45 +0100
Subject: [PATCH] create_new_label: Use correct label for DASDs
Requires an updated partman-base. In case a disk is indentified
as DASD, make sure that the default disk label is "dasd".
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
lib/disk-label.sh | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/disk-label.sh b/lib/disk-label.sh
index b24f4a8..167f3c3 100644
--- a/lib/disk-label.sh
+++ b/lib/disk-label.sh
@@ -118,7 +118,13 @@ default_disk_label () {
ppc64el)
echo gpt;;
s390|s390x)
- echo msdos;;
+ if [ -e ./label ]; then
+ disklabel=$(cat label)
+ fi
+ if [ "$disklabel" != dasd ]; then
+ disklabel=msdos
+ fi
+ echo $disklabel;;
sh4)
echo msdos;;
sparc|sparc64)
--
1.9.1
Re: Debian install using LVM
On 12.04.2016 01:11, Dimitri John Ledkov wrote: > Hello, > > On 12 April 2016 at 00:00, Martha McConaghy <u...@vm.marist.edu> wrote: >> I've been fighting with a Debian install all day and wonder if anyone else >> has run into the same problem. I wanted to use LVM for the root filesystem, >> so created a /boot partition and an LVM for the rest. Everything works fine >> until it comes to the step where it tries to write out ZIPL. That step >> fails. >> I tried all sorts of combinations, but the only that actually works is >> creating 1 partition for / with no LVM at all. Something is not right. >> >> The timestamp on the install files I'm using is April 2, so they are pretty >> new. The level of Debian is jessie. >> > > I recommend to try testing aka stretch. There were LVM fixes uploaded > there. As usual do attach /var/log/syslog from the d-i to help > debugging what's going wrong. That is exactly the point, Debian Jessie's installer only accepts the root device on a DASD partition. With Stretch, root can be anywhere including LVM volumes. > > Note there is also Debian specific mailing debian-s390: > https://lists.debian.org/debian-s390/ > > Regards, > > Dimitri. > [...] -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: Debian install using LVM
On 16.04.2016 09:19, Philipp Kern wrote: > On 2016-04-12 23:32, Viktor Mihajlovski wrote: >> The LVM on DASD issue should be resolved by bumping the release level of >> zipl-installer to either 0.0.28 or 0.0.32 (preferable) in the next point >> release. Since this addresses an installability problem, I would hope >> that such an update would be acceptable. > > I'll need to look at the diff, but it'd be helpful to have a > confirmation that this is all that's needed. (E.g. by rebuilding > jessie's d-i with just this one udeb built for jessie.) > > Kind regards and thanks > Philipp Kern > Well, I had encouraging but mixed results: with the zipl-installer_0.0.32 udeb the boot setup was completed correctly. However, the system still didn't get up because the DASD(s) holding the root LV were not set online in the initramfs because the sysconfig-hardware in Jessie lacks the initramfs hooks (you wrote that in your blog back in October but I forgot that...). Enabling the DASD in the emergency shell and activating the volume group led to successful completion of the system boot. That means it will be necessary to also update the sysconfig-hardware package (e.g. to 0.0.10+nmu4)). I lack the skills to tweak my Jessie mirror to upgrade the package there, so there's a still some residual risk. -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: Debian install using LVM
On 16.04.2016 09:19, Philipp Kern wrote: > On 2016-04-12 23:32, Viktor Mihajlovski wrote: >> The LVM on DASD issue should be resolved by bumping the release level of >> zipl-installer to either 0.0.28 or 0.0.32 (preferable) in the next point >> release. Since this addresses an installability problem, I would hope >> that such an update would be acceptable. > > I'll need to look at the diff, but it'd be helpful to have a > confirmation that this is all that's needed. (E.g. by rebuilding > jessie's d-i with just this one udeb built for jessie.) > > Kind regards and thanks > Philipp Kern > True, there could be more than that. I'll take a stab at it and post my results... -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Bug#856559: predictable interface name broken for virtio-ccw
Source: systemd Version: 232 Severity: normal Tags: upstream patch X-Debbugs-CC: debian-s390@lists.debian.org Dear Maintainer, in Linux running as a KVM guest on a s390 system, virtio interfaces are named eth instead of enc as expected for ccw devices. The upstream commit at [1] fixes this by applying the ccw name generation on virtio-ccw interfaces. [1] https://github.com/systemd/systemd/commit/ecc11cf70cf5c6eb18f431e9d29d4823fa0c2ed8 Thanks!
Bug#856558: udev-generated /dev/disk/by-path names broken for virtio disks
Source: systemd Version: 232 Severity: normal Tags: upstream patch X-Debbugs-CC: debian-s390@lists.debian.org Dear Maintainer, in Linux running as a KVM guest, virtio disks show up in the following format in the /dev/disk/by-path directory: virtio-pci- (on x86, s390 and armv7l) This format implies that the device is a virtio-pci device, however this is only true for x86. On s390 it's virtio-ccw and on arm it's typically virtio-mmio. The upstream commit at [1] fixes this by generating a uniform path id in the format - This will typically be something like pci-:00:00:7.0 (for x86) ccw-0.0.1234 (for s390) platform-a003e00.virtio_mmio (for arm) On x86 additional symlinks are created for backward compatibility, i.e. virtio-pci-:00:00:7.0 This patch is only needed for systemd 229 or higher. [1] https://github.com/systemd/systemd/commit/fb92fbb1b171ef94207a1ebc111ef0e414d49b4 Thanks!
Re: OSA and bridge_role=primary on boot
On 26.04.2017 08:15, Benjamin Jakob Zimmermann wrote:
> Ok,
> thank you for pointing me into the right direction.
>
> The working solution is the following entry in /etc/network/interfaces:
> [...]
> allow-ovs br0
> iface br0 inet manual
>
> allow-ovs [ccwdev0-encif]
> iface [ccwdev0-encif]
> pre-up znetconf -a [ccwdev0] -o layer2=1 -o bridge_role=primary
> [...]
>
> This way both interfaces come up as soon as I am starting open vswitch
> ('systemctl start openvswitch-switch').
>
> I did not manage to set bridge_role in the post-up, since it is already
> online at that point of time.
> I had also no success with changes in /etc/sysconfig/scripts/
> hardware/hwup-ccw-group.
>
> Do you know if 'chzdev' will be in future s390-tools in stretch?
>
[...]
Well, it's contained in the upstream source package, so it would just be
a matter of including the binaries lszdev and chzdev (plus the man pages).
The other thing is that one has to get rid of the old-style config
files, e.g. by not installing them in the first place, which what Ubuntu
did.
It might be nice if the Ubuntu changes to s390-tools and
d-i/sysconfig-writer could be backported to Debian (Dimitri?).
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: OSA and bridge_role=primary on boot
On 25.04.2017 13:44, Benjamin Jakob Zimmermann wrote: > Hello, > I am using debian stretch and I am trying to have openvswitch to work right > after rebooting the machine. > > So far, I manually configure the card with znetconf and then start > openvswitch and then manually bring up the interfaces. > > To visualize my approach, I list the commands (bridge and port had already > been added to ovs beforehand): > # znetconf -a [ccwdev0] -o layer2=1 -o bridge_role=primary > # systemctl start openvswitch-switch > # ip l s [ccwdev0] up > # ip l s br0 up > > Everything works out fine, I can now live migrate vm's via virsh. > > What options do I have to add to > /etc/sysconfig/hardware/config-ccw-0.0.[ccwdev0] to set the bridge_role > when the interface is brought up? > > Best, > Benjamin. > Hi, I fear there's no out-of-the box support for the bridge_role property in sysconfig-hardware. As a temporary circumvention you could apply the following change in /etc/sysconfig/scripts/hardware/hwup-ccw-group: 1. locate the line containing write_setting "portno" "$QETH_PORTNO' 2. insert the following line write_setting "bridge_role" "$QETH_BRIDGE_ROLE' Then you can add QETH_BRIDGE_ROLE=primary to the config file. Needless to say that this will not survive a package update. You might be better served by setting the property in a post-up command for the interface. I am not really sure whether it makes sense to add more properties to the sysconfig handling because in the long run persistent CCW device configurations should be done using chzdev, see https://www.ibm.com/developerworks/linux/linux390/s390-tools-1.33.0.html#newtools On the other hand, this will probably not happen for stretch :-(. -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Bug#873714: virt-install --location fails for s390x guests
Package: virt-manager
Version: 1:1.4.0-5
Tags: patch, stretch, d-i
X-Debbugs-CC: debian-s390@lists.debian.org
Dear Maintainer,
when I try to install a s390x KVM guest using the following command
virt-install --name testing --ram 1024 --disk
/var/lib/libvirt/images/testing.qcow2,bus=virtio --location
http://ftp.de.debian.org/debian/dists/testing/main/installer-s390x
I get the following error message:
==
ERRORError validating install location: Could not find an
installable distribution at
'http://ftp.de.debian.org/debian/dists/testing/main/installer-s390x'
The location must be the root directory of an install tree.
See virt-install man page for various distro examples
===
even though the location URL is correct. This is because the install
files location differs from i386/amd64. The attached patch - also
available upstream - will fix this (for Debian and Ubuntu).
--
Kind Regards
Viktor Mihajlovski
--- a/virtinst/urlfetcher.py
+++ b/virtinst/urlfetcher.py
@@ -1106,6 +1106,12 @@
kernel_basename = "linux"
if self._treeArch in ["ppc64el"]:
kernel_basename = "vmlinux"
+
+if self._treeArch == "s390x":
+hvmroot = "%s/generic/" % self._url_prefix
+kernel_basename = "kernel.%s" % self.name.lower()
+initrd_basename = "initrd.%s" % self.name.lower()
+
self._hvm_kernel_paths = [
(hvmroot + kernel_basename, hvmroot + initrd_basename)]
@@ -1124,7 +1130,11 @@
return False
filename = "%s/MANIFEST" % self._url_prefix
-regex = ".*%s.*" % self._installer_dirname
+if self.arch == "s390x":
+regex = ".*generic/kernel\.%s.*" % self.name.lower()
+else:
+regex = ".*%s.*" % self._installer_dirname
+
if not self._fetchAndMatchRegex(filename, regex):
logging.debug("Regex didn't match, not a %s distro", self.name)
return False
@@ -1173,7 +1183,10 @@
if self.fetcher.hasFile("%s/MANIFEST" % self._url_prefix):
# For regular trees
filename = "%s/MANIFEST" % self._url_prefix
-regex = ".*%s.*" % self._installer_dirname
+if self.arch == "s390x":
+regex = ".*generic/kernel\.%s.*" % self.name.lower()
+else:
+regex = ".*%s.*" % self._installer_dirname
elif self.fetcher.hasFile("install/netboot/version.info"):
# For trees based on ISO's
self._url_prefix = "install"
Re: qemu install
On 5/17/20 8:57 PM, Valentin Vidić wrote: Hi, I'm trying to install a s390x VM using qemu: $ qemu-system-s390x -machine s390-ccw-virtio -nographic \ --cdrom debian-10.4.0-s390x-netinst.iso \ -kernel boot/linux_vm -initrd boot/root.bin -append init=/bin/sh but it doesn't seem to work - there is no network, cdrom or disk. Should this work or is this usecase not supported? I'd recommend to try virt-install, see http://kvmonz.blogspot.com/p/knowledge-use-virt-install-for-kvm.html. virt-install will set up the VM in a proper way. You will need to invoke virt-install with --arch=s390x if your running on an x86 box and make sure you have the qemu-system-s390x package installed. Chance for success will probably increase with the currency of the QEMU used. The invocation you've reported above doesn't instantiate a virtio disk and network interface (which are the only device types supported for s390x. Similary virtual CD/DVD must be on virtio-scsi for s390x. Again, virt-install and virsh are your friends here. -- Kind Regards, Viktor
Re: qemu install
On 5/18/20 8:00 PM, Valentin Vidić wrote: On Mon, May 18, 2020 at 07:31:15PM +0200, Benjamin Jakob Zimmermann wrote: $ qemu-system-s390x -M s390-ccw-virtio -m 1G -smp 1 -enable-kvm -nographic -device virtio-net-ccw,netdev=mynet0 -netdev tap,id=mynet0,script=qemu-ifup -drive file=/dev/disk/by-path/ccw-0.0. -kernel loopdir/boot/linux_vm -initrd loopdir/boot/root.bin -append 'debian-installer/allow_unauthenticated=true' This works on a z13 and z14. Works also fine with clefOS (CentOS clone). Thanks for the info. Indeed it seems that things work with the stretch image so I will try to use that. But can we also try to fix buster and unstable images as these seem to be broken at the moment? I have identified the following problems: 1. debian-installer fails to start on serial port due to wrong device name (ttyS1 vs ttysclp0). I can boot with init=/bin/sh and make a symlink but a patch is here: https://salsa.debian.org/installer-team/rootskel/-/merge_requests/2/diffs 2. initrd does not include the required modules (virtio_net and virtio_blk) so network and disk devices are not visible. Had to build a new initrd with these included. I glanced over the d-i config and udebs. It seems that with buster the virtio-modules udeb was removed under the assumption that the virtio modules are to be found in nic-modules and scsi-modules. Unfortunately, those don't include the virtio modules for s390x. Would you care to open a defect against d-i? 3. installation starts but at some point debootstrap fails with May 17 20:12:05 debootstrap: dpkg: error processing package s390-tools (--configure): May 17 20:12:05 debootstrap: dependency problems - leaving unconfigured May 17 20:12:06 debootstrap: Errors were encountered while processing: May 17 20:12:06 debootstrap: s390-tools May 17 20:12:07 debootstrap: dpkg: dependency problems prevent configuration of s390-tools: May 17 20:12:07 debootstrap: s390-tools depends on perl:any. So probably s390-tools package needs to be updated? -- Kind Regards, Viktor
Re: qemu install
On 5/18/20 8:00 PM, Valentin Vidić wrote: On Mon, May 18, 2020 at 07:31:15PM +0200, Benjamin Jakob Zimmermann wrote: $ qemu-system-s390x -M s390-ccw-virtio -m 1G -smp 1 -enable-kvm -nographic -device virtio-net-ccw,netdev=mynet0 -netdev tap,id=mynet0,script=qemu-ifup -drive file=/dev/disk/by-path/ccw-0.0. -kernel loopdir/boot/linux_vm -initrd loopdir/boot/root.bin -append 'debian-installer/allow_unauthenticated=true' This works on a z13 and z14. Works also fine with clefOS (CentOS clone). Thanks for the info. Indeed it seems that things work with the stretch image so I will try to use that. But can we also try to fix buster and unstable images as these seem to be broken at the moment? I have identified the following problems: 1. debian-installer fails to start on serial port due to wrong device name (ttyS1 vs ttysclp0). I can boot with init=/bin/sh and make a symlink but a patch is here: https://salsa.debian.org/installer-team/rootskel/-/merge_requests/2/diffs 2. initrd does not include the required modules (virtio_net and virtio_blk) so network and disk devices are not visible. Had to build a new initrd with these included. 3. installation starts but at some point debootstrap fails with May 17 20:12:05 debootstrap: dpkg: error processing package s390-tools (--configure): May 17 20:12:05 debootstrap: dependency problems - leaving unconfigured May 17 20:12:06 debootstrap: Errors were encountered while processing: May 17 20:12:06 debootstrap: s390-tools May 17 20:12:07 debootstrap: dpkg: dependency problems prevent configuration of s390-tools: May 17 20:12:07 debootstrap: s390-tools depends on perl:any. So probably s390-tools package needs to be updated? I tried to install under z/VM with the same debootstrap failure. It seems that it would be necessary to add perl to the list of bootstrap packages in order to satisfy the s390-tools depends. -- Kind Regards, Viktor
Re: qemu install
On 5/19/20 5:02 PM, Valentin Vidić wrote: On Tue, May 19, 2020 at 04:18:06PM +0200, Viktor Mihajlovski wrote: I tried to install under z/VM with the same debootstrap failure. It seems that it would be necessary to add perl to the list of bootstrap packages in order to satisfy the s390-tools depends. Yes, not sure what is the problem there, perhaps s390-tools needs to use perl-base instead? FWIW, lscpumf and chcpumf use the Data::Dumper package which require the full perl setup. Perhaps it would make sense to split s390-tools into a basic package containing the tools needed for device setup and an extension package with all the additional stuff. That would be up to the maintainer. -- Kind Regards, Viktor
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On 6/2/20 5:17 AM, Rod Gaiotto wrote: Hello folks, I'm attempting to install a Debian 10.4.0-s390x in a z/VM system under a zEC12 CEC - 2827 I've set 1 CPs + 1 GB of memory and a 4 cyls DASD (30 Gbs ~). The installation crashes during the OS base installation step. Follow the logs: Jun 2 02:55:59 debootstrap: Processing triggers for systemd (241-7~deb10u4) ... Jun 2 02:55:59 debootstrap: Errors were encountered while processing: Jun 2 02:55:59 debootstrap: s390-tools Jun 2 02:56:00 debootstrap: dpkg: dependency problems prevent configuration of s390-tools: Jun 2 02:56:00 debootstrap: s390-tools depends on perl:any. Jun 2 02:56:00 debootstrap: Jun 2 02:56:00 debootstrap: dpkg: error processing package s390-tools (--configure): Jun 2 02:56:00 debootstrap: dependency problems - leaving unconfigured Jun 2 02:56:00 debootstrap: Errors were encountered while processing: Jun 2 02:56:00 debootstrap: s390-tools Jun 2 02:56:01 debootstrap: dpkg: dependency problems prevent configuration of s390-tools: Jun 2 02:56:01 debootstrap: s390-tools depends on perl:any. Jun 2 02:56:01 debootstrap: Jun 2 02:56:01 debootstrap: dpkg: error processing package s390-tools (--configure): Jun 2 02:56:01 debootstrap: dependency problems - leaving unconfigured Jun 2 02:56:01 debootstrap: Errors were encountered while processing: Jun 2 02:56:01 debootstrap: s390-tools Jun 2 02:56:02 debootstrap: dpkg: dependency problems prevent configuration of s390-tools: Jun 2 02:56:02 debootstrap: s390-tools depends on perl:any. Jun 2 02:56:02 debootstrap: Jun 2 02:56:02 debootstrap: dpkg: error processing package s390-tools (--configure): Jun 2 02:56:02 debootstrap: dependency problems - leaving unconfigured Jun 2 02:56:02 debootstrap: Errors were encountered while processing: Jun 2 02:56:02 debootstrap: s390-tools Jun 2 02:56:03 debootstrap: dpkg: dependency problems prevent configuration of s390-tools: Jun 2 02:56:03 debootstrap: s390-tools depends on perl:any. Jun 2 02:56:03 debootstrap: Jun 2 02:56:03 debootstrap: dpkg: error processing package s390-tools (--configure): Jun 2 02:56:03 debootstrap: dependency problems - leaving unconfigured Jun 2 02:56:03 debootstrap: Errors were encountered while processing: Jun 2 02:56:03 debootstrap: s390-tools Jun 2 02:56:18 base-installer: error: exiting on error base-installer/debootstrap-failed Jun 2 02:56:20 main-menu[296]: WARNING **: Configuring 'bootstrap-base' failed with error code 1 Jun 2 02:56:20 main-menu[296]: WARNING **: Menu item 'bootstrap-base' failed. Jun 2 02:56:25 main-menu[296]: INFO: Modifying debconf priority limit from 'high' to 'medium' Jun 2 02:56:25 debconf: Setting debconf/priority to medium Jun 2 02:56:29 main-menu[296]: INFO: Menu item 'save-logs' selected Does anybody got the same error? Yes, see https://lists.debian.org/debian-s390/2020/05/msg7.html Thanks -- Rodrigo Gaiotto Systems & Software Engineer 19-99169-8485 -- Kind Regards, Viktor
