Bug#825931: s390-netdevice virtio interface choice misleading

[Hendrik Brueckner]

On Wed, Oct 26, 2016 at 10:53:36PM +0200, 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.

It is the IUCV network device (netiucv device driver) that is deprecated.
The HVC IUCV (console access), as well as, the AF_IUCV (socket-based IUCV
communication) is supported.

Bug#829562: s390-zfcp: fail to activate fcp devices for more than >100 fcp devices

[Hendrik Brueckner]

Control: tags -1 + patch
>From 0ae9d69941b34728c23a1b844fe3006ed7f7cd88 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Thu, 30 Jun 2016 12:45:19 +0200
Subject: [PATCH] zfcp-config: remove maximum number of FCP devices

Previously, the number of FCP devices was limited to 100 for selection.
In environments with numerous FCP devices, the installer could be limited
with cio_ignore to make the required FCP devices available only.

In case an installation requires more than 100 FCP devices, the
implementation is adjusted to allocate memory to contain the list
of all detected FCP devices.  The limiting factor will then become
the memory available in the installer environment.

Note that a similar change has been also added to the s390-dasd and
s390-netdevice installer modules.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Reviewed-by: Benjamin Block <bbl...@linux.vnet.ibm.com>
---
 debian/changelog |  7 +++
 zfcp-config.c| 53 +++--
 2 files changed, 46 insertions(+), 14 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 85ea1a3..fe612fa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+s390-zfcp (1.0.4) UNRELEASED; urgency=medium
