[UBUNTU 20.04] Subiquity installer cannot find dasd device

[bugproxy]

I'm installing Ubuntu 20.04 with a nocloud-net installation source on a z/VM guest. I'm currently limited to seeing installation output only through webhook reporter, because I cannot access shell on the target system during installation.

Installation stops at trying to find a dasd disk. I tried following Curtin documentation on dasd and examples from https://github.com/canonical/curtin/blob/master/examples/tests/basic-dasd.yaml with different options, but had no success.

Kernel command-line:
cio_ignore=all,!condev,!0.0.3695,!0.0.bdf0-0.0.bdf2 url=http://bistro.lnxne.boe/ubuntu/UBUNTU20.04/ubuntu-20.04-live-server-s390x.iso ip=172.18.76.38::172.18.0.1:255.254.0.0:m8330038.lnxne.boe:encbdf0:none:172.18.0.1 autoinstall ds=nocloud-net;s=http://t35lp37.lnxne.boe:8080/cfg/

#cloud-config
autoinstall:
  version: 1
  reporting:
    remote:
      type: webhook
      endpoint: http://t35lp37.lnxne.boe:8080/log/
      level: DEBUG
  refresh-installer:
    update: yes
  apt:
    primary:
    - arches: [s390x]
      uri: http://us.ports.ubuntu.com/ubuntu-ports
  identity: {hostname: m8330038, password: .ueYA4yxzICWX9/.wxG7epPimsn.FM/CuMQMqjgbBbawyn5T3zYyGc5Io4ZNRcvItBWojzpO1S8bkTpthJRPc4Q.,
    realname: user, username: user}
  keyboard: {layout: us, variant: ''}
  locale: en_US
  ssh:
    allow-pw: true
    authorized-keys: []
    install-server: true
  storage:
    config:
      - {device_id: 0.0.3695, blocksize: 4096, disk_layout: cdl, mode: quick, preserve: false, type: dasd, id: dasd-dasda}
      - {ptable: vtoc, serial: 0X3695, path: /dev/dasda, wipe: superblock-recursive, preserve: false, name: '', grub_device: false, device_id: 0.0.3695, type: disk, id: disk-dasda}
      - {device: disk-dasda, size: 22153265152, wipe: superblock, flag: '', number: 1, preserve: false, type: partition, id: partition-0}
      - {fstype: ext4, volume: partition-0, preserve: false, type: format, id: format-0}
      - {device: format-0, path: /, type: mount, id: mount-0}

I get the following output on the webhook:
curtin start subiquity/Filesystem/apply_autoinstall_config:
curtin start subiquity/Filesystem/apply_autoinstall_config/convert_autoinstall_config:
curtin finish subiquity/Filesystem/apply_autoinstall_config/convert_autoinstall_config: {'device_id': '0.0.3695', 'grub_device': False, 'id': 'disk-dasda', 'name': '', 'path': '/dev/dasda', 'preserve': False, 'ptable': 'vtoc', 'serial': '0X3695', 'type': 'disk', 'wipe': 'superblock-recursive'} matched no disk
curtin finish subiquity/Filesystem/apply_autoinstall_config: {'device_id': '0.0.3695', 'grub_device': False, 'id': 'disk-dasda', 'name': '', 'path': '/dev/dasda', 'preserve': False, 'ptable': 'vtoc', 'serial': '0X3695', 'type': 'disk', 'wipe': 'superblock-recursive'} matched no disk
curtin start subiquity/Error/1589794065.193394184.ui/add_info:
curtin finish subiquity/Error/1589794065.193394184.ui/add_info: written to /var/crash/1589794065.193394184.ui.crash

When I use a simple configuration described in Ubuntu Wiki ( https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls/ConfigReference#storage ), I get a different output:

  storage:
    layout:
      name: direct

curtin start subiquity/Filesystem/apply_autoinstall_config:
curtin finish subiquity/Filesystem/_probe/probe_once: restricted=False
curtin finish subiquity/Filesystem/_probe:
curtin start subiquity/Filesystem/apply_autoinstall_config/convert_autoinstall_config:
curtin finish subiquity/Filesystem/apply_autoinstall_config/convert_autoinstall_config: 'None Type' object has no attribute 'grub_device'
curtin finish subiquity/Filesystem/apply_autoinstall_config: 'NoneType' object has no attribu te 'grub_device'

(same with layout "lvm")

Manual installation works fine, but I need to enable the DASD in the menu.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dirk (wedibit)]

I can confirm the problem with

   storage:
    layout:
      name: direct

[Michael Hudson-Doyle (mwhudson)]

FWIW https://github.com/CanonicalLtd/subiquity/pull/789 will allow you to open a shell when connecting via SSH.

I think you will need to have early-commands that use chzdev to activate the drive you want to use before you can use it? We should add more explicit support for device activation (possibly to the extent of automatically activating devices referenced by the config) but it's not done yet.

[Heather Lemon (hypothetical-lemon)]

I followed this https://bytefreaks.net/gnulinux/send-altctrldelete-to-qemu-virtual-machine and it helped me get a shell inside of ubuntu-server but I was also running in a VM.

[Frank Heimes (fheimes)]

This works if one enables the s390x devices in the early-command section.
I tried it with the latest subiquity 20.06.1:
https://github.com/CanonicalLtd/subiquity/releases/tag/20.06.1

One either needs to make sure that the installer get's updated to at least 20.06.1 (or latest) or
a current daily live image can be used instead:
http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/

Sample snippet:
  early-commands:
    - chzdev zfcp -e e000
    - chzdev zfcp -e e100
    - chzdev zfcp-lun -e --online
    - chzdev -e dasd 162a

Closing this for now (project-wise).

[Frank Heimes (fheimes)]

Or of course also using the focal daily-live image:
http://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-06-26 02:47 EDT-------
IBM Bugzilla status-> closed, Fix Released