[Ubuntu 20.04] - Install - problem

[bugproxy]

Hello,

I finally started installing Ubuntu 20.04 and running into a problem. I looked at the available documentation which seem to be similar to previous Ubuntu install on IBM Z. I punch the parmfile, initrd, and kernel into the z/VM rdr and IPL 00C using the exec supplied as I did before but it stop in the middle and went to a "emergency mode" instead of asking me for the network information as in Ubuntu 18.04. Here is the output of both during the installation. Any idea what I'm missing?

Ubuntu 20.04
[ 0.043942] Linux version 5.4.0-26-generic (buildd@bos02-s390x-015) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #30-Ubuntu SMP Mon Apr 20 16:57:22 UTC 2020
(Ubuntu 5.4.0-26.30-generic 5.4.30)
[ 0.043945] setup.1a06a7: Linux is running as a z/VM guest operating system in 64-bit mode
[ 0.043955] setup.b050d0: The maximum memory size is 65536MB
[ 0.043957] cma: Reserved 4 MiB at 0x0000000fffc00000
[ 0.043980] numa.196305: NUMA mode: plain
[ 0.044128] cpu.33a262: 4 configured CPUs, 0 standby CPUs
[ 0.044569] Write protected kernel read-only data: 11556k
[ 0.044985] Zone ranges:
[ 0.044986] DMA [mem 0x0000000000000000-0x000000007fffffff]
[ 0.044987] Normal [mem 0x0000000080000000-0x0000000fffffffff]
[ 0.044988] Movable zone start for each node
[ 0.044989] Early memory node ranges
[ 0.044990] node 0: [mem 0x0000000000000000-0x0000000fffffffff]
[ 0.044995] Initmem setup node 0 [mem 0x0000000000000000-0x0000000fffffffff]
[ 0.709681] percpu: Embedded 34 pages/cpu s98816 r8192 d32256 u139264
[ 0.709718] Built 1 zonelists, mobility grouping on. Total pages: 16515072
[ 0.709719] Policy zone: Normal
[ 0.709720] Kernel command line: %@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[ 0.710375] printk: log_buf_len individual max cpu contribution: 4096 bytes
[ 0.710376] printk: log_buf_len total cpu_extra contributions: 258048 bytes
[ 0.710376] printk: log_buf_len min size: 262144 bytes
[ 0.710565] printk: log_buf_len: 524288 bytes
[ 0.710566] printk: early log buf free: 259540(99%)
[ 0.730700] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear)
[ 0.740791] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear)
[ 0.740793] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 2.981614] Memory: 65904376K/67108864K available (9076K kernel code, 1708K rwdata, 2476K rodata, 3424K init, 948K bss, 1200392K reserved, 4096K cma-reserved
)
[ 2.981627] random: get_random_u64 called from kmem_cache_open+0x42/0x4a0 with crng_init=001: HCPGSP2627I The virtual machine is placed in CP mode due to a S
IGP initial CPU reset from CPU 00.
02: HCPGSP2627I The virtual machine is placed in CP mode due to a SIGP initial CPU reset from CPU 00.
03: HCPGSP2627I The virtual machine is placed in CP mode due to a SIGP initial CPU reset from CPU 00.

[ 2.981826] SLUB: HWalign=256, Order=0-3, MinObjects=0, CPUs=64, Nodes=1
[ 2.981841] ftrace: allocating 29625 entries in 116 pages
[ 2.986940] rcu: Hierarchical RCU implementation.
[ 2.986941] rcu: RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=64.
[ 2.986942] Tasks RCU enabled.
[ 2.986943] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 2.986943] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=64
[ 2.989549] NR_IRQS: 3, nr_irqs: 3, preallocated irqs: 3
[ 2.989624] clocksource: tod: mask: 0xffffffffffffffff max_cycles: 0x3b0a9be803b0a9, max_idle_ns: 1805497147909793 ns
[ 2.989710] Console: colour dummy device 80x25
[ 2.990875] random: fast init done
[ 2.991934] printk: console [ttyS0] enabled
[ 2.992046] pid_max: default: 65536 minimum: 512
[ 2.992083] LSM: Security Framework initializing
[ 2.992089] Yama: becoming mindful.
[ 2.992434] AppArmor: AppArmor initialized
[ 2.992780] Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[ 2.993118] Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[ 2.993136] *** VALIDATE tmpfs ***
[ 2.993294] *** VALIDATE proc ***
[ 2.993380] *** VALIDATE cgroup1 ***
[ 2.993381] *** VALIDATE cgroup2 ***
[ 2.993663] rcu: Hierarchical SRCU implementation.
[ 2.994504] smp: Bringing up secondary CPUs ...
[ 2.994990] smp: Brought up 1 node, 4 CPUs
[ 3.004343] devtmpfs: initialized
[ 3.005550] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 3.006849] futex hash table entries: 16384 (order: 10, 4194304 bytes, vmalloc)
[ 3.007289] NET: Registered protocol family 16
[ 3.007312] audit: initializing netlink subsys (disabled)
[ 3.007371] audit: type=2000 audit(1589399435.894:1): state=initialized audit_enabled=0 res=1
[ 3.007381] Spectre V2 mitigation: etokens
[ 3.015003] HugeTLB registered 1.00 MiB page size, pre-allocated 0 pages
[ 3.017263] iommu: Default domain type: Translated
[ 3.017322] SCSI subsystem initialized
[ 3.022080] NetLabel: Initializing
[ 3.022080] NetLabel: domain hash size = 128
[ 3.022081] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 3.022090] NetLabel: unlabeled traffic allowed by default
[ 3.031466] *** VALIDATE bpf ***
[ 3.031549] VFS: Disk quotas dquot_6.6.0
[ 3.031564] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 3.031574] *** VALIDATE ramfs ***
[ 3.031578] *** VALIDATE hugetlbfs ***
[ 3.031653] AppArmor: AppArmor Filesystem Enabled
[ 3.032512] NET: Registered protocol family 2
[ 3.032815] tcp_listen_portaddr_hash hash table entries: 32768 (order: 7, 524288 bytes, linear)
[ 3.034249] TCP established hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc)
[ 3.034963] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes, linear)
[ 3.035027] TCP: Hash tables configured (established 524288 bind 65536)
[ 3.035434] UDP hash table entries: 32768 (order: 8, 1048576 bytes, linear)
[ 3.035798] UDP-Lite hash table entries: 32768 (order: 8, 1048576 bytes, linear)
[ 3.035962] NET: Registered protocol family 1
[ 3.035967] NET: Registered protocol family 44
[ 3.036002] Trying to unpack rootfs image as initramfs...
[ 3.098351] Initramfs unpacking failed: Decoding failed
[ 3.099639] Freeing initrd memory: 25316K
[ 3.100032] *** VALIDATE hypfs ***
[ 3.100246] Initialise system trusted keyrings
[ 3.100255] Key type blacklist registered
[ 3.100278] workingset: timestamp_bits=42 max_order=24 bucket_order=0
[ 3.100932] zbud: loaded
[ 3.101155] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 3.101242] fuse: init (API version 7.31)
[ 3.101252] *** VALIDATE fuse ***
[ 3.101253] *** VALIDATE fuse ***
[ 3.101307] Platform Keyring initialized
[ 3.104998] Key type asymmetric registered
[ 3.105000] Asymmetric key parser 'x509' registered
[ 3.105006] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[ 3.105046] io scheduler mq-deadline registered
[ 3.108312] loop: module loaded
[ 3.108342] tun: Universal TUN/TAP device driver, 1.6
[ 3.108373] device-mapper: uevent: version 1.0.3
[ 3.108399] device-mapper: ioctl: 4.41.0-ioctl (2019-09-16) initialised: <email address hidden>
[ 3.108429] cio.b5d5f6: Channel measurement facility initialized using format extended (mode autodetected)
[ 3.109764] drop_monitor: Initializing network drop monitor service
[ 3.109858] NET: Registered protocol family 10
[ 3.113680] Segment Routing with IPv6
[ 3.113695] NET: Registered protocol family 17
[ 3.113719] Key type dns_resolver registered
[ 3.113748] registered taskstats version 1
[ 3.113751] Loading compiled-in X.509 certificates
[ 3.115068] Loaded X.509 cert 'Build time autogenerated kernel key: 01fa03be7dbdcc047dba8cc4b3de19635d2916cb'
[ 3.115109] zswap: loaded using pool lzo/zbud
[ 3.115176] Key type ._fscrypt registered
[ 3.115177] Key type .fscrypt registered
[ 3.118675] Key type big_key registered
[ 3.120423] Key type encrypted registered
[ 3.120426] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.120429] ima: No TPM chip found, activating TPM-bypass!
[ 3.120432] ima: Allocated hash algorithm: sha1
[ 3.120438] ima: No architecture policies found
[ 3.120442] evm: Initialising EVM extended attributes:
[ 3.120443] evm: security.selinux
[ 3.120444] evm: security.SMACK64
[ 3.120444] evm: security.SMACK64EXEC
[ 3.120444] evm: security.SMACK64TRANSMUTE
[ 3.120445] evm: security.SMACK64MMAP
[ 3.120445] evm: security.apparmor
[ 3.120446] evm: security.ima
[ 3.120446] evm: security.capability
[ 3.120446] evm: HMAC attrs: 0x1
[ 3.121049] Freeing unused kernel memory: 3424K
[ 3.159689] Write protected read-only-after-init data: 88k
[ 3.159690] Run /init as init process
Loading, please wait...
Starting version 245.4-4ubuntu3
[ 3.166103] random: systemd-udevd: uninitialized urandom read (16 bytes read)

[ 3.166322] random: systemd-udevd: uninitialized urandom read (16 bytes read)

[ 3.166326] random: systemd-udevd: uninitialized urandom read (16 bytes read)

[ 3.216527] qeth.87067b: loading core functions
Begin: Starting firmware auto-configuration ... done.
Begin: Loading essential drivers ... [ 4.609640] raid6: vx128x8 gen() 22931 MB/s
[ 4.729639] raid6: vx128x8 xor() 14526 MB/s
[ 4.729640] raid6: using algorithm vx128x8 gen() 22931 MB/s
[ 4.729640] raid6: .... xor() 14526 MB/s, rmw enabled
[ 4.729641] raid6: using s390xc recovery algorithm
[ 4.730501] xor: automatically using best checksumming function xc
done.
Begin: Running /scripts/init-premount ... ln: /tmp/mountroot-fail-hooks.d//scripts/init-premount/lvm2: No such file or directory
done.
Begin: Mounting root file system ... Begin: Running /scripts/nfs-top ... done.
Begin: Running /scripts/nfs-premount ... done.
Begin: Running /scripts/casper-premount ... done.
done.
[ 34.219679] random: crng init done
[ 34.219685] random: 7 urandom warning(s) missed due to ratelimiting

BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) [6nUnable to find a medium containing a live file system

Ubuntu 18.04
[ 0.366977] Linux version 4.15.0-20-generic (buildd@bos02-s390x-014) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #21-Ubuntu SMP Tue Apr 24 06:14:23 UTC 2018
 (Ubuntu 4.15.0-20.21-generic 4.15.17)
[ 0.366983] setup.1a06a7: Linux is running as a z/VM guest operating system in 64-bit mode
[ 0.693006] setup.b050d0: The maximum memory size is 65536MB
[ 0.693012] cma: Reserved 4 MiB at 0x0000000fffc00000
[ 0.693045] numa.196305: NUMA mode: plain
[ 0.693195] cpu.33a262: 4 configured CPUs, 0 standby CPUs
[ 0.693640] Write protected kernel read-only data: 11884k
[ 0.694906] Zone ranges:
[ 0.694908] DMA [mem 0x0000000000000000-0x000000007fffffff]
[ 0.694909] Normal [mem 0x0000000080000000-0x0000000fffffffff]
[ 0.694911] Movable zone start for each node
[ 0.694912] Early memory node ranges
[ 0.694913] node 0: [mem 0x0000000000000000-0x0000000fffffffff]
[ 0.694915] Initmem setup node 0 [mem 0x0000000000000000-0x0000000fffffffff]
[ 1.506244] random: fast init done
[ 1.508080] percpu: Embedded 24 pages/cpu @ (ptrval) s59392 r8192 d30720 u98304
[ 1.508171] Built 1 zonelists, mobility grouping on. Total pages: 16515072
[ 1.508173] Policy zone: Normal
[ 1.508175] Kernel command line: %@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[ 1.510120] log_buf_len individual max cpu contribution: 4096 bytes
[ 1.510121] log_buf_len total cpu_extra contributions: 258048 bytes
[ 1.510122] log_buf_len min size: 131072 bytes
[ 1.510175] log_buf_len: 524288 bytes
[ 1.510176] early log buf free: 128436(97%)
[ 3.625859] Memory: 66020408K/67108864K available (8084K kernel code, 1063K rwdata, 3796K rodata, 976K init, 804K bss, 1084360K reserved, 4096K cma-reserved
[ 3.626091] SLUB: HWalign=256, Order=0-3, MinObjects=0, CPUs=64, Nodes=1
[ 3.626102] ftrace: allocating 26213 entries in 103 pages
[ 3.651389] Hierarchical RCU implementation.
[ 3.651391] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=64.
[ 3.651392] 01: HCPGSP2627I The virtual machine is placed in CP mode due to a
 SIGP initial C
PU reset from CPU 00.
02: HCPGSP2627I The virtual machine is placed in CP mode due to a SIGP initial CPU reset from CPU 00.
03: HCPGSP2627I The virtual machine is placed in CP mode due to a SIGP initial CPU reset from CPU 00.
 Tasks RCU enabled.
[ 3.651393] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=64
[ 3.653291] NR_IRQS: 3, nr_irqs: 3, preallocated irqs: 3
[ 3.653347] clocksource: tod: mask: 0xffffffffffffffff max_cycles: 0x3b0a9be8
03b0a9, max_idle_ns: 1805497147909793 ns
[ 3.655715] console [ttyS0] enabled
[ 3.655848] pid_max: default: 65536 minimum: 512
[ 3.655906] Security Framework initialized
[ 3.655907] Yama: becoming mindful.
[ 3.656065] AppArmor: AppArmor initialized
[ 3.680584] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
[ 3.692369] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
[ 3.692730] Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 3.693125] Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 3.693589] Hierarchical SRCU implementation.
[ 3.694307] smp: Bringing up secondary CPUs ...
[ 3.694772] smp: Brought up 1 node, 4 CPUs
[ 3.703824] devtmpfs: initialized
[ 3.706221] evm: security.selinux
[ 3.706222] evm: security.SMACK64
[ 3.706223] evm: security.SMACK64EXEC
[ 3.706224] evm: security.SMACK64TRANSMUTE
[ 3.706225] evm: security.SMACK64MMAP
[ 3.706226] evm: security.apparmor
[ 3.706227] evm: security.ima
[ 3.706228] evm: security.capability
[ 3.706351] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, m
x_idle_ns: 19112604462750000 ns
[ 3.706556] futex hash table entries: 16384 (order: 10, 4194304 bytes)
[ 3.708074] NET: Registered protocol family 16
[ 3.708117] audit: initializing netlink subsys (disabled)
[ 3.708171] audit: type=2000 audit(1589400596.940:1): state=initialized audit_enabled=0 res=1
[ 3.708184] Spectre V2 mitigation: execute trampolines.
[ 3.709530] HugeTLB registered 1.00 MiB page size, pre-allocated 0 pages
[ 3.709862] SCSI subsystem initialized
[ 3.712824] NetLabel: Initializing
[ 3.712825] NetLabel: domain hash size = 128
[ 3.712826] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 3.712838] NetLabel: unlabeled traffic allowed by default
[ 3.729462] VFS: Disk quotas dquot_6.6.0
[ 3.729490] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 3.729616] AppArmor: AppArmor Filesystem Enabled
[ 3.729848] NET: Registered protocol family 2
[ 3.730220] TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
[ 3.732532] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 3.733097] TCP: Hash tables configured (established 524288 bind 65536)
[ 3.733282] UDP hash table entries: 32768 (order: 8, 1048576 bytes)
[ 3.733983] UDP-Lite hash table entries: 32768 (order: 8, 1048576 bytes)
[ 3.734761] NET: Registered protocol family 1
[ 3.734790] Unpacking initramfs...
[ 3.912078] Freeing initrd memory: 13060K
[ 3.913151] Initialise system trusted keyrings
[ 3.913158] Key type blacklist registered
[ 3.913177] workingset: timestamp_bits=42 max_order=24 bucket_order=0
[ 3.914401] zbud: loaded
[ 3.914964] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 3.915090] fuse init (API version 7.26)
[ 3.916368] Key type asymmetric registered
[ 3.916370] Asymmetric key parser 'x509' registered
[ 3.916398] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 2
50)
[ 3.916438] io scheduler noop registered
[ 3.916439] io scheduler deadline registered
[ 3.916484] io scheduler cfq registered (default)
[ 3.918967] loop: module loaded
[ 3.918988] tun: Universal TUN/TAP device driver, 1.6
[ 3.919052] device-mapper: uevent: version 1.0.3
[ 3.919112] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: <email address hidden>
[ 3.919143] cio.b5d5f6: Channel measurement facility initialized using format
 extended (mode autodetected)
