After upgrade from 15.0 LVM Raid is set to NOT ACTIVE at boot

Hi,
After upgrading to 15.1 from 15.0 I have issues during boot. It jumps to maintenance mode where I have to remove /etc/fstab line for my LVM raid and reboot, then it boots normally, then I have to do *pvscan --cache --activate ay *to activate the drive and mount it (it works both from command line and from YAST).
Everything works just fine but after reboot the same problem occurs, can you please point me to more user friendly solution, please?
Thanks

Does /etc/mdadm.conf exist? Is it the same file as used with 15.0? Is it valid?

It exists, not sure if it’s the same file as in 15.0 or not because I haven’t changed anything prior or after the upgrade.
Here is check for validity:

linux-051o:~ # cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb1[1] sdc1[3] sda1[0]
      15628050688 blocks super 1.0 level 5, 128k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/59 pages [0KB], 65536KB chunk

unused devices: <none>
linux-051o:~ # mdadm --detail /dev/md0
/dev/md0:
           Version : 1.0
     Creation Time : Sun Apr 14 18:56:52 2019
        Raid Level : raid5
        Array Size : 15628050688 (14904.07 GiB 16003.12 GB)
     Used Dev Size : 7814025344 (7452.04 GiB 8001.56 GB)
      Raid Devices : 3
     Total Devices : 3
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sat Jun  8 21:10:18 2019
             State : clean 
    Active Devices : 3
   Working Devices : 3
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 128K

Consistency Policy : bitmap

              Name : any:0
              UUID : ff5b18ca:97578e37:5dd6abc1:86ecdb8c
            Events : 37194

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       3       8       33        2      active sync   /dev/sdc1


If you can reliably reproduce this issue, boot with “systemd.log_level=debug printk.devkmsg=on” on kernel command line and provide “journalctl -b” output after it fails.

I just did my first 15.0 to 15.1 online/zypper dup upgrade involving software RAID1 (but no LVM), with kernel locked. /etc/mdadm.conf did not get changed. First boot with old kernel, OK. Installation of 15.1 update kernel lp151.28.4.1 failed to produce an initrd in /boot/. The dup and kernel upgrade boots I did using “systemd.log_level=debug printk.devkmsg=on” on kernel command line. Running mkinitrd -f manually produced error message “targets failed”. I saved journal for each boot too. What should I do next? Attach to Bug 1136641 Failure to install leap15.1 on system with existing md-RAID and LVM](1136641 – Failure to install leap15.1 on system with existing md-RAID and LVM) the saved journals? Something else?

Scratch the parts about no initrd… Old age visual obstacles late at night were causing havoc. It’s booting 15.1 normally now.

Here it is SUSE Paste

This post will expire in 4 Weeks

Not good.
Adjust “Delete After” period in future pastings.

LVM seems to misdetect MD RAID component device for PV which later leads to confusion and failure to detect it second time.

čen 10 10:48:24 linux-051o dracut-initqueue[311]: Scanning devices sdd2  for LVM logical volumes system/rootčen 10 10:48:24 linux-051o dracut-initqueue[311]: inactive '/dev/system/root' [25.00 GiB] inherit
čen 10 10:48:24 linux-051o dracut-initqueue[311]: WARNING: Device /dev/sda1 has size of 15628051087 sectors which is smaller than corresponding PV size of 31256101376 sectors. Was device resized?
čen 10 10:48:24 linux-051o dracut-initqueue[311]: One or more devices used as PVs in VG papuckovi-raid have changed sizes.
...
čen 10 10:48:29 linux-051o systemd[1]: Started LVM2 PV scan on device 8:50.
čen 10 10:48:29 linux-051o lvm[1020]:   Request to update PV Vsbbh2-saFC-gbQt-d9mb-9Xi7-RWSM-Hf3zVA in lvmetad gave response failed. Reason: Ignore duplicate PV
čen 10 10:48:29 linux-051o lvm[1020]:   WARNING: To avoid corruption, restart lvmetad (or disable with use_lvmetad=0).
čen 10 10:48:29 linux-051o systemd[1]: lvm2-pvscan@9:0.service: Main process exited, code=exited, status=5/NOTINSTALLED
čen 10 10:48:29 linux-051o systemd[1]: Failed to start LVM2 PV scan on device 9:0.
čen 10 10:48:29 linux-051o systemd[1]: lvm2-pvscan@9:0.service: Unit entered failed state.
čen 10 10:48:29 linux-051o systemd[1]: lvm2-pvscan@9:0.service: Failed with result 'exit-code'.

which leads systemd to believe that device is not present.

Use of MD metadata format 1.1 or 1.2 instead of 1.0 would likely prevent it (by making start of array no more aligned with physical partition start), but changing it requires full backup/destroy/restore. I would say you have two options - configure LVM to only scan MD RAID devices (see option “filter” in lvm.conf) or disable lvmetad as message suggests (see option “use_lvmetad” in the same place). The former looks more clean.

what period is better for this case?

Was it changed recently? The RAID is pretty new… :frowning: I will try to configure LVM scan filter to your recommendations and see if it helps, thanks :slight_smile:

Sorry for double quote, didn’t make it in the time limit for editing. Is there a chance that something is wrong with those two lines?

čen 10 10:48:24 linux-051o dracut-initqueue[311]: Scanning devices sdd2   for LVM logical volumes system/root
čen 10 10:48:24 linux-051o  dracut-initqueue[311]: inactive '/dev/system/root' [25.00 GiB] inherit

Leading to not loading /etc/mdadm.conf properly because the root filesystem is not iniciated? When running fsck on sdd2 it says that Dirty bit is set, so there might be another problem with that.
The system disk is a flash drive with 2 partitions:
0) /boot/efi

  1. LVM with only /

this was default configuration when installing Leap 15.0 back in April and it was my first time with LVMs so I just let the installer do the job for me.