Jira links for reference

• epic jsc#SLE-16263
• dev jsc#PM-1895

Note to non-SUSE readers: links in this document are only for reference, they don't contain information not mentioned in the text below.

Collected use cases

Here's an overview of the use cases that have been brought up:

• hidpi setting (bsc#1173451)
• (brief) summary of current network settings (bsc#1168487)
• control registration (SCC) settings, like access to update repos
  (bsc#1168490) - and keep these settings for target system
• proxy/authentication settings (bsc#1168495, jsc#PM-2272), also an option to copy these settings to target systen
• view self-update/driver update state
• present extra features (e.g. security roles (jsc#PM-1245))
• 'allow vendor change' state for repository

What is possibly doable

This is just a collection of ideas. It doesn't imply all of them have to be implemented.

1. A link on the first installer page or a separate first page to edit global settings

That could offer control over all kinds of settings that are not directly exposed currently. Like

• repository URL
• autoupgrade
• update vs. normal install
• selfupdate state
• driver update state
• network config
• proxy

Or for things that can't always be autodetected correctly or where the user simply prefers something else

• hidpi

Generally everything from a hypothetical yast.conf (see later).
Changing might involve a restart.
Some things might be read-only (e.g. a network overview).

2. A link on each page to hide additional settings

Much like a 'more' button, or think of the 3 dots on Android.
Maybe not on each page but (say) on the client's main page.

That could offer context related settings that are not always needed. Like

• whether or not to use updates (on the registration page)
• extra security roles (on the roles page?)

If changing a setting in a later stage requires a yast restart, things might get tricky or simply annoy the user too much.

3. A way to store (and keep) settings

It would be a good opportunity to introduce a yast config file to read and store settings. E.g. [/usr]/etc/yast.conf + [/usr]/etc/yast.d.

• it's a central place, settings can easily be copied
• linuxrc could use it instead of install.inf
• it could make weird things like touch /var/lib/YaST2/reconfig_system redundant in the long run
• you could store convenience settings; e.g. turn off the partitioner's 'continue despite this warning' dialog
• it's very helpful to be able to override settings for debugging, e.g. architecture
• it could consolidate the various ways to influence yast
• it can be documented with a man-page (and people know where to look for it)

The config file format should be human-readable (like YAML, not XML).

Maybe: allow environment variables to override config entries in a systematic, predictable way - e.g. based on the keys in the YAML file. For example given a hypothetical yast.conf fragment with

---
arch: s390x
debug: false

install:
  hidpi: false
  repourl: http://example.com/foo
  textmode: true
  update: false

Allow YAST_ARCH=aarch64 YAST_INSTALL_HIDPI=true to change arch and hidpi settings.

Improve Time Zone Selection During Installation

This is part of #903 (Make the installation process shorter).

In the installation workflow (#914), we have this time zone selection:

Problems

• The default is always wrong. For whatever weird reason, it defaults to New York / US Eastern Time (IIRC set from control.xml).

• All kinds of web pages find my approximate location by Geo-IP. Why can't we do the same, at least as the initial value?

• Usability is poor; you have to click very precisely, and that almost never works (see below).

• That level of detail isn't even needed for many users; almost all of Europe uses the same time zone, so it's pointless to locate the exact city.

If this isn't the correct section for this please forward me, thank you.

My sole user for this machine is in none of the important groups by default. I've installed this to be used a personal machine, so this stuff should be configured automatically during intiial configuration by yast-installation.

This has meant that I am unable to invoke flatpak remove as my user. This prevents me removing them from plasma-discover either, which is a significant problem for a home user.

Instead, for simple administrative tasks, I must delegate them to the superuser. This a significant security and convenience flaw, which Fedora Workstation KDE Spin Rawhide does not share.

I've even had to manually add myself to wheel. That's why it is demonstrated as added in the screenshots:

Simplify Online Repos Installation Workflow Steps

This is part of #903 (Make the installation process shorter).

In the installation workflow (#914), we have these steps:

Asking about Online Repos

Selecting Online Repos

Problems

• It's two steps (three if you also count the "Writing..." step where the user just has to wait)

• One step would be totally sufficient (see below)

• Most information in the second step is redundant (see below)

• The second step is much too detailed. It suggests much more complexity than there really is.

• Most users simply don't care: Just use the defaults.

Hi:

At the end of the installation stage, there is a routine that enables "haveged" ..This is no longer needed, I fixed the haveged package to do something sane instead (it is activated by systemd+udev when installed and the neccesary conditions are met)

While working on a research task about if the UI and UX of yast2-firstboot can be improved, I realized the workflow in the provided firstboot.xml example file does not include a step with the settings summary before finishing its execution.

I missed it because

• It is present during the installation process, and
• It allows a not-sequential navigation among the configuration. I.e., the user can go "back" to change, let's say, the bootloader configuration without going back through all the previous screens, and
• It is annoying to have to go Back Back Back and then Next Next Next just because you changed your mind about the keyboard layout settings.

As annoying as a Next-Next-Next driven installation?

I think so.

That's why I'm opening this issue/discussion: for proposing to rethink our installation process and (almost) start directly it in the interactive installation summary, using the defaults that were set by the product installation control file. Thus, the user only needs to make the desired adjustments and proceed to install the product. Hopefully, this could make it quite some steps short and more pleasant (I guess).

Obviously, some steps cannot be skipped (user creation? language and keyboard? product selection + registration? role?) until reaching the summary but, IMHO, it should not stop us to explore this proposal.

In fact, this is how Fedora's installer looks/behaves like, although with a nicer (arguable if you want; that depends on the beholder's eye) UI. I mean, not using a RichText summary.

Fedora 33	openSUSE TW
Workstation Server

Thoughts?

📝 you can find more opinions/discussion at https://lists.opensuse.org/archives/list/[email protected]/thread/7MD6JME5KVK3XBPW5VNRZIO7M2TNAE6G/

• The default one is almost always broken
• Remove this fallback as it can't work anyway
• Of course, report that control file hasn't been found

YaST Installation Screenshots: Tumbleweed 2021-02-20

Screenshots from a YaST Installation of openSUSE Tumbleweed from 2021-02-20 (DVD ISO).

This issue is meant as a reference for screenshots. For any discussions, please open a new issue.

This is the simplest possible linear installation workflow without changing any defaults, i.e. what you get when you just enter the bare minimum of data and click "Next" in every workflow step.

Installation Medium Boot Menu

Network Auto-Setup

Language Selection, Keyboard and License

Hardware Probing

Asking about Online Repos

Selecting Online Repos

Writing / Activating the Selected Online Repos

System Role

Storage (Partitioning) Proposal

Time Zone

Creating the First User Account

Installation Proposal (Summary)

Confirming the Installation Settings to Start the Installation

Performing the Installation: Installing Packages

Finishing the Installation

Asking about Rebooting (With Timer)

Booting

Installation Medium Boot Menu

Since the installation media are still active (the installation USB stick is still plugged in), the boot menu from the media appears a second time.

Boot Menu of the Newly Installed System

Booting the Newly Installed System

The Desktop of the Newly Installed System with Welcome Message

The yupdate patch command is not working as expected when running an openSUSE TW installation in a XEN guest from the latest available NET iso ( VERSION_ID 20200604).

Removing the STDERR redirection for the rake install command

I get a "No such file or directory - rake" error, but I'm not sure what is going on.

https://bugzilla.suse.com/show_bug.cgi?id=1208003 has allowed OpenSUSE to be installable on my LINX 1010 tablet. However, during installation, the display is rotated -90 degrees (to the left) which causes installation to be unnecessarily difficult because the trackpad of the connected keyboard does not account for this rotation despite it obviously being the firmware's default.

I propose that the first page of the installer become a simple dialog asking whether the screen should be rotated, and by how much. I recommend that it be its own page because it would allow keyboard navigation to be convenient.

Imagine you are eager to install your first Linux, and you are greeted by this:

(It's all Greek to me...)

Err... WTF is this? I don't understand the language.
What am I supposed to do here?
Can somebody please talk to me in a language that I understand?!
How do I switch to another language here?

That's what we are doing to our users with our first installation dialog, only with English as the default language:

This dialog is clearly overcrowded. Worse, it is overcrowded with stuff that makes the main purpose of this first installation step almost impossible: Switch to a language that the user can understand. 90% of the screen space being occupied by legalese blurb doesn't make this any easier.

This first installation dialog has been pressed into service for 4 completely different (and largely unrelated) tasks:

• Greet the user and tell him what this is (what product will be installed)
• Select the installation language
• Select the keyboard layout (and offer an opportunity to test it)
• Display the product license (and offer different translations)

The only thing that it does well is the last one: Display the product license. Sadly, that is the one thing that nobody really wants; not the user, not the developers. Only the corporate lawyers.

Selecting the language is the most crucial operation here; without that, the user cannot make sense of anything else. This is basically a showstopper until (by sheer accident, not by design) the user discovers that tiny combo box with the languages that is tucked away in the top left corner. It doesn't draw much attention to itself. It's not very obvious that this is the thing to use to enable the user to understand the rest of the dialog.

Bottom line: This dialog fails miserably at its most important task.

All linux distros except openSUSE have an option to choose Colemak as default keyboard layout

Installation Proposal: Software, Patterns, Roles

This is part of #903 (Make the installation process shorter).

In the installation workflow (#914), we have this workflow step for selecting a role for the installation target machine:

Many steps later, just before actually starting the installation, we have this installation proposal summarizing all the collected settings:

Problems

• The proposal is no longer really a "summary" in the true sense of the word; it is overcrowded, flooding the user with information.

• I don't see the previously selected role anywhere.

• What was selected as the role was expanded to the software patterns that constitute the role, yet the relationship is not clear.

• There are way too many patterns visible there, some of them just because of technical reasons, not really contributing anything useful for the user.

When installing a machine in an isolated network, it's common to over-ride the "sources" section from grub to specify an alternate download url. However, yast2 does not use this url during the repository initialisation step, and all online repositories are forced to https://download.opensuse.org.

Expected Results:

When a custom source is used from grub, these should be the "base urls" used. Alternately, a method to override this in a custom source would be useful :)

Thanks!

While the YaST-installer in Tumbleweed still uses LUKS1 for Full Disk Encryption as default (to enable LUKS2 you have to add "YAST_LUKS2_AVAILABLE=1" as kernel command line option), Agama on ALP already supports LUKS2 with the additional authentication mechanism via TPM2.0.

With the last SRs (sr#1090915 and sr#1090821) being accepted into Factory, the sources in ALP and Factory are finally in sync and IMHO it would be a good time to do the switch from LUKSv1 to v2 with the same defaults as we have in ALP.

While grub2 currently does not support Argon2, we are currently tied to use PBKDF2 as encryption-algorithms. Nevertheless, there are also plans to introduce Argon2 support.
Therefore, it would be nice if the functionality could be easily extended to select an Algorithm in the future.

Please let me know if you need any additional information.

Hello!

Maybe the KDE icon at the desktop selection in the installation should be updated... The icon looks like a bit KDE 4 era :)
Maybe something more Plasma like that? https://quitter.es/avatar/17041-96-20160617151952.jpeg

Fedora allows configuring no password during installation. I know of 2 people who I have suggested Linux to who have decided not to use it simply because a password appears mandatory.

It's not. passwd -d removes this necessity, which means that for such people who shall merely invoke that command subsequent to installation, this mandatory password field is silly, since it wastes time if they'll merely remove it again!

Would configuring YaST2 Security > Password Settings > Minimum Acceptable Password Length to be 0 by default potentially remediate this?

Supports #903.

Hello,

I'm doing a PXE installation (maybe it is relevant) and got an error at https://github.com/yast/yast-network/blob/b3c7b5f27c7aff1d93d99dec37fb485563302dcd/src/lib/network/wicked.rb#L52

I launched the debugger and got two values from query_wicked(iface, "//hostname")

["opensuse152", "opensuse152.localnet."]

From /var/run/wicked/leaseinfo.eth0.dhcp.(ipv4|ipv6), the FQDN is from IPv6 and the plain hostname is from IPv4. I'll try to fix my DHCP setup but yast2 should also deal with that nicely (not raising an exception).

(In this repo so the UX issues are all near each other)

From

https://documentation.suse.com/sle-micro/5.0/single-html/SLE-Micro-installation/#article-installation

Problems

Dialog Title

Authentication for the System Administrator "root"

This is much too long. It consumes way too much screen space in this dialog; almost a quarter of the total screen space.

It's also much too verbose for any user who is not a complete beginner. Linux users know what a root password is; with that title, they have to decipher it first and then do the mental mapping to "oh, it's the root password". Yes, it can also be a root key, not just a password.

But that attempt of being 100% correct and also explaining basic Linux terms to novice users coming from the Windows world is way over the top; it drowns the information content in all that needlessly verbose wording.

I suggest to drastically shorten this to one of

Root Password

or

Root Authentication

(less easy to understand because it doesn't use well-known Linux terms such as root and root password)

For novices, an explanation could be added on the right side where right now it says

Do not forget what you enter here

e.g.

This is the authentication for the "root" user, the system administrator.

Do not forget what you enter here.

Side note: This kind of stuff is what we used to have that help panel for. But that had to go because certain people didn't think it looked cool enough; and now we get all kinds of static texts in the main dialog because the help text is not immediately visible anymore (out of sight and out of mind). That was a clear step back in usability.

Additional Buttons

Everything below the input fields is adding to the complexity, yet probably rarely used. We have 4 (!) UI elements there:

• The static label "Import Public SSH Key"
• The menu button with locations where to import them from
• The "Refresh" button
• The "Browse" button

Both "Refresh" and "Browse" look very much like an afterthought, and they are surely even more rarely used than the menu button. That is a clear case of overengineering killing usability. Those buttons shouldn't be there in the first place, let alone so prominently.

Alternative 1: Use a Pop-Up

We could reduce this to only one button "Import Public SSH Key..." that opens a pop-up dialog.

That dialog could contain the locations, preferably in a selection box, so the user doesn't have to click twice: Once to open the selection pop-up, once to select an item there.

The dialog should be a basic "OK" / "Cancel" dialog. It's debatable where the two remaining buttons "Refresh" and "Browse..." should go: To the right side of the selection box (preferably); or in the dialog button box left of "OK" and "Cancel"? (Meh...).

On second thought, this is probably not very clear if the user should ever go back to this dialog: We'd need to tell him somehow that an imported SSH key (and which one) is used.

Alternative 2: Add more Actions to the Menu Button

We could also remove those two buttons from the dialog and move the corresponding actions to the menu button that right now only holds the locations:

• VBOX_CD-ROM (/dev/sr0)
• ... (/dev/sdv1)
• ---------- (menu separator)
• Refresh
• Browse...

That would move those kludge buttons out of the way, yet they would still be easily accessible; and, even better, at the one place where a user who needs them looks first:

When I want to import a key, I first check the list with the locations, so I click to open the list of available ones. If I don't find the location that I want there, I see the other two actions: "Refresh" and "Browse".

There is no need to pollute the main dialog with that; even less since those things are very rarely used.

I have a Bluetooth mouse. I don't have a USB wireless transceiver. I was able to use my wired keyboard for installation, but some people use entirely wireless keyboards, too, and I'd like to be able to use my mouse for this purpose.

(I realize the folly of purchasing a mouse that doesn't support wired communication, but my Logitech MX Master 3S is the best mouse that I was able to locate.)

A simple section at the start that pairs a mouse or keyboard if necessary (ideally without any user interaction necessary previously to support such entirely wireless nutcases) would be brilliant for those who simply didn't consider this problem when purchasing their peripherals.

IMO inst_mode have been already removed, but maybe not from update, only from installation.

Currently we have to enable libyui REST API in the installer using startshell=1 option in order to run extend libyui-rest-api command and extend inst-sys with required libraries. See https://github.com/libyui/libyui/tree/master/libyui-rest-api

In openQA integration we have to introduce additional steps, and enabling it is not so problematic like handling start shell before the reboot, as on exotic backends like zVM or powerVM, it's more tricky to communicate with SUT (system under test).

As of now, only viable option is to use DUD files, which also require extra steps. Would be great if we could have a parameter to extend installer without interactive steps, e.g. extend=libyui-rest-api,gdb. We can also have solution which is less generic and enables REST API only.

openQA job example: https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD&machine=64bit&test=RAID0_gpt&version=Tumbleweed#step : you can see setup_libyui and teardown_libyui steps which we have to conduct in order to use REST API.