Skip to content

Instantly share code, notes, and snippets.

Ancor Gonzalez Sosa ancorgs

Block or report user

Report or block ancorgs

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
ancorgs /
Last active Aug 22, 2019
Multipath and AutoYaST experiments


  • When multipath is activated in a Linux system, ALL disks in such system are grouped into multipath devices. For example, if sda is an individual disk while sdb and sdc are actually part of the same multipath, the system will contain two multipath block devices (one for sdb+sdc and another one for sda only). That's represented in the targetmap by the corresponding CT_DISK and CT_DMMULTIPATH elements. When using libstorage-ng, all those disks and multipath devices are also represented in the devicegraph.
  • With AutoYaST, multipath is only activated if start_multipath is true. The presence of a CT_DMMULTIPATH drive has no influence.
  • Important: AutoYaST in SLE12-SPX will often select the disk with bios_id=0x80 for the first drive, no matter whether such drive is CT_DISK or CT_DMMULTIPATH and no matter whether the disk is part of a multipath device. See [this code](

This shows a preliminary idea on how the SUMA requirements could be addressed reusing a lot of code from the current partitioning proposal and from the current Guided Setup.

In the control file, we just need to add a new attribute to identify volumes that must be allocated in its own separate LVM VG. The rest of the <partitioning> section of control.xml would stay as it is now.

And then, the new wizard would reuse many of the steps already present in the current Guided Setup.

ancorgs /
Created Apr 29, 2019
Explanations and labels for editing a partition

Improving the "select disks" screen

See the "Improve devices selection in the Guided Setup PBI.

We basically have to answer three questions.

  1. Which information to display for each device?
  2. Which widget to use for a reasonable number of disks?
  3. Which widget to use for an insane number of disk?

Leaving aside what is correct and what is not, I have problems putting these two sentences from the chat together (from a purelly technical low-level POV).

  1. We can do any change in the WhateverImpl classes without affecting ABI compatibility "because users of library does not use Impl".

  2. A change in the public Bcache breaks ABI compatibility "for all programs linked to libstorage-ng, no matter if bcache stuff is used at all".

Why changing the Bcache class has an binary influence in the other public classes but changing WhateverImpl does not? How are they different in that regard? As I understand, the fact that WhateverImpl is non-public is a convention, not something the compiler knows.


Change 1

Instead of including the skelcd-* packages directly in the inst-sys, the inst-sys will contain a repo containing the skelcd-* packages and maybe also the licenses or any other stuff that the first steps of the installer (i.e. registration and any previous step) expect to get from libzypp.

Let's say that repo is located at /usr/share/fallback-repo

Change 2

ancorgs /
Last active Oct 26, 2018
Wild idea 1 (second iteration) for Partitioner UI
ancorgs /
Last active Sep 21, 2018
Wild idea 1 for Partitioner UI

needed partitions in a S/390 system

  • trying to install in a (E)CKD DASD disk
    • if the disk is formatted as LDL
      • raises an error (no proposal possible in such disk). FIXME: why?
    • if the disk is formatted as CDL
      • with a partitions-based proposal
        • if /boot is within a XFS or ext2/3/4 partition
          • requires no additional partition since the firmware can find the kernel
        • if /boot is within other type of file system
You can’t perform that action at this time.