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
Bug#873714: s/virt-manager/virtinst/
Package: virtinst Source: virt-manager Sorry, I've just realized that I've specified the wrong binary package (virt-manager is the source package). -- Kind Regards Viktor Mihajlovski
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-s...@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"
Bug#856559: predictable interface name broken for virtio-ccw
On 05.03.2017 14:47, Martin Pitt wrote: > Control: notfound -1 233-1 > Control: tag -1 pending > > Viktor Mihajlovski [2017-03-02 13:52 +0100]: >> 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 patch is fairly intrusive, but as this only affects s390x, unstable names > for network interfaces are awkwar, and this also avoids upgrading trouble from > Stretch to Buster I agree this should be backported. Committed to stretch > branch. Hi Martin, this will make current and future life much easier (same is true for the virtio disk path ids). Big thanks! > > Thanks, > > Martin > -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski
Bug#856559: predictable interface name broken for virtio-ccw
Source: systemd Version: 232 Severity: normal Tags: upstream patch X-Debbugs-CC: debian-s...@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-s...@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!
Bug#825931: s390-netdevice virtio interface choice misleading
On 26.10.2016 22:53, Philipp Kern wrote: > On 10/26/2016 05:13 PM, Dimitri John Ledkov wrote: >> Currently s390-netdevice in the code supports following >> networktypes: * qeth * ctc * iucv * virtio >> >> virtio is, in fact, a no-op. > > Yup. > >> iucv refers to "IUCV network device" which has been deprecated >> at least since October 2005 (linux v2.6+) > > I guess IUCV is only deprecated for networking, not for console > access, right? I would not mind dropping it then. > >> ctc refers to channel-to-channel devices which has also been >> deprecated at least since October 2005 (linux v2.6+) > > CTC is used by default by Hercules. I suppose it can also do qeth > now? Or maybe that's just in a fork? Last I checked it still > worked, as well. > >> The migration path from above to is onto Hipersockets or QDIO. >> Both migration paths are handled on the linux side by the qeth >> kernel module as fas as I understand. >> >> Hence, the only option of the 4 that may do anything is qeth, if >> there are any qeth devices detected that need activation. >> >> Furthermore, I'm not sure if iucv network device works correctly >> - confirm_iucv function returns WANT_ERROR, unless after >> activating iucv one must continue with the ctc code path. >> >> Imho, we should simply skip the whole d-i module if there are no >> qeth devices to activate. If there are any qeth devices to >> activate, display multi select question of the qeth devices to >> activate. Multi-select question, such that continue without >> selecting any is a valid option (for example if one wants to >> install using the PCIe interfaces). > > I very much sympathize with this idea in general. If we can also > detect if CTC devices are on the bus, only showing the prompt if > devices can be found would be useful. Did the kernel start off not > offering all devices in sysfs because LPARs can have a huge amount > of them? Or did it always rely on blacklisting in this case? I > suppose that the original reason was that you actually had to enter > device numbers because it couldn't probe, but then on the other > hand the selection for qeth was shown for a long time now. Whether (and which) CCW devices are probed and exposed via sysfs is controlled by the cio_ignore kernel parameter, actually black and white listing at the same time. And the reason to add this was that LPARs can have really many devices. The last time I looked the installer modules were not equipped to deal with cio_ignore and the installer image didn't utilize the cio_ignore parameter, so a Debian installer will see all CCW devices. > > Kind regards and thanks Philipp Kern > -- 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: Followup
On 24.10.2016 00:41, Philipp Kern wrote: [...] >> >> [1] >> http://changelogs.ubuntu.com/changelogs/pool/main/p/partman-base/partman-base_187ubuntu2/changelog >> >> [2] >> http://changelogs.ubuntu.com/changelogs/pool/main/p/partman-partitioning/partman-partitioning_110ubuntu4/changelog > >> > I pushed the first one (together with another fix for extended > partitions) to git now. As we're currently in the process of > cutting another debian-installer release, I'll wait with the upload > and then push the fix to partman-partitioning after the new > partman-base is in the archive. > > Kind regards and thanks Philipp Kern > Thanks, I'll verify once the new package versions show up. -- 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: Followup
Dear Maintainer(s), the patches have been incorporated in Ubuntu's d-i since their 16.04 release ([1],[2]) and I would hope that thereby they have gotten sufficient test coverage in the meantime. I haven't heard of breakages for other architectures and they have positively fixed the issues for s390. Based on this I'd like to propose that the patches be applied to the respective Debian upstream packages. Thanks for your consideration. [1] http://changelogs.ubuntu.com/changelogs/pool/main/p/partman-base/partman-base_187ubuntu2/changelog [2] http://changelogs.ubuntu.com/changelogs/pool/main/p/partman-partitioning/partman-partitioning_110ubuntu4/changelog -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski
Bug#825931: s390-netdevice virtio interface choice misleading
On 19.06.2016 13:34, Philipp Kern wrote: > Is such a thing even possible? > > If not could we simply skip that prompt if we see a regular one because then > we > know it's VirtIO/PCI/other? > > Kind regards and thanks > Philipp Kern > we can definitely have the situation that both an channel and a PCI ethernet interface are present ... but one could consider to make channel device configuration for all of DASD, network and FCP optional if no corresponding cu types are detected. In this case one could drop the "other" option unconditionally indeed. -- 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#825931: s390-netdevice virtio interface choice misleading
Package: s390-netdevice Version: 0.0.44 Severity: normal Tags: d-i patch X-Debbugs-CC: debian-s...@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#815916: patch update
On 27.02.2016 15:56, Philipp Kern wrote:
> On Fri, Feb 26, 2016 at 01:16:23PM +0100, Viktor Mihajlovski wrote:
>> the first patch to partman-base introduced a regression in the case of
>> pristine disks because it didn't check for ped_disk_new() failure.
>> Please use the new patch here instead.
>
> I think you attached the old patch again, could that be?
>
> % diff /tmp/0001-parted_devices-Add-disk-label-type-to-device-directo.patch-*
> 4c4
> < Subject: [PATCH] parted_devices: Add disk label type to device directory
> ---
>> Subject: [PATCHv2] parted_devices: Add disk label type to device directory
>
> Kind regards and thanks
> Philipp Kern
>
Quite obviously, thanks for checking.
As the saying goes, third time's a charm, so here we are:
--
Kind Regards
Viktor Mihajlovski
>From 88320f8a3d5875c04fe8e55275de6cfc6fb54f40 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: [PATCHv3] 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 | 8 ++--
2 files changed, 8 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..197698e 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,13 @@ 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 && disk->type && disk->type->name ?
+ disk->type->name : "unknown");
}
int
--
1.9.1
Bug#815916: patch update
the first patch to partman-base introduced a regression in the case of
pristine disks because it didn't check for ped_disk_new() failure.
Please use the new patch here instead.
--
Mit freundlichen Grüßen/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: [PATCHv2] 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
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-s...@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
Bug#814076: Patch committed upstream
The upstream project has accepted the suggested patch. Please consider to cherry-pick 8c6de55e4375bd63ae0d0dc7dd7104a7c2290cac to resolve the issue in Debian. Thanks!
Bug#814076: parted crashes on lvm, on a dasd drive
Source: parted
Version: 3.2
Severity: normal
Tags: patch upstream
Dear Maintainer,
Running parted print against a logical volume
residing on a DASD will result in a core dump, caused by divide by zero.
See also https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1541510
and
http://lists.alioth.debian.org/pipermail/parted-devel/2016-February/004790.html.
The attached patch provides a solution for the problem.
Thanks!
>From c351c57bb440d7b56830832a255b62d89804ea3d Mon Sep 17 00:00:00 2001
From: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
Date: Thu, 4 Feb 2016 16:47:21 +0100
Subject: [PATCH] fdasd.c: Safeguard against geometry misprobing
Fixes an issue with parted print being run against a logical
volume realised by extents on a physical volume residing on
a DASD.
We must make sure that geometry, device blocksize and DASD
attributes are present before we start format verifications
If any of it is missing this is not a DASD.
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
libparted/labels/fdasd.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libparted/labels/fdasd.c b/libparted/labels/fdasd.c
index 7e6a77a..968b332 100644
--- a/libparted/labels/fdasd.c
+++ b/libparted/labels/fdasd.c
@@ -1021,13 +1021,20 @@ fdasd_get_geometry (const PedDevice *dev, fdasd_anchor_t *anc, int f)
goto error;
}
- if (ioctl(f, HDIO_GETGEO, >geo) != 0)
+ if (ioctl(f, HDIO_GETGEO, >geo) != 0 ||
+ anc->geo.heads == 0 ||
+ anc->geo.sectors == 0 ||
+ anc->geo.cylinders == 0 ) {
fdasd_error(anc, unable_to_ioctl,
_("Could not retrieve disk geometry information."));
+ goto error;
+ }
- if (ioctl(f, BLKSSZGET, ) != 0)
+ if (ioctl(f, BLKSSZGET, ) != 0) {
fdasd_error(anc, unable_to_ioctl,
_("Could not retrieve blocksize information."));
+ goto error;
+ }
/* get disk type */
if (ioctl(f, BIODASDINFO, _info) != 0) {
--
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#806341: closed by Philipp Kern <pk...@debian.org> (Bug#806341: fixed in zipl-installer 0.0.29)
On 06.01.2016 11:36, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the zipl-installer package:
>
> #806341: zipl-installer: Using standard device names can result in a
> non-bootable system
>
> It has been closed by Philipp Kern <pk...@debian.org>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Philipp Kern
> <pk...@debian.org> by
> replying to this email.
>
>
Unfortunately, there was a syntax error in the script, as Hendrik found
out. The following patch fixes it. Sorry for the extra loop.
commit f3fb779f532d8d092c10e1e7b6d99a0b4d818549
Author: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Thu Jan 14 12:21:47 2016 +0100
postinst: correct if syntax
Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
diff --git a/debian/zipl-installer.postinst b/debian/zipl-installer.postinst
index 4e4d1ee..8fa251b 100755
--- a/debian/zipl-installer.postinst
+++ b/debian/zipl-installer.postinst
@@ -23,6 +23,7 @@ if rootlvm="$(lvm lvdisplay -C -ovg_name,lv_name
--noheadings ${rootfs})"
then
info "Root filesystem is on LV (${rootlvm})"
elif rootuuid="$(block-attr --uuid ${rootfs})"
+then
info "Root filesystem UUID is ${rootuuid}"
PARAMETER="root=UUID=${rootuuid}"
fi
--
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#808041: s390-zfcp: Install Debian on FC-attached SCSI devices on s390
On Fri, 18 Dec 2015 23:59:21 +0100 Philipp Kern <pk...@debian.org> wrote: ... > > Is there a way I could test FCP installation? As far as I understand > there is no emulation of a zFCP-like setup anywhere right, and you'd > need to have access to a zFCP controller? > > (Which are harder to partition/segment than DASD-based storageâ¦) ... Thanks for pushing the patches! I don't know of FCP emulation either. To test the module, you would indeed have to have a zFCP HBA defined plus the necessary storage network setup (with zoning/LUN masking) configured. As I already have tested Hendrik's original patchset, building off of the d-i repository will probably not lead to new insights. I could however offer to re-run tests once a udeb is built for s390-fcp. If I can provide additional info (logs of an install, screenshots, ...), I'd be more than happy to do so. -- 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#806341: zipl-installer: Using standard device names can result in a non-bootable system
Package: zipl-installer
Version: 0.0.28
Severity: normal
Tags: d-i patch
Dear Maintainer,
Currently, the root= statement used by zipl will contain a standard device
name like /dev/dasda1.
This will only work reliable if only one disk device is used while booting.
If more than one disk device is discovered the name of the device used by
the root filesystem might change resulting in a not found root filesystem.
I suggest to use the filesystem UUID of the root filesystem where possible,
similar to what's used in /etc/fstab.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.2.0-1-s390x (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From a29dbc2bc4548b39c1dc340bf2c02f70724b72a1 Mon Sep 17 00:00:00 2001
From: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
Date: Thu, 26 Nov 2015 17:45:51 +0100
Subject: [PATCH] postinst: use UUID for root device parameter where possible
The approach to use a default device node like /dev/dasdn for
the root= kernel parameter is unsafe if more than one disk
device is brought online during IPL as the device node identifier
could change.
A safer way is to construct the root= parameter to match the
/etc/fstab entry for the root fs.
Here we use block-attr --uuid to find out the root filesystem's
UUID and pass this via kernel parameter. If no UUID is found fall
back to the mapdevfs-determined device.
If the root file system is on a logical volume, it is currently not
possible to mount it by UUID in the initrd. Therefore fall back to
the device mapper path which is unique (enough).
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
debian/zipl-installer.postinst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/debian/zipl-installer.postinst b/debian/zipl-installer.postinst
index c70ab6f..c3b7f31 100755
--- a/debian/zipl-installer.postinst
+++ b/debian/zipl-installer.postinst
@@ -19,6 +19,13 @@ rootfs="$(mapdevfs $rootfs_devfs)"
log "Root filesystem on ${rootfs} (${rootfs_devfs})"
PARAMETER="root=${rootfs}"
+if rootlvm="$(lvm lvdisplay -C -ovg_name,lv_name --noheadings ${rootfs})"
+then
+info "Root filesystem is on LV (${rootlvm})"
+elif rootuuid="$(block-attr --uuid ${rootfs})"
+info "Root filesystem UUID is ${rootuuid}"
+PARAMETER="root=UUID=${rootuuid}"
+fi
cat > /target/etc/zipl.conf << EOF
[defaultboot]
--
1.9.1
Bug#803333: parted: cannot partition virtio attached DASD
Source: parted Version: 3.2 Severity: normal Dear Maintainer, parted doesn't currently allow to partition DASDs when running inside KVM on s390 machines. This is caused by outdated DASD handling code originating from the s390-tools fdasd tool. Upstream parted has recently been updated to allow to recognize and partition DASDs that are passed to a KVM guest as virtio block devices. It would be nice if you could cherry pick the following commits from upstream parted to resolve the issue. http://git.savannah.gnu.org/cgit/parted.git/commit/?id=4d480d980a9b69b432b8d60df3c4397ba8cdc965 http://git.savannah.gnu.org/cgit/parted.git/commit/?id=834713b5aee1edc004f863231dd489ee3a79f536 Thanks for your consideration.
