Add test for live installer based on Kde-Live

[okurz]

The live installer was missing for some time from the media and the left overs
in tests showed to be out of date. Changing all necessary references to ensure
the live medium can be booted, the net installer can be run from the plasma
session and the installed Tumbleweed system boots correctly. In the process an
issue with the live installer has been found and is worked around while
recording a reference to the bug.

Adds new variable 'LIVE_INSTALLATION'. 'LIVETEST' must not be set but only
'LIVECD'.

Verification run: http://lord.arch/tests/3043

[okurz]

@Vogtinator

@sysrich as suggested :-)

[okurz]

took me quite some time to get a robust handling of plasma screenlock, i.e. http://lord.arch/tests/2987 through http://lord.arch/tests/3042. I tried to detect screenlocker first during installation and unlock every time which is unstable as the unlocking takes quite some time so we can miss a lot of progress of the installer, especially the "rebootnow" dialog and automatically disappearing installer which actually prevent proper unlocking so the test would get stuck at a locked screen eventually. Then, I tried to unlock it only on the first occurence of locking, openi an xterm while installation is running and disable screenlock but opening the desktop runner while installation is running is near to impossible due to severe performance drop during installation. So then I tried to disable the screenlock for good during the initial setup in 'live_installation'. I did not find any working approach how to disable the plasma screenlock in a robust manner e.g. following advices in https://forum.kde.org/viewtopic.php?f=289&t=125371, https://forum.kde.org/viewtopic.php?f=111&t=132367, http://askubuntu.com/questions/61339/what-is-the-screen-locking-mechanism-under-kde, http://xmodulo.com/control-screen-lock-settings-linux-desktop.html, http://superuser.com/questions/986345/how-to-disable-the-10-minute-screen-timeout-lock-in-kde. So, back to 'install_and_reboot' where again the screenlock is detected, soft failure recorded, screen unlocked and from then on the mouse is wiggled continuously during installation every 30 seconds to ensure the screen is not locked.

[Vogtinator]

Did you try to uncheck the box in:

If it still locks after a certain time, it's a bug that should be reported on the KDE bugzilla.

[okurz]

I did not try to unlock the checkbox in systemsettings but it was unlocked after I wrote ~/.config/kscreenlockerrc
I am not sure if these config files are automatically evaluated or if I need to retrigger reading, e.g. by going to the systemsettings dialog. Anyway, for the current implementation of the test I am not willing to change it anymore right now. Took me too many attempts to get it right. Can you approve it and we see about this later? Anyway, I filed the bug about the screenlocker because I think it should be disabled. Maybe just the change to ~/.config/kscreenlockerrc over kiwi config works?

[DimStar77]

why the limitation to 'Plasma live' in your text? The live installer is also on the GNOME Live media in Tumbleweed

[okurz]

start with Plasma live, get it done, then extend GNOME Live?

[DimStar77]

https://openqa.opensuse.org/tests/245106/modules/updates_packagekit_kde/steps/1/src has some code that is disabling screensavers in plasma (there is similar code in ghe _gpk version)

[kravciak]

If you turn off screensaver by manually editing config files you need to tell KDE config daemon that something has changes - it was easier to workaround this (updates_packagekit_kde).

[okurz]

ok. I will try the visual approach then.

[okurz]

funny thing, the screenlocker approach you pointed me to in ? https://openqa.opensuse.org/tests/245106#step/updates_packagekit_kde/2 I can not see in the video the screenlock checkbox is actually disabled, is it? I am reluctant to follow on with this screenlocker approach. It's a mess. Can we please just merge my test and improve it later? I want to get it of my table and follow on with some other things. It will show unforeseen weird issues that no one thought about anyway I'd assume.

@DimStar77 is ok with it.