+
+  * Improve displaying numereous detected FCP devices by replacing the
+hard-coded limit with a dynamically allocated solution (Closes: #829562)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Thu, 30 Jun 2016 
11:39:49 +0200
+
 s390-zfcp (1.0.3) unstable; urgency=medium
 
   * Drop useless debian/po directory. Closes: #817206, #821173
diff --git a/zfcp-config.c b/zfcp-config.c
index bed4a32..c0129dc 100644
--- a/zfcp-config.c
+++ b/zfcp-config.c
@@ -36,10 +36,18 @@
 #define PRESEED_DELIM  ","
 #define SCSI_ASYNC_TRIES   15
 #define SCSI_ASYNC_TIMEOUT 25/* useconds */
-#define MAX_HOST_LIST_ITEMS100
-#define MAX_HOST_LIST_SIZE (MAX_HOST_LIST_ITEMS * (9 + 20 +1))
+#define ZFCP_ENTRY_SIZE(9 + 20 + 1)
 #define MAX_LUN_LIST_SIZE  2048
 
+/* Memory buffer descriptor for an arbitrary number of
+ * detected FCP devices and their device information.
+ */
+struct dev_list
+{
+   char*buf;
+   size_t  size;
+};
+
 /* Definition of a zFCP host adapter */
 struct zfcp_host {
struct ccw_devid devid;   /* CCW device ID */
@@ -342,16 +350,16 @@ static cmdstatus_t debconf_show_error(struct 
debconfclient *client,
 static void build_zfcp_host_list(void *key __unused, void *value, void *data)
 {
struct zfcp_host *host = value;
-   char *buf = data;
+   struct dev_list *devlist = data;
 
-   if (buf[0])
-   strncat(buf, ",", MAX_HOST_LIST_SIZE);
-   strncat(buf, host->name, MAX_HOST_LIST_SIZE);
+   if (devlist->buf[0])
+   di_snprintfcat (devlist->buf, devlist->size, ", ");
+   di_snprintfcat(devlist->buf, devlist->size, host->name);
 
if (host->configured)
-   strncat(buf, " (configured)", MAX_HOST_LIST_SIZE);
+   di_snprintfcat (devlist->buf, devlist->size, " (configured)");
else if (host->online)
-   strncat(buf, " (not configured)", MAX_HOST_LIST_SIZE);
+   di_snprintfcat (devlist->buf, devlist->size, " (not 
configured)");
 }
 
 static void preseed_select_one(void *key, void *value, void *data)
@@ -413,18 +421,33 @@ static enum state_wanted select_zfcp_host(struct 
debconfclient *client,
  struct zfcp_host **zfcp_host)
 {
cmdstatus_t rc;
-   char hostlist[MAX_HOST_LIST_SIZE], *val, *delim;
+   char *val, *delim;
struct ccw_devid devid;
+   struct dev_list hostlist;
 
-   memset(, 0, sizeof(hostlist));
-   di_tree_foreach(zfcp_hosts, build_zfcp_host_list, hostlist);
+   /*
+* Allocate memory to store the detected FCP devices along
+* with their state information.
+*/
+   hostlist.size = ZFCP_ENTRY_SIZE * di_tree_size (zfcp_hosts);
+   hostlist.buf = di_malloc0 (hostlist.size);
+   if (hostlist.buf == NULL)
+   {
+   di_warning("Could not allocate memory for FCP device list\n");
+   return WANT_ERROR;
+   }
+   di_tree_foreach(zfcp_hosts, build_zfcp_host_list, );
 
-   debconf_subst(client, TEMPLATE_PREFIX "select_zfcp_host", "choices", 
hostlist);
+   debconf_subst(client, TEMPLATE_PREFIX "select_zfcp_host", "choices", 
hostlist.buf);
rc = debconf_result(client, "critical", TEMPLATE_PREFIX 
"select_zfcp_host", );
-   if (rc == CMD_GOBACK)
+   if (rc == CMD_GOBACK) {
+   di_free (hostlist.buf);
return WANT_BACKUP;
-   if (!strcmp(&

Bug#829562: s390-zfcp: fail to activate fcp devices for more than >100 fcp devices

[Hendrik Brueckner]

Package: s390-zfcp
Version: 1.0.3
Severity: normal
Tags: d-i

The s390-zfcp module has a hard-coded limit of about ~100 FCP devices
for installation.  If there are more than ~100 FCP devices, the module
fails and the user cannot activate any FCP device for installation.

The work around would be to limit the FCP devices to those that are
actually required for installation with the cio_ignore= kernel parameter.

I will attach a patch to correct the behavior to work with numerous
FCP devices (similar to those I have provided for s390-netdevice and
s390-dasd).

Thanks and kind regards,
  Hendrik

Bug#816600: [PATCH] Adjust regexpes to include all ipv4 and ipv6 addresses, list all ip addresses (sans loopback) in the template instructions, and use only the first ip address in the example command

[Hendrik Brueckner]

Hi Dimitri,

On Fri, Apr 01, 2016 at 12:47:00AM +0100, Dimitri John Ledkov wrote:
> ---
>  debian/changelog | 10 ++
>  debian/network-console.postinst  | 15 +--
>  debian/network-console.templates |  2 +-
>  3 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/debian/changelog b/debian/changelog
> index a518cd1..0521276 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,13 @@
> +network-console (1.54) UNRELEASED; urgency=medium
> +
> +  [ Dimitri John Ledkov ]
> +  * Adjust regexpes to include all ipv4 and ipv6 addresses, list all ip
> +addresses (sans loopback) in the template instructions, and use only
> +the first ip address in the example command. Closes: #816600 LP:
> +#1552368
> +
> + -- Dimitri John Ledkov   Fri, 01 Apr 2016 00:42:39 +0100
> +
>  network-console (1.53) unstable; urgency=medium
> 
>[ Colin Watson ]
> diff --git a/debian/network-console.postinst b/debian/network-console.postinst
> index f164446..090cb26 100755
> --- a/debian/network-console.postinst
> +++ b/debian/network-console.postinst
> @@ -85,22 +85,25 @@ apt-install openssh-server || true
> 
>  case "$(udpkg --print-os)" in
>   linux)
> - IPADDR=$(ip addr | grep '^[[:space:]]*inet ' | grep -v 
> "127\.0\." | \
> -  head -n 1 | sed 's/.*inet \([0-9.]*\).*/\1/')
> + IPADDRS=$(ip addr | grep '^[[:space:]]*inet6\? ' | grep -v -e 
> "127\.0\." -e "::1" | \
> +  sed 's/.*inet6\? \([a-f0-9.:]*\).*/\1/')
>   ;;
>   kfreebsd)
> - IPADDR=$(ifconfig| grep '^[[:space:]]*inet ' | grep -v 
> "127\.0\." | \
> -  head -n 1 | sed 's/.*inet \([0-9.]*\).*/\1/')
> + IPADDRS=$(ifconfig| grep '^[[:space:]]*inet6\? ' | grep -v -e 
> "127\.0\." -e "::1" | \
> +  sed 's/.*inet6\? \([a-f0-9.:]*\).*/\1/')
>   ;;
>   hurd)
> - IPADDR=$(fsysopts /servers/socket/2 | sed 's/.*--address=\([^ 
> ]*\).*/\1/')
> + IPADDRS=$(fsysopts /servers/socket/2 | sed 's/ /\n/g' | sed -n 
> 's/--address6\?=\([a-f0-9.:]*\).*/\1/p')
>   ;;
>   *)
> - IPADDR="TODO"
> + IPADDRS="TODO"
>   ;;
>  esac
> 
> +IPADDR=$(IFS=" " ; set -- $IPADDRS ; echo $1)
> +
>  db_subst $TEMPLATE_ROOT/start ip $IPADDR
> +db_subst $TEMPLATE_ROOT/start ips $IPADDRS
>  db_subst $TEMPLATE_ROOT/start fingerprint $KEY_FINGERPRINT
>  case "$ARCHDETECT" in
>  arm*/ixp4xx)
> diff --git a/debian/network-console.templates 
> b/debian/network-console.templates
> index 1c542ea..e55a653 100644
> --- a/debian/network-console.templates
> +++ b/debian/network-console.templates
> @@ -66,7 +66,7 @@ Type: note
>  #flag:translate!:3
>  _Description: Start SSH
>   To continue the installation, please use an SSH client to connect to the
> - IP address ${ip} and log in as the "installer" user. For example:
> + IP address ${ips} and log in as the "installer" user. For example:
>   .
>  ssh installer@${ip}
>   .
> -- 

Looks great.  Many thanks!

Kind regards,
  Hendrik

Bug#816600: postinst: IPv6 address is not displayed in 'Start SSH' invitation

[Hendrik Brueckner]

Control: severity -1 wishlist

On Thu, Mar 10, 2016 at 01:30:44AM +, Dimitri John Ledkov wrote:
> On Thu, Mar 3, 2016 at 11:12 AM, Hendrik Brueckner
> <brueck...@linux.vnet.ibm.com> wrote:
> > Package: network-console
> > Version: 1.53
> > Severity: normal
> > Tags: d-i patch
> >
> > Dear Maintainer,
> >
> > in IPv6-only environments, the "Start SSH" invitation does not include
> > the IPv6 address to log in to the installer system.  Below is a patch
> > that extends the postinst script to detect an IPv6 address if no IPv4
> > address could be found.
> >
> 
> To be honest, I don't think it's only about IPv6-only environments.
> A person performing the installation may only be on IPv6 link-local,
> IPv6 autoconfigure, IPv4, only, whilst the machine to be installed has
> dual-stack / all combos.
> Unusual, true, but totally possible.
> 
> Thus, I think, we should enumerate all IP addresses, sans loopback,
> and display them all.

It would make sense to display all possible IP addresses to connect to
the installer environment.  This change is not that simple because it
requires debconf template modifications to provide an enumerated list
of IP addresses.  Hence reducing the severity of this bug to address
this requirement in future.

Thanks and kind regards,
  Hendrik

Bug#818495: install: add zdsfs and HMC DVD access fuse file systems

[Hendrik Brueckner]

Package: s390-tools
Version: 1.33.0-1
Severity: normal
Tags:

Hi,

this is another request to include utilities for s390x specific FUSE file
systems.  Apart from the already included cmsfs-fuse, I would like to also
these:

The zdsfs FUSE file system can be used to read-only access z/OS physical
sequential and partitioned data sets on DASDs.

And also the hmcdrvfs file system to mount and access removable media
(CD, DVD, USB-sticks) contents on the HMC.  A future use case could be
to package this in the udeb to install or retrieve data from a DVD on HMC.

As usual, patch will follow.

Thanks and kind regards,
  Hendrik

Bug#818591: control: split and improve dependency handling for disk detection

[Hendrik Brueckner]

Control: tags -1 + patch
>From 18604958d335666c4154c1e500dc424aff0c5998 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 18 Mar 2016 12:05:01 +0100
Subject: [PATCH] control: split and improve dependency handling for disk
 detection

To improve and provide a "guided" flow, split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

The disk-detect package depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.  With this split,
installation on mixed DASD and SCSI disks are possible.  Also move
the module before the disk-detect module in the Debian installer
menu.

See also related Debian Bugs for:
  disk-detect: #818586
  s390-zfcp: #818592

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/changelog | 8 
 debian/control   | 4 ++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 69a0aa2..c83ad59 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+s390-dasd (0.0.36) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Split and improve dependency handling for disk detection and
+move the module before the disk-detect d-i module (Closes: #818591)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Fri, 18 Mar 2016 
11:59:33 +0100
+
 s390-dasd (0.0.35) unstable; urgency=low
 
   * Team upload
diff --git a/debian/control b/debian/control
index f036662..e4c75fb 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Package: s390-dasd
 Package-Type: udeb
 Architecture: s390 s390x
 Depends: ${shlibs:Depends}, ${misc:Depends}, dasd-modules, 
s390-sysconfig-writer, s390-tools-udeb
-Provides: harddrive-detection
-XB-Installer-Menu-Item: 3700
+Provides: harddrive-detection-dasd
+XB-Installer-Menu-Item: 3400
 Description: Configure DASD
  Configure DASD, s390 specific harddisks. 
-- 
2.7.0

Bug#818381: install/lsscm: display storage-class memory

[Hendrik Brueckner]

Control: tags -1 + patch

On Wed, Mar 16, 2016 at 05:23:59PM +0100, Hendrik Brueckner wrote:
> Package: s390-tools
> Version: 1.33.0-1
> Severity: normal
> Tags:
> 
> could you package the lsscm utility.  The lsscm command display information
> about storage-class memory, also known as, Flash Express.

Patch follows below.

Thanks and kind regards,
  Hendrik
diff -Nru s390-tools-1.33.0/debian/changelog s390-tools-1.33.0/debian/changelog
--- s390-tools-1.33.0/debian/changelog  2016-02-14 14:00:40.0 +0100
+++ s390-tools-1.33.0/debian/changelog  2016-03-16 17:25:05.0 +0100
@@ -1,3 +1,11 @@
+s390-tools (1.33.0-2) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Added missing lsscm command to display Storage-Class Memory,
+aka. Flash Express  (Closes: #818381)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Wed, 16 Mar 2016 
17:13:53 +0100
+
 s390-tools (1.33.0-1) unstable; urgency=medium
 
   [ Philipp Kern ]
diff -Nru s390-tools-1.33.0/debian/s390-tools.install 
s390-tools-1.33.0/debian/s390-tools.install
--- s390-tools-1.33.0/debian/s390-tools.install 2016-02-14 14:00:14.0 
+0100
+++ s390-tools-1.33.0/debian/s390-tools.install 2016-03-16 17:25:00.0 
+0100
@@ -100,6 +100,8 @@
 /usr/share/man/man8/lszcrypt.8
 /sbin/lszfcp
 /usr/share/man/man8/lszfcp.8
+/sbin/lsscm
+/usr/share/man/man8/lsscm.8
 
 # zdump
 /sbin/zgetdump

Bug#818586: disk-detect/control: Improve harddrive detection dependency on s390x

[Hendrik Brueckner]

Package: hw-detect
Version: 1.116
Severity: important
Tags: d-i

On Linux on z Systems, there are two major disk storage environments,
the direct-attached storage disk (DASD) and SCSI over Fibre-Channel.

There are the s390-dasd and s390-zfcp d-i modules to configure and
enable DASDs and FCP devices.  Note that on s390x, disks are not
available by default to Linux and must be enabled in advance.

The s390-dasd and s390-zfcp both provide the harddrive-detection
dependency and, thus, each could fulfill the dependency to silenty
ignore the other.  That behavior does not allow to mix DASDs and
SCSI disk on single installation (except you call both manually,
for example, in the expert mode).

To improve and provide a "guided" flow, I have split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

disk-detect depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.

With this split, the guided installation will install disk-detect to
solve the harddrive-detection dependency.  In turn, disk-detect will
then rely on the s390-dasd and s390-zfcp d-i modules to provide DASD
and FC-attached SCSI disks.  If both modules fail, the user perceives
the default disk-detect behavior, for example, users might configure
iSCSI.

The other nice benefit of this dependency split is the seamlessly
enablement of multipath with disk-detect (through preseeding).
For s390, multipathing should be always considered when SCSI is used.
I probably will extend the s390-zfcp module to set disk-detect's
multipath debconf variable for usability.


I will attach a patch with changelog when I have received the bug
number for report.  For s390-dasd and s390-zfcp, I will also open
bug reports to implement the dependency chain.

Feedback is welcome.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen

Bug#818595: dasd-config: allow users to re-format DASDs in non-expert mode

[Hendrik Brueckner]

Package: s390-dasd
Version: 0.0.35
Severity: normal
Tags: d-i patch

Recently, a change lowered the priority of the question to low-level
format a DASD.  The "low" priority caused the question to be displayed
only in the expert mode (unless debconf priority has been manually
changed).

There are cases where users might want to low-level format a DASD
even if it is already formatted.  For example, if a DASD uses LDL
and the user wants to reformat the DASD as CDL.

Thus, increase the priority to "high" to be always displayed in
non-expert mode again.  Of course, depending on the format status
a meaningful default is set.

Thanks and kind regards,
  Hendrik
>From 00784c5bbd3a88e2ba6a06a1375a214babbdf540 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Wed, 9 Mar 2016 17:35:20 +0100
Subject: [PATCH] dasd-config: allow users to re-format DASDs in non-expert
 mode

Recently, a change lowered the priority of the question to low-level
format a DASD.  The "low" priority caused the question to be displayed
only in the expert mode (unless debconf priority has been manually
changed).

There are cases where users might want to low-level format a DASD
even if it is already formatted.  For example, if a DASD uses LDL
and the user wants to reformat the DASD as CDL.

Thus, increase the priority to "high" to be always displayed in
non-expert mode again.  Of course, depending on the format status
a meaningful default is set.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 dasd-config.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dasd-config.c b/dasd-config.c
index 7ff57c7..9978fee 100644
--- a/dasd-config.c
+++ b/dasd-config.c
@@ -367,7 +367,7 @@ static enum state_wanted format (void)
 */
debconf_reset (client, template);
debconf_subst (client, template, "device", channel_current->name);
-   ret = my_debconf_input (channel_current->formatted ? "low" : "critical",
+   ret = my_debconf_input (channel_current->formatted ? "high" : 
"critical",
template, );
 
if (ret == CMD_GOBACK)
-- 
2.7.0

Bug#818591: control: split and improve dependency handling for disk detection

[Hendrik Brueckner]

Package: s390-dasd
Version: 0.0.35
Severity: important
Tags: d-i

To improve and provide a "guided" flow, split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

The disk-detect package depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.  With this split,
installation on mixed DASD and SCSI disks are possible.  Also move
the module before the disk-detect module in the Debian installer
menu.

See also the related Debian bug report #818586 for the disk-detect
package.

As usual, I will attach a patch with changelog and bug information.

Thanks and kind regards,
  Hendrik

Bug#818495: install: add zdsfs and HMC DVD access fuse file systems

[Hendrik Brueckner]

Control: tags -1 + patch

On Thu, Mar 17, 2016 at 04:42:02PM +0100, Hendrik Brueckner wrote:
> 
> this is another request to include utilities for s390x specific FUSE file
> systems.  Apart from the already included cmsfs-fuse, I would like to also
> these:
> 
> The zdsfs FUSE file system can be used to read-only access z/OS physical
> sequential and partitioned data sets on DASDs.
> 
> And also the hmcdrvfs file system to mount and access removable media
> (CD, DVD, USB-sticks) contents on the HMC.  A future use case could be
> to package this in the udeb to install or retrieve data from a DVD on HMC.
> 
> As usual, patch will follow.

Patch to add these tools is below.

Thanks and kind regards,
  Hendrik
diff -Nru s390-tools-1.33.0/debian/changelog s390-tools-1.33.0/debian/changelog
--- s390-tools-1.33.0/debian/changelog  2016-02-14 14:00:40.0 +0100
+++ s390-tools-1.33.0/debian/changelog  2016-03-17 17:19:47.0 +0100
@@ -1,3 +1,10 @@
+s390-tools (1.33.0-2) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Added zdsfs and hmc drive FUSE file systems (Closes: #818495)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Thu, 17 Mar 2016 
17:11:49 +0100
+
 s390-tools (1.33.0-1) unstable; urgency=medium
 
   [ Philipp Kern ]
diff -Nru s390-tools-1.33.0/debian/s390-tools.install 
s390-tools-1.33.0/debian/s390-tools.install
--- s390-tools-1.33.0/debian/s390-tools.install 2016-02-14 14:00:14.0 
+0100
+++ s390-tools-1.33.0/debian/s390-tools.install 2016-03-17 17:13:06.0 
+0100
@@ -120,6 +120,16 @@
 /usr/share/man/man1/cmsfs-fuse.1
 /etc/cmsfs-fuse/filetypes.conf
 
+# HMC removable media access
+/usr/bin/hmcdrvfs
+/usr/share/man/man1/hmcdrvfs.1
+/usr/sbin/lshmc
+/usr/share/man/man8/lshmc.8
+
+# zdsfs
+/usr/bin/zdsfs
+/usr/share/man/man1/zdsfs.1
+
 # kernel stuff
 ../../kernel/zz-zipl /etc/initramfs/post-update.d
 ../../kernel/zz-zipl /etc/kernel/postinst.d

Bug#818385: install/cpumf: work with the CPU-measurement facilities

[Hendrik Brueckner]

Package: s390-tools
Version: 1.33.0-1
Severity: normal
Tags:

Hi Philipp,

this is a request to package a set of utilities to display information
about the CPU-measurement counter and sampling facilities.  Both facilities
provide hardware support for counters (cycles, instructions, etc.) and
sampling.

The lscpumf command displays information about the installed facilities
and provide an overview of authorized and available hardware counters.
The counter list informs users about authorized hardware counters and
its number and symbolic name, for example, to be specified for perf tool.

The chcpumf command changes sampling buffer charactistics for the kernel
support for the hardware sampler.

Apart from the user command, there is a helper program to parse data files.

I will attach a patch when I have a bug number to provide you an changelog
entry for convenience.

Thanks and kind regards,
  Hendrik

Bug#818592: control: split and improve dependency handling for disk detection

[Hendrik Brueckner]

Control: tags -1 + patch
>From 967d360afb9d89c5fac42e4590f879d41efbe618 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 18 Mar 2016 12:09:52 +0100
Subject: [PATCH] control: split and improve dependency handling for disk
detection

To improve and provide a "guided" flow, split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

The disk-detect package depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.  With this split,
installation on mixed DASD and SCSI disks are possible.  Also move
the module before the disk-detect module in the Debian installer
menu.

See also related Debian Bugs for:
  disk-detect: #818586
  s390-dasd: #818591

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/changelog | 8 
 debian/control   | 4 ++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index d09b22e..2c7c5ef 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+s390-zfcp (1.0.2) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Split and improve dependency handling for disk detection and
+move the module before the disk-detect d-i module (Closes: #818592)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Fri, 18 Mar 2016 
11:59:33 +0100
+
 s390-zfcp (1.0.1) unstable; urgency=medium
 
   * Unmark strings for translation.
diff --git a/debian/control b/debian/control
index 66e8056..150df23 100644
--- a/debian/control
+++ b/debian/control
@@ -12,8 +12,8 @@ Package: s390-zfcp
 Package-Type: udeb
 Architecture: s390x
 Depends: ${shlibs:Depends}, ${misc:Depends}, scsi-modules, 
s390-sysconfig-writer
-Provides: harddrive-detection
-XB-Installer-Menu-Item: 3700
+Provides: harddrive-detection-zfcp
+XB-Installer-Menu-Item: 3400
 Description: Activate and configure FCP devices for installation
  Configure FCP devices to install Debian on FC-attached SCSI devices
  available on Linux on z Systems.
-- 
2.7.0

Bug#818611: netcfg: Misleading error message when parsing line with trailing blank

[Hendrik Brueckner]

Control: tags -1 + patch

Bug#818611: netcfg: Misleading error message when parsing line with trailing blank

[Hendrik Brueckner]

Package: netcfg
Version: 1.137
Severity: normal
Tags: d-i

Dear maintainer(s),

when specifying IP addresses with leading or trailing blanks, netcfg does not
correctly identify the IP address and fails.  For example,

Configure a network using static addressing  
---  
  
The IP address is unique to your computer and may be:  
  
 * four numbers separated by periods (IPv4);  
 * blocks of hexadecimal characters separated by colons (IPv6).  
  
You can also optionally append a CIDR netmask (such as "/24").  
  
If you don't know what to use here, consult your network administrator. 
 
IP address:  
Prompt: '?' for help> 9.152.162.103
9.152.162.103 
  
!! ERROR: Malformed IP address  
  
The IP address you provided is malformed. It should be in the form 
x.x.x.x   
where each 'x' is no larger than 255 (an IPv4 address), or a sequence 
of blocks 
 
of hexadecimal digits separated by colons (an IPv6 address). Please try 
again.  
Press enter to continue

This can easily happen, especially, when entering IP addresses within
command line console, such as the z/VM console on z Systems (s390x).

The expected behavior is that leading and trailing blanks should be ignored.
Note that the root cause of the error condition above is triggered by a
failing inet_pton() call which does not expect blanks for an IP address
string.

To correct this behavior, I have attached two patches for discussion:

The first patch removes trailing blanks for the case above. Note that there
is already an rtrim() function that has been reused.  Also an additional
function, strtrim(), is introduced to remove any leading blanks.
The "make test" has been enhanced to verify this behavior.

The second patch removes leading and trailing blanks on IP addresses entered
for other network configurations, for example, point-to-point.

Feedback is welcome.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen
>From 944acf2a089e5eb60a76c58d896f8c3713aad0a4 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 5 Feb 2016 16:32:42 +0100
Subject: [PATCH 1/2] common/ipaddr: remove leading and trailing whitespaces

Leading or trailing whitespaces are not removed from the IP address,
for example, when specified by the user.  If the IP address contains
whitespaces, parsing the address fails and a malformed address is
reported even if the IP address would be valid.

To remove trailing whitespaces, extend the rtrim() function to remove
multiple spaces.  Introduce a new function, strtrim() to remove any
leading spaces.

Also add a test case to verify the changed behavior.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 netcfg-common.c   | 24 +---
 netcfg.h  |  1 +
 test/test_netcfg_parse_cidr_address.c | 26 ++
 3 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/netcfg-common.c b/netcfg-common.c
index 376e6ca..c6d1d8d 100644
--- a/netcfg-common.c
+++ b/netcfg-common.c
@@ -1577,10 +1577,11 @@ int netcfg_parse_cidr_address(const char *address, 
struct netcfg_interface *inte
 struct in_addr addr;
 struct in6_addr addr6;
 int ok;
-char *maskptr, addrstr[NETCFG_ADDRSTRLEN];
+char *maskptr, *addrstr, addrbuf[NETCFG_ADDRSTRLEN];
 int i;
 
-strncpy(addrstr, address, NETCFG_ADDRSTRLEN);
+strncpy(addrbuf, address, NETCFG_ADDRSTRLEN);
+addrstr = strtrim(addrbuf);
 
 if ((maskptr = strchr(addrstr, '/'))) {
 /* Houston, we have a netmask; split it into bits */
@@ -1730,7 +1731,24 @@ void rtrim(char *s)

n = strlen(s) - 1;

-   while (isspace(s[n])) {
+   while (n >= 0 && isspace(s[n])) {
s[n] = '\0';
+   n--;
}
 }
+
+char *strtrim(char *s)
+{
+   size_t len;
+
+   len = strlen(s);
+   if (!len)
+   return s;
+
+   rtrim(s);
+
+   while (*s && isspace(*s))
+   s++;
+
+   return s;
+}
diff --git a/netcfg.h b/netcfg.h
index 771fed3..00a2cea 100644
--- a/netcfg.h
+++ b/netcfg.h
@@ -249,6 +249,7 @@ extern void preseed_hostname_from_fqdn(struct debconfclient 
*client, char *fqdn)
 extern int netcfg_dhcp(struct debconfclient *client, struct netcfg_interface 
*interface);
 
 extern void rtrim(char *);
+extern char *strtrim(char *s);
 
 /* ipv6.c */
 extern void nc_v6_wait_for_complete_configuration(const struct 
netcfg_interface *interface);
diff --git a/test/test_netcfg_parse_cidr_address.c 
b/test/test_netcfg_

Bug#818385: install/cpumf: work with the CPU-measurement facilities

[Hendrik Brueckner]

Control: tags -1 + patch

On Wed, Mar 16, 2016 at 05:50:16PM +0100, Hendrik Brueckner wrote:
> 
> this is a request to package a set of utilities to display information
> about the CPU-measurement counter and sampling facilities.  Both facilities
> provide hardware support for counters (cycles, instructions, etc.) and
> sampling.
[...]
> I will attach a patch when I have a bug number to provide you an changelog
> entry for convenience.

As promised below the patch.

Thanks and kind regards,
  Hendrik
diff -Nru s390-tools-1.33.0/debian/changelog s390-tools-1.33.0/debian/changelog
--- s390-tools-1.33.0/debian/changelog  2016-02-14 14:00:40.0 +0100
+++ s390-tools-1.33.0/debian/changelog  2016-03-16 17:39:33.0 +0100
@@ -1,3 +1,12 @@
+s390-tools (1.33.0-2) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Added tools to display information about the CPU-measurement counter
+and sampling facilities.  This includes a database with hardware
+counter information.  (Closes: #818385)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Wed, 16 Mar 2016 
17:13:53 +0100
+
 s390-tools (1.33.0-1) unstable; urgency=medium
 
   [ Philipp Kern ]
diff -Nru s390-tools-1.33.0/debian/s390-tools.install 
s390-tools-1.33.0/debian/s390-tools.install
--- s390-tools-1.33.0/debian/s390-tools.install 2016-02-14 14:00:14.0 
+0100
+++ s390-tools-1.33.0/debian/s390-tools.install 2016-03-16 17:42:58.0 
+0100
@@ -37,6 +37,19 @@
 /usr/share/man/man8/iucvtty.8
 /usr/share/man/man9/hvc_iucv.9
 
+# CPU-measurement facility
+/usr/bin/lscpumf
+/usr/share/man/man1/lscpumf.1
+/usr/sbin/chcpumf
+/usr/share/man/man8/chcpumf.8
+/lib/s390-tools/cpumf_helper
+/usr/share/s390-tools/cpumf/cpum-cf-hw-counter.map
+/usr/share/s390-tools/cpumf/cpum-cf-extended-z10.ctr
+/usr/share/s390-tools/cpumf/cpum-cf-extended-z196.ctr
+/usr/share/s390-tools/cpumf/cpum-cf-extended-zEC12.ctr
+/usr/share/s390-tools/cpumf/cpum-cf-generic.ctr
+/usr/share/s390-tools/cpumf/cpum-sf-modes.ctr
+
 # qetharp
 /sbin/qetharp
 /usr/share/man/man8/qetharp.8

Bug#818586: disk-detect/control: Improve harddrive detection dependency on s390x

[Hendrik Brueckner]

Control: block -1 by 818591 818592

Bug#818586: disk-detect/control: Improve harddrive detection dependency on s390x

[Hendrik Brueckner]

Control: tags -1 + patch
>From 131e2f4325e3203e6ac30ffe38005dfe01d96fcc Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 18 Mar 2016 11:22:12 +0100
Subject: [PATCH] disk-detect/control: Improve harddrive detection dependency
 on s390x

On Linux on z Systems, there are two major disk storage environments,
the direct-attached storage disk (DASD) and SCSI over Fibre-Channel.

There are the s390-dasd and s390-zfcp d-i modules to configure and
enable DASDs and FCP devices.  Note that on s390x, disks are not
available by default to Linux and must be enabled in advance.

The s390-dasd and s390-zfcp both provide the harddrive-detection
dependency and, thus, each could fulfill the dependency to silenty
ignore the other.  That behavior does not allow to mix DASDs and
SCSI disk on single installation (except you call both manually,
for example, in the expert mode).

To improve and provide a "guided" flow, I have split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

disk-detect depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.

With this split, the guided installation will install disk-detect to
solve the harddrive-detection dependency.  In turn, disk-detect will
then rely on the s390-dasd and s390-zfcp d-i modules to provide DASD
and FC-attached SCSI disks.  If both modules fail, the user perceives
the default disk-detect behavior, for example, users might configure
iSCSI.

The other nice benefit of this dependency split is the seamlessly
enablement of multipath with disk-detect (through preseeding).
For s390, multipathing should be always considered when SCSI is used.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/changelog | 8 
 debian/control   | 6 --
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 477f23a..1c564fd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+hw-detect (1.117) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Improve and split harddrive detection into DASD and SCSI dependency
+on s390x (Closes: #818586)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Fri, 18 Mar 2016 
11:21:31 +0100
+
 hw-detect (1.116) unstable; urgency=medium
 
   [ Colin Watson ]
diff --git a/debian/control b/debian/control
index bf4b663..7c1a8a3 100644
--- a/debian/control
+++ b/debian/control
@@ -24,8 +24,10 @@ Description: Detect network hardware and load kernel drivers 
for it
 
 Package: disk-detect
 Package-Type: udeb
-Architecture: all
-Depends: cdebconf-udeb (>= 0.38), hw-detect, di-utils (>= 1.13), pciutils-udeb
+Architecture: any
+Depends: cdebconf-udeb (>= 0.38), hw-detect, di-utils (>= 1.13), pciutils-udeb,
+harddrive-detection-dasd [s390x],
+harddrive-detection-zfcp [s390x]
 Priority: optional
 Provides: harddrive-detection
 Enhances: hw-detect
-- 
2.7.0

Bug#818381: install/lsscm: display storage-class memory

[Hendrik Brueckner]

Package: s390-tools
Version: 1.33.0-1
Severity: normal
Tags:

Hi,

could you package the lsscm utility.  The lsscm command display information
about storage-class memory, also known as, Flash Express.


Thanks and kind regards,
  Hendrik

Bug#818592: control: split and improve dependency handling for disk detection

[Hendrik Brueckner]

Package: s390-zfcp
Version: 1.0.1
Severity: important
Tags: d-i

To improve and provide a "guided" flow, split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

The disk-detect package depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.  With this split,
installation on mixed DASD and SCSI disks are possible.  Also move
the module before the disk-detect module in the Debian installer
menu.

See also related Debian Bug #818586 for the disk-detect package.

Patch for the control file will follow.

Thanks and kind regards,
  Hendrik

Bug#816600: postinst: IPv6 address is not displayed in 'Start SSH' invitation

[Hendrik Brueckner]

Package: network-console
Version: 1.53
Severity: normal
Tags: d-i patch

Dear Maintainer,

in IPv6-only environments, the "Start SSH" invitation does not include
the IPv6 address to log in to the installer system.  Below is a patch
that extends the postinst script to detect an IPv6 address if no IPv4
address could be found.

Thanks and kind regards,
  Hendrik
>From 46f274510e68bc3ce843a14b2c229ab30706d68d Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Thu, 3 Mar 2016 10:51:01 +0100
Subject: [PATCH] network-console: display IPv6 address to access installer 
system

The IP address in the ssh command to log into the installer system
is not display in IPv6-only environments.  Enhance the post install
to detect and display IPv6 addresses if no IPv4 address could be
found.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/network-console.postinst |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/debian/network-console.postinst b/debian/network-console.postinst
index f164446..512f121 100755
--- a/debian/network-console.postinst
+++ b/debian/network-console.postinst
@@ -87,6 +87,13 @@ case "$(udpkg --print-os)" in
linux)
IPADDR=$(ip addr | grep '^[[:space:]]*inet ' | grep -v 
"127\.0\." | \
 head -n 1 | sed 's/.*inet \([0-9.]*\).*/\1/')
+
+   if test -z "$IPADDR"; then
+   # Check for an IPv6 address if an IPv4 address
+   # could not be found
+   IPADDR=$(ip addr |grep '^[[:space:]]*inet6 ' | grep -v 
"::1" | \
+head -n 1 | sed 's/.*inet6 
\([a-fA-F0-9:]*\).*/\1/')
+   fi
;;
kfreebsd)
IPADDR=$(ifconfig| grep '^[[:space:]]*inet ' | grep -v 
"127\.0\." | \
-- 
1.7.1

Bug#666399: s390-dasd fails to work with >20 devices visible (mostly in LPAR mode)

[Hendrik Brueckner]

Control: tags -1 + patch

On Tue, Feb 16, 2016 at 06:22:30PM +0100, Hendrik Brueckner wrote:
> On Tue, Feb 16, 2016 at 05:34:02PM +0100, Holger Wansing wrote:
> > Hendrik Brueckner <brueck...@linux.vnet.ibm.com> wrote:
> > > On Sun, Feb 14, 2016 at 05:46:39PM +0100, Philipp Kern wrote:
> > > > > For example,
> > > > > 
> > > > >   cio_ignore=all,!ipldev,!condev,!0.0.da00-0.0.da10
> > > > > 
> > > > > ignores all devices except the console device, the IPL device, and the
> > > > > range of devices from 0.0.da00 to 0.0.da10 that might be DASDs or any
> > > > > other devices.  Note that you can change the cio_ignore settings at 
> > > > > runtime,
> > > > > so you can later make additional devices visible.
> > > > > 
> > > > > With this solution, there is no hardcoded limit necessary and the user
> > > > > can still see the list of DASDs to be configured.
> > > > > 
> > > > > What do you think?
> > > > 
> > > > it'd be nice to see that in the installation manual, I think, so that
> > > > it's at least documented.
> 
> Actually, this is already documented in the installation manual:
> 
> https://d-i.debian.org/manual/en.s390x/ch05s01.html

Because this is already documented, below a patch that removes the
get_channel() function to handle more than 20 DASDs.  If there are
numerous DASDs, the cio_ignore could be used to limit the list to
those that are required for the Linux instance / installer.

The patch also corrects a stack overflow for displaying DASDs which
similar to the one in s390-netdevice which was corrected few weeks
ago.

Thanks and kind regards,
  Hendrik
>From 04236b0f262476dfdc84fc751f72dd65519be83f Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Thu, 14 Jan 2016 17:04:36 +0100
Subject: [PATCH] dasd-config: always list available DASDs for selection and 
configuration

Previously, the DASD configuration module prompted the user to specify
DASDs if there were more than 20 DASDs available.  If this dialog is
shown, the user can configure DASD devices; but can only return to the
installer through the  button.  The  triggers a special
debconf return code and the "hardware-detection" dependency for this is
not satisfied.  Later the partitioner will complain and the intermediate
configuration file might not be copied to the target system.

The second disadvantage with prompt is that the user does not see which
DASDs are already online and configured.  See also Debian bug 666399 for
more details.

This commit removes the prompt to manually enter DASDs.  The panel to
select particular DASDs is displayed instead.

Of course, there can be the case where LPARs have access to (almost)
every device.  For this case, the solution is to use the "cio_ignore"
kernel parameter.  With this kernel parameter you can control the
devices that are visible to the Linux instance.

For example,

cio_ignore=all,!ipldev,!condev,!0.0.da00-0.0.da10

ignores all devices except the console device, the IPL device, and the
range of devices from 0.0.da00 to 0.0.da10 that might be DASDs or any
other devices.  Note that you can change the cio_ignore settings at
runtime, so you can later make additional devices visible.

With this solution, there is no hardcoded limit necessary and the user
can still see the list of DASDs to be configured.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 dasd-config.c |   71 -
 1 files changed, 35 insertions(+), 36 deletions(-)

diff --git a/dasd-config.c b/dasd-config.c
index e085534..daa53a4 100644
--- a/dasd-config.c
+++ b/dasd-config.c
@@ -18,6 +18,7 @@
 
 #define SYSCONFIG_DIR "/etc/sysconfig/hardware/"
 #define TEMPLATE_PREFIX"s390-dasd/"
+#define DASD_ENTRY_SIZE32
 
 static struct debconfclient *client;
 
@@ -173,62 +174,62 @@ static enum state_wanted detect_channels (void)
return WANT_NEXT;
 }
 
-static enum state_wanted get_channel_input (void)
+struct buffer_desc
 {
-   int ret, dev;
-   char *ptr;
-
-   while (1)
-   {
-   ret = my_debconf_input ("critical", TEMPLATE_PREFIX "choose", 
);
-   if (ret == 30)
-   return WANT_BACKUP;
-
-   dev = channel_device (ptr);
-   if (dev >= 0)
-   {
-   channel_current = di_tree_lookup (channels, );
-   if (channel_current)
-   return WANT_NEXT;
-   }
-
-   ret = my_debconf_input ("critical", TEMPLATE_PREFIX 
"choose_invalid", );
-

Bug#815918: dasdfmt: detect format status and improve handling

[Hendrik Brueckner]

Package: s390-dasd
Version: 0.0.34
Severity: normal
Tags: d-i patch

Hi,

below you can find three patches to improve the low-level formatting
of DASDs.  After an DASD has been enabled (set online), the status
sysfs attribute can be used to check if a DASD is formatted.  Depending
on the value of the status (n/f for non-formatted), the priority and
default answer for the ""Format the DASD" question is properly set.

The dasdfmt program fails if the DASD to be formatted is already in use.
This might happen if the partitioner detected a physial volume which
becomes part of an mapped LVM device.  In such a case, the error handling
is improved.

Also the "Go back" button was not correctly detected because the code
tested for a wrong return code.  This has been corrected too.

Kind regards,
  Hendrik
>From 74df2f8fe686d29e19b937332127f514531b5d33 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Thu, 11 Feb 2016 18:18:48 +0100
Subject: [PATCH 1/4] dasdfmt: report user error if disk is in use

Display an error message if the disk to be low-level formatted is in use.
This might happen if disk was or is used as physical volume for LVM. If
the DASD is already mapped, for example, from going back from the
partitioner, the DASD cannot be low-level formatted.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Reviewed-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
 dasd-config.c  | 18 ++
 debian/s390-dasd.templates |  7 +++
 2 files changed, 25 insertions(+)

diff --git a/dasd-config.c b/dasd-config.c
index 37a0fec..b8d9203 100644
--- a/dasd-config.c
+++ b/dasd-config.c
@@ -326,7 +326,25 @@ static enum state_wanted format (void)
debconf_progress_stop (client);
 
if (ret)
+   {
+   if (di_exec_mangle_status (ret) == 2)
+   {
+   /*
+* dasdfmt failed because the DASD is in use. For 
example,
+* it is mapped as part of an LVM.
+*/
+   debconf_subst (client, TEMPLATE_PREFIX 
"format_disk_in_use",
+  "device", channel_current->name);
+   debconf_input (client, "critical",
+  TEMPLATE_PREFIX "format_disk_in_use");
+   debconf_capb (client);
+   ret = debconf_go (client);
+   debconf_capb (client, "backup");
+
+   return WANT_BACKUP;
+   }
return WANT_ERROR;
+   }
 
return WANT_NEXT;
 }
diff --git a/debian/s390-dasd.templates b/debian/s390-dasd.templates
index 2c307be..8d443c0 100644
--- a/debian/s390-dasd.templates
+++ b/debian/s390-dasd.templates
@@ -36,6 +36,13 @@ _Description: Format the device?
  If you are sure the device has already been correctly formatted, you don't
  need to do so again.
 
+Template: s390-dasd/format_disk_in_use
+Type: error
+_Description: The DASD ${device} is in use
+ Could not low-level format the DASD ${device} because the DASD
+ is in use.  For example, the DASD could be a member of a mapped device in
+ an LVM volume group.
+
 Template: s390-dasd/formatting
 Type: text
 # :sl5:
-- 
2.7.0

>From aa69e1cd3390444f4b88ef6eaa6eafff07e71aeb Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 12 Feb 2016 11:04:17 +0100
Subject: [PATCH 2/4] dasdfmt: detect and properly handle already formatted
 DASDs

When the DASD has been set online, the device driver provides basic
information about the status of the DASD.  The status can be used
to detect whether a DASD is low-level formatted.

If the DASD is already low-level formatted, properly set the default
and reduce the priority for asking the user to low-level format the
DASD.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Reviewed-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
 dasd-config.c  | 72 +++---
 debian/s390-dasd.templates | 16 +++
 2 files changed, 79 insertions(+), 9 deletions(-)

diff --git a/dasd-config.c b/dasd-config.c
index b8d9203..a25d992 100644
--- a/dasd-config.c
+++ b/dasd-config.c
@@ -33,6 +33,7 @@ struct channel
char devtype[SYSFS_NAME_LEN];
bool configured;
bool online;
+   bool formatted;
enum channel_type type;
 };
 
@@ -293,15 +294,75 @@ static int format_handler (const char *buf, size_t len, 
void *user_data __attrib
return 0;
 }
 
+static bool dasd_is_formatted (const char *name)
+{
+   int tries;
+   bool formatted;
+   struct sysfs_device *device;
+   struct sysfs_attribute *status;
+
+   formatted = false;
+   device = sysfs_open_device ("ccw", name

Bug#815912: dasd: detect if a DASD is already configured

[Hendrik Brueckner]

Package: s390-dasd
Version: 0.0.34
Severity: normal
Tags: d-i patch

If you have configured one ore more DASDs, the s390-dasd shows
them as "(configured)".  If you then leave the module, for example,
with "Finish", and re-enter the module again, the DASDs show up as
"online" again.

The patch below enhances the detect_channels_driver() function
to check if a configuration file exists, that means, if DASDs
are already online and configured.

Kind regards,
  Hendrik
>From ba645de637b74de9a58e4296dae0f4bd6a785c07 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Mon, 15 Feb 2016 17:44:29 +0100
Subject: [PATCH 4/4] dasd: detect if a DASD is already configured

If the s390-dasd module is started twice, already configured DASDs
appear as "online".  Enhance the detect_channels_driver() function
to check if a configuration file exists, that means, if DASDs are
already online and configured.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Reviewed-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
 dasd-config.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/dasd-config.c b/dasd-config.c
index 6194da7..e085534 100644
--- a/dasd-config.c
+++ b/dasd-config.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -111,6 +112,7 @@ static enum state_wanted setup ()
 
 static enum state_wanted detect_channels_driver (struct sysfs_driver *driver, 
int type)
 {
+   char path[PATH_MAX];
struct dlist *devices;
struct sysfs_device *device;
 
@@ -141,6 +143,10 @@ static enum state_wanted detect_channels_driver (struct 
sysfs_driver *driver, in
if (strtol (attr_online->value, NULL, 10) > 0)
current->online = true;
 
+   /* Check if the current DASD is already configured */
+   snprintf (path, sizeof (path), SYSCONFIG_DIR "config-ccw-%s", 
current->name);
+   current->configured = !access (path, F_OK);
+
di_tree_insert (channels, current, current);
}
 
-- 
2.7.0

Bug#815819: sysconfig-hardware udev rule ignores INTERFACE_NAME property

[Hendrik Brueckner]

On Wed, Feb 24, 2016 at 02:50:58PM -0300, Raphael Philipe Mendes da Silva wrote:
> Package: sysconfig-hardware
> Version: 0.0.11
> Severity: normal
> X-Debbugs-CC: brueck...@linux.vnet.ibm.com,mihaj...@linux.vnet.ibm.com
> 
> I wanted to change the network interface name without using a custom
> udev rule like 70-persistent-net.rules.
> To do that, In Debian 8, I created a network interface hardware config
> file (/etc/sysconfig/hardware/config-ccw-0.0.) with the following
> content:
> 
> CCWGROUP_CHANS=(0.0. 0.0.xxxy 0.0.xxxz)
> QETH_PORTNAME=OSAPORT
> QETH_PORTNO=0
> QETH_OPTIONS=(layer2)
> INTERFACE_NAME=ethfoo
> 
> The interface is created and is up. However the name of the
> interface remains enccw0.0.
> 

Have you tried to create systemd network link file to assign a different
name?  This should be then the long-term way how to rename interface
names.  But I agree to correct the behavior in sysconfig-hardware for
correctness.

Thanks and kind regards,
  Hendrik

Bug#815166: preseed/url: correctly handle IPv6 addresses

[Hendrik Brueckner]

Package: preseed
Version: 1.70
Severity: normal
Tags: d-i patch

Dear maintainer,

trying to fetch a preseed URL using an IPv6 address fails.  For example,
consider the preseed/url setting:
http://[fd00:9:152:48:1822::162:199]/dir/preseed.cfg
which becomes
http://[fd00.example.org:9:152:48:1822::162:199]/dir/preseed.cfg

The problem is that "fd00" is treated as hostname without domain and, thus,
the domain name is appended resulting in "fd00.example.org".  Of course,
this is no longer a valid IPv6 address.

To solve this problem, I added a patch that enhances the auto-install.sh
to detect IPv6 addresses.  I also added few more unit test cases to cover
different URLs with IPv6 addresses with user, password, and port variations:

[...]
ok 11 - ftp with user/password, IPv4, and domain
ok 12 - ftp with user/password, IPv4, and domain and port
ok 13 - http with short IPv6 and domain
ok 14 - http with simple IPv6 and domain
ok 15 - http with IPv6 and domain
ok 16 - http with IPv6, port, and domain
ok 17 - http with user/password, IPv6 and domain
ok 18 - http with user/password, IPv6, port, and domain

Thanks and kind regards,
  Hendrik
>From dbc8bc790c781530954d2b58b0050472bbaef354 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 19 Feb 2016 11:23:50 +0100
Subject: [PATCH] auto-install: correctly handle IPv6 addresses

The auto-install does not properly detect IPv6 address when they
are specified in an URL.  Typically, the first IPv6 address part
is to be considered as the hostname and, if specified, a domain
name is appended.  For example,

http://[fd00:9:152:48:1822::162:199]/dir/preseed.cfg

becomes

http://[fd00.example.org:9:152:48:1822::162:199]/dir/preseed.cfg

which is no longer a valid IPv6 address.  To solve this problem,
enhance auto-install.sh and test for IPv6 addresses in URLs.
Also added few IPv6 unit test cases.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 auto-install.sh |5 +++-
 t/01-auto-install.t |   55 +++
 2 files changed, 59 insertions(+), 1 deletions(-)

diff --git a/auto-install.sh b/auto-install.sh
index a1551a1..e38ecf5 100755
--- a/auto-install.sh
+++ b/auto-install.sh
@@ -34,7 +34,10 @@ else
db_get auto-install/defaultroot && dir="$RET"
 fi
 
-if expr $host_port : [^.]*$ >/dev/null; then
+if expr "$host_port" : '^.*\[[:a-fA-F0-9]*\]' > /dev/null; then
+   # IPv6 address with or without port
+   :
+elif expr $host_port : [^.]*$ >/dev/null; then
db_get netcfg/get_domain && domain="$RET"
 
if [ -n "$domain" ] && [ "$domain" != "unassigned-domain" ] && [ 
"$domain" != "unnassigned-domain" ]; then
diff --git a/t/01-auto-install.t b/t/01-auto-install.t
index 10e6945..4822536 100755
--- a/t/01-auto-install.t
+++ b/t/01-auto-install.t
@@ -122,6 +122,61 @@ is(run_test('preseed/url'=>'ftp://foo/preseed.cfg',
'ftp:// is kept'
   );
 
+is(run_test('preseed/url'=>'ftp://user:pass@10.11.12.13/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=ftp://user:pass@10.11.12.13/foo/preseed.cfg',
+'ftp with user/password, IPv4, and domain'
+  );
+
+is(run_test('preseed/url'=>'ftp://user:pass@10.11.12.13:8080/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=ftp://user:pass@10.11.12.13:8080/foo/preseed.cfg',
+'ftp with user/password, IPv4, and domain and port'
+  );
+
+is(run_test('preseed/url'=>'http://[fe80::5054:ff:fe23:8018]/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=http://[fe80::5054:ff:fe23:8018]/foo/preseed.cfg',
+'http with short IPv6 and domain'
+  );
+
+is(run_test('preseed/url'=>'http://[::1]/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=http://[::1]/foo/preseed.cfg',
+'http with simple IPv6 and domain'
+  );
+is(run_test('preseed/url'=>'http://[fd00:9:152:48:1822::162:199]/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=http://[fd00:9:152:48:1822::162:199]/foo/preseed.cfg',
+'http with IPv6 and domain'
+  );
+
+is(run_test('preseed/url'=>'http://[fd00:9:152:48:1822::162:199]:8080/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+
'preseed/url=http://[fd00:9:152:48:1822::162:199]:8080/foo/preseed.cfg',
+'http with IPv6, port, and domain'
+  );
+
+is(run_test('preseed/url'=>'http://user:pass@[fd00:9:152:48:1822::162:199]/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+   

Bug#545906: Debian S390 Install Failed to create a file system during installer process

[Hendrik Brueckner]

On Tue, Feb 16, 2016 at 08:46:58PM -0800, Martin Michlmayr wrote:
> * HAND, RAY  [2009-09-09 21:09]:
> > Package: Partman-ext3
> > Version:  2.6.26-2
> > 
> > In the partition disks screen I get the error:
> > 
> > The ext3 file system creation in partition #1 of DASD 0.0.0300 (ECKD) 
> > failed.
> 
> I'm sorry that nobody responded to the bug report you filed back in
> 2009.  Do you still have access to this system?
> 
> s390: maybe you can take a brief look at the logs to see if that's
> still relevant.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545906
> 
According to the syslog, partman tried to access beyond the size of the
DASD.  Because partman-ext3 works today, I suspect that the problem has
been solved in last years.  I can only suspect about the root case but
I ran into a similar issue (other work area) where the calculation of
the DASD size was wrong due to incorrect use of ioctl.  There are ioctl
that return the size in bytes and blocks (I think there was a 32 and 64
bit variant, which returned in different units).  So the size calculation
was broken and I received the same error message.  Maybe partman-ext3
was also affected by this change.  Not sure.

For short: I would suggest to close this bug and re-open if the problem
still persists.

Thanks and kind regards,
  Hendrik

Bug#666399: s390-dasd fails to work with >20 devices visible (mostly in LPAR mode)

[Hendrik Brueckner]

On Tue, Feb 16, 2016 at 05:34:02PM +0100, Holger Wansing wrote:
> Hendrik Brueckner <brueck...@linux.vnet.ibm.com> wrote:
> > On Sun, Feb 14, 2016 at 05:46:39PM +0100, Philipp Kern wrote:
> > > > For example,
> > > > 
> > > > cio_ignore=all,!ipldev,!condev,!0.0.da00-0.0.da10
> > > > 
> > > > ignores all devices except the console device, the IPL device, and the
> > > > range of devices from 0.0.da00 to 0.0.da10 that might be DASDs or any
> > > > other devices.  Note that you can change the cio_ignore settings at 
> > > > runtime,
> > > > so you can later make additional devices visible.
> > > > 
> > > > With this solution, there is no hardcoded limit necessary and the user
> > > > can still see the list of DASDs to be configured.
> > > > 
> > > > What do you think?
> > > 
> > > it'd be nice to see that in the installation manual, I think, so that
> > > it's at least documented.

Actually, this is already documented in the installation manual:

https://d-i.debian.org/manual/en.s390x/ch05s01.html

> > 
> > How are installation manual changes are handled?
> 
> You can find the various manual formats in
> https://d-i.debian.org/manual/
> 
> The source code is under 
> http://anonscm.debian.org/viewvc/d-i/trunk/manual/
> or via
> svn co svn://anonscm.debian.org/svn/d-i/trunk/manual


Thanks for pointing to the manual locations.

> 
> Patches could be provided at debian-boot or as a wishlist bug 
> against installation-guide.

Ok... good to know.


Thanks and kind regards,
  Hendrik

Bug#666399: s390-dasd fails to work with >20 devices visible (mostly in LPAR mode)

[Hendrik Brueckner]

On Sun, Feb 14, 2016 at 05:46:39PM +0100, Philipp Kern wrote:
> On Wed, Dec 16, 2015 at 02:15:10PM +0100, Hendrik Brueckner wrote:
> > Honestly, I would propose a different approach to limit the DASD device
> > available to the Debian installer.   I believe that typical customer
> > environments have set up their LPARs (and z/VM guest virtual machines)
> > to limit the number of devices to those required/designated for the LPAR.
> > 
> > Of course, there can be the case where LPARs almost have access to (almost)
> > every device.  For this case, the solution is to use "cio_ignore" kernel
> > parameter.  With this kernel parameter you can control the devices that
> > are visible to the Linux instance.
> > 
> > For example,
> > 
> > cio_ignore=all,!ipldev,!condev,!0.0.da00-0.0.da10
> > 
> > ignores all devices except the console device, the IPL device, and the
> > range of devices from 0.0.da00 to 0.0.da10 that might be DASDs or any
> > other devices.  Note that you can change the cio_ignore settings at runtime,
> > so you can later make additional devices visible.
> > 
> > With this solution, there is no hardcoded limit necessary and the user
> > can still see the list of DASDs to be configured.
> > 
> > What do you think?
> 
> it'd be nice to see that in the installation manual, I think, so that
> it's at least documented.

How are installation manual changes are handled?

Thanks and kind regards,
  Hendrik

Bug#813506: zipl-installer: set up re-IPL to boot newly installed Debian/Linux

[Hendrik Brueckner]

Hi Philipp,

On Mon, Feb 08, 2016 at 08:59:23AM +0100, Hendrik Brueckner wrote:
> On Sun, Feb 07, 2016 at 01:31:49AM +0100, Philipp Kern wrote:
> > On Tue, Feb 02, 2016 at 05:40:34PM +0100, Hendrik Brueckner wrote:
> > > --- a/debian/zipl-installer.postinst
> > > +++ b/debian/zipl-installer.postinst
> > > @@ -57,8 +57,5 @@ EOF
> > >  sed -e 's/^do_bootloader.*$/do_bootloader = yes/' < 
> > > /target/etc/kernel-img.conf > /target/etc/kernel-img.conf.$$
> > >  mv /target/etc/kernel-img.conf.$$ /target/etc/kernel-img.conf
> > >  
> > > -mount -t proc none /target/proc || true
> > > -
> > > -log-output -t zipl-installer chroot /target /sbin/zipl
> > > -
> > > -umount /target/proc || true
> > > +# Run zipl in the installed target instance
> > > +in-target /sbin/zipl -V
> > 
> > I'm a bit sad that this loses the zipl-installer tagging in
> > /var/log/syslog because in-target does not support customized logging.
> > It will log everything as "in-target".
> > 
> > At least there's prior art here in grub-installer calling in-target
> > if $ROOT is /target. in-target does a bunch of stuff with policy-rc.d,
> > for instance. But I guess that should be safe then...
> 
> For me "in-target" seems to be more convenient.  Of course, logging target
> is different but I think that it is OK for zipl.  The alternative would be
> something like this:
> 
> =
> --- a/debian/zipl-installer.postinst
> +++ b/debian/zipl-installer.postinst
> @@ -57,8 +57,18 @@ EOF
>  sed -e 's/^do_bootloader.*$/do_bootloader = yes/' < 
> /target/etc/kernel-img.conf > /target/etc/kernel-img.conf.$$
>  mv /target/etc/kernel-img.conf.$$ /target/etc/kernel-img.conf
> 
> -mount -t proc none /target/proc || true
> +mount -o bind /proc /target/proc || true
> +mount -o bind /sys /target/sys || true

For running zipl on an (linear) mapped LVM device, the device mapper helper
for zipl (and resp. for chreipl too) requires access to sysfs.  That means
mounting /sys is an important step.  Michael Roesch on CC reported this
issues to me.  With this problem solved (either manually or using in-target)
zipl'ing on linear mapped LVM devices will work.

Thanks and kind regards,
  Hendrik

Bug#710674: please build for s390x

[Hendrik Brueckner]

Control: severity -1 important
Control: tags -1 + patch

Dear maintainer,

hereby yet another request to build makedumpfile for the s390x platform.
The makedumpfile program is required to fully support kdump.

On s390x, makedumpfile is also used to post-process "standalone" dumps.
"Standalone" dumps are dumps created by the traditional dump mechanisms,
DASD dump and zfcp dump utilities.  There are still used and provide a
fallback in case kdump itself fails.

So I have increased to severity of this bug.  Attached is a patch to
enable the build for s390x, as well as, enabling the LZO compression
for makedumpfile.  LZO compression would be nice but is not a must.

Kind regards,
  Hendrik
diff -Nru makedumpfile-1.5.9/debian/changelog 
makedumpfile-1.5.9/debian/changelog
--- makedumpfile-1.5.9/debian/changelog 2015-12-09 15:53:57.0 +0100
+++ makedumpfile-1.5.9/debian/changelog 2016-02-09 15:55:36.0 +0100
@@ -1,3 +1,11 @@
+makedumpfile (1:1.5.9-4) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Build makedumpfile for s390x (Closes: #710674)
+  * Enable LZO compression for makedumpfile
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Tue, 09 Feb 2016 
15:50:33 +0100
+
 makedumpfile (1:1.5.9-3) sid; urgency=medium
 
   * debian/patches/0003-support-kernel-4.2.patch :
diff -Nru makedumpfile-1.5.9/debian/control makedumpfile-1.5.9/debian/control
--- makedumpfile-1.5.9/debian/control   2015-11-24 13:19:43.0 +0100
+++ makedumpfile-1.5.9/debian/control   2016-02-09 15:55:36.0 +0100
@@ -4,12 +4,12 @@
 Maintainer: Louis Bouchard <louis.bouch...@ubuntu.com>
 Standards-Version: 3.9.5
 Build-Depends: debhelper (>= 7.0.50), libelf-dev, libz-dev, libdw-dev (>= 
0.141-2ubuntu1),
-libbz2-dev, dh-systemd (>=1.5), po-debconf
+libbz2-dev, liblzo2-dev, dh-systemd (>=1.5), po-debconf
 Vcs-Git: git://git.debian.org/collab-maint/makedumpfile.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/makedumpfile.git;a=summary
 
 Package: makedumpfile
-Architecture: i386 amd64 powerpc ia64 lpia x32 armel armhf ppc64el
+Architecture: i386 amd64 powerpc ia64 lpia x32 armel armhf ppc64el s390x
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}
 Recommends: crash, kexec-tools
 Replaces: kdump-tools (<< 1.3.4-1~)
diff -Nru makedumpfile-1.5.9/debian/rules makedumpfile-1.5.9/debian/rules
--- makedumpfile-1.5.9/debian/rules 2015-11-20 16:19:35.0 +0100
+++ makedumpfile-1.5.9/debian/rules 2016-02-09 15:55:36.0 +0100
@@ -4,7 +4,7 @@
dh $@ --with=systemd
 
 override_dh_auto_build:
-   dh_auto_build -- LINKTYPE=dynamic
+   dh_auto_build -- LINKTYPE=dynamic USELZO=on
 
 override_dh_installinit:
# Start right after syslog is available, and don't bother stopping

Bug#813506: zipl-installer: set up re-IPL to boot newly installed Debian/Linux

[Hendrik Brueckner]

Hi Philipp,

On Sun, Feb 07, 2016 at 01:31:49AM +0100, Philipp Kern wrote:
> On Tue, Feb 02, 2016 at 05:40:34PM +0100, Hendrik Brueckner wrote:
> > --- a/debian/zipl-installer.postinst
> > +++ b/debian/zipl-installer.postinst
> > @@ -57,8 +57,5 @@ EOF
> >  sed -e 's/^do_bootloader.*$/do_bootloader = yes/' < 
> > /target/etc/kernel-img.conf > /target/etc/kernel-img.conf.$$
> >  mv /target/etc/kernel-img.conf.$$ /target/etc/kernel-img.conf
> >  
> > -mount -t proc none /target/proc || true
> > -
> > -log-output -t zipl-installer chroot /target /sbin/zipl
> > -
> > -umount /target/proc || true
> > +# Run zipl in the installed target instance
> > +in-target /sbin/zipl -V
> 
> I'm a bit sad that this loses the zipl-installer tagging in
> /var/log/syslog because in-target does not support customized logging.
> It will log everything as "in-target".
> 
> At least there's prior art here in grub-installer calling in-target
> if $ROOT is /target. in-target does a bunch of stuff with policy-rc.d,
> for instance. But I guess that should be safe then...

For me "in-target" seems to be more convenient.  Of course, logging target
is different but I think that it is OK for zipl.  The alternative would be
something like this:

=
--- a/debian/zipl-installer.postinst
+++ b/debian/zipl-installer.postinst
@@ -57,8 +57,18 @@ EOF
 sed -e 's/^do_bootloader.*$/do_bootloader = yes/' < 
/target/etc/kernel-img.conf > /target/etc/kernel-img.conf.$$
 mv /target/etc/kernel-img.conf.$$ /target/etc/kernel-img.conf
 
-mount -t proc none /target/proc || true
+mount -o bind /proc /target/proc || true
+mount -o bind /sys /target/sys || true
+mount -o bind /dev /target/dev || true
 
-log-output -t zipl-installer chroot /target /sbin/zipl
+rc=0
+if ! log-output -t zipl-installer chroot /target /sbin/zipl -V; then
+   # Unmount the bound file systems before exiting
+   rc=1
+fi
 
+umount /target/dev || true
+umount /target/sys || true
 umount /target/proc || true
+
+exit $rc
=

The point here is that if zipl fails, the file systems needs to un-mounted.
The "set -e" causes the script to end but with the file systems still mounted.
Because that's exactly what in-target does, I preferred it rather than
sending the patch above.  I am also fine with the patch above if you like
that approach more and keep the zipl logging idenntifier.

> 
> > diff --git a/finish-install.d/70chreipl b/finish-install.d/70chreipl
> > new file mode 100755
> > index 000..ff8bcb9
> > --- /dev/null
> > +++ b/finish-install.d/70chreipl
> > @@ -0,0 +1,3 @@
> > +#!/bin/sh -e
> > +
> > +in-target chreipl /boot || true
> 
> Did you test that /usr/sbin is in PATH? For zipl we specify /sbin
> explicitly. (And yes, those might well be different execution
> environments...)

Yep, I tested this several times.  Of course, using /sbin/chreipl would
be safer here.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen


IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Bug#807442: patch

[Hendrik Brueckner]

Hi Dann,

I have CC'ed Wolfgang who takes care of it from customer service perspective.
Within our team, we received some feedback for your patches that I want to
share with you.

On Fri, Jan 29, 2016 at 04:17:32PM -0700, dann frazier wrote:
> On Sun, Dec 13, 2015 at 03:50:01PM +0100, Philipp Kern wrote:
> > On Tue, Dec 08, 2015 at 03:17:49PM -0700, dann frazier wrote:
> > > diff -Nru s390-tools-1.32.0/debian/changelog 
> > > s390-tools-1.32.0/debian/changelog
> > > --- s390-tools-1.32.0/debian/changelog2015-10-25 17:12:02.0 
> > > +0100
> > > +++ s390-tools-1.32.0/debian/changelog2015-12-08 23:14:52.0 
> > > +0100
> > > @@ -1,3 +1,9 @@
> > > +s390-tools (1.32.0-2) UNRELEASED; urgency=medium
> > > +
> > > +  * Add dbginfo.sh. (Closes: #807442)
> > > +
> > > + -- dann frazier <da...@debian.org>  Tue, 08 Dec 2015 22:33:52 +0100
> > > +
> > >  s390-tools (1.32.0-1) unstable; urgency=medium
> > >  
> > >* New upstream release
> > > diff -Nru s390-tools-1.32.0/debian/s390-tools.install 
> > > s390-tools-1.32.0/debian/s390-tools.install
> > > --- s390-tools-1.32.0/debian/s390-tools.install   2014-07-26 
> > > 23:59:18.0 +0200
> > > +++ s390-tools-1.32.0/debian/s390-tools.install   2015-12-08 
> > > 23:08:30.0 +0100
> > > @@ -10,6 +10,10 @@
> > >  /sbin/dasdview
> > >  /usr/share/man/man8/dasdview.8
> > >  
> > > +# dbginfo.sh
> > > +/sbin/dbginfo.sh
> > > +/usr/share/man/man1/dbginfo.sh.1
> > > +
> > >  # fdasd
> > >  /sbin/fdasd
> > >  /usr/share/man/man8/fdasd.8
> > 
> > Three comments:
> > 
> >  * dbginfo.sh should tell the user that the information in the tarball
> >is sensitive.
> >  * The resulting tarball should be 0600 by default. (The script needs
> >to run as root anyway, but placing the result world-readable in
> >/tmp does not seem smart.)
> >  * Unless this is expected to be in /sbin, given that it's user
> >invoked and not usually scripted, should this be in /usr/sbin
> >instead?
> 
> Good feedback, thanks Philipp! I've addressed all 3 issues in the
> attached updated patch.

> diff -Nru s390-tools-1.32.0/debian/changelog 
> s390-tools-1.32.0/debian/changelog
> --- s390-tools-1.32.0/debian/changelog2015-12-13 09:50:48.0 
> -0500
> +++ s390-tools-1.32.0/debian/changelog2016-01-29 12:56:29.0 
> -0500
> @@ -1,3 +1,12 @@
> +s390-tools (1.32.0-3) UNRELEASED; urgency=medium
> +
> +  * Add dbginfo.sh. (Closes: #807442, LP: #1539719)
> +- dbginfo.sh-umask.patch: Avoid leaking content to unprivileged users.
> +- dbginfo.sh-warn.patch: Warn users about the sensitivity of the data
> +  this tool collects.
> +
> + -- dann frazier <da...@debian.org>  Fri, 29 Jan 2016 12:49:16 -0500
> +
>  s390-tools (1.32.0-2) unstable; urgency=medium
> 
>[ Hendrik Brueckner ]
> diff -Nru s390-tools-1.32.0/debian/patches/dbginfo.sh-umask.patch 
> s390-tools-1.32.0/debian/patches/dbginfo.sh-umask.patch
> --- s390-tools-1.32.0/debian/patches/dbginfo.sh-umask.patch   1969-12-31 
> 19:00:00.0 -0500
> +++ s390-tools-1.32.0/debian/patches/dbginfo.sh-umask.patch   2016-01-29 
> 12:21:06.0 -0500
> @@ -0,0 +1,16 @@
> +Description: dbginfo.sh: set umask to prevent local leaks of sensitive data
> +Author: dann frazier <da...@debian.org>
> +Last-Update: 2016-01-29
> +
> +Index: s390-tools-1.32.0/scripts/dbginfo.sh
> +===
> +--- s390-tools-1.32.0.orig/scripts/dbginfo.sh
>  s390-tools-1.32.0/scripts/dbginfo.sh
> +@@ -12,6 +12,7 @@ export LC_ALL
> + # The general name of this script
> + readonly SCRIPTNAME="${0##*/}"
> + 
> ++umask 0077

This is tricky and probaly leads to changed permissions that might be useful
to detect permissions problem.  Wolfgang and team worked on this topic and
a problem fix will be provided with the next s390-tools version.  The idea
here is to change the permission of the directory which will be created to
contain all service data.

> + 
> + 
> + # print version info
> diff -Nru s390-tools-1.32.0/debian/patches/dbginfo.sh-warn.patch 
> s390-tools-1.32.0/debian/patches/dbginfo.sh-warn.patch
> --- s390-tools-1.32.0/debian/patches/dbginfo.sh-warn.patch1969-12-31 
> 19:00:00.0 -0500
> +++ s390-tools-1.32.0/debian/patches/dbginfo.sh-warn.patch2016-01-29 
> 12:32:51.0 -0500
> @@ -0,0 +1,

Bug#813519: s390/template-arch: set always_halt to false to allow reboots

[Hendrik Brueckner]

Control: tags -1 + patch

>From 6790a25873838a265282bf5e97fa36d21cfebfbc Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Tue, 2 Feb 2016 17:24:09 +0100
Subject: [PATCH] templates-arch: reset always_halt to its default for s390

Remove the s390 specific defaults for always_halt and reset it back
to false.  This allows the installer to boot into the newly installed
Linux instance on System z.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/changelog  | 8 +++-
 debian/templates-arch | 2 --
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 30e64ca..0171f5d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
 rootskel (1.114) UNRELEASED; urgency=medium
 
+  [ Colin Watson ]
   * Use HTTPS for Vcs-* URLs, and link to cgit rather than gitweb.
 
- -- Colin Watson <cjwat...@debian.org>  Fri, 29 Jan 2016 13:35:23 +
+  [ Hendrik Brueckner ]
+  * templates-arch: Set always_halt to false for s390 to allow rebooting
+into the newly installed Linux instances.  See also #813506.
+(Closes: #813519)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Tue, 02 Feb 2016 
16:40:34 +0100
 
 rootskel (1.113) unstable; urgency=medium
 
diff --git a/debian/templates-arch b/debian/templates-arch
index f90854e..cf3a0e6 100644
--- a/debian/templates-arch
+++ b/debian/templates-arch
@@ -8,8 +8,6 @@ Description: for internal use; can be preseeded
 Template: debian-installer/exit/always_halt
 Type: boolean
 Default: false
-Default[s390]: true
-Default[s390x]: true
 Description: for internal use only
  Always halt the machine
 
-- 
2.7.0.rc3

Bug#813519: s390/template-arch: set always_halt to false to allow reboots

[Hendrik Brueckner]

Package: rootskel
Version: 1.113
Severity: normal
Tags: d-i

Dear maintainer,

I work on some installer improvements for Linux on z Systems (s390).
After the installation completed, the newly installed Linux instance
is not booted; instead, the installer halts the system.  The reason
is a different default for the always_halt setting in templates-arch.

To prepare the re-IPL settings to boot the newly installed Linux
instance, the chreipl must be called.  I opened bug #813506 [1] for
the zipl-installer package to call chreipl.

I will attach a patch with changelog information soon.

Thanks and kind regards,
  Hendrik

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813506

Bug#813519: s390/template-arch: set always_halt to false to allow reboots

[Hendrik Brueckner]

Control: block -1 by 813506

Bug#813506: zipl-installer: set up re-IPL to boot newly installed Debian/Linux

[Hendrik Brueckner]

Control: tags -1 + patch

On Tue, Feb 02, 2016 at 04:56:51PM +0100, Hendrik Brueckner wrote:
> 
> Patches with changelog information will be added soon by me.
> 

Attached patch to simply the call to zipl and chreipl using the
in-target command.  The in-target command prepares an environment
with /dev, /sys, and /proc file systems mounted.  This is necessary
for both, zipl and chreipl, for calling their helper programs for
mapped devices.

The second patch is just an update to the debian/changelog for
convenience.

Thanks and kind regards,
  Hendrik
>From 799975b0ca9dd609929f23670475d2160e7ec145 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Wed, 2 Dec 2015 11:17:23 +0100
Subject: [PATCH 1/2] zipl-installer: use in-target to run zipl and also setup
 re-IPL settings

To IPL from device mapper devices, zipl runs its zipl_helper.device_mapper
to obtain IPL device information.  To ensure /sys, /dev, and /proc are
properly mounted, use the "in-target" command.  in-targe prepares a chroot
environment for running commands within the newly installed Linux instance.

The zipl command is called with -V to display verbose information about
the installed Linux kernels and boot map.

Also use the in-target to run chreipl to prepare the boot of newly
installed Linux instances at the end of the installation.  Note that
chreipl also use a helper to detect the IPL device for linear mapped
devices, for example, LVM or multipath devices.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/zipl-installer.install  | 1 +
 debian/zipl-installer.postinst | 7 ++-
 finish-install.d/70chreipl | 3 +++
 3 files changed, 6 insertions(+), 5 deletions(-)
 create mode 100644 debian/zipl-installer.install
 create mode 100755 finish-install.d/70chreipl

diff --git a/debian/zipl-installer.install b/debian/zipl-installer.install
new file mode 100644
index 000..45307a4
--- /dev/null
+++ b/debian/zipl-installer.install
@@ -0,0 +1 @@
+finish-install.d   usr/lib
diff --git a/debian/zipl-installer.postinst b/debian/zipl-installer.postinst
index 48e5e48..147776c 100755
--- a/debian/zipl-installer.postinst
+++ b/debian/zipl-installer.postinst
@@ -57,8 +57,5 @@ EOF
 sed -e 's/^do_bootloader.*$/do_bootloader = yes/' < 
/target/etc/kernel-img.conf > /target/etc/kernel-img.conf.$$
 mv /target/etc/kernel-img.conf.$$ /target/etc/kernel-img.conf
 
-mount -t proc none /target/proc || true
-
-log-output -t zipl-installer chroot /target /sbin/zipl
-
-umount /target/proc || true
+# Run zipl in the installed target instance
+in-target /sbin/zipl -V
diff --git a/finish-install.d/70chreipl b/finish-install.d/70chreipl
new file mode 100755
index 000..ff8bcb9
--- /dev/null
+++ b/finish-install.d/70chreipl
@@ -0,0 +1,3 @@
+#!/bin/sh -e
+
+in-target chreipl /boot || true
-- 
2.7.0.rc3

>From 8bfc5c2087f8e1ac667b6bfa5b3c12511eb22e03 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Mon, 18 Jan 2016 15:01:35 +0100
Subject: [PATCH 2/2] changelog: update changelog for 0.0.31

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/changelog | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 9782ffb..a4b3b2f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,15 @@
 zipl-installer (0.0.31) UNRELEASED; urgency=medium
 
+  [ Colin Watson ]
   * Use HTTPS for Vcs-* URLs, and link to cgit rather than gitweb.
 
- -- Colin Watson <cjwat...@debian.org>  Fri, 29 Jan 2016 13:35:24 +
+  [ Hendrik Brueckner ]
+  * postinst/finish-install: use in-target to run zipl and chreipl.
+The chreipl command prepares and configures the re-IPL settings
+to boot the newly installed Linux instance after installation.
+(Closes: #813506)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Mon, 18 Jan 2016 
14:54:44 +0100
 
 zipl-installer (0.0.30) unstable; urgency=medium
 
-- 
2.7.0.rc3

Bug#813506: zipl-installer: set up re-IPL to boot newly installed Debian/Linux

[Hendrik Brueckner]

Package: zipl-installer
Version: 0.0.30
Severity: normal
Tags: d-i

Hi,

I have a small enhancement on the zipl-installer package to prepare and
set up the re-IPL settings to boot into the newly installed Linux instance.

To set up the re-IPL settings, a call to chreipl is required from within
the installed system.  This is required beccause chreipl uses a helper
script to detect the IPL device for linear mapped devices, for example,
LVM or multipath devices.

Note that there is also a change required for the rootskel package to
reset the debian-installer/exit/always_halt to false.

Patches with changelog information will be added soon by me.

Thanks and kind regards,
  Hendrik

Bug#813098: hwup-ccw-group: fail to configure qeth if device is built into kernel

[Hendrik Brueckner]

Package: sysconfig-hardware
Version: 0.0.11
Severity: normal

Hi,

booting Debian with a kernel that has the qeth device drivers (core, l2, and l3)
compiled into the kernel, the network interfaces fail to come up.

For example, consider this configuration:

root@localhost:~# cat /etc/sysconfig/hardware/config-ccw-0.0.f100 
CCWGROUP_CHANS=(0.0.f100 0.0.f101 0.0.f102)
QETH_PORTNAME=OSAPORT
QETH_PORTNO=0
QETH_OPTIONS=()
INTERFACE_NAME=eth1

running the "hwup" command results in this error message:

root@localhost:~# hwup ccw 0.0.f100
no kernel module for qeth devices available!

Looking at the "hwup-ccw-group" script, the affect place is:

elif [ "$NAME" == qeth ]; then
  modprobe qeth 2> /dev/null || :

  if [ -d $SYSFS/module/qeth ]; then
DRIVER=qeth
  else
error "no kernel module for qeth devices available!"
  fi
fi

If the qeth device drivers are built into the kernel, the modprobe fails but
this case is properly handled.  However, if qeth is built-in, there is no
"$SYSFS/module/qeth" directory.

The solution is to update the check and test for a different directory.  The
preferred directory is:

/sys/bus/ccw/drivers/qeth

which will be created when the qeth device driver is loaded (either built-in
or after a modprobe).

Thanks and kind regards,
  Hendrik

Bug#813089: qeth/ctc: correct stack corruption for numerous qeth/ctc devices

[Hendrik Brueckner]

Package: s390-netdevice
Version: 0.0.39
Severity: important
Tags: d-i patch

Hi,

the s390-netdevice fails to display the list of qeth netword device if there
are numerous network devices available.  For example, with 68 or more qeth
network devices (each consisting of 3 devices).

The problem is a static buffer defined on the stack of the get_ctc_channels()
and get_qeth_device() functions.  When iterating through the tree/list of
network devices, the buffer is filled to be later displayed to the user.
The strncat() function writes beyond the end the of the buffer and corrupts
the function stack.

To solve this problem, the buffer that contains the network device list is
dynamically allocated.  The buffer size is determined from the number of
network devices.

Thanks and kind regards,
  Hendrik
>From 223ebc92969fcb5996aef83e4bfdfe93f2861c51 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Thu, 21 Jan 2016 19:53:36 +0100
Subject: [PATCH 2/3] netdevice: correct stack corruption due to numerous
 devices

If there are numerous network devices present, the size of the
static buffer (on the stack) is exceeded and the program fails.

Dynamically allocate memory to create a complete list of channel
devices to be displayed to the user.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 netdevice.c | 89 ++---
 1 file changed, 68 insertions(+), 21 deletions(-)

diff --git a/netdevice.c b/netdevice.c
index b8512fb..c886170 100644
--- a/netdevice.c
+++ b/netdevice.c
@@ -85,6 +85,12 @@ static const struct driver drivers[] =
{ "qeth", CHANNEL_TYPE_QETH },
 };
 
+struct buffer_desc
+{
+   char  *buf;
+   size_t size;
+};
+
 enum
 {
TYPE_NONE = 0,
@@ -314,54 +320,76 @@ static di_hfunc get_ctc_channels_append;
 static void get_ctc_channels_append (void *key __attribute__ ((unused)), void 
*value, void *user_data)
 {
struct channel *channel = value;
-   char *buf = user_data;
+   struct buffer_desc *bd = user_data;
+
if (channel->type == CHANNEL_TYPE_CU3088_CTC)
-   {
-   if (buf[0])
-   strncat (buf, ", ", 64 * 8);
-   strncat (buf, channel->name, 64 * 8);
-   }
+   di_snprintfcat (bd->buf, bd->size, "%s%s",
+   bd->buf[0] ? ", " : "",
+   channel->name);
 }
 
 static enum state_wanted get_ctc_channels (void)
 {
-   char buf[64 * 8] = { 0 }, *ptr;
const char *template;
+   struct buffer_desc bd;
int dev, ret;
+   char *ptr;
 
-   di_tree_foreach (channels, get_ctc_channels_append, buf);
+   /* Allocate memory to create the complete list of channels,
+* account 2 characters as list separator, 9 characters to
+* contain the channel bus-ID (xx.y.), and a NUL to end
+* the string.
+*/
+   bd.size = di_tree_size (channels) * (2 + 9 + 1);
+   bd.buf = di_malloc0 (bd.size);
 
-   if (!strlen (buf))
+   di_tree_foreach (channels, get_ctc_channels_append, );
+
+   if (!strlen (bd.buf))
{
my_debconf_input ("critical", TEMPLATE_PREFIX "ctc/no", );
+   di_free (bd.buf);
return WANT_BACKUP;
}
 
template = TEMPLATE_PREFIX "ctc/choose_read";
-   debconf_subst (client, template, "choices", buf);
+   debconf_subst (client, template, "choices", bd.buf);
debconf_input (client, "critical", template);
ret = debconf_go (client);
if (ret == 30)
+   {
+   di_free (bd.buf);
return WANT_BACKUP;
+   }
if (ret)
+   {
+   di_free (bd.buf);
return WANT_ERROR;
+   }
debconf_get (client, template);
 
dev = channel_device (client->value);
device_current->ctc.channels[0] = di_tree_lookup (channels, );
 
template = TEMPLATE_PREFIX "ctc/choose_write";
-   debconf_subst (client, template, "choices", buf);
+   debconf_subst (client, template, "choices", bd.buf);
debconf_input (client, "critical", template);
ret = debconf_go (client);
if (ret == 30)
+   {
+   di_free (bd.buf);
return WANT_BACKUP;
+   }
if (ret)
+   {
+   di_free (bd.buf);
return WANT_ERROR;
+   }
debconf_get (client, template);
 
dev = channel_device (client->value);
device_current->ctc.channels[1] = di_tree_lookup (channels, );
+   di_free (bd.buf);
 
return WANT_NEXT;
 }
@@ -408,41 +436,60 @@ static di_hfunc get_qeth_device_append;
 static void get_qeth_device_append (void *key __att

Bug#813121: qeth: layer2 and portno are not substituted in template

[Hendrik Brueckner]

Package: s390-netdevice
Version: 0.0.39
Severity: minor
Tags: d-i patch

Hi,

the layer2 and portno settings for qeth devices are not substituted
in the "qeth/confirm" template.  Below is a patch that calls
debconf_subst() to insert the specified settings for confirmation by
the user.

Thanks and kind regards,
  Hendrik
>From 6a73bf95b59885fb484569ac2439057c3a90cbd4 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 20 Nov 2015 14:18:12 +0100
Subject: [PATCH 1/3] qeth: substitute layer and port number in qeth/confirm
 template

The layer and relative port number variables are not substitued for
the "qeth/confirm" dialog.  Hence, call debconf_subst() to provide
this information to the user.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 netdevice.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/netdevice.c b/netdevice.c
index 6905c2d..b8512fb 100644
--- a/netdevice.c
+++ b/netdevice.c
@@ -541,7 +541,11 @@ static enum state_wanted confirm_qeth (void)
const char *template = TEMPLATE_PREFIX "qeth/confirm";
int ret;
char *ptr;
+   char *layer2 = device_current->qeth.layer2 ? "yes" : "no";
+   char *portno = device_current->qeth.port ? "1" : "0";
 
+   debconf_subst (client, template, "layer2", layer2);
+   debconf_subst (client, template, "port", portno);
debconf_subst (client, template, "device0", 
device_current->qeth.channels[0]->name);
debconf_subst (client, template, "device1", 
device_current->qeth.channels[1]->name);
debconf_subst (client, template, "device2", 
device_current->qeth.channels[2]->name);
-- 
2.7.0.rc3

Bug#813030: zipl-installer: remove obsolete portname

[Hendrik Brueckner]

Package: zipl-installer
Version: 0.0.38
Severity: minor
Tags: d-i patch

Hi,

this a small patch to remove the portname attribute.  The attribute
is obsolete and cannot be changed anymore.  Further it will be removed
in a future kernel version.

See also the attached patch.


Thanks and kind regards,
  Hendrik
>From 912031a56bb9271a0e8b4bbb90118bb6ae7fc72e Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 20 Nov 2015 11:09:23 +0100
Subject: [PATCH 1/4] qeth: remove portname

The portname attribute is no longer necessary and will be removed soon.
See also upstream kernel commit:

commit 239ff408ddd8fa7a19c53ed247daec855ff11ea2
Author: Ursula Braun <ursula.br...@de.ibm.com>
Date:   Fri Sep 18 16:06:50 2015 +0200

qeth: move OSA portname into deprecated status

An OSA-Express port name was required to identify a shared OSA port.
All operating system instances that shared the port had to use the
same port name. This requirement no longer applies.

Signed-off-by: Ursula Braun <ursula.br...@de.ibm.com>
Signed-off-by: David S. Miller <da...@davemloft.net>

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/po/templates.pot | 17 -
 debian/s390-netdevice.templates | 15 ---
 netdevice.c | 28 
 3 files changed, 4 insertions(+), 56 deletions(-)

diff --git a/debian/po/templates.pot b/debian/po/templates.pot
index f6bae74..dabf4e2 100644
--- a/debian/po/templates.pot
+++ b/debian/po/templates.pot
@@ -166,7 +166,6 @@ msgid ""
 "The configured parameters are:\n"
 " channels = ${device0}, ${device1}, ${device2}\n"
 " port = ${port}\n"
-" portname = ${portname}\n"
 " layer2   = ${layer2}"
 msgstr ""
 
@@ -190,22 +189,6 @@ msgstr ""
 #. Description
 #. :sl5:
 #: ../s390-netdevice.templates:10001
-msgid "Portname:"
-msgstr ""
-
-#. Type: string
-#. Description
-#. :sl5:
-#: ../s390-netdevice.templates:10001
-msgid ""
-"Please enter the portname of your OSA-Express card. This name must be 1 to 8 "
-"characters long and must be equal on all systems accessing the same card."
-msgstr ""
-
-#. Type: string
-#. Description
-#. :sl5:
-#: ../s390-netdevice.templates:10001
 msgid ""
 "Leave it empty if you want to use HiperSockets. This parameter is required "
 "for cards with microcode level 2.10 or later or when you want to share a "
diff --git a/debian/s390-netdevice.templates b/debian/s390-netdevice.templates
index aa641f2..39fc0b7 100644
--- a/debian/s390-netdevice.templates
+++ b/debian/s390-netdevice.templates
@@ -64,7 +64,6 @@ _Description: Do you accept this configuration?
  The configured parameters are:
   channels = ${device0}, ${device1}, ${device2}
   port = ${port}
-  portname = ${portname}
   layer2   = ${layer2}
 
 Template: s390-netdevice/qeth/no
@@ -74,20 +73,6 @@ _Description: No OSA-Express QDIO cards / HiperSockets
  No OSA-Express QDIO cards / HiperSockets were detected. If you are running
  VM please make sure that your card is attached to this guest.
 
-Template: s390-netdevice/qeth/portname
-Type: string
-# :sl5:
-_Description: Portname:
- Please enter the portname of your OSA-Express card. This name must be 1 to
- 8 characters long and must be equal on all systems accessing the same
- card.
- .
- Leave it empty if you want to use HiperSockets. This parameter is
- required for cards with microcode level 2.10 or later or when you want to
- share a card.
- .
- The name will automatically be converted to uppercase.
-
 Template: s390-netdevice/qeth/port
 Type: string
 Default: 0
diff --git a/netdevice.c b/netdevice.c
index a4e1aea..6ddece9 100644
--- a/netdevice.c
+++ b/netdevice.c
@@ -60,7 +60,6 @@ struct device
struct channel *channels[3];
bool layer2;
int port;
-   char portname[32];
} qeth;
struct
{
@@ -109,7 +108,6 @@ enum state
GET_QETH_DEVICE,
GET_QETH_LAYER2,
GET_QETH_PORT,
-   GET_QETH_PORTNAME,
GET_IUCV_DEVICE,
GET_IUCV_PEER,
CONFIRM_CTC,
@@ -479,27 +477,13 @@ static enum state_wanted get_qeth_port (void)
return WANT_NEXT;
 }
 
-static enum state_wanted get_qeth_portname_iucv_peer (enum state state)
+static enum state_wanted get_iucv_peer (void)
 {
-   const char *template = NULL;
char *ptr, *tmp;
int ret, i, j;
 
-   switch (state)
-   {
-   case GET_QETH_PORTNAME:
-   template = TEMPLATE_PREFIX "qeth/portname";
-   tmp = device_current->qeth.portname;
-   break;
-   case GET_IUCV_PEER:
- 

Bug#813033: qeth: ask for relative OSA port number

[Hendrik Brueckner]

Package: s390-netdevice
Version: 0.0.38
Severity: important
Tags: d-i patch

Hi,

below is another patch for the s390-netdevice regarding qeth device
configuration.  Some cards require the specification of the relative
port number on the OSA card.   Ths s390-netdevice has template and
state information for this attribute but lacks the actual
implementation.

The attached patch will let the user specify the relative OSA port
number.  The setting can also be preseeded if necessary.


Thanks and kind regards,
  Hendrik
>From 439483cd533d865d96a8c8119b221e9a56f25925 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 20 Nov 2015 12:57:36 +0100
Subject: [PATCH 2/4] qeth: ask for the relative OSA port number

Let the user specify the port number because this is required for
particular OSA cards.

Reported-by: Elisabeth Puritscher <elisabeth.puritsc...@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 netdevice.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/netdevice.c b/netdevice.c
index 6ddece9..6905c2d 100644
--- a/netdevice.c
+++ b/netdevice.c
@@ -638,6 +638,22 @@ static enum state_wanted write_sysfs (void)
syslog (LOG_ERR, "Can't write ccwgroup device attribute 
layer2");
return WANT_ERROR;
}
+
+   /* Set the relative port number.
+* Valid port numbers are 0 (default) or 1
+*/
+   if (device_current->qeth.port)
+   {
+   attr = sysfs_get_device_attr (device, "portno");
+   if (attr)
+   {
+   if (sysfs_write_attribute (attr, "1", 1) < 0)
+   {
+   syslog (LOG_ERR, "Could not write 
device attribute portno");
+   return WANT_ERROR;
+   }
+   }
+   }
}
 
attr = sysfs_get_device_attr (device, "online");
@@ -703,6 +719,7 @@ static enum state_wanted write_qeth (void)
 
if (device_current->qeth.layer2)
fprintf (config, "QETH_OPTIONS=(layer2)\n");
+   fprintf (config, "QETH_PORTNO=%d", device_current->qeth.port);
 
fclose (config);
 
@@ -837,8 +854,7 @@ int main (int argc __attribute__ ((unused)), char *argv[] 
__attribute__ ((unused
state = GET_QETH_LAYER2;
break;
case GET_QETH_LAYER2:
-   /* state = GET_QETH_PORT; */
-   state = CONFIRM_QETH;
+   state = GET_QETH_PORT;
break;
case GET_QETH_PORT:
state = CONFIRM_QETH;
-- 
2.7.0.rc3

Bug#813030: zipl-installer: remove obsolete portname

[Hendrik Brueckner]

Control: reassign -1 s390-netdevice
Control: retitle -1 s390-netdevice/qeth: remove obsolete portname

Bug#812336: [s390x] udeb: include modules to mount ISOs (loop device)

[Hendrik Brueckner]

Hi,

On Sat, Jan 23, 2016 at 10:01:44PM +0100, Philipp Kern wrote:
> On Fri, Jan 22, 2016 at 02:52:09PM +0100, Hendrik Brueckner wrote:
> > for mounting ISO images within the Debian Installer, the loop and ISO file
> > system module udebs are missing and should be included. I will attach a
> > patch to resolve this issue.
> > 
> > These module udebs are required by the the iso-scan/load-iso debian 
> > installer
> > packages.
> 
> that sounds good to me. For context: This makes sense now that KVM is
> supported on s390x and you can attach CD drives to a VM.

Correct.

Another use case is a particular type of installation: Put an ISO image on a
DASD or SCSI disk in future.  In the installer, set the DASD/SCSI disk online
and then use the iso-scan/load-iso modules to mount and search for the ISO
image to proceed installation.  That way, an external network connection might
not be required.

Thanks and kind regards,
  Hendrik

Bug#812588: install/ziomon: include FCP performance monitoring utilities

[Hendrik Brueckner]

Package: s390-tools
Version: 1.32.0-2
Severity: normal

Hi,

I am going to attach a patch that includes the ziomon utilities.
The ziomon program collects data relevant to FCP performance,
such as the FCP I/O configuration, I/O workload, and the utilization
of FCP resources.  The ziomon includes additional programs to generate
reports from the collected performance data.

Patch will follow...

Thanks and kind regards,
  Hendrik

Bug#812588: install/ziomon: include FCP performance monitoring utilities

[Hendrik Brueckner]

Control: tags -1 + patch

On Mon, Jan 25, 2016 at 12:09:12PM +0100, Hendrik Brueckner wrote:
> I am going to attach a patch that includes the ziomon utilities.
> The ziomon program collects data relevant to FCP performance,
> such as the FCP I/O configuration, I/O workload, and the utilization
> of FCP resources.  The ziomon includes additional programs to generate
> reports from the collected performance data.

Below you can find a patch that includes the ziomon suite of utilities.

Note that the integration of ziomon requires additional dependencies on
blktrace, rsync, and tar, as well as, some updates on the recommends.

I have declared these dependencies in the control file for the s390-tools
package.  An alternative approach would be to integrate ziomon in its own
(sub)package.  Administrators could then decide to install ziomon if they
require its functionality.

What do you think?

Thanks and kind regards,
  Hendrik
diff -Nru s390-tools-1.32.0/debian/changelog s390-tools-1.32.0/debian/changelog
--- s390-tools-1.32.0/debian/changelog  2016-01-20 14:37:09.0 +0100
+++ s390-tools-1.32.0/debian/changelog  2016-01-25 12:18:49.0 +0100
@@ -1,3 +1,10 @@
+s390-tools (1.32.0-4) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Add zfcp monitoring and reporting tools (ziomon) (Closes: #812588)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Mon, 25 Jan 2016 
11:49:05 +0100
+
 s390-tools (1.32.0-3) UNRELEASED; urgency=medium
 
   [ Hendrik Brueckner ]
diff -Nru s390-tools-1.32.0/debian/control s390-tools-1.32.0/debian/control
--- s390-tools-1.32.0/debian/control2015-12-13 15:41:14.0 +0100
+++ s390-tools-1.32.0/debian/control2016-01-25 12:03:53.0 +0100
@@ -9,8 +9,8 @@
 
 Package: s390-tools
 Architecture: s390 s390x
-Depends: ${shlibs:Depends}, ${misc:Depends}, gawk
-Recommends: sg3-utils
+Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, blktrace, rsync, tar
+Recommends: sg3-utils, multipath-tools, lsscsi
 Description: A set of fundamental utilities for Linux on S/390
  The package contains:
   * dasdfmt, which is used to low-level format ECKD-DASDs with either
diff -Nru s390-tools-1.32.0/debian/s390-tools.install 
s390-tools-1.32.0/debian/s390-tools.install
--- s390-tools-1.32.0/debian/s390-tools.install 2016-01-20 14:00:29.0 
+0100
+++ s390-tools-1.32.0/debian/s390-tools.install 2016-01-25 12:24:02.0 
+0100
@@ -111,6 +111,24 @@
 /usr/share/man/man5/zipl.conf.5
 /usr/share/man/man8/zipl.8
 
+# ziomon
+/usr/sbin//ziomon
+/usr/sbin//ziomon_util
+/usr/sbin//ziomon_mgr
+/usr/sbin//ziomon_zfcpdd
+/usr/sbin//ziomon_fcpconf
+/usr/sbin//ziorep_config
+/usr/sbin//ziorep_utilization
+/usr/sbin//ziorep_traffic
+/usr/share/man/man8/ziomon.8
+/usr/share/man/man8/ziomon_util.8
+/usr/share/man/man8/ziomon_mgr.8
+/usr/share/man/man8/ziomon_zfcpdd.8
+/usr/share/man/man8/ziomon_fcpconf.8
+/usr/share/man/man8/ziorep_config.8
+/usr/share/man/man8/ziorep_utilization.8
+/usr/share/man/man8/ziorep_traffic.8
+
 # hyptop
 /usr/sbin/hyptop
 /usr/share/man/man8/hyptop.8

Bug#812336: [s390x] udeb: include modules to mount ISOs (loop device)

[Hendrik Brueckner]

Control: tags -1 + patch

Attached patch to add the module udebs.
>From 29c5deff3510c2e326c2f4d9c35d0c3dddf5dab2 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 22 Jan 2016 14:37:59 +0100
Subject: [PATCH] [s390x] udeb: include modules to mount ISOs (loop device)

To mount ISO images within the Debian Installer, the loop device
support is required.  Also the CD/DVD file systems are required too.

Hence, add the ISO and UDF file systems modules, as well as, the
loop device modules.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/changelog   | 8 
 debian/installer/s390x/modules/s390x/isofs-modules | 1 +
 debian/installer/s390x/modules/s390x/loop-modules  | 1 +
 debian/installer/s390x/modules/s390x/udf-modules   | 1 +
 4 files changed, 11 insertions(+)
 create mode 100644 debian/installer/s390x/modules/s390x/isofs-modules
 create mode 100644 debian/installer/s390x/modules/s390x/loop-modules
 create mode 100644 debian/installer/s390x/modules/s390x/udf-modules

diff --git a/debian/changelog b/debian/changelog
index 83d54a0..8178765 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+linux (4.3.3-8) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * [s390x] udeb: include modules to mount ISOs (loop device)
+(Closes: #812336)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Fri, 22 Jan 2016 
14:34:21 +0100
+
 linux (4.3.3-7) unstable; urgency=medium
 
   * linux-image-dbg: Don't rely on upstream makefile to make .build-id
diff --git a/debian/installer/s390x/modules/s390x/isofs-modules 
b/debian/installer/s390x/modules/s390x/isofs-modules
new file mode 100644
index 000..da4fa9a
--- /dev/null
+++ b/debian/installer/s390x/modules/s390x/isofs-modules
@@ -0,0 +1 @@
+#include 
diff --git a/debian/installer/s390x/modules/s390x/loop-modules 
b/debian/installer/s390x/modules/s390x/loop-modules
new file mode 100644
index 000..c1c948f
--- /dev/null
+++ b/debian/installer/s390x/modules/s390x/loop-modules
@@ -0,0 +1 @@
+#include 
diff --git a/debian/installer/s390x/modules/s390x/udf-modules 
b/debian/installer/s390x/modules/s390x/udf-modules
new file mode 100644
index 000..b90d7ee
--- /dev/null
+++ b/debian/installer/s390x/modules/s390x/udf-modules
@@ -0,0 +1 @@
+#include 
-- 
2.3.9

Bug#812336: [s390x] udeb: include modules to mount ISOs (loop device)

[Hendrik Brueckner]

Package: src:linux
Version: 4.3.0-1
Severity: normal
Tags: d-i

Ben,

for mounting ISO images within the Debian Installer, the loop and ISO file
system module udebs are missing and should be included. I will attach a
patch to resolve this issue.

These module udebs are required by the the iso-scan/load-iso debian installer
packages.

Thanks and kind regards,
  Hendrik

Bug#812340: [s390x] udeb: include btrfs-modules

[Hendrik Brueckner]

Package: src:linux
Version: 4.3.0-1
Severity: normal
Tags: d-i

Ben,

here is yet another debian-installer udeb request.  The btrfs module udeb is not
included.  Apart from the btrfs-modules udeb, the zlib-modules is also
required to resolve zlib_deflate dependency.   Again, patch follows.

Kind regards,
  Hendrik

Bug#812340: [s390x] udeb: include btrfs-modules

[Hendrik Brueckner]

Control: tags -1 + patch

Attached the patch to add the btrfs-modules udeb.  You might apply
the patch after #812336 "[s390x] udeb: include modules to mount ISOs".

Thanks.
>From 4129f8f8619c414af98795d3ef63aad11d13f473 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 22 Jan 2016 15:39:53 +0100
Subject: [PATCH] [s390x] udeb: include btrfs-modules

Add btrfs-modules udeb.  Also add zlib-modules udeb because btrfs
requires zlib_deflate.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/changelog   | 3 ++-
 debian/installer/s390x/modules/s390x/btrfs-modules | 1 +
 debian/installer/s390x/modules/s390x/zlib-modules  | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)
 create mode 100644 debian/installer/s390x/modules/s390x/btrfs-modules
 create mode 100644 debian/installer/s390x/modules/s390x/zlib-modules

diff --git a/debian/changelog b/debian/changelog
index 890dad8..3b8f8d7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,8 +3,9 @@ linux (4.3.3-8) UNRELEASED; urgency=medium
   [ Hendrik Brueckner ]
   * [s390x] udeb: include modules to mount ISOs (loop device)
 (Closes: #812336)
+  * [s390x] udeb: include btrfs-modules (Closes: #812340)
 
- -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Fri, 22 Jan 2016 
14:34:21 +0100
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Fri, 22 Jan 2016 
15:21:08 +0100
 
 linux (4.3.3-7) unstable; urgency=medium
 
diff --git a/debian/installer/s390x/modules/s390x/btrfs-modules 
b/debian/installer/s390x/modules/s390x/btrfs-modules
new file mode 100644
index 000..e261e13
--- /dev/null
+++ b/debian/installer/s390x/modules/s390x/btrfs-modules
@@ -0,0 +1 @@
+#include 
diff --git a/debian/installer/s390x/modules/s390x/zlib-modules 
b/debian/installer/s390x/modules/s390x/zlib-modules
new file mode 100644
index 000..e02ad64
--- /dev/null
+++ b/debian/installer/s390x/modules/s390x/zlib-modules
@@ -0,0 +1 @@
+#include 
-- 
2.3.9

Bug#812092: s390-tools/install: package additional management utilities

[Hendrik Brueckner]

Package: s390-tools
Version: 1.32.0-2
Severity: normal
Tags:

Package and install additional management tools:

- lschp and chchp to list and manage channel-paths (CHPIDs)
- dasdstat to display DASD statistics
- cio_ignore to manage CIO blacklists and devices visible to the Linux
  instance
- znetconf to configure and manage network devices

Patch will follow.

Thanks and kind regards,
  Hendrik

Bug#812092: s390-tools/install: package additional management utilities

[Hendrik Brueckner]

Control: tags -1 + patch

Attaching the debdiff with the change for the s390-tools.install file.
diff -Nru s390-tools-1.32.0/debian/changelog s390-tools-1.32.0/debian/changelog
--- s390-tools-1.32.0/debian/changelog  2015-12-13 15:50:48.0 +0100
+++ s390-tools-1.32.0/debian/changelog  2016-01-20 14:37:09.0 +0100
@@ -1,3 +1,12 @@
+s390-tools (1.32.0-3) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Clean up lsluns comment leftovers
+  * Install additional management utilities: lschp, chchp, dasdstat,
+cio_ignore, and znetconf with its related files. (Closes: #812092)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Tue, 19 Jan 2016 
10:41:20 +0100 
+
 s390-tools (1.32.0-2) unstable; urgency=medium
 
   [ Hendrik Brueckner ]
diff -Nru s390-tools-1.32.0/debian/s390-tools.install 
s390-tools-1.32.0/debian/s390-tools.install
--- s390-tools-1.32.0/debian/s390-tools.install 2015-12-13 15:47:24.0 
+0100
+++ s390-tools-1.32.0/debian/s390-tools.install 2016-01-20 14:00:29.0 
+0100
@@ -10,6 +10,10 @@
 /sbin/dasdview
 /usr/share/man/man8/dasdview.8
 
+# dasdstat
+/sbin/dasdstat
+/usr/share/man/man8/dasdstat.8
+
 # fdasd
 /sbin/fdasd
 /usr/share/man/man8/fdasd.8
@@ -41,10 +45,22 @@
 /sbin/qethconf
 /usr/share/man/man8/qethconf.8
 
+# znetconf
+/sbin/znetconf
+/lib/s390-tools/lsznet.raw
+/lib/s390-tools/znetcontrolunits
+/usr/share/man/man8/znetconf.8
+
 # lsluns
 /usr/sbin/lsluns
 /usr/share/man/man8/lsluns.8
 
+# channel path management
+/sbin/lschp
+/usr/share/man/man8/lschp.8
+/sbin/chchp
+/usr/share/man/man8/chchp.8
+
 # tape390
 /sbin/tape390_display
 /usr/share/man/man8/tape390_display.8
@@ -64,18 +80,16 @@
 # zconf
 /sbin/chccwdev
 /usr/share/man/man8/chccwdev.8
+/sbin/cio_ignore
+/usr/share/man/man8/cio_ignore.8
 /usr/sbin/chmem
 /usr/share/man/man8/chmem.8
 /sbin/chzcrypt
 /usr/share/man/man8/chzcrypt.8
-/sbin/lschp
-/usr/share/man/man8/lschp.8
 /sbin/lscss
 /usr/share/man/man8/lscss.8
 /sbin/lsdasd
 /usr/share/man/man8/lsdasd.8
-#/sbin/lsluns
-#/usr/share/man/man8/lsluns.8
 /usr/sbin/lsmem
 /usr/share/man/man8/lsmem.8
 /sbin/lsqeth

Bug#811391: finish-install.d/07speakup: remove superfluous 'fi' leftover

[Hendrik Brueckner]

Control: tags -1 + patch

Attaching patch.
>From 71840fc0f7bcb9c5d80330bb8ccbc1b2e4a673e0 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Mon, 18 Jan 2016 15:23:00 +0100
Subject: [PATCH] speakup: remove superfluous 'fi'

Commit cd6e3cab78fc3 "Enable screen reader in KDE" removed an if
condition but left the 'fi' there.  Found this problem by inspecting
the d-i syslog:

Jan 14 15:40:18 finish-install: /usr/lib/finish-install.d/07speakup: line 95:
syntax error: unexpected "fi"

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 debian/changelog   | 8 
 finish-install.d/07speakup | 1 -
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index ab9d9dd..b59331a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+finish-install (2.59) UNRELEASED; urgency=medium
+
+  [Hendrik Brueckner]
+  * finish-install.d/07speakup: remove superfluous 'fi' leftover
+    (Closes: #811391)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Mon, 18 Jan 2016 
15:26:04 +0100
+
 finish-install (2.58) unstable; urgency=high
 
   [ Steve McIntyre ]
diff --git a/finish-install.d/07speakup b/finish-install.d/07speakup
index 3767cc4..4219dfc 100755
--- a/finish-install.d/07speakup
+++ b/finish-install.d/07speakup
@@ -90,7 +90,6 @@ END
/bin/in-target su -s /bin/sh -c "kwriteconfig --file 
kaccessibleapp --group Main --key SpeechEnabled 'true'" "$USERNAME" || true
# KDE5
/bin/in-target su -s /bin/sh -c "kwriteconfig5 --file kaccessrc 
--group ScreenReader --key Enabled 'true'" "$USERNAME" || true
-   fi
fi
 fi
 
-- 
2.6.4

Bug#811391: finish-install.d/07speakup: remove superfluous 'fi' leftover

[Hendrik Brueckner]

Package: finish-install
Version: 2.58
Severity: normal
Tags: d-i

The d-i syslog contains this error message:

Jan 14 15:40:18 finish-install: /usr/lib/finish-install.d/07speakup: line 95:
syntax error: unexpected "fi"

Correct shell syntax in finish-install.d/07speakup.  Patch will follow.

Thanks and kind regards,
  Hendrik

Bug#808041: s390-zfcp: Install Debian on FC-attached SCSI devices on s390

[Hendrik Brueckner]

Hi!

On Tue, Dec 15, 2015 at 06:07:23PM +0100, Cyril Brulebois wrote:
> Hendrik Brueckner <brueck...@linux.vnet.ibm.com> (2015-12-15):
> > Package: d-i.debian.org
> > Severity: normal
> > Tags: d-i
> > 
> > Dear Debian Installer Team and Maintainers,
> > 
> > I would like to contribute a new package for the Debian Installer
> > to configure FCP devices and install Debian on SCSI devices which
> > are available on Linux on z Systems.
> > 
> > FCP device provide access to SAN storage, for example, SCSI devices.
> > SCSI devices and DASD devices are the main storage devices on a mainframe.
> > 
> > With the FCP configuration utility, users can enable FCP devices.
> > Depending on the hardware configuration of the FCP devices, LUNs will
> > be automatically detected and attached;  alternatively, users are guided
> > to manually add LUNs.  The FCP configuration utility can be preseeded
> > to perform an unattended configuration of FCP devices.
> > 
> > I will attach the patches for this new utility, as well as, a README
> > with more details in another mail.
> > 
> > Feedback for the FCP configuration utility is very welcome!
> > I am looking forward to discuss and work with you on the steps to make
> > it available with the Debian Installer.
> 
> Thanks! I'm adding Philipp and S/390 people in copy so that we get as
> many eyes as possible on your proposed patches.
>

Thank you... CCing is more clear.  I initially added Philipp and the s390
mailing using X-Debbugs-CC.

> I'm afraid I don't know
> much about this platform for one thing, and lack time to learn more
> about it right now for another; sorry about that. :/

No problem.   Getting access to s390 hardware is a bit difficult.
But any help and feedback regarding the integration into debian
and the debian installer is very helpful.

Thanks and kind regards,
  Hendrik


pgpHp6u61sW8Q.pgp
Description: PGP signature

Bug#666399: s390-dasd fails to work with >20 devices visible (mostly in LPAR mode)

[Hendrik Brueckner]

Hi Philipp,

Alexander (on CC) just reported ran into the same issue.  His system has more
than 20 DASDs and the dialog continues to show up.  The  triggers the
special debconf return code and the "hardware-detection" dependency for this
module is not satisfied.  This reported when starting the partitioner.

On Wed, Apr 04, 2012 at 10:16:24AM +0200, Philipp Kern wrote:
> On Wed, Apr 04, 2012 at 09:32:50AM +0200, Bastian Blank wrote:
> > On Fri, Mar 30, 2012 at 02:52:58PM +0200, Philipp Kern wrote:
> > > I'm not sure about the rationale for this.
> > s390 system can have hundreds or thousands of DASD devices. With the
> > text frontend it is simply impossible to display such a long list, with

I agree that the list of DASDs can be large.

> > slang it is just not pretty. So this code should ask for the device id
> > instead of showing a list.

The dialog to enter the DASD makes sense... in the current implementation you
will not get out of it with having the "hardware-detection" dependency
fulfilled.  The other side effect is that you will never see a list of DASDs
which are currently online and configured.   Of course, you would see them
later in the partitioner.

> 
> Aye.  Text is indeed a good reason.  As for the dialog interface you get via
> the SSH installer I found it to be acceptable with two hundred devices.
> 
> So the device ID picker should get an option to Finish.  Can such a text input
> field get an additional way out than Go Back and Ok?

I do not think that another button is possible.  One solution would be to
literally enter "Finish" or something similar to complete the DASD module.

Honestly, I would propose a different approach to limit the DASD device
available to the Debian installer.   I believe that typical customer
environments have set up their LPARs (and z/VM guest virtual machines)
to limit the number of devices to those required/designated for the LPAR.

Of course, there can be the case where LPARs almost have access to (almost)
every device.  For this case, the solution is to use "cio_ignore" kernel
parameter.  With this kernel parameter you can control the devices that
are visible to the Linux instance.

For example,

cio_ignore=all,!ipldev,!condev,!0.0.da00-0.0.da10

ignores all devices except the console device, the IPL device, and the
range of devices from 0.0.da00 to 0.0.da10 that might be DASDs or any
other devices.  Note that you can change the cio_ignore settings at runtime,
so you can later make additional devices visible.

With this solution, there is no hardcoded limit necessary and the user
can still see the list of DASDs to be configured.

What do you think?

P.S. For the FCP configuration module, I documented this approach already
in the README file.


Thanks and kind regards,
  Hendrik


pgpWkboLK_ekM.pgp
Description: PGP signature

Bug#808041: s390-zfcp: Install Debian on FC-attached SCSI devices on s390

[Hendrik Brueckner]

Hi Dimitri,

On Tue, Dec 15, 2015 at 07:33:56PM +, Dimitri John Ledkov wrote:
> On 15 December 2015 at 17:07, Cyril Brulebois <k...@debian.org> wrote:
> > Hendrik Brueckner <brueck...@linux.vnet.ibm.com> (2015-12-15):
> >> Package: d-i.debian.org
> >> Severity: normal
> >> Tags: d-i
> >>
> >> Dear Debian Installer Team and Maintainers,
> >>
> >> I would like to contribute a new package for the Debian Installer
> >> to configure FCP devices and install Debian on SCSI devices which
> >> are available on Linux on z Systems.
> >>
> >> FCP device provide access to SAN storage, for example, SCSI devices.
> >> SCSI devices and DASD devices are the main storage devices on a mainframe.
> >>
> >> With the FCP configuration utility, users can enable FCP devices.
> >> Depending on the hardware configuration of the FCP devices, LUNs will
> >> be automatically detected and attached;  alternatively, users are guided
> >> to manually add LUNs.  The FCP configuration utility can be preseeded
> >> to perform an unattended configuration of FCP devices.
> >>
> >> I will attach the patches for this new utility, as well as, a README
> >> with more details in another mail.
> >>
> >> Feedback for the FCP configuration utility is very welcome!
> >> I am looking forward to discuss and work with you on the steps to make
> >> it available with the Debian Installer.
> >
> > Thanks! I'm adding Philipp and S/390 people in copy so that we get as
> > many eyes as possible on your proposed patches. I'm afraid I don't know
> > much about this platform for one thing, and lack time to learn more
> > about it right now for another; sorry about that. :/
> 
> 
> I'm part of debian-installer team, and have been mostly uploading
> partman-* et.al. packages. So I don't know all of the d-i, but do have
> a fairly good working knowledge of it. I certainly can review /
> sponsor things for you.

Great!  Thank you very much for helping me and it would be amazing if you
could act as sponsor.

> I also have access to s390x hardware to test things out. But my s390x
> specific skills are extremely basic at the moment. I can just about
> ipl things to get me into installer.
> 

That's good to know ;-)  First of all, if you questions regarding s390x,
do not hesitate to ask me or the debian-s390 mailing list.  If you can
IPL the system and get into the installer, you have already master lots
of things.  Within the Linux instance, then, things looks similar to Linux
on other platforms maybe except the way how devices are managed.

Let me provide some more insights into device management on the mainframe
because that's one of the fundamental differences to other platforms.

A mainframe is a large system and there can be numerous devices.  These
devices managed through an I/O subsystem, called the channel subsystem.
To handle devices on the channel subsystem, the Linux kernel provides a
dedicated layer, the common I/O layer (CIO).  This layer represents the
maninframe (s390) devices to Linux.  A device on the channel subsystem
is represented by a bus-ID in Linux, for example, 0.0.1224.  The "1234"
portion is the device number ranging from  to .  Managing this
range of possible devices can be complex.

Due to the complexity, devices are disabled by default. Hence, devices
that the Linux instances require must be enabled first, i.e., the devices
must be set online.  This step can include some device configuration
changes.
After the devices are enabled, they appear to the Linux instance, for
example, as DASDs or FCP devices.  Some device configuration can or must
be performed at enablement.

This particular enablement step is unique to Linux on the mainframe.
After enablement, device management is similar to other Linux platforms.

So that's why there the DASD and the FCP device configuration module: to
enable DASD and FCP devices and block devices and SCSI devices available
to the Linux instance.  Then, they can be partitioned like any other
SCSI disk.


Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen


IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Bug#808007: [PATCH] s390-dasd: check if DASD is already online

[Hendrik Brueckner]

Hi,

On Tue, Dec 15, 2015 at 05:59:23PM +0100, Cyril Brulebois wrote:
> Hendrik Brueckner <brueck...@linux.vnet.ibm.com> (2015-12-15):
> > Control: tags -1 + patch
> > 
> > Attach a patch to check if the DASD is already online because
> > trying to set a DASD online twice results in an error causing
> > the s390-dasd module to fail.
> 
> I'm no DASD expert but this looks fine from afar. Was that successfully
> tested and confirmed to work? Trying to figure out whether to make it
> migrate to testing ASAP for inclusion in the next d-i release.

From my side, feel free to include it.  Alexander (alkl) on CC did some
testing on it.  The results for this issue are OK but we found some others
in a different area.  I will follow-up on them in January.

Thanks and kind regards,
  Hendrik


pgpp3wC14iqS8.pgp
Description: PGP signature

Bug#806900: partman-multipath: correct mpath device detection and bindings

[Hendrik Brueckner]

Hi Cyril!

On Wed, Dec 16, 2015 at 12:06:01AM +0100, Cyril Brulebois wrote:
> Mathieu Trudel-Lapierre  (2015-12-02):
> > > Mathieu mentioned branches a while ago:
> > >   https://lists.debian.org/debian-boot/2015/05/msg00271.html
> > >
> > >
> > That's spot on, it's exactly what is needed in partman-multipath.
> 
> OK.
> 
> > Still, shouldn't we also copy over the wwids file from the installer onto
> > the target?
> 
> I'll let Hendrik follow up on that.
> 
> > hw-detect needs a similar change, which I've already done at [1], and some
> > changes for the output of multipath -l in partman-base at [2].
> > 
> > [1]
> > http://anonscm.debian.org/cgit/d-i/hw-detect.git/commit/?h=people/cyphermox/mpath-detect
> > [2]
> > http://anonscm.debian.org/cgit/d-i/partman-base.git/log/?h=people/cyphermox/multipath5
> 
> OK. Unfortunately I haven't been able to spend sufficient time on d-i
> lately so I'm afraid the 3 patchsets will have to wait until after the
> upcoming release.

It's fine to defer them to a follw-up release.  I have continued to work on
the multipath stuff and I will provide a summary of what I think needs to be
integrated.  Briefly, there are some additional changes on top of those which
I'd like to discuss with you and the community. 

Thanks a lot!

Kind regards,
  Hendrik


pgpFmTvZPuCqP.pgp
Description: PGP signature

Bug#808007: [PATCH] s390-dasd: check if DASD is already online

[Hendrik Brueckner]

Control: tags -1 + patch

Attach a patch to check if the DASD is already online because
trying to set a DASD online twice results in an error causing
the s390-dasd module to fail.

Thanks and kind regards,
  Hendrik
diff -Nru s390-dasd-0.0.32/dasd-config.c s390-dasd-0.0.33/dasd-config.c
--- s390-dasd-0.0.32/dasd-config.c  2015-12-14 11:42:56.0 +0100
+++ s390-dasd-0.0.33/dasd-config.c  2015-12-14 11:43:07.0 +0100
@@ -244,6 +244,9 @@
struct sysfs_device *device;
struct sysfs_attribute *attr;
 
+   if (channel_current->online)
+   return WANT_NEXT;
+
device = sysfs_open_device ("ccw", channel_current->name);
if (!device) {
di_error("s390-dasd: could not open device %s",
diff -Nru s390-dasd-0.0.32/debian/changelog s390-dasd-0.0.33/debian/changelog
--- s390-dasd-0.0.32/debian/changelog   2015-12-14 11:42:56.0 +0100
+++ s390-dasd-0.0.33/debian/changelog   2015-12-15 09:47:15.0 +0100
@@ -1,3 +1,12 @@
+s390-dasd (0.0.33) UNRELEASED; urgency=medium
+
+  * Setting a DASD online if it is already online, results in EINVAL
+and the s390-dasd module exists immediately.
+Check if an DASD is already online and, if so, advance to the next
+configuration step.  (Closes: #808007)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Mon, 14 Dec 2015 
11:41:55 +0100
+
 s390-dasd (0.0.32) unstable; urgency=medium
 
   * If no channel is found, exit cleanly. This allows s390-dasd to step


pgpFiog4zBm6w.pgp
Description: PGP signature

Bug#808041: s390-zfcp: Install Debian on FC-attached SCSI devices on s390

[Hendrik Brueckner]

Package: d-i.debian.org
Severity: normal
Tags: d-i

Dear Debian Installer Team and Maintainers,

I would like to contribute a new package for the Debian Installer
to configure FCP devices and install Debian on SCSI devices which
are available on Linux on z Systems.

FCP device provide access to SAN storage, for example, SCSI devices.
SCSI devices and DASD devices are the main storage devices on a mainframe.

With the FCP configuration utility, users can enable FCP devices.
Depending on the hardware configuration of the FCP devices, LUNs will
be automatically detected and attached;  alternatively, users are guided
to manually add LUNs.  The FCP configuration utility can be preseeded
to perform an unattended configuration of FCP devices.

I will attach the patches for this new utility, as well as, a README
with more details in another mail.

Feedback for the FCP configuration utility is very welcome!
I am looking forward to discuss and work with you on the steps to make
it available with the Debian Installer.

Thank you very much!

Kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen


pgpkyj7v5fj9G.pgp
Description: PGP signature

Bug#808041: s390-zfcp: Install Debian on FC-attached SCSI devices on s390 (patches)

[Hendrik Brueckner]

Control: tags -1 + patch

Below you can find the patches for the FCP configuration utility.
The patch set consists of five patches:

1. A README file describing how to use the FCP configuration utility.
2. Generic interfaces and functions to manage CCW devices on s390.
3. Functions to manage FCP devices.
4. The FCP configuration utility.
5. Debian packaging files to build the Debian Installer udeb.

Initial tests to configure FCP devices ran successful on z/VM and LPAR
using FCP devices with and without N_Port ID virtualization (NPIV).

Review and feedback of the patches is very welcome!  As a beginner in
Debian packaging, please review the Debian packaging files.

Thank you in advance!

Kind regards,
  Hendrik
From b88cc8f54a3badfa1585a7d3d87d0bade3067211 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Tue, 15 Dec 2015 11:06:21 +0100
Subject: [PATCH 1/5] s390-zfcp: README

Provide a README file with explanations and tipps for using the
FCP device configuration Debian Installer module.

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 README | 118 +
 1 file changed, 118 insertions(+)
 create mode 100644 README

diff --git a/README b/README
new file mode 100644
index 000..7537276
--- /dev/null
+++ b/README
@@ -0,0 +1,118 @@
+= FCP device management for the Debian Installer =
+
+***
+Debian Installer module to configure FCP devices to install Debian
+Linux instances on FC-attached SCSI devices on Linux on z Systems.
+***
+
+Using the FCP device configuration module
+-
+You can use the FCP device configuration module in two different ways:
+
+1. Configuring FCP devices interactively
+2. Configuring FCP devices through preseeding
+
+Configuring FCP devices interactively
+~
+When the FCP device configuration module starts, it scans the
+CCW bus for FCP devices.  If it detects FCP devices, a panel
+appears to let the user select a particular FCP device for
+configuration.
+
+After the user selected a particular FCP device for configuration,
+the module enables the FCP device first.
+
+After the FCP device is active, the module checks if the FCP devices
+uses N_Port ID virtualization.  If the FCP device uses N_Port ID
+virtualization and automatic LUN scanning is switched on (the default
+setting), no further user configuration steps are required.
+The FCP device becomes configured.
+
+If the FCP does not use N_Port ID virtualization or automatic LUN
+scanning is switched off, the user is requested to specify LUNs.
+To add LUNs, the user must specify the target port (WWPN) and the
+logical unit number (LUN) as pair, WWPN:LUN.  The user can add
+numerous LUNs and, if necessary, can also remove them.  The specified
+LUNs will be attached to the system and the FCP device configuration
+module writes the respective configuration file.
+
+Configuring FCP devices through preseeding
+~~
+Use the *s390-zfcp/zfcp* variable to specify one or more FCP devices
+to be configured.  With this variable, you specify a comma-separated
+list of entries.  An entry can be either the bus-ID of an FCP device
+or a combination of the bus-ID of an FCP device followed by the WWPN
+and LUN, each delimited by a colon.
+
+For example:
+
+   0.0.1234,0.0.5678:0x2005000e11159c32:0x1234567800
+
+The bus-ID for an FCP device is sufficient if
+
+1. the FCP device uses N_Port ID virtualization and
+2. automatic LUN scanning is switched on (default)
+
+You have to specify triplets consisting of the bus-ID of the FCP device,
+WWPN, and LUN in any other case.  Note that the FCP device configuration
+module fails if an entry specified with the *s390-zfcp/zfcp* variable is
+not valid.  An error message which describes the error is written to the
+syslog.
+
+
+Additional installation considerations
+~~
+After you completed and configured your FC-attached SCSI devices,
+consider to set up multipath.  To prevent single path failures,
+install your Linux instance on those multipath devices.
+
+Note that it is sufficient to install on multipath devices even
+if there is only a single path available.  Later, you can extend
+your multipath setup and configure additional paths.  Note that
+configuring multipath later, on already installed Linux instances,
+is typically complex.
+
+
+Controlling the FCP device configuration behavior
+-
+You can control different aspects of the FCP device configuration
+through kernel and module parameters.  The FCP device configuration
+module does not change any of the kernel and module parameters
+described below.
+
+s

Bug#807442: patch

[Hendrik Brueckner]

On Mon, Dec 14, 2015 at 09:28:08AM +0100, Hendrik Brueckner wrote:
> On Sun, Dec 13, 2015 at 03:50:01PM +0100, Philipp Kern wrote:
> > On Tue, Dec 08, 2015 at 03:17:49PM -0700, dann frazier wrote:
> > > --- s390-tools-1.32.0/debian/s390-tools.install   2014-07-26 
> > > 23:59:18.0 +0200
> > > +++ s390-tools-1.32.0/debian/s390-tools.install   2015-12-08 
> > > 23:08:30.0 +0100
> > > @@ -10,6 +10,10 @@
> > >  /sbin/dasdview
> > >  /usr/share/man/man8/dasdview.8
> > >  
> > > +# dbginfo.sh
> > > +/sbin/dbginfo.sh
> > > +/usr/share/man/man1/dbginfo.sh.1
> > > +
> >
> >  * Unless this is expected to be in /sbin, given that it's user
> >invoked and not usually scripted, should this be in /usr/sbin
> >instead?

I am not sure what you exactly mean with "user" invoked.
Anyhow, /sbin/ makes sense because the intention of the dbginfo.sh
script is to collect system and debugging information.  So it is
important to have it available early (even before /usr becomes
mounted).

I would also go further and would suggest to included it in the
s390-tools udeb package to be available in the debian installer
too.  But I would have to check if it runs in the debian installer
environment.  I could also imagine to integrate it into the
installation-report module.

Thanks and kind regards,
  Hendrik


pgp4VFlwRTv1O.pgp
Description: PGP signature

Bug#807442: patch

[Hendrik Brueckner]

Hi Philipp,

On Sun, Dec 13, 2015 at 03:50:01PM +0100, Philipp Kern wrote:
> On Tue, Dec 08, 2015 at 03:17:49PM -0700, dann frazier wrote:
> > diff -Nru s390-tools-1.32.0/debian/changelog 
> > s390-tools-1.32.0/debian/changelog
> > --- s390-tools-1.32.0/debian/changelog  2015-10-25 17:12:02.0 
> > +0100
> > +++ s390-tools-1.32.0/debian/changelog  2015-12-08 23:14:52.0 
> > +0100
> > @@ -1,3 +1,9 @@
> > +s390-tools (1.32.0-2) UNRELEASED; urgency=medium
> > +
> > +  * Add dbginfo.sh. (Closes: #807442)
> > +
> > + -- dann frazier   Tue, 08 Dec 2015 22:33:52 +0100
> > +
> >  s390-tools (1.32.0-1) unstable; urgency=medium
> >  
> >* New upstream release
> > diff -Nru s390-tools-1.32.0/debian/s390-tools.install 
> > s390-tools-1.32.0/debian/s390-tools.install
> > --- s390-tools-1.32.0/debian/s390-tools.install 2014-07-26 
> > 23:59:18.0 +0200
> > +++ s390-tools-1.32.0/debian/s390-tools.install 2015-12-08 
> > 23:08:30.0 +0100
> > @@ -10,6 +10,10 @@
> >  /sbin/dasdview
> >  /usr/share/man/man8/dasdview.8
> >  
> > +# dbginfo.sh
> > +/sbin/dbginfo.sh
> > +/usr/share/man/man1/dbginfo.sh.1
> > +
> >  # fdasd
> >  /sbin/fdasd
> >  /usr/share/man/man8/fdasd.8
> 
> Three comments:
> 
>  * dbginfo.sh should tell the user that the information in the tarball
>is sensitive.
>  * The resulting tarball should be 0600 by default. (The script needs
>to run as root anyway, but placing the result world-readable in
>/tmp does not seem smart.)

Thanks for the feedback.  I think that sounds good.  I put the s390-tools
owners for their feedback on CC.

>  * Unless this is expected to be in /sbin, given that it's user
>invoked and not usually scripted, should this be in /usr/sbin
>instead?
> 

Kind regards,
  Hendrik


pgpc0EN1oVlag.pgp
Description: PGP signature

Bug#807470: s3t/install: please incude zipl/chreipl dm helper

[Hendrik Brueckner]

Tags: -1 + patch

Bug#807470: s3t/install: please incude zipl/chreipl dm helper

[Hendrik Brueckner]

Tags: -1 patch

On Wed, Dec 09, 2015 at 09:17:52AM +0100, Hendrik Brueckner wrote:
> 
> Patch will provided separately.

Attached.
diff -Nru s390-tools-1.32.0/debian/changelog s390-tools-1.32.0/debian/changelog
--- s390-tools-1.32.0/debian/changelog  2015-10-25 17:12:02.0 +0100
+++ s390-tools-1.32.0/debian/changelog  2015-12-09 09:32:50.0 +0100
@@ -1,3 +1,12 @@
+s390-tools (1.32.0-2) UNRELEASED; urgency=medium
+
+  * Install the device-mapper helper for zipl and chreipl to boot from and
+prepare an underlying disk device of a mapped device for IPL.  This
+applies to linear mapped devices, for example, multipath devies or LVM.
+(Closes: #807470)
+
+ -- Hendrik Brueckner <brueck...@linux.vnet.ibm.com>  Wed, 02 Dec 2015 
14:54:09 +0100
+
 s390-tools (1.32.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru s390-tools-1.32.0/debian/s390-tools.install 
s390-tools-1.32.0/debian/s390-tools.install
--- s390-tools-1.32.0/debian/s390-tools.install 2014-07-26 23:59:18.0 
+0200
+++ s390-tools-1.32.0/debian/s390-tools.install 2015-12-02 14:59:19.0 
+0100
@@ -19,6 +19,7 @@
 /usr/sbin/lsreipl
 /usr/sbin/chshut
 /usr/sbin/lsshut
+/lib/s390-tools/chreipl_helper.device-mapper
 /usr/share/man/man8/chreipl.8
 /usr/share/man/man8/lsreipl.8
 /usr/share/man/man8/chshut.8
@@ -88,6 +89,7 @@
 
 # zipl
 /sbin/zipl
+/lib/s390-tools/zipl_helper.device-mapper
 /usr/share/man/man5/zipl.conf.5
 /usr/share/man/man8/zipl.8
 

Bug#807470: s3t/install: please incude zipl/chreipl dm helper

[Hendrik Brueckner]

Package: s390-tools
Version: 1.32.0-1
Severity: normal
Tags:

Please include the chreipl and zipl device mapper helper to prepare and
boot from linear mapped devices, for example, LVM.

Patch will provided separately.


Kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen

Bug#807442: patch

[Hendrik Brueckner]

Hi Dann,

On Tue, Dec 08, 2015 at 03:17:49PM -0700, dann frazier wrote:
> Attached.

> diff -Nru s390-tools-1.32.0/debian/changelog 
> s390-tools-1.32.0/debian/changelog
> --- s390-tools-1.32.0/debian/changelog2015-10-25 17:12:02.0 
> +0100
> +++ s390-tools-1.32.0/debian/changelog2015-12-08 23:14:52.0 
> +0100
> @@ -1,3 +1,9 @@
> +s390-tools (1.32.0-2) UNRELEASED; urgency=medium
> +
> +  * Add dbginfo.sh. (Closes: #807442)
> +
> + -- dann frazier <da...@debian.org>  Tue, 08 Dec 2015 22:33:52 +0100
> +
>  s390-tools (1.32.0-1) unstable; urgency=medium
> 
>* New upstream release
> diff -Nru s390-tools-1.32.0/debian/s390-tools.install 
> s390-tools-1.32.0/debian/s390-tools.install
> --- s390-tools-1.32.0/debian/s390-tools.install   2014-07-26 
> 23:59:18.0 +0200
> +++ s390-tools-1.32.0/debian/s390-tools.install   2015-12-08 
> 23:08:30.0 +0100
> @@ -10,6 +10,10 @@
>  /sbin/dasdview
>  /usr/share/man/man8/dasdview.8
> 
> +# dbginfo.sh
> +/sbin/dbginfo.sh
> +/usr/share/man/man1/dbginfo.sh.1
> +
>  # fdasd
>  /sbin/fdasd
>  /usr/share/man/man8/fdasd.8

Thanks for submitting this patch and the lsluns patch as well.  I am about to
open another bug to include the device-mapper helper for zipl and chreipl as
well.  They are required for booting from device-mapper devices, for example,
LVM, multipath.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen


IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Bug#807470: s3t/install: please incude zipl/chreipl dm helper

[Hendrik Brueckner]

Control: tags: -1 + patch

Bug#806900: partman-multipath: correct mpath device detection and bindings

[Hendrik Brueckner]

Package: partman-multipath
Version: 4
Severity: important
Tags: d-i patch

Dear Maintainers,

the partman-multipath installer modules does not detect multipath devices
because the multipath alias names have been changed.  Also the location of
the bindings file has been changed and, therefore, correct its location in
the post-base-installer script.

Below you can find a patch that solves both problems.  Feedback is welcome.

Thanks!

Kind regards,
  Hendrik
>From d4c73caff072a79bd6e4428480fc34951ca6d84c Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Thu, 26 Nov 2015 17:29:11 +0100
Subject: [PATCH 1/2] multipath: update check for mpath device and bindings

The mulitpath-tools use different alias names and store their
bindings in in the /etc/multipath/ directory.  This commit
changes detection of mpath devices and mulitpath configuration
accordingly.

The alias names for user friendly names have been changed from
mpath[0-9] to mpath[a-z] since 2008.  So update all mpath checkings
to use new alias naming scheme.

See also
https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=81716d6fe5ccf220e320e168391817810645c3b4

The location of the bindings file which maps the alias names to
particular wwn's also changed.  The bindings file moved from
the /var/lib/multipath/ directory to the /etc/multipath/ directory.

The bindings file is required to successfully map an multipath alias
always to the same SCSI disk.  Without these bindings, for example,
the device with the root file system might appear as a different mpathX
device after an reboot.

See also
https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=8ee04831d2535a5afcf5dd40a27e2645ec0b7ffa

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 init.d/multipath_flag | 2 +-
 post-base-installer.d/60multipath | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/init.d/multipath_flag b/init.d/multipath_flag
index 862765f..fdd32aa 100755
--- a/init.d/multipath_flag
+++ b/init.d/multipath_flag
@@ -7,7 +7,7 @@ for dev in /var/lib/partman/devices/*; do
cd $dev
 
[ -f device ] || continue
-   for frdisk in $(multipath -l | grep '^mpath[0-9]\+ ' | sed 
's/\(mpath[0-9]\+\) .*/\1/'); do
+   for frdisk in $(multipath -l | grep '^mpath[a-z]\+ ' | sed 
's/\(mpath[a-z]\+\) .*/\1/'); do
case $(cat device) in
/dev/mapper/$frdisk)
>multipath
diff --git a/post-base-installer.d/60multipath 
b/post-base-installer.d/60multipath
index cb21b60..35169fe 100755
--- a/post-base-installer.d/60multipath
+++ b/post-base-installer.d/60multipath
@@ -2,7 +2,7 @@
 
 set -e
 
-if [ $(multipath -l | grep '^mpath[0-9]\+' | wc -l) -eq 0 ]; then
+if [ $(multipath -l | grep '^mpath[a-z]\+' | wc -l) -eq 0 ]; then
exit 0
 fi
 
@@ -13,9 +13,9 @@ if [ -r /etc/multipath.conf ]; then
 fi
 
 # copy over the persistent binding
-if [ -r /var/lib/multipath/bindings ]; then
-   mkdir -p /target/var/lib/multipath
-   cp /var/lib/multipath/bindings /target/var/lib/multipath/
+if [ -r /etc/multipath/bindings ]; then
+   mkdir -p /target/etc/multipath
+   cp /etc/multipath/bindings /target/etc/multipath
 fi
 
 # the initramfs will be updated by the kernel installation
-- 
2.6.2

Bug#806713: disk-detect/multipath: update checks for changed mpath alias names

[Hendrik Brueckner]

Package: disk-detect
Version: 1.114
Severity: normal
Tags: d-i patch

Dear maintainers,

An update in the multipath-tools, [1], changed the naming scheme for
mpath aliases created when the user friendly names option is specified.

The alias naming changed from mpath0 to mpatha replacing the numeric
digits with alphabetic letters.  The patch below updates the disk-detect.sh
to correctly detect multipath devices with the new naming scheme.

On the people/cyphermox/mpath-detect branch in the d-i/hw-detect
repository, there is already a patch for the same problem.  I could not
find a bug report for it.  So that's why I am opening this one to keep
this problem in mind.
It would be great if you could help me to understand the practice on how
such problem fixes becomes integrated.

Apart from the disk-detect package, the partman-multipath package is
also affected by mpath naming change.  I will open a separate bug report
and attach a patch to solve the naming there.

Many thanks in advance!

[1]
https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=81716d6fe5ccf220e320e168391817810645c3b4

Kind regards,
  Hendrik
>From 8ecaf3a49c1b7d0f765895ebc8156efadcc0ca23 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 27 Nov 2015 11:17:57 +0100
Subject: [PATCH] disk-detect/multipath: update checks for changed mpath alias 
names

The alias naming scheme for user friendly names has been changed
from mpath[0-9] to mpath[a-z] a while ago.  Update the disk-detect.sh
script to use the new alias naming scheme to correctly detect multipath
devices.

See also
https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=81716d6fe5ccf220e320e168391817810645c3b4

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 disk-detect.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk-detect.sh b/disk-detect.sh
index c3b77cc..8498f4f 100755
--- a/disk-detect.sh
+++ b/disk-detect.sh
@@ -113,7 +113,7 @@ EOF
fi
log-output -t disk-detect /sbin/multipath -v$MP_VERBOSE
 
-   if multipath -l 2>/dev/null | grep -q '^mpath[0-9]\+ '; then
+   if multipath -l 2>/dev/null | grep -q '^mpath[a-z]\+ '; then
return 0
else
return 1
-- 
2.6.2

Bug#806443: disk-detect/multipath: default path selector is not loaded

[Hendrik Brueckner]

On Fri, Nov 27, 2015 at 03:33:39PM +, Ben Hutchings wrote:
> On Fri, 2015-11-27 at 15:39 +0100, Hendrik Brueckner wrote:
> [...]
> > --- a/disk-detect.sh
> > +++ b/disk-detect.sh
> > @@ -202,7 +202,7 @@ fi
> >  db_get disk-detect/multipath/enable
> >  if [ "$RET" = true ]; then
> >  >  > if anna-install multipath-udeb; then
> > ->  >   > MODULES="dm-mod dm-multipath dm-round-robin dm-emc"
> > +>  >   > MODULES="dm-mod dm-multipath dm-service-time dm-round-robin 
> > dm-emc"
> >  >  >   > # We need some dm modules...
> >  >  >   > depmod -a >/dev/null 2>&1 || true
> >  >  >   > for MODULE in $MODULES; do
> 
> At least dm-service-time and dm-round-robin will be automatically
> loaded by the kernel when needed.  I'm not sure about the others.

Just tried it out... the dm-multipath must be loaded manually, otherwise:

~ # multipath
Nov 27 16:42:37 | DM multipath kernel driver not loaded

~ # modprobe dm-multipath
~ # multipath
create: 36005076307ffc5e382db undef IBM,2107900
size=20G features='0' hwhandler='0' wp=undef
`-+- policy='round-robin 0' prio=1 status=undef
  |- 0:0:0:1088110722 sda 8:0   undef ready running
  `- 1:0:0:1088110722 sde 8:64  undef ready running

Loading the module and running multipath automatically loads the other
kernel modules:

~ # lsmod
Module  Size  Used by
dm_round_robin 16384  4
dm_multipath   32768  5 dm_round_robin
scsi_dh20480  1 dm_multipath
dm_mod139264  5 dm_multipath
sd_mod 49152  8
qeth_l245056  1
fuse  122880  0
qeth  122880  1 qeth_l2
ccwgroup   20480  1 qeth
zfcp  122880  8
scsi_transport_fc  69632  1 zfcp
scsi_mod  241664  4 zfcp,scsi_transport_fc,scsi_dh,sd_mod
dasd_eckd_mod 110592  0
dasd_mod   98304  1 dasd_eckd_mod

multipath automatically tries to load its default path selector module.  In
the example, I modified the multipath.conf to use round-robin.

So strictly this patch is not necessary but at least consistent regarding
the manual loading of the other modules.  I leave the change up to the
maintainer of the hw-detect/disk-detect package.

Thanks for your help.

Kind regards,
  Hendrik


pgpUwt8x437pv.pgp
Description: PGP signature

Bug#806443: disk-detect/multipath: default path selector is not loaded

[Hendrik Brueckner]

Package: disk-detect
Version: 1.114
Severity: normal
Tags: d-i patch

Dear Maintainers,

I am about to configure and install on multipath devices.
The multipath program can create mappings but fails to load
the mappings into the kernel.  The problem is that the mulitpath
program included in multipath-udeb_0.5.0+git1.656f8865 uses the
service-time as default path selector for some time.
See also git commit:

https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/libmultipath/defaults.h?id=1bcf07988d7dc026099242a2a787178fdd27f8d1

The attached patch updates the disk-detect.sh script to the
dm-service-time.ko kernel module.  Note that I have already
opened the below Debian bug to include the dm-service-time.ko
module into the multipath-module package:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806131

So this bug report slightly depends on the above.

A possible workaround is to create the multipath.conf file with
round-robin as default path selector.  This might be a good choice
for a jessie backport if it is required.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen
>From aab885128205ce9a29741e3c8578d4b79e9d3d88 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
Date: Fri, 27 Nov 2015 11:28:05 +0100
Subject: [PATCH] disk-detect/multipath: load service-time path selector module

Load the dm-service-time.ko kernel module to make the service-time path
selector available.  Note that service-time is the default path selector
for some years.

See also
https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/libmultipath/defaults.h?id=1bcf07988d7dc026099242a2a787178fdd27f8d1

Depends on Debian Bug #806131

Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
 disk-detect.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk-detect.sh b/disk-detect.sh
index 8498f4f..88f67c6 100755
--- a/disk-detect.sh
+++ b/disk-detect.sh
@@ -202,7 +202,7 @@ fi
 db_get disk-detect/multipath/enable
 if [ "$RET" = true ]; then
if anna-install multipath-udeb; then
-   MODULES="dm-mod dm-multipath dm-round-robin dm-emc"
+   MODULES="dm-mod dm-multipath dm-service-time dm-round-robin 
dm-emc"
# We need some dm modules...
depmod -a >/dev/null 2>&1 || true
for MODULE in $MODULES; do
-- 
2.6.2

Bug#806131: multipath-modules-4.2.0-1-s390x-di misses dm-service-time.ko

[Hendrik Brueckner]

Control: affects -1 disk-detect

On Thu, Nov 26, 2015 at 09:10:22PM +, Ben Hutchings wrote:
> Control: tag -1 moreinfo
> 
> On Tue, 2015-11-24 at 17:06 +0100, Hendrik Brueckner wrote:
> > Package: src:linux
> > Version: 4.2.6-1
> > Severity: normal
> > Tags: d-i
> > 
> > Dear Debian Kernel Maintainers,
> > 
> > while trying out the Debian Installer and setting up multipath, I 
> > encountered
> > the problem that the multipath tool uses the service-time path selector as
> > default (this has been changed some months ago according to the history of
> > the multipath-tools git repository
> > (git://anonscm.debian.org/pkg-lvm/multipath-tools.git).
> 
> Only months ago?  It looks like it changed before jessie:
> 
> https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/libmultipath/defaults.h?id=1bcf07988d7dc026099242a2a787178fdd27f8d1

Yes.. it's been long there.

> In which case this needs to be fixed there too.

That makes sense too.  Of course, the disk-detect package which includes the
multipath device detection needs to be updated too in order to load the kernel
module.  I open a separate bug for this soon.

> > Because the debian installer disk-detect module does not specify a 
> > particular
> > path selector when creating a multipath configuration file, the multipath 
> > tool
> > tries to establish path maps using the its default.
> > 
> > To solve the problem, I suggest to add and package the dm-service-time.ko
> > for the multipath-modules-4.2.0-1-s390x-di udeb.  According to the contents
> > of https://anonscm.debian.org/git/kernel/linux.git, I guess adding
> > "dm-service-time.ko" to the "debian/installer/modules/multipath-modules" is
> > necessary.
> 
> That looks right, yes.

Thank you Ben.

Hendrik

Bug#805965: boot-s390-common, d390.ins: initrd overwrites kernel due to a low offset

[Hendrik Brueckner]

On Tue, Nov 24, 2015 at 05:08:17PM +, Steve McIntyre wrote:
> On Tue, Nov 24, 2015 at 05:39:16PM +0100, Hendrik Brueckner wrote:
> >On Tue, Nov 24, 2015 at 01:00:13PM +, Steve McIntyre wrote:
> >> On Tue, Nov 24, 2015 at 12:38:16PM +0100, Hendrik Brueckner wrote:
> >> >
> >> >To correct this problem, please update the memory location to which
> >> >the initrd is loaded from 0x0080 (8M) to 0x0200 (32MB).
> >> >
> >> >The 0x0200 memory location is the preferred and commonly used
> >> >memory location.   As far as I could see, this affects all d390.ins
> >> >files, as well as, the boot-s390-common files which create the
> >> >root.off file.
> >> 
> >> ACK, thanks for your report. In fact, just 2 weeks back Philipp Kern
> >> (in CC) has added some fixes in this exact area in debian-cd
> >> git. He's moved the root.bin up to 0x0100 (16MB); I'd be happy to
> >> move it up to 0x0200 as you suggest. Phil - what do you think?
> >
> >Actually, the best solution would be to calculate this offset dynamically,
> >and write the modified root.off and d390.ins file.  For the initrd offset
> >calcuation, take the size of the vmlinuz kernel image + 4MB (0x0040).
> 
> OK, that's easy enough. Are there any alignment issues to worry about
> on top of that - do we have to pad that to the next 1MB, say?
> 
No alignment issues.  The initrd could be right after the kernel image.
Adding some space between prevents a potential move of the initrd.  The
kernel includes some checks to ensure the initrd does not collide, for
example, with the BSS section.  If it conflicts, the kernel moves the
initrd after these areas.  So providing some room between avoids some
memory copy operations.

Thanks and kind regards,
  Hendrik

Bug#806131: multipath-modules-4.2.0-1-s390x-di misses dm-service-time.ko

[Hendrik Brueckner]

Package: src:linux
Version: 4.2.6-1
Severity: normal
Tags: d-i

Dear Debian Kernel Maintainers,

while trying out the Debian Installer and setting up multipath, I encountered
the problem that the multipath tool uses the service-time path selector as
default (this has been changed some months ago according to the history of
the multipath-tools git repository
(git://anonscm.debian.org/pkg-lvm/multipath-tools.git).

Because the debian installer disk-detect module does not specify a particular
path selector when creating a multipath configuration file, the multipath tool
tries to establish path maps using the its default.

To solve the problem, I suggest to add and package the dm-service-time.ko
for the multipath-modules-4.2.0-1-s390x-di udeb.  According to the contents
of https://anonscm.debian.org/git/kernel/linux.git, I guess adding
"dm-service-time.ko" to the "debian/installer/modules/multipath-modules" is
necessary.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen


IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Bug#805965: boot-s390-common, d390.ins: initrd overwrites kernel due to a low offset

[Hendrik Brueckner]

On Tue, Nov 24, 2015 at 01:00:13PM +, Steve McIntyre wrote:
> On Tue, Nov 24, 2015 at 12:38:16PM +0100, Hendrik Brueckner wrote:
> >Package: debian-cd
> >Version: 3.1.17
> >Severity: important
> >
> >Dear debian-cd Maintainers,
> >
> >I recently encountered a problem at the installation of Debian on s390:
> >
> >The d390.ins specifies where to load the kernel image and the initrd into
> >memory.  The current d390.ins uses:
> >
> >--
> >* Debian GNU/Linux for S/390 (boot from CD-ROM or FTP-Server)
> >linux_vm 0x
> >root.off 0x0001040c
> >root.siz 0x00010414
> >parmfile 0x00010480
> >root.bin 0x0080
> >--
> >
> >The size of the linux_vm is about 11M and the initrd is loaded at
> >the memory address 0x0080 (8M) which overrides the kernel image.
> >A result, the kernel and debian installer cannot be started on logical
> >partitions (LPAR) on z Systems.
> >
> >To correct this problem, please update the memory location to which
> >the initrd is loaded from 0x0080 (8M) to 0x0200 (32MB).
> >
> >The 0x0200 memory location is the preferred and commonly used
> >memory location.   As far as I could see, this affects all d390.ins
> >files, as well as, the boot-s390-common files which create the
> >root.off file.
> 
> ACK, thanks for your report. In fact, just 2 weeks back Philipp Kern
> (in CC) has added some fixes in this exact area in debian-cd
> git. He's moved the root.bin up to 0x0100 (16MB); I'd be happy to
> move it up to 0x0200 as you suggest. Phil - what do you think?

Actually, the best solution would be to calculate this offset dynamically,
and write the modified root.off and d390.ins file.  For the initrd offset
calcuation, take the size of the vmlinuz kernel image + 4MB (0x0040).

The 4MB just adds some place for the kernel BSS section.  It is not
strictly necessary, as the kernel moves the initrd out of its BSS
section before it clearing it.

This would be the better solution and it works even if the kernel grows
over time.

> 
> I'm also going to make sure the fixes are backported to our stable
> build tree for the next point release.

Thanks.  For backports, it should be sufficient to increase the offset
for current and future, we might consider the dynamic approach above.

Thanks and kind regards,
  Hendrik

Bug#805965: boot-s390-common, d390.ins: initrd overwrites kernel due to a low offset

[Hendrik Brueckner]

Package: debian-cd
Version: 3.1.17
Severity: important

Dear debian-cd Maintainers,

I recently encountered a problem at the installation of Debian on s390:

The d390.ins specifies where to load the kernel image and the initrd into
memory.  The current d390.ins uses:

--
* Debian GNU/Linux for S/390 (boot from CD-ROM or FTP-Server)
linux_vm 0x
root.off 0x0001040c
root.siz 0x00010414
parmfile 0x00010480
root.bin 0x0080
--

The size of the linux_vm is about 11M and the initrd is loaded at
the memory address 0x0080 (8M) which overrides the kernel image.
A result, the kernel and debian installer cannot be started on logical
partitions (LPAR) on z Systems.

To correct this problem, please update the memory location to which
the initrd is loaded from 0x0080 (8M) to 0x0200 (32MB).

The 0x0200 memory location is the preferred and commonly used
memory location.   As far as I could see, this affects all d390.ins
files, as well as, the boot-s390-common files which create the
root.off file.


Thanks and kind regards,
Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen


IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294