Forgot to add, that I use my SSD as cache for my hard-disk on LVM. Setup was done following this guide: https://rwmj.wordpress.com/2014/05/22/using-lvms-new-cache-feature

Hello,

Could you please provide some logs about how it failed?

Also if you are with the missing home can you reconstruct the lvm group?

Created attachment 679842 [details]
journalctl -xb

Output of journalctl -xb after a failed boot attempt

Created attachment 679844 [details]
lvdisplay on non-broken system

Created attachment 679845 [details]
pvdisplay on non-broken system

Created attachment 679846 [details]
vgdisplay on non-broken system

Created attachment 679847 [details]
lvdisplay on broken system

Created attachment 679848 [details]
pvdisplay on broken system

Created attachment 679849 [details]
vgdisplay on broken system

After re-enabling the lvm2 update I collected some info using journalctl -xb, lvdisplay, pvdisplay and vgdisplay. I don't know what you mean by 'reconstruct the lvm group'.

Only the output of lvdisplay and vgdisplay is different.

--- a/bad_vgdisplay.txt
+++ b/ok_vgdisplay.txt
@@ -8,7 +8,7 @@
   VG Status             resizable
   MAX LV                0
   Cur LV                1
-  Open LV               0
+  Open LV               1
   Max PV                0
   Cur PV                2
   Act PV                2

--- a/bad_lvdisplay.txt
+++ b/ok_lvdisplay.txt
@@ -5,10 +5,13 @@
   LV UUID                EOJfPM-awmM-ebDP-7k4H-CORP-Betb-AAO2m4
   LV Write Access        read/write
   LV Creation host, time (none), 2016-04-02 17:49:59 +0200
-  LV Status              NOT available
+  LV Status              available
+  # open                 1
   LV Size                1.36 TiB
   Current LE             356515
   Segments               1
   Allocation             inherit
   Read ahead sectors     auto
+  - currently set to     1024
+  Block device           254:3

Jun 07 11:31:47 linux-bshe lvm[1083]: Can't process LV vg_files/lv_home: cache target support missing from kernel?
Jun 07 11:31:47 linux-bshe lvm[1083]: 0 logical volume(s) in volume group "vg_files" now active

Comes from: lib/activate/dev_manager.c

        if (segtype->ops->target_present &&                                    
            !segtype->ops->target_present(seg_present->lv->vg->cmd,            
                                          seg_present, NULL)) {                
                log_error("Can't process LV %s: %s target support missing "    
                          "from kernel?", display_lvname(seg->lv), target_name);
                return 0;                                                      
        }   

Commit that created this is fba86dd4 and the check looks correct.

I noticed some thin provisioning warnings.

I found some warning around thin provisioning that might've fixed it. Should be published here:

http://download.opensuse.org/repositories/home:/scarabeus_iv:/branches:/Base:/System/openSUSE_Tumbleweed

I tried your fix, but sadly it doesn't work.

Jun 07 17:17:11 linux-bshe lvm[1080]: Can't process LV vg_files/lv_home: cache target support missing from kernel?

If you want, I can attach the new journalctl output.

