Skip to content

Instantly share code, notes, and snippets.

@shundhammer
Last active January 19, 2022 15:57
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save shundhammer/2d9e04b0c8722e7af79e853df7a24222 to your computer and use it in GitHub Desktop.
Save shundhammer/2d9e04b0c8722e7af79e853df7a24222 to your computer and use it in GitHub Desktop.
PaaP (Partitioner as a Product)

PaaP (Partitioner as a Product)

Author: Stefan Hundhammer shundhammer@suse.com

Motivation

The YaST installer is a very powerful, but also very complex tool; it is designed to cover a large variety of Linux installation scenarios. The user is asked a lot of questions in a lot of workflow steps; but in many of these, you can simply click "Next" and rely on the defaults.

In regular intervals, somebody tries to come up with something drastically simpler; an installer that is so dumbed down that it is borderline useless for all but the most trivial cases.

But those very simple installers may have their place; in many cases, they are sufficient to do the job. Or they would be; if only they had some of those features that make YaST so powerful. You only rarely need the sophisticated software management down to selecting invididual packages. Even more rarely you need to configure all those kdump parameters or bootloader details.

But partitioning would be nice. With or without LVM, with or without LUKS encryption, with or without RAID, with or without Bcache; all those modern storage technologies.

In other cases, like when you install a virtual machine in QEMU, VirtualBox or VmWare, you might rely on simple defaults. But on real hardware, when you need to take care to keep your existing Windows or another Linux distribution alive, you will want to use a powerful partitioner.

When you know the power of the YaST partitioner, you may also want to use it when you plan to install something completely different; like Windows or Ubuntu or Fedora. None of their partitioners comes even close to the YaST partitioner's capabilities.

Sure, you can boot from an openSUSE or SLE installation medium and then do the partitioning from there. But then you still need to answer the remaining questions to get to the execution phase where the disks are actually partitioned, filesystems created; and then it begins to install packages. This is where you have to abort the installation, clean the new filesystems again and then reboot into that other installation medium of the system that you really want to install.

If only there were an easier and more intuitive way to do this...

PaaP: The Standalone Partitioner Medium

For this use case it would be useful to have a separate medium, very much like the YaST installer, that only has a minimalistic installation workflow that is finished when the partitioning is executed:

  • Boot from the PaaP medium
  • First hardware probing (mostly for X)
  • Start an X server, if possible
  • Start YaST in Qt (GUI) mode if possible or in NCurses (text) mode if not
  • Storage probing (only roughly ordered):
    • Disks
    • Multipath
    • RAID
    • Partitions
    • LVM
    • LUKS
    • Btrfs
    • Bcache
    • ...
  • Storage proposal for preconfigured products according to control.xml (to be discussed)
  • Guided setup for preconfigured products / for standard cases
  • Expert partitioner if requested
  • Storage actions summary
  • Confirm execution
  • Execute storage actions
  • Finished. Ready to reboot.

Integration with other Installation Methods

Not having a decent partitioning tool can be a deal-breaker for other installation methods where YaST is not desired at all; for example:

  • Deploying an image
  • Kiwi with a more complex storage setup
  • Installation with SALT or similar tools

AutoYaST?

It should also be possible to combine the power AutoYaST with such a tool: Feed the PaaP medium with an AutoYaST profile (stripped down to only contain the storage-related part) and do only the storage setup with YaST/AutoYaST.

Open Issues

  • Storing some data that the user already entered, such as mountpoints; maybe store them in a chroot'ed hierarchy like /paap/etc/fstab to avoid getting them overwritten, and for being consumed by the next tool.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment