Installed lpar onto 154d dasd drive, using LVM automatic partitioning recipe.
After installation and reipl, I did the following:

$ sudo chzdev -e 254d
ECKD DASD 0.0.254d configured

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.4.0-60-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
Using config file '/etc/zipl.conf'
Ignore section 'old': Image file '/boot/vmlinuz.old'
Building bootmap in '/boot'
Building menu 'menu'
Adding #1: IPL section 'ubuntu' (default)
Ignore #2: IPL section 'old'
Preparing boot device: dasda (154d).
Done.

$ sudo pvcreate /dev/dasdb1
WARNING: ext4 signature detected on /dev/dasdb1 at offset 1080. Wipe it? [y/n]: 
y
  Wiping ext4 signature on /dev/dasdb1.
  Physical volume "/dev/dasdb1" successfully created

$ sudo vgextend s1lp7-vg /dev/dasdb1
  Volume group "s1lp7-vg" successfully extended

$ sudo lvextend s1lp7-vg/root /dev/dasdb1
  Size of logical volume s1lp7-vg/root changed from 38.89 GiB (9957 extents) to 
80.16 GiB (20521 extents).
  Logical volume root successfully resized.

$ sudo resize2fs /dev/mapper/s1lp7--vg-root 
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/mapper/s1lp7--vg-root is mounted on /; on-line resizing 
required
old_desc_blocks = 3, new_desc_blocks = 6
The filesystem on /dev/mapper/s1lp7--vg-root is now 21013504 (4k) blocks long.

Which is activate another dasd drive; update initramfs; format physical
volume on the new drive's partition; extend volume group to include that
physical volume; extend root logical volume to use new the new physical
volume; and resize the root filesystem. Confirmed with df that root
filesystem is now twice as big.

At the end of all of this I have triggered a reboot; whilst watching
Operating system messages. Reboot was completed successfully. Thus imho
this bug is invalid.

However, I do think that on Ubuntu systems "chzdev -e" should always
trigger "initramfs-update -u" irrespective of what has been activated.
Such that initramfs has as up-to-date udev rules as possible. Simply
because it is impossible to predict at chzdev activation time whether or
not something will be formated and added to become part of the rootfs
backing devices or not.

** Changed in: linux (Ubuntu)
       Status: New => Invalid

** Changed in: ubuntu-z-systems
       Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1641078

Title:
  System cannot be booted up when root filesystem is on an LVM on two
  disks

Status in Ubuntu on IBM z Systems:
  Invalid
Status in linux package in Ubuntu:
  Invalid

Bug description:
  ---Problem Description---
  LVMed root file system acrossing multiple disks cannot be booted up 
    
  ---uname output---
  Linux ntc170 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:47:15 UTC 2016 
s390x s390x s390x GNU/Linux
   
  ---Patches Installed---
  n/a
   
  Machine Type = z13 
   
  ---System Hang---
   cannot boot up the system after shutdown or reboot
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   Created root file system on an LVM and the LVM crosses two disks. After shut 
down or reboot the system, the system cannot be up. 
   
  Stack trace output:
   no
   
  Oops output:
   no
   
  System Dump Info:
    The system is not configured to capture a system dump.
   
  Device driver error code:
   Begin: Mounting root file system ... Begin: Running /scripts/local-top ...   
lvmetad is not active yet, using direct activation during sysinit 
    Couldn't find device with uuid 7PC3sg-i5Dc-iSqq-AvU1-XYv2-M90B-M0kO8V. 
   
  -Attach sysctl -a output output to the bug.

  More detailed installation description:

  The installation was on a FCP SCSI SAN volumes each with two active
  paths.  Multipath was involved.  The system IPLed fine up to the point
  that we expanded the /root filesystem to span volumes.  At boot time,
  the system was unable to locate the second segment of the /root
  filesystem.   The error message indicated this was due to lvmetad not
  being not active.

  Error message:   
         Begin: Running /scripts/local-block ...   lvmetad is not active yet, 
using direct activation during sysinit 
         Couldn't find device with uuid 7PC3sg-i5Dc-iSqq-AvU1-XYv2-M90B-M0kO8V 
          Failed to find logical volume "ub01-vg/root" 
          
  PV Volume information: 
  physical_volumes { 

                 pv0 { 
                         id = "L2qixM-SKkF-rQsp-ddao-gagl-LwKV-7Bw1Dz" 
                         device = "/dev/sdb5"        # Hint only 

                         status = ["ALLOCATABLE"] 
                         flags = [] 
                         dev_size = 208713728        # 99.5225 Gigabytes 
                         pe_start = 2048 
                         pe_count = 25477        # 99.5195 Gigabytes 
                 } 

                 pv1 { 
                         id = "7PC3sg-i5Dc-iSqq-AvU1-XYv2-M90B-M0kO8V" 
                         device = "/dev/sda"        # Hint only 

                         status = ["ALLOCATABLE"] 
                         flags = [] 
                         dev_size = 209715200        # 100 Gigabytes 
                         pe_start = 2048 
                         pe_count = 25599        # 99.9961 Gigabytes 

  
  LV Volume Information: 
  logical_volumes { 

                 root { 
                         id = "qWuZeJ-Libv-DrEs-9b1a-p0QF-2Fj0-qgGsL8" 
                         status = ["READ", "WRITE", "VISIBLE"] 
                         flags = [] 
                         creation_host = "ub01" 
                         creation_time = 1477515033        # 2016-10-26 
16:50:33 -0400 
                         segment_count = 2 

                         segment1 { 
                                 start_extent = 0 
                                 extent_count = 921        # 3.59766 Gigabytes 

                                 type = "striped" 
                                 stripe_count = 1        # linear 

                                 stripes = [ 
                                         "pv0", 0 
                                 ] 
                         } 
                         segment2 { 
                                 start_extent = 921 
                                 extent_count = 25344        # 99 Gigabytes 

                                 type = "striped" 
                                 stripe_count = 1        # linear 

                                 stripes = [ 
                                         "pv1", 0 
                                 ] 
                         } 
                 } 

  
  Additional testing has been done with CKD volumes and we see the same 
behavior.   Only the UUID of the fist volume in the VG can be located at boot, 
and the same message:  lvmetad is not active yet, using direct activation 
during sysinit 
  Couldn't find device with uuid xxxxxxxxxxxxxxxxx  is displayed for CKD disks. 
Just a different UUID is listed.   
  If the file /root file system only has one segment on the first volume,  CKD 
or SCSI  volumes, the system will IPL.  Because of this behavior, I do not 
believe the problem is related to SAN disk or multipath.   I think it is due to 
the system not being able to read the UUID on any PV in the VG other then the 
IPL disk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1641078/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to