(In reply to Thibaut Brandscheid from comment #14)
> I tried your fix, but sadly it doesn't work.
> 
> Jun 07 17:17:11 linux-bshe lvm[1080]: Can't process LV vg_files/lv_home:
> cache target support missing from kernel?
> 
> If you want, I can attach the new journalctl output.

The complain is that dm_cache was not found either as builtin or module in kernel.

I checked the kernel config and we built it all as modules:
CONFIG_DM_BIO_PRISON=m
CONFIG_DM_PERSISTENT_DATA=m
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_THIN_PROVISIONING=m
CONFIG_DM_CACHE=m
CONFIG_DM_CACHE_SMQ=m
CONFIG_DM_CACHE_CLEANER=m

Please try to run as root "modprobe dm_cache" (maybe it is dash, not underscore) and see if then lvchange can enable your mount.

lvchange -ay lv_home

(In reply to Tomáš Chvátal from comment #15)
> (In reply to Thibaut Brandscheid from comment #14)
> > I tried your fix, but sadly it doesn't work.
> > 
> > Jun 07 17:17:11 linux-bshe lvm[1080]: Can't process LV vg_files/lv_home:
> > cache target support missing from kernel?
> > 
> > If you want, I can attach the new journalctl output.
> 
> The complain is that dm_cache was not found either as builtin or module in
> kernel.
> 
> I checked the kernel config and we built it all as modules:
> CONFIG_DM_BIO_PRISON=m
> CONFIG_DM_PERSISTENT_DATA=m
> CONFIG_DM_CRYPT=m
> CONFIG_DM_SNAPSHOT=m
> CONFIG_DM_THIN_PROVISIONING=m
> CONFIG_DM_CACHE=m
> CONFIG_DM_CACHE_SMQ=m
> CONFIG_DM_CACHE_CLEANER=m
> 
> Please try to run as root "modprobe dm_cache" (maybe it is dash, not
> underscore) and see if then lvchange can enable your mount.
> 
> lvchange -ay lv_home

Also you can just list all the modules using "lsmod.

> modprobe dm_cache
No output (tried it with dm-cache too).

> lvchange -ay lv_home
Volume group "lv_home" not found
Cannot process volume group lv_home

I add the lsmod output as attachment.

Created attachment 680051 [details]
lsmod

output was generated using the proposed fix-repo of this bug-report

(In reply to Thibaut Brandscheid from comment #17)
> > modprobe dm_cache
> No output (tried it with dm-cache too).

It is the dm_cache, it loaded it based on your output of lsmod.
> 
> > lvchange -ay lv_home
> Volume group "lv_home" not found
> Cannot process volume group lv_home
> 
Ok wrong hame, you want to simply start your domain.
The series of the vgscan/pvscan/vgscan + vgchange if that does not work.

Or you can try to restart the systemd service. After the modprobe

systemctl restart lvm2-activation.service

*** Bug 983565 has been marked as a duplicate of this bug. ***

As per the 2nd report it is confirmed that just the dm_cache module is missing.

Adding dracut maintainers to CC, guys any idea if it is something amiss there or what could decide suddenly not to load that module?

I executed vgscan, pvscan & lvscan. The output of lvscan is:

inactive '/dev/vg_files/lv_home' [1.36 TiB] inherit

After running 'lvchange -ay /dev/vg_files/lv_home' and 'systemctl default' xorg is started and the login-manager is displayed. Network is still down, but can be revived with 'systemctl restart network-online.target'.

*** Bug 983833 has been marked as a duplicate of this bug. ***

(In reply to Martin Pluskal from comment #23)
> *** Bug 983833 has been marked as a duplicate of this bug. ***

FYI, Bug 983833 is about dm-thin-pool failing to be loaded. If you modprobe dm-thin-pool && vgchange -ay in the emergency shell, it boots.

Workaround: edit /etc/default/grub and add
 rdloaddriver=dm-thin-pool
to GRUB_CMDLINE_LINUX_DEFAULT.

A similar workaround should work for dm-cache.

Reassigning to dracut maintainer as it is most probably issue there.

@reporter (or anybody having the issue) please provide output of following command on the failing and working systems:

lsinitrd /boot/initrd

Created attachment 681069 [details]
lsinitrd output, as requested

This is from a non-working system. I don't have the initrds for old systems, since they are recreated all the time.

Note that dm-thin-pool.ko is present. The problem is that it isn't loaded before lvm2-activation.service. That won't show up in the lsinitrd output.

I'm also affected with missing dm-cahce.
My initrd has dm-cache.ko file but it does not load it as module is not listed as one to be loaded (lsinitrd -m).

In my case, the partition is /home and it is not necessary to be mounted until fstab is applied. At this time, initrd might be long gone.

Is this really dracut/initrd job to load the dm-cache? Shouldn't systemd/udev/whatever do this job?

(In reply to Luiz Angelo Daros de Luca from comment #27)
> I'm also affected with missing dm-cahce.
> My initrd has dm-cache.ko file but it does not load it as module is not
> listed as one to be loaded (lsinitrd -m).

Those are initrd/dracut modules, not kernel modules.

> In my case, the partition is /home and it is not necessary to be mounted
> until fstab is applied. At this time, initrd might be long gone.

Ditto here.

> Is this really dracut/initrd job to load the dm-cache? Shouldn't
> systemd/udev/whatever do this job?

I've been wondering the same. Shouldn't /usr/lib/systemd/system-generators/lvm2-activation-generator create a module-loading service?

Or shouldn't vgchange cause the module to be loaded by itself?

This is still present in current TW. Go to YaST partitioner, create thin pool + thin volume, assign it mount point, reboot - system drops to emergency mode shell.

Immediately before calling YaST no dm-thin-pool kernel module is loaded; after exiting YaST dm-thin-pool kernel module is loaded. So /something/ loads them in YaST (although I could not find what).

The bug is unrelated to dracut or initrd in general, because these modules are *not* needed in initrd (root fs is not on thin pool) and there is no reason to add them.

As there appears no auto-load mechanism for DM table drivers in kernel, either LVM must load them (it must know what DM tables it needs) or YaST must add modules to be loaded at boot to /etc/modules-load.d.

Of course adding auto-load to kernel would be even better ... as for now simply attempting "lvcreate -T" without modprobe dm-thin-pool first does not work.

The problem was that lvm2 did not find modprobe during build and so did not attempt module autoloading. Please test proposed fix that adds modutils to BuildRequires in home:arvidjaar:boo:983221/openSUSE_Tumbleweed (only i586 and x86_64). This fixes problem for me.

This should be reassigned back to LVM2 ...

(In reply to Andrei Borzenkov from comment #30)
> The problem was that lvm2 did not find modprobe during build and so did not
> attempt module autoloading. Please test proposed fix that adds modutils to
> BuildRequires in home:arvidjaar:boo:983221/openSUSE_Tumbleweed (only i586
> and x86_64). This fixes problem for me.
> 
> This should be reassigned back to LVM2 ...

Verified the fix. It really is working. Thanks for debugging.
Do you want to create the submission yourself?

(In reply to Tomáš Chvátal from comment #31)
> (In reply to Andrei Borzenkov from comment #30)
> > The problem was that lvm2 did not find modprobe during build and so did not
> > attempt module autoloading. Please test proposed fix that adds modutils to
> > BuildRequires in home:arvidjaar:boo:983221/openSUSE_Tumbleweed (only i586
> > and x86_64). This fixes problem for me.
> > 
> > This should be reassigned back to LVM2 ...
> 
> Verified the fix. It really is working. Thanks for debugging.
> Do you want to create the submission yourself?

Never mind. I created the submission for factory taking your changelog and change to the spec file.

Thanks a lot for your work.

This is an autogenerated message for OBS integration:
This bug (983221) was mentioned in
https://build.opensuse.org/request/show/491000 Factory / lvm2

*** Bug 1026707 has been marked as a duplicate of this bug. ***