Bug 1139948

Summary:	Problems using an LVM LV to create a bcache device
Product:	[openSUSE] openSUSE Distribution	Reporter:	Ancor Gonzalez Sosa <ancor>
Component:	YaST2	Assignee:	Coly Li <colyli>
Status:	RESOLVED FIXED	QA Contact:	Jiri Srain <jsrain>
Severity:	Normal
Priority:	P5 - None	CC:	ancor, aschnell, colyli, luizluca, snwint
Version:	Leap 15.1
Target Milestone:	---
Hardware:	Other
OS:	Other
URL:	https://trello.com/c/2UEz8I0J
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Bug Depends on:	1139783
Bug Blocks:

Description Ancor Gonzalez Sosa 2019-07-01 15:21:51 UTC

+++ This bug was initially created as a clone of Bug #1139783 +++

I decided to keep the original one to track the AutoYaST issue (which ignores an LV been used as part of a bcache setup) and create this clone to track the problems with bcache triggered by using the Expert Partitioner.

Using such tool, the user can use LVM LV for bcache. It accepts nicely until it actually do partitioning.

It tries to run:

 # /usr/sbin/bcache set-cachemode /dev/system-slow/home-back writethrough
 Error:Wrong device name found

While this one works:

 # /usr/sbin/bcache set-cachemode $(readlink -f /dev/system-slow/home-back) writethrough

It accepts /dev/dm-* but not /dev/system-slow/home-back.

The same goes with "bcache attach" that does not follow symlinks.

After installation finish, it works as expected. The only caveat (probably related) is that systemd waits until it times out for a resume= device (kernel cmdline resume=/dev/disk/by-id/ata-VBOX_HARDDISK_VB4e22b7b1-3df6870d-part3) while my disks have 2 partitions or less and swap is a LVM LV at /dev/system/swap. Fixing that at /etc/default/grub and updating grub.cfg fixes the problem.

In summary (for this particular bug report):

1) Since the bcache tools seem to not follow symlinks, libstorage-ng should follow call them with the proper file name (or with any flag that makes the tools follow the symlinks).
2) yast2-bootloader should not write the wrong (non-existing) device into /etc/default/grub:GRUB_CMDLINE_LINUX_DEFAULT

Comment 1 Arvin Schnell 2019-07-01 18:11:38 UTC

(In reply to Ancor Gonzalez Sosa from comment #0)

> 1) Since the bcache tools seem to not follow symlinks, libstorage-ng should
> follow call them with the proper file name (or with any flag that makes the
> tools follow the symlinks).

From my point of view it is a bug in bcache to not follow symlinks.

Comment 2 Ancor Gonzalez Sosa 2019-07-02 08:18:18 UTC