[ 3.923591] NET: Registered protocol family 10
[ 3.927905] Segment Routing with IPv6
[ 3.927924] NET: Registered protocol family 17
[ 3.928114] Key type dns_resolver registered
[ 3.928226] registered taskstats version 1
[ 3.928230] Loading compiled-in X.509 certificates
[ 3.930800] Loaded X.509 cert 'Build time autogenerated kernel key: 2c09740200a469c634326d6c1a2c77a41c129820'
[ 3.930813] zswap: loaded using pool lzo/zbud
[ 3.934411] Key type big_key registered
[ 3.934414] Key type trusted registered
[ 3.936076] Key type encrypted registered
[ 3.936078] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.936081] ima: No TPM chip found, activating TPM-bypass! (rc=-19)
[ 3.936105] evm: HMAC attrs: 0x1
[ 3.936530] Freeing unused kernel memory: 976K
[ 3.936542] Write protected read-only-after-init data: 52k
[ 3.975930] qeth.87067b: loading core functions
Starting system log daemon: syslogd, klogd.
 [1;24r [4l (B )0 [m [1;24r [H [J [24;1H [m

                                              Configure the network device
----------------------------

Please choose the type of your primary network interface that you will need for

installing the Debian system (via NFS or HTTP). Only the listed devices are
supported.
Network device type:
  1: ctc: Channel to Channel (CTC) or ESCON connection,
  2: qeth: OSA-Express in QDIO mode / HiperSockets,
  3: iucv: Inter-User Communication Vehicle - available for VM guests only,

  4: virtio: KVM VirtIO,
Prompt: '?' for help>

[Frank Heimes (fheimes)]

With Ubuntu Server 20.04 a new installer (called "subiquity") was introduced.
And subiquity is a bit different compared to d-i.

For the transition phase we still have one (last) 20.04 GA image with d-i, available here (but already marked as legacy):
http://cdimage.ubuntu.com/ubuntu-legacy-server/releases/20.04/release/

Since d-i is legacy, I of course recommended to use (and to become familiar) with subiquity.
And subiquity is available here:
http://cdimage.ubuntu.com/releases/20.04/release/
It operates a bit differently and requires (aot) some data that needs to be handed over via the parmfile.
Please have a look here for some more details:
https://ubuntu-on-big-iron.blogspot.com/2020/03/glimpse-at-subiquity.html

On top one may of course also try the 'ready to use' cloud images (for KVM) or container images (LXD) - for their specific use cases.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-05-20 09:30 EDT-------
The document on Ubuntu 20.04 doesn't mention changes in the installer to subiquity installer. It doesn't mention updates to parmfile to include the ip definitions and ftp to the Ubuntu 20.04.

After having done the parmfile update, the installation proceeded using DASD storage with a usable size of 50GB but when the DASD was selected, Ubuntu complained that the DASD has 0B and cannot proceed.

[Frank Heimes (fheimes)]

The fact that a parmfile is currently needed for a subiquity installation is not ideal and there is a Launchpad bug open to change this: LP 1854513 (https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1854513)
You are welcome to join LP 1854513 and to click the green link in the upper area that says "Does this bug affect you?", to express the urgency of that ticket for you, too.

Regarding the DASD that you are using - is it a DASD ECKD or FBA?
Based on the size I assume it's a DASD FBA (z/VM EDEV) -- or a 3390 model54? (FBA support is in the works)
In case of a DASD ECKD, did you tried to add a VTOC and to (re-)format the disk at the 'Storage configuration' screen? Was the disk used and formatted prior to this installation?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-05-20 13:40 EDT-------
I said I was using DASD. FBA is defined using EDEV of an FCP disk. DASD was dedicated to the guest so it's not a minidisk either. I wrote on my last note with Heinz that the for the DASD, VTOC is not highlighted as a possible selection only FORMAT. When I select the FORMAT option, the installer crash. I also sent the install crash logs to Heinz. I don't see in the bugzilla to attached the logs. I did go into the shell and did a dasdfmt and the dasdfmt was able to format the disk successfully. I went back to the installer and request to do the install again and it detected the the DASD having about 50GB. Looks like you need a dasdfmt DASD to do the install. Before a newly defined DASD or a z/VM formatted DASD was not a problem before. Next, it showed me a LVM allocations it decided for me which I find odd, a 1GB /boot and a 4GB for /. I attempted to changed the sized to 30GB and continue the install but I thought why not allocated all the free DASD space available and after this the installer crash. Restarted the install and for space for /, I said 30GB and it install successfully. I sent screen shots plus the install crash logs to Heinz. Is there a way to attached the logs in the bugzilla?

[Frank Heimes (fheimes)]

I'll ask Heinz-Werner to attach the logs and the screenshots from that mail conversation.

So you are using a DASD ECKD - since it has about 50 GB I assume it's probably a 3390 Model54 - I'll try to find a spare one for test and re-creation.

The storage configuration screen should look like this:
================================================================================
  Storage configuration [ Help ]
================================================================================
  To continue you need to: Mount a filesystem at /

  AVAILABLE DEVICES ^

    DEVICE TY┌─────────────────────────┐
  [ LX0200 lo│< (close) │
    partition 1 existing, already formatted as ext2,│ Info >│
                 mounted │ Reformat >│
    partition 2 existing, unused │ Add VTOC Partition >│
                                                     │ Format >│
  [ Create software RAID (md) > ] │ Remove from RAID/LVM │
  [ Create volume group (LVM) > ] └─────────────────────────┘
                                                                             │
                                                                             │
  USED DEVICES
                                                                             v

                                 [ Done ]
                                 [ Reset ]
                                 [ Back ]

Based on the selected DASD (ECKD), specified by it's device name (here LX0200), the installer provides options to 'Add VTOC' (wipe out disk, too) and to (re-)format.

The suggestion about 1GB for /boot and a 4GB for root is indeed too limited, and this got already
addressed here: https://bugs.launchpad.net/subiquity/+bug/1785321 and further more fixed here: https://github.com/CanonicalLtd/subiquity/pull/737
This happened a while ago and the modification got already rolled out with subiquity 20.05.1 (https://github.com/CanonicalLtd/subiquity/releases/tag/20.05.1).
Hence with current installations (of course in non-air-gapped environments) the subiquity installer looks for updates at the beginning and in case there is one, it let's you know and offers to update itself.
The update screen comes with a message like "Version 20.05.1 of the installer is now available (20.04.3 is currently running)."
Doing so and accepting to update, you shouldn't run into that issue with the small LVs anymore.

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-22 10:05 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-22 10:05 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-22 10:06 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-22 10:06 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-22 10:07 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-22 10:08 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-22 10:11 EDT-------

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-05-22 10:29 EDT-------
I have attached the crash install logs and a screen shot of the Storage Configuration panel. As you can see the "Add VTOC Partition" is not highlighted and cannot be selected. Going back to the DASD storage. You can configure 3390 DASD in multiples of a 3390 MOD1 so you're not limited to the traditional 3390 sizes such as 3390 MOD3, 3390 MOD9, 3390 MOD27, and 3390 MOD54. The DASD storage I defined is a 3390 MOD60 (60 * MOD1). I did not format it in z/VM using CPFMTXA. The storage defined has never been used. We dedicated to the guest which we have done for past install of Ubuntu 18.04 and other Linux on IBM Z distros. We never had a problem. Thinking that it may be that it isn't formatted may be the problem, I format the DASD in z/VM using CPFMTXA. Still have the same problem. From you screen shot you provided with a volser of LX0200, the DASD looks like it has been used before by Linux and was formatted using dasdfmt.

As for the subiquity installer looking for updates at the beginning and if there is one, it let's you know and offers to update itself, I don't get it in the beginning. I do get it on a reinstall. I did request the update, but it did not resolve my DASD having 0B of storage. Going into the shell and doing a dasdfmt on the DASD did solved my problem. The correct size of 50GB shows up on a reinstall, but having to go into the shell and doing a dasdfmt is pretty awkward during an installation. I did experience multiple crash going back and forth.

A question about parmfile. The parmfile line is limited to 80 characters. Is there a way to continue pass 80 characters. I need to specify addition DNS. I need a total of 2. the ip line just fits the ip information with 1 DNS. Probably that is why I'm not prompted for the installer update in the beginning but subsequently after I add the second DNS during the install.

[Frank Heimes (fheimes)]

First of all thanks for sharing the additional information.
I would assume that things worked for you on such a special disk by coincidence - such DASDs are not tested nor supported by subiquity or d-i.
We only use and test on standard 3390 models (like 9, 27, 54 etc.) and work for FBA is underway.
Can you share on how you define such a 3390 MOD60 (60 * MOD1) on zVM (incl. user direct and the dasdfmt command with the options you've used) - and which z/VM release you are using? Since I'm not aware about such kind of DASD definitions...

I 'think' CPFMTXA shouldn't be needed for Linux (just for CMS disks) - for Linux only dasdfmt (with cdl) is needed in case of DASD ECKD storage.

Regarding the parmfile - well, the parmfile is not generally limited to 80 characters, but on z/VM CMS the standard file with 80 chars is the limitation. But that shouldn't be a problem, since you can just proceed with the next line after you reached 80 characters - the linux kernel treats it all as one long line (I think the max is about 11 lines in total). Make sure you don't have unwanted spaces inside of your arguments - in case one argument spans multiple lines.
It's best to start a new line if an argument doesn't fit into the existing line - just to avoid problems.
In case one single argument itself is longer than 80 characters, well, you have to proceed with the next line. In this case the tooling is a bit tricky, since xedit shows by default the command prefix on the very left which 'eats up' some characters - I suggest to disable it to see the entire 80 characters (prefix off | on).

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-05-26 20:05 EDT-------
This is strange that you're saying you only support the traditional 3390 Mod9, Mod27, and Mod54 because on Ubuntu 18.04, we're able to install the OS on a 100GB DASD without any problems. RHEL 8.1 and SLES 15 SP1 doesn't have a problem installing on DASD storage greater then 3390 Mod54. Storage greater then 3390 Mod54 is part of the IBM EAV (Extended Address Volume) support and the current max storage is 1TB. I thought the Linux DASD drivers should support DASD size greater than a 3390 Mod54. This is evident by the fact that going into the shell and doing a dasdfmt works and with the correct DASD size.

The definition of the DASD that are multiple of Mod1 is not handle by z/VM or even KVM. This is done via the IBM System Storage DS8000 series (DS8K) storage console. I've attached display from the console and captions.

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-26 20:07 EDT-------

[Frank Heimes (fheimes)]

Thanks for sharing the configuration details.
Well, I didn't really said that the support is limited to Mod9, 27 and 54, these were just examples, there are more models, like for example Model-108 and Model-108 is a 3390 standard size as well afaik.
But tbh. in the last 15 years where I work on s390x technology I didn't got in touch with a single installation where non-standard sizes were used or disks > mod54.
Even several IBM documentations just mention and recommend the standard sizes, like 'Practical Migration from x86 to Linux on IBM System z' or 'The Virtualization Cookbook'.
For full flexibility in size there is always to option to use zFCP instead of DASD storage.

And it's not surprising that things work differently on 16.04 and 18.04 compared to 20.04, since the installer is brand new - the DASD driver itself of course didn't changed much.
One of the positive things about the new installer is that it's shell offers a nearly fully fledged live system, that allows configurations beyond the installer capabilities.
On top there is still a 20.04 image with a d-i installer available (nowadays called the legacy image: http://cdimage.ubuntu.com/ubuntu-legacy-server/releases/20.04/release/), but of course we want people to switch over to the new one.
Btw. the DASD driver supports even more today pretty uncommon DASD types, like 9345 or 3380, but these aren't tested either.

I'm not going to close this ticket and will try to further investigate what happened and maybe even find a way to re-create (if possible in our env.), but will lower the importance to Medium, since two workarounds exist (legacy image and manual intervention via installer shell).

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-05-27 04:05 EDT-------
(In reply to comment #23)
> First of all thanks for sharing the additional information.
> I would assume that things worked for you on such a special disk by
> coincidence - such DASDs are not tested nor supported by subiquity or d-i.
> We only use and test on standard 3390 models (like 9, 27, 54 etc.) and work
> for FBA is underway.
> Can you share on how you define such a 3390 MOD60 (60 * MOD1) on zVM (incl.
> user direct and the dasdfmt command with the options you've used) - and
> which z/VM release you are using? Since I'm not aware about such kind of
> DASD definitions...
>
> I 'think' CPFMTXA shouldn't be needed for Linux (just for CMS disks) - for
> Linux only dasdfmt (with cdl) is needed in case of DASD ECKD storage.
>
> Regarding the parmfile - well, the parmfile is not generally limited to 80
> characters, but on z/VM CMS the standard file with 80 chars is the
> limitation. But that shouldn't be a problem, since you can just proceed with
> the next line after you reached 80 characters - the linux kernel treats it
> all as one long line (I think the max is about 11 lines in total). Make sure
> you don't have unwanted spaces inside of your arguments - in case one
> argument spans multiple lines.
> It's best to start a new line if an argument doesn't fit into the existing
> line - just to avoid problems.
> In case one single argument itself is longer than 80 characters, well, you
> have to proceed with the next line. In this case the tooling is a bit
> tricky, since xedit shows by default the command prefix on the very left
> which 'eats up' some characters - I suggest to disable it to see the entire
> 80 characters (prefix off | on).

IMO and IIRC any type of 3390 DASD should be usable, regardless of having multiple 3390-Mod1 capacity or just specified cylinders. We also test 3390-ModA EAV and EAV-II DASDs with 77....1062 Mod1 multiples.

The Volume Labael LX0200 is suspicious. IIRC it indicates, that this DASD has been LDL formatted, and often installers can not handle LDL-formatted DASDs, because there is only a single partition that can not be changed.

Please destroy the formatting of the DASD, either by using a CMS tool like CPFMTXA or (under linux) dasdfmt (if you terminate dasdfmt, the format is destroyed) - or do a manual dasdfmt with default parameters, which will use cdl formatting (instead of ldl), and use blocksize 4096.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-05-28 09:52 EDT-------
Not sure if this is related, but from the crash install logs:

mkfs /dev/dasda

It appears that an attempt is made to create a file system on the full block device, instead of a partition. Note that this will fails since writes to the first blocks of an ECKD DASD block device will result in data loss of the contained data.

In any way, I don't see anything related to the DASD driver, so re-assigning back to Heinz-Werner.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-05-28 10:46 EDT-------
This is a newly created device so that was no formatting, but later on it was CPFMTXA formatted under z/VM but the result under Ubuntu installer was the same indicating 0B.

[Frank Heimes (fheimes)]

After all I think I'm coming to the same conclusion like Thorsten (#18).
The ECKD DASD driver should just be able to handle all ECKD DASD type 3390 disks of any flavour, incl. 3390-ModA EAV and EAV-II DASDs. There is no further dependency.

Since a brand new disk device was used (#20), I assume that the low-level format of the disk (using dasdfmt) could be the missing bit. It either couldn't be found and triggered in the UI or wasn't possible (for whatever reason).

May I suggest the following (to prove if this assumption is correct or not):

1) could you redo the installation (again with a brand new disk, that was not yet low-level formatted with dasdfmt), ideally using the updated focal daily live image, available here:
http://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/
a) that image will later become the 20.04.1 image
b) that image will not require a parmfile anymore - if there is no parmfile with the basic network config given, an early component of the installer will just ask about the basic network info interactively in the console

2) start the installation until you reach the initial subiquity text-based UI screen, but do not proceed there, and just hit 'F2' (or F1 for Help and the 'Enter shell') to reach the installer shell. (One of the big advantages of the new installer is that you are now already in a full-fledged live system.)
a) find the disk you are going to use with 'lszdev'
b) enable that disk manually with 'chzdev -e <device>'
c) check with 'lszdev' or 'lsdasd' the assigned block device name (highly likely 'dasda')
d) manually low-level format that disk with 'dasdfmt --disk_layout=cdl -b 4096 /dev/dasda'
[ e) optionally create a partition using 'fdasd -a /dev/dasda' ]

Then I think it's easiest (even if a bit annoying) to restart the installation from scratch, but now proceed with the subiquity text-based UI.
If you are now able to complete the installation, it indicates that we need to look at the dasdfmt portion of the installer, if you still struggle to complete the installation, please post the issues here - ideally including the content of /var/log and (in case not empty) /var/crash.

[Frank Heimes (fheimes)]

Just coming back to the documentation on the new way of doing installations, especially on s390x with 20.04. It got now reworked and improved and incl. several (also s390x platform specific) step-by-step examples.

The landing page is the official Ubuntu Server Guide for 20.04 LTS (chapter 'Installation'):
Ubuntu Server Guide - 20.04 LTS:
http: https://ubuntu.com/server/docs/install/general
pdf: https://assets.ubuntu.com/v1/10d22089-ubuntu-server-guide.pdf

The step-by-step examples can also be found at 'discourse' where it's possible to comment on them:
- "Interactive live server installation on IBM Z LPAR (s390x)"
  https://discourse.ubuntu.com/t/interactive-live-server-installation-on-ibm-z-lpar-s390x/16601
- "Interactive live server installation on IBM z/VM (s390x)"
  https://discourse.ubuntu.com/t/interactive-live-server-installation-on-ibm-z-vm-s390x/16604

For the reason of completeness let me also point to the autoinstall documents here:
- "Non-interactive IBM Z LPAR (s390x) installation using autoinstall"
  https://discourse.ubuntu.com/t/non-interactive-ibm-z-lpar-s390x-installation-using-autoinstall/16988
- "Non-interactive IBM z/VM (s390x) installation using autoinstall"
  https://discourse.ubuntu.com/t/non-interactive-ibm-z-vm-s390x-installation-using-autoinstall/16995

[Pedro Principeza (pprincipeza)]

Adding a minor mention in the LP Bug, as we had a customer being affected by the issue while installing 20.04.1 on a z14, atop of z/VM 6.4, using unformatted 3390-M9s.

The workaround provided by Herr Heimes on LP Bug #1878596, Comment #21, has proven to be a workaround for the issue.

I believe we should either check for the current format of the disk on z/VM (that's not filesystem formatting, as Heimes pointed out, but rather a low-level format of the ECKD to be used) using lszdev/lsdasd then use dasdfmt, or point out in the docs we should have someone run CPFMTXA in z/VM to add CDL to the DASD, enabling its usage by the Guest.

[Launchpad Janitor (janitor)]

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

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-09-10 13:04 EDT-------
I did an CPFMTXA format on the DASD device and it did not solve the problem.

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-22 10:06 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2020-05-26 20:07 EDT-------

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-09-11 05:49 EDT-------
(In reply to comment #38)
> I did an CPFMTXA format on the DASD device and it did not solve the problem.

After a CPFMTXA or any other method to destroy a Linux DASD formatting a DASD will be reported as not formatted ("n/f").
Whenever a DASD is being detected as not formatted, the installer should offer the dasdfmt (with -l cdl -b 4096) and ask for confirmation.

[Frank Heimes (fheimes)]

Hi Thorsten, I agree.
And that initial low level format issue is currently looked at based on LP 1887669.
Having that in mind I came up with the suggestion in comment #21 (https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1878596/comments/21)
asking for a little detour via the installer shell and doing a manual:
'dasdfmt --disk_layout=cdl -b 4096 /dev/dasda'
and
'fdasd -a /dev/dasda'
(replace 'dasda' for yours)
Due to the richness of the live installer one can almost do everything there, and with that suggestion I wanted to make sure (and narrow down) that the issue is really only caused by a not yet low-level formatted dasd.
If formatted this way the installation (and all follow-on installation on this dasd) should work.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-09-17 14:59 EDT-------
I used the Ubuntu 20.04 focal image mentioned below because the live-server version did not prompt for installation information during install.

http://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/

The focal version does prompt but have some suggestion. Listed below is the output of the installation with the focal version.

00: 0000003 FILES PURGED
00: RDR FILE 0037 SENT FROM ZUKVMPF1 PUN WAS 0037 RECS 101K CPY 001 A NOHOLD NO
KEEP
00: RDR FILE 0041 SENT FROM ZUKVMPF1 PUN WAS 0041 RECS 0001 CPY 001 A NOHOLD NO
KEEP
00: RDR FILE 0045 SENT FROM ZUKVMPF1 PUN WAS 0045 RECS 334K CPY 001 A NOHOLD NO
KEEP
00: 0000003 FILES CHANGED
00: 0000003 FILES CHANGED
01: HCPGSP2627I The virtual machine is placed in CP mode due to a SIGP initial C
PU reset from CPU 00.
[ 1.666495] Initramfs unpacking failed: Decoding failed
Unable to find a medium container a live file system
Attempt interactive netboot from a URL?
yes no (default yes): yes
Available qeth devices:
0.0.1c70
zdev to activate (comma separated, optional): 0.0.1c70
QETH device 0.0.1c70:0.0.1c71:0.0.1c72 configured
Two methods available for IP configuration:
* static: for static IP configuration
* dhcp: for automatic IP configuration
static dhcp (default 'dhcp'): static
ip: 192.168.11.37
netmask (default 255.255.255.0): 255.255.240.0
gateway (default 192.168.11.1): 192.168.5.1
dns (default 192.168.5.1): 192.168.10.10 9.0.128.50 9.0.130.50
vlan id (optional):
http://cdimage.ubuntu.com/releases/focal/release/ubuntu-20.04-live-server-s390x
.iso (default)
url:
http_proxy (optional):
Configuring networking...
QETH device 0.0.1c70:0.0.1c71:0.0.1c72 already configured
IP-Config: enc1c70 hardware address 02:20:12:00:00:0b mtu 1500
IP-Config: enc1c70 guessed broadcast address 192.168.15.255
IP-Config: enc1c70 complete:
address: 192.168.11.37 broadcast: 192.168.15.255 netmask: 255.255.240.0
gateway: 192.168.5.1 dns0 : 192.168.10.10 dns1 : 0.0.0.0
rootserver: 0.0.0.0 rootpath:
filename :
BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6.1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) [6nwget: bad address 'cdimage.ubuntu.com'
Unable to find a medium containing a live file system

This particular one failed because, I wasn't aware of how to specified multiple DNS ip addresses, but it should be noted that I get "[ 1.666495] Initramfs unpacking failed: Decoding failed" and it waited a while before continuing. When I first saw this message I thought it had failed already. It did finally come back and prompted me for installation information. From the output it looks like it supports multiple DNS ip addresses but the prompt doesn't tell you how. I bypass this problem by specified the DNS for external and the installation worked. The DASD that is not dasdfmt first will cause installation failure even using the focal version of the Ubuntu 20.04 ISO. I went into help on top of the screen and starting a shell to do a dasdfmt on the DASD, but after completing the dasdfmt command, you cannot continue where you left off in the installation. You need to restart the Ubuntu 20.04 insta...

[Steve Langasek (vorlon)]

> http://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/

Please note that development has ceased on the legacy d-i installer, and although daily images have been produced, we are not intending to update this installer in future point releases of 20.04. So while the d-i images may be useful for comparative testing, the focus should be on fixing this in the live installer.

> I used the Ubuntu 20.04 focal image mentioned below because the live-server
> version did not prompt for installation information during install.

Which installation information were you not prompted for?

[Frank Heimes (fheimes)]

So you picked the right image and installer '20.04.1' (live installer), since you got interactively promped at the console for the basic network configuration information, indicated by:
"Attempt interactive netboot from a URL?" (and the following questions), great!
(The 20.04 image does not have this, but is superseeded by the 20.04.1 image anyway ...)

Looks like some more information/clarification about the DNS configuration option at this early stage of the installation is needed.
At this stage of the installaton it's about making sure that the installer is able to find and reach the image file (ISO).
Hence, either an external DNS is needed, in case you point to the external location of the installation image at http://cdimage.ubuntu.com (it's the default), or an internal DNS is needed in case the installation is based on a local install server (or maybe even none). Internal install servers are pretty often used in IBM Z and LinuxONE customer environments and would of course also require that an URL, other than the default is specified, that points to your local install server.

So far pristine DASDs (DASDs that were never used before and are therefor not yet low-level formatted) need to be manually formatted in the (live installer) shell - for now - like I suggested in comment #21 and like you now successfully did.
This is a known bug that is currently look at and is btw. addressed in this separate LP ticket:
LP 1887669 - "subiquity on s390x doesn't handle pristine DASD disks that need an initial low-level format" (https://bugs.launchpad.net/bugs/1887669)
(Btw. you are welcome to click the link - roughly at the upper/left at LP 1887669 - that this bug affects you too.)

I'm happy to see that the installation now worked for you (with this little workaround of manually calling dasdfmt at the shell) - since it tells me that the somewhat special 3390-ModA EAV and EAV-II DASDs (like your 3390 MOD60 - configured as a multiple of 60 of a 3390 MOD1) generally work!

Just reiterating on Steve's comment:
- The the legacy d-i 20.04 image (mentioned earlier) is still available, but will not be updated anymore
- If you think that it should be possible to specify more (network, but also other) configuration information or if more clarity is needed, please let us know.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-11-11 10:36 EDT-------
IBM Bugzilla status->closed, documented within the BZ

[Frank Heimes (fheimes)]

This bug is fixed with
https://github.com/CanonicalLtd/subiquity/releases/tag/21.01.1
for Ubuntu releases H, G and F.

I tested it also with a IBM EAV (Extended Address Volume) 3390-A 180 (= 180 x Mod1).
Just notice that a dasdfmt that subiquity does under the hood may take a very long time (depending on your setup).