Bug 1104899

Summary:	If yast2 bootloader (or kernel update) detects a running docker it fails
Product:	[openSUSE] openSUSE Distribution	Reporter:	Andreas Schneider <asn>
Component:	YaST2	Assignee:	Josef Reidinger <jreidinger>
Status:	RESOLVED FIXED	QA Contact:	Jiri Srain <jsrain>
Severity:	Critical
Priority:	P1 - Urgent	CC:	ancor, jreidinger, sbahling
Version:	Leap 15.1
Target Milestone:	---
Hardware:	Other
OS:	Other
URL:	https://trello.com/c/B8WEpPv5
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Andreas Schneider 2018-08-15 08:20:08 UTC

If yast2 bootloader detects a running docker it fails.


  Probing file systems failed

  Unexpected situation found in the system.


If you check the details you get:


  command '/sbin/udevadm info '/dev/mapper/docker-254'' failed:                                                                

  stderr:
  Unknown device, --name=, --path=, or absolute path in /dev/ or /sys expected.
  exit code: 4


Because of this, a kernel update leaves the system in a broken state and if you reboot the system doesn't come up.


I dunno which tool it is exatly but it should ignore docker devices!!!

Comment 1 Scott Bahling 2018-08-15 09:41:15 UTC

I think the problem is that the docker device has a ':' in the name and that breaks the blkid parsing in libstorage:

https://github.com/openSUSE/libstorage-ng/blob/master/storage/SystemInfo/CmdBlkid.cc#L63

libstorage assumes the following output format from blkid:

DEVICE_PATH: DEVICE INFO

example:

  /dev/sda1: UUID="03b51670-8c55-43c9-95ad-a89e7b8951b7" TYPE="swap" PARTUUID="000031e8-01"

The following on our system is breaking the parsing:

  /dev/mapper/docker-254:3-266193-pool: UUID="b8965f68-1e7c-4fac-982b-5859dca91de5" TYPE="ext4"

libstorage splits the device path out as /dev/mapper/docker-254 and I guess that gets used for /dev/udevadm call which subsequently fails.

Comment 2 Scott Bahling 2018-08-15 09:43:27 UTC

(In reply to Scott Bahling from comment #1)

> libstorage splits the device path out as /dev/mapper/docker-254 and I guess
> that gets used for /dev/udevadm call which subsequently fails.
                      ^^^^^^^^^^^
                     /sbin/udevadm of course

Comment 3 Josef Reidinger 2018-08-15 14:35:52 UTC

ancor - looks like something for storage team as it expect modification of libstorage-ng?

Comment 5 Josef Reidinger 2018-08-17 12:09:47 UTC

Thanks, so we have to fix udevadm parsing.

Comment 6 Josef Reidinger 2018-08-22 12:20:25 UTC

fix is in review https://github.com/openSUSE/libstorage-ng/pull/563

Comment 7 Josef Reidinger 2018-08-22 12:52:45 UTC

fix merged for SLE15 SP1 and Leap 15.1 and TW.

Comment 12 Swamp Workflow Management 2019-06-14 16:14:21 UTC

SUSE-RU-2019:1498-1: An update that has 6 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1104899,1120979,1121720,1122660,1130256,1134330
CVE References: 
Sources used:
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src):    libstorage-ng-3.3.318-3.25.5
SUSE Linux Enterprise Module for Basesystem 15 (src):    autoyast2-4.0.69-3.17.10, libstorage-ng-3.3.318-3.25.5, yast2-storage-ng-4.0.221-3.43.1
SUSE Linux Enterprise Installer 15 (src):    autoyast2-4.0.69-3.17.10, libstorage-ng-3.3.318-3.25.5, yast2-storage-ng-4.0.221-3.43.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 13 Swamp Workflow Management 2019-06-24 13:35:00 UTC

openSUSE-RU-2019:1609-1: An update that has 6 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1104899,1120979,1121720,1122660,1130256,1134330
CVE References: 
Sources used:
openSUSE Leap 15.0 (src):    autoyast2-4.0.69-lp150.2.19.1, libstorage-ng-3.3.318-lp150.2.19.1, yast2-storage-ng-4.0.221-lp150.2.28.1