Bugzilla – Bug 1026707
Yast2 failed to list cached lvm without dm-cache loaded
Last modified: 2017-05-04 14:50:04 UTC
Hello, I have a LV cached (man 7 lvmcache). When I started a new Yast installation in Tumbleweed 20170208, it failed to find it because it was missing kernel module dm-cache. Please, check for cached LV and load dm-cache or simply always load it.
This scenario is not supported. This requires manual intervention before you can start the installation.
The scenario, in case, is a system that was already using a cached LV and just want to upgrade its system using yast-installer. Yast does not need to setup or change the cached LV, just see it, which would even allow the user to simply remove it (if included the fix from bug 1026712). Without the module, yast does not list the cached LV. It gives the user wrong information. The cached LV is not visible anywhere inside the partitioner. Also, when I check the volume group, yast shows the space used by the cached LV as not allocated (which is false). The user would want to create a new LV in order to use this "not allocated" space, but then, yast will offer only the real free space. The correct behavior would be to list the not active LV, even if only to allow it to be removed. yast just needed the module in order to use this setup flawlessly. When module is loaded, yast just sees the cached LV as a normal LV. It can format, mount and use normally. The only remaining problem is dracut, which cannot detect that rootfs needs dm-cache. I workaround it adding dm-cache to a new file /etc/modules-load.d/lvm.conf Would it be too much difficult to add the extra module or does it have a bad side-effect?
Hi Luiz, Looks it's same as bsc#983221. The fix is already staged for factory - https://build.opensuse.org/request/show/491000 I don't know why this bug was not routed to me:-/ BTW, please find the right bugowner next time by OBS: osc maintainer --email lvm2 *** This bug has been marked as a duplicate of bug 983221 ***
(In reply to zhen ren from comment #3) > I don't know why this bug was not routed to me:-/ BTW, please find the right > bugowner next time by OBS: > osc maintainer --email lvm2 For problems like this, it is difficult for a bug reporter to figure out on which level it is. It's difficult enough even for us: Is it YaST on the Ruby level, is it our libstorage, or any of the tools that library ultimately calls?