(In reply to Arvin Schnell from comment #1)
> (In reply to Ancor Gonzalez Sosa from comment #0)
> 
> > 1) Since the bcache tools seem to not follow symlinks, libstorage-ng should
> > follow call them with the proper file name (or with any flag that makes the
> > tools follow the symlinks).
> 
> From my point of view it is a bug in bcache to not follow symlinks.

Coly, what's your point of view as bcache maintainer?

Comment 3 Ancor Gonzalez Sosa 2019-07-23 09:36:54 UTC

Coly, ping...

Comment 4 Coly Li 2019-07-24 15:44:45 UTC

(In reply to Ancor Gonzalez Sosa from comment #3)
> Coly, ping...

My new email service does not forward bugzilla messages to suse.de account. Just realize the problem. Sure I start to handle this problem.

Comment 5 Coly Li 2019-07-30 17:00:35 UTC

(In reply to Coly Li from comment #4)
> (In reply to Ancor Gonzalez Sosa from comment #3)
> > Coly, ping...
> 
> My new email service does not forward bugzilla messages to suse.de account.
> Just realize the problem. Sure I start to handle this problem.

Shaoxiong Li <dahefanteng@gmail.com>, a bcache-tool developer is interested to fix the problem. Now the fix is in processing.

I will update the status once any progress is made.

Thanks.

Comment 6 Coly Li 2019-08-01 17:41:27 UTC

Shaoxiong Li composes a patch for this problem,
https://github.com/dahefanteng/bcache-tools/commit/5cb9e78ac083a3e6f608622c29c95971640872cc

So far the test looks working, can anybody else help to confirm whether the problem is fixed by this patch ?  Then I can be more confident to merge this patch and have them in 15.1.

Thanks in advance.

Comment 7 Coly Li 2019-09-28 05:33:03 UTC

(In reply to Coly Li from comment #6)
> Shaoxiong Li composes a patch for this problem,
> https://github.com/dahefanteng/bcache-tools/commit/
> 5cb9e78ac083a3e6f608622c29c95971640872cc
> 
> So far the test looks working, can anybody else help to confirm whether the
> problem is fixed by this patch ?  Then I can be more confident to merge this
> patch and have them in 15.1.

The patch is OK but the commit log should be improved. Once the patch merged into upstream bcache-tools, I will take it.

Comment 8 Coly Li 2020-02-16 13:34:44 UTC

(In reply to Coly Li from comment #7)
> (In reply to Coly Li from comment #6)
> > Shaoxiong Li composes a patch for this problem,
> > https://github.com/dahefanteng/bcache-tools/commit/
> > 5cb9e78ac083a3e6f608622c29c95971640872cc
> > 
> > So far the test looks working, can anybody else help to confirm whether the
> > problem is fixed by this patch ?  Then I can be more confident to merge this
> > patch and have them in 15.1.
> 
> The patch is OK but the commit log should be improved. Once the patch merged
> into upstream bcache-tools, I will take it.

I just notice package bcache-tools-1.1.0 is in Tumbleweed already, which includes the fix to follow symbolink.

Hmm, should we close this report ?

Comment 9 Ancor Gonzalez Sosa 2020-02-17 09:52:25 UTC

(In reply to Coly Li from comment #8)
> (In reply to Coly Li from comment #7)
> > 
> > The patch is OK but the commit log should be improved. Once the patch merged
> > into upstream bcache-tools, I will take it.
> 
> I just notice package bcache-tools-1.1.0 is in Tumbleweed already, which
> includes the fix to follow symbolink.
> 
> Hmm, should we close this report ?

In general, I agree with closing it as it is, but... there is no plan to release it as a maintenance update or even a installer update for SLE-15-SP1?

It was originally reported for Leap 15.1 and we may get similar reports from customers doing similar tests with SLE-15-SP1 in a near future.

Comment 10 Coly Li 2020-02-17 10:41:10 UTC

(In reply to Ancor Gonzalez Sosa from comment #9)
> (In reply to Coly Li from comment #8)
> > (In reply to Coly Li from comment #7)
> > > 
> > > The patch is OK but the commit log should be improved. Once the patch merged
> > > into upstream bcache-tools, I will take it.
> > 
> > I just notice package bcache-tools-1.1.0 is in Tumbleweed already, which
> > includes the fix to follow symbolink.
> > 
> > Hmm, should we close this report ?
> 
> In general, I agree with closing it as it is, but... there is no plan to
> release it as a maintenance update or even a installer update for SLE-15-SP1?
> 
> It was originally reported for Leap 15.1 and we may get similar reports from
> customers doing similar tests with SLE-15-SP1 in a near future.

SLE15-SP1 is released for a while, I guess product team won't update the package version. But I can do a backport for SLE12-SP4/SLE12-SP5/SLE15-SP1/SLE15-SP2.

So let's keep this report open, until the backport packages are accepted into our products.

Comment 11 Ancor Gonzalez Sosa 2020-02-17 11:36:10 UTC

(In reply to Coly Li from comment #10)
> 
> SLE15-SP1 is released for a while, I guess product team won't update the
> But I can do a backport for SLE12-SP4/SLE12-SP5/SLE15-SP1/SLE15-SP2.

Thanks a ton

Comment 12 Coly Li 2020-03-03 06:58:50 UTC

(In reply to Ancor Gonzalez Sosa from comment #11)
> (In reply to Coly Li from comment #10)
> > 
> > SLE15-SP1 is released for a while, I guess product team won't update the
> > But I can do a backport for SLE12-SP4/SLE12-SP5/SLE15-SP1/SLE15-SP2.
> 
> Thanks a ton

bcache-tools for SLE12-SP4 and SLE12-SP5 are based on bcache-tools-0.1.g71, too far from 1.0.9. So the backport will be only for SLE15-SP1 and SLE15-SP2.

Now SLE15-SP2 already has bcache-tools-1.1 in, I am working on SLE15-SP1.

Comment 13 Coly Li 2020-03-03 11:19:25 UTC

(In reply to Coly Li from comment #12)
> (In reply to Ancor Gonzalez Sosa from comment #11)
> > (In reply to Coly Li from comment #10)
> > > 
> > > SLE15-SP1 is released for a while, I guess product team won't update the
> > > But I can do a backport for SLE12-SP4/SLE12-SP5/SLE15-SP1/SLE15-SP2.
> > 
> > Thanks a ton
> 
> bcache-tools for SLE12-SP4 and SLE12-SP5 are based on bcache-tools-0.1.g71,
> too far from 1.0.9. So the backport will be only for SLE15-SP1 and SLE15-SP2.
> 
> Now SLE15-SP2 already has bcache-tools-1.1 in, I am working on SLE15-SP1.

The backport is submitted to SLE15-SP1:Update, let's wait for the progress.

Comment 15 Swamp Workflow Management 2020-03-16 23:13:48 UTC

SUSE-RU-2020:0700-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 1139948
CVE References: 
Sources used:
SUSE Linux Enterprise Module for Basesystem 15-SP1 (src):    bcache-tools-1.0.9-3.8.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

Comment 16 Swamp Workflow Management 2020-03-23 20:19:22 UTC

openSUSE-RU-2020:0369-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 1139948
CVE References: 
Sources used:
openSUSE Leap 15.1 (src):    bcache-tools-1.0.9-lp151.2.3.1

Comment 17 Coly Li 2020-03-28 17:46:53 UTC

The package is in SLE15-SP1. Here I close this report.