Reinstall KDE system with LXQt [3]

This is the third article in a series about problems with KDE leading to a reinstallation with LXQt. Both running on top of Debian 10.

The computer concerned is running two NICs because it needs to access both networks that I have here. I have the main one based on a corporate wireless link from next door, which is filtered and throttled, and a second networtk based on a Skinny cellular broadband network modem, which is not filtered or throttled, although speed is moot since there are limitations inherent with 4G cellular data. The Skinny modem is connected to the local devices through a Ubiquiti AirRouter, which includes a DHCP server and network switch. It also provides the wireless network for phones or tablets. The capabilities of the AirRouter are much better than those built into the Huawei Skinny modem for internal networks and that is why I am using it.

There are some issues with LXQt mainly in panels but apart from that the reinstallation of software has gone well on the platform. One issue with this computer in general is that it needs more installed RAM and I am planning to address that in the next week or two, since I need it to be able to run a virtual machine at the same time as the range of stuff I normally use it for. One issue was reinstalling Gimp, I had difficulty in working out where Gimp keeps its config data as I wanted to copy over the config from my existing computer. It turns out that Gimp uses ~/.config/Gimp as a path, but apparently it also used a Flatpak specific path in ~/.var/ to store some data and there is considerable confusion over why it maintains these two paths especially as the user interface of the Preferences dialog doesn't actually point to the ~/.config path when it appears it should.

One of the interesting experiments this week has been to work with the mounting arms that I use to hold some displays. I have used Brateck wall mount arms with VESA adapters on them for this for some years. The key has been to modify these to allow fine control of the height so that when displays are stacked vertically, it is easy to put them close together. 

This photo shows how the attachment of the arm to the "wall" (in this case a vertical post attached to the desk) has been modified to allow its height to be adjustable. This is done with two right angle brackets which are bolted together using 80 mm length M6 gutter bolts, which gives theoretically an adjustment range of 80 mm.

I have to work around issues with the backup system from one of my computers at the moment. rynsc has not been able to connect over the network between the computers and running the backup locally on a computer seems to be the way to go at the moment.

Reinstall KDE system with LXQt [2]; KDE network and display configuration extremely difficult with numerous bugs

As related yesterday I found various issues with KDE on a computer and decided to reinstall Debian 10 with LXQt as the user interface. After completing the installation I attempted to use ConnMan, which is the network configuration manager that comes with LXQt on Debian, to do a manual configuration of the 1.x network adapter to set its IP address manually without using DHCP. However, my experience has repeated that found in another computer where I had used ConnMan in the past, where it has continued to send DHCP requests for this network adapter despite the manual setting and overridden the blank "gateway" setting specified in the manual settings, with the DHCP settings. In this case, the setting that was overridden was the DNS server; it was configuring the system to use the 1.x network's DNS server address obtained via DHCP instead of the 4.x network's DNS server obtained via DHCP for the 4.x network adapter. 

As I have noted the Lubuntu network configuration manager does not have this problem and is definitely the best out of all three. However as I am not sure at this stage of being able to install this on the computer, my next step was to uninstall ConnMan and set the network parameters in the /etc/network/interfaces file. After uninstalling ConnMan, dhclient could not complete any DHCP requests for any interfaces; it seems that dhclient is configured to use settings provided by ConnMan and would have to be reconfigured to work with it. 

The interfaces file entries ended up looking similar to this

auto enp0s31f6

allow-hotplug enp0s31f6

iface enp0s31f6 inet static

           address 192.168.4.173/24

           gateway 192.168.4.11

auto enx00500b60c1eb7

allow-hotplug enx00500b60c1eb7

iface enx00500b60c1eb7 inet static

           address 192.168.1.173/24

In addition, /etc/resolv.conf contains the entry

nameserver 192.168.4.11

After completing these entries the system was rebooted and further checking confirmed the settings had been applied. In addition it was confirmed there had been no further lease requests to any DHCP servers, the lease for the 1.x network adapter (the problematic one that was pushing through unwanted default gateway and DNS server settings) had expired and had not been renewed. 

It therefore appears I have resolved so far the display issues and also the network issues. The only remaining issue out of 3 mentioned in the original article to be resolved is to get x11vnc running. Then there are the separate matters of reinstalling the software that was on this computer before I reinstalled it.

LXQt has some obvious differences from KDE and one of those is the panel configuration is different and at present it will not support more than one panel on the desktop and will not support a panel being in the top position on the lower display, which in the configuration I have with my displays is the ideal place to have just one panel that is shared between both screens. Although a panel can be placed there and used normally, the panel cannot be right clicked and configured using any of the usual menu options for configuration because the menu is truncated. The only fix being to move the panel to the bottom using the panel.conf file, stop and restart the panel and then configure at the bottom then move back to the top when finished configuring. I will have to check with the LXQt project to see if they have any fixes for this problem.

The other key issue of course is fewer widgets available yet for LXQt. The main one I do not have is the disk free space. I can simulate the CPU monitor bars like I am using on KDE (they show CPU usage, memory usage and swap usage) with some of the built in widgets. So apart from some niggling issues related to the differences between the desktop environments I expect to proceed quickly to having this system up and running again fairly soon and to be able to have a more reliable and easier to use system than I was experiencing with KDE.

Reinstall KDE system with LXQt [1]; KDE network and display configuration extremely difficult with numerous bugs

KDE has some great reputation as a desktop environment in Linux and has won considerable plaudits. It however has numerous unresolved bugs which I have observed in the display and network configurations that are leading me to ditch KDE on one of my desktop computers in favour of LXQt. I have had three computers running KDE and one running LXQt all on top of Debian but I will be taking two computers onto LXQt and therefore only having two running KDE.

The concerning issues that are being observed with KDE mainly concern non standard configurations in both display and network, and also the inability to use x11vnc on KDE which somehow blocks it from running. The problem can be summed up as KDE not being sufficiently versatile to allow different configurations where the standard ones are insufficient. For example the VNC client designed for KDE, Krfb, will only buffer one display on a two display computer, making it inferior compared to x11vnc.

The summary of the issues experienced to date is:

• Networking. Unable to configure a static IP address and route for a network adapter and stop the automatic configuration of an adapter via DHCP. Unable to disable a network adapter and stop it from connecting as KDE ignores the disable setting and creates another new adapter with the same settings as the disabled one (the only option then is to disable or remove the adapter at hardware level).
• Display. Unable to save the configuration of two displays on my computer. The displays are stacked vertically. KDE is unable to remember these settings and after each reboot, defaults to side by side displays.
• Remote Frame Buffer. As mentioned above, KDE stops x11vnc from working. Krfb will only buffer one display in a dual display system.

My networking requirement is special as the computer has two network adapters due to being required to connect with two different networks. On LXQt this is relatively easy to set up. On KDE I have experienced the problems mentioned that it keeps ignoring the manual settings. Only one of the adapters can be a default gateway because there can only be one default route to the internet. I have made it clear that the manually configured adapter will not have a default gateway but KDE ignores the instruction to use the manual settings and keeps sending DHCP requests on that network. The net result is it has become impossible to enforce the required network configuration of the computer. 

To illustrate that this is not difficult on other desktop environments, I have set up a virtual machine on the same computer which is set up in VirtualBox settings with the two network adapters with the appropriate configuration in LXQt (the VM is running Lubuntu). This has worked flawlessly without all the dramas that KDE is creating. The network configuration on LXQt on the virtual machine is implemented as the option "Shared to other computers" which allows the specification of an IP address and netmask without gateway settings. In other words that adapter does not have a gateway specified and must not send DHCP requests on the network.

Another difference between LXQt and KDE with regard to networking is the list of configuration methods and their implementation. In the connection manager that is provided with Lubuntu, which is admittedly different from LXQt on Debian, "Shared to other computers" lets a manual IP address and netmask be specified. But this information can't be put in when selecting the same configuration method in KDE. The KDE network manager in this case automatically creates its own IP address on the 10.x.x.x network and you obviously have to configure the rest of your network to match.

The key problem with KDE is it takes over too many things in a computer and makes it difficult to work around its default settings. In LXQt it is extremely straightforward to configure a non standard dual display and save the settings in a config file, extremely straightforward to install and manage x11vnc and it can be more straightforward to configure a network adapter. However ConnMan is a bit more tricky to configure than the Lubuntu network manager - the Lubuntu one is one of the best ones I have used on Linux overall.

I have started a complete reinstall of Debian 10 on the computer despite my misgivings over having to reinstall all the software (including the tricky iscan software for the Epson scanner), because KDE has such an impact on the system, that it is difficult just to put LXQt over the top of it.

Free Linux video editors [4]: Kdenlive

So...I have been creating and editing home video for quite a number of years now. It wasn't a thing much when I was at school; schools didn't have much in the way of video equipment, and editing software at a reasonable price for the low spec PCs we had back then was almost non existent. Most of my time editing video goes back about 20 years to a multimedia course I did at CPIT as part of my DipBC qualification. There, we got to use Adobe Premiere Pro on PCs. From that, I went on to work in a school environment and Windows Movie Maker was available around that time on Windows XP. I also purchased a license for Adobe Premiere Elements and used it for a time, as well as a license for Vegas Movie Studio; both of these products are targeted at the lower end of the video editing market and are lite versions of Premiere Pro and Vegas Pro respectively. So I have a bit of experience with various low end movie editing programs. Premiere Elements was, I remember, very difficult to use, tended to crash a lot. VMS was a lot more stable once various patches had been applied, and had the capability to directly author DVDs. I also purchased a software package to write Lightscribe labels onto DVDs and used these packages together to produce official video DVDs for the school for a while.

When it's come to Linux I naturally expected it would be possible to find some reasonably good video editing software but it has taken a fair while to achieve this, which is reasonable when we consider the resources available to the open source community. In some respects this is a failing of the open source model itself, in that many projects are started and then abandoned or forked. This has happened numerous times in video editing and has been one of my frustrations early on with attempting to locate good software; examples being ShotCut and Pitivi mentioned in earlier articles in this series. Thankfully, as time has gone on and with further investigations, more high quality packages have become known to me. For the moment, Kdenlive has turned out to be the best for the type of stuff I do, and has quite a reasonable range of capabilities, few of which I have actually needed to use in my sample project.

Kdenlive, like some of the other editors such as Avidemux, is basically a GUI front end to the well known FFMpeg libraries, via an intermediary called Melt (MLT). This makes a whole lot of sense to implement the hard work via a well known and resourced existing software library rather than invent a new one in a software application. Kdenlive is thus essentially an application that makes it possible to visually assemble and preview the various source elements that will be combined into a video production. Once this stage has been completed, clicking the Render button calls up MLT/FFMpeg to do the hard work of producing the final video. Of course, this can be quite a slow process, but it can run away in the background; unlike GIMP it doesn't demand a high level of the system's resources so that everything else grinds to a halt.

I found the GUI very easy to work with and only needed to make a few references to the online documentation. The timeline worked more or less exactly the same as other editors I have used and this part was very straightforward; Kdenlive also proved to be very stable when working with it, with no crashes experienced. My very basic project consisted of editing together two large clips which each was made up by joining together a number of smaller ones in Avidemux, and as mentioned previously, the second one was rescaled from 1920x1080 to 640x480 to match the resolution of the first one. There were also some smaller clips to add to the end which were in 1920x1080 that I didn't bother to resize before bringing them into Kdenlive. Since the output resolution of Kdenlive was already set to 640x480, it did the letterboxing and downscaling of these clips itself, which is a useful capability I wasn't aware of. The rendering was also stable, and the fact it took 5 hours to complete rendering the 3 hour clip at 640x480 has not been a significant concern; what has been much more important is the fact the software has proved to be stable and reliable. So I expect this package can do everything I need and I will be interested to see where I can go with it in future. I didn't use any transitions in my project and it will be interesting to explore these in whatever type of video I might work with in future.

Ubuntu LTS vs non LTS releases

Good day. As I install various versions of Ubuntu on a few virtual machines and computers and also use Debian on some as well, there is naturally an important comparison to be made between the Debian and Ubuntu release cycles. Ubuntu has stabilised on a twice yearly release cycle but the LTS releases are every two years and as I am now finding, the 5 years of support for an LTS release is much preferable to only a few months for intermediate releases. Recently I have had to deal with systems installed with Disco releases that are now not being supported for updates as what I understood to be about two years of support has been dropped to just nine months resulting in 404 errors when apt attempts to contact the servers for updates. This in turn affects the ability to install new software as well as update existing packages.

This realisation leads me to conclude that as far as any version of Ubuntu is concerned, it is best to stick with LTS unless you are intending to keep updating every year or twice a year to the latest release. For my laptop that is only used occasionally I am depending on it being able to be installed with new software at any time and not have the situation I had this week where I was unable to install Zoom because the supporting packages for the installation were not available from the official repositories. I was then forced to update to a later version before being able to complete the installation.

For this type of situation we must therefore conclude that it is best to rely on the Ubuntu LTSs which like Debian come out less frequently but are supported for a longer period. The latest LTS is 20.04 (Focal) and hopefully it won't need to be updated until at least 2 years when the next LTS comes out for the software I use on the laptop because I don't want to be caught the same way again. The best thing that can be said is that you can streamline a reinstall by remounting /home to a separate partition and then install as much software as you can to your home folders but this is not possible to achieve for software that relies on apt, dpkg or snap to install. I have only been able to achieve this with portable type software such as AppImage that can be placed into any path as a single file and run there, as well as Firefox Developer and Thunderbird which are designed as portable applications that can run from any folder path and consist of multiple files and folders that can be extracted to any path from an archive.

Using Kodi with multiple monitors is abysmal.

Kodi is a great media player except for how it handles display settings. One of the areas that will really trip it up is when your computer has multiple monitors, especially if they have different resolutions.

What I am generally seeing in my experience with multiple monitors is that Kodi's default if it is the wrong monitor, then you go into the System settings and change the screen to the monitor you want to use, it tries to use that screen, trips over something silly like it is a different resolution from the one it was on before, and refuses to use it. 

Even if you go into the settings file and hard code the display you want it to be on, you can't get it to actually display on that screen, it will completely ignore you.

What I find really annoying is if I manage to get it to work on the correct screen, then if I reinstall the operating system, I have to go through this annoyance all over again. Every other piece of software on my computer can see that there is an existing user profile with settings in it for them to read, but Kodi insists that I have to set it up all over again.

At any rate here is where some of the settings are stored in the settings file.

You can set the monitor to be used by finding the .kodi folder in your user profile, then go into the userdata folder, open guisettings.xml and scroll down to the section starting with <videoscreen>. Then find the <monitor> </monitor> line. This should show the name of the display to be used, e.g.

<monitor>HDMI-2</monitor>

To get the names of the display outputs on your computer, open a command prompt and run

xrandr

which gives a list of the ports with their names. For example a typical output might look like

VGA-1 disconnected...

HDMI-1 connected...

HDMI-2 connected primary...

so the display name you want is one of those ones like VGA-1, HDMI-1, DP-1 and so on.

If Kodi is using its "default monitor", this line will look something like

<monitor default="true">Default</monitor>

and then you need to change it to look like the format above to use the monitor you want.

If Kodi still won't use the correct display then I have found a brute force approach to the settings can be helpful. I recommend you back up guisettings.xml first.

Edit as above except in the <videoscreen> section remove every line except the one that specifies the monitor, e.g.
<videoscreen>
       <monitor>HDMI-2</monitor>
</videoscreen> 

I have found this to work, but once Kodi is running, then naturally it may be necessary to go into the Settings section in the application and change a few of the other settings that were in there, because of the ones you deleted from the settings file.

However on other occasions I have found that Kodi will only work for the first time it runs with most of the display settings removed. After it has written some new stuff into the config file, the next time it starts up, it's problems again, like the settings it wrote to the file contradict the one that tells it which display to use. In other words, this problem can't actually be solved.

So it is simply impossible to use Kodi in certain display configurations; it won't work on any display except the default one.

First Kubuntu computer

So the NUC gets Kubuntu. The primary reason for wanting it on this is with the screen layout with vertical screens, wanting to have the taskbar in the middle between the two, with one taskbar for both. With a TV as the upper screen and the lower screen a smaller computer monitor turned into portrait mode, the logical place to put the taskbar is at the top of the computer monitor, and leave the TV with no taskbar wasting space on it. Don't have to move the mouse so far to get to the taskbar from the top screen either.

The installation was of Kubuntu 19.10 and went very smoothly. As we all know, Kubuntu is the version of Ubuntu that has KDE as its default desktop environment. It is being trialled as an alternative to Lubuntu for offering the same ease of installation whilst also giving us the full bells and whistles of the KDE desktop. How well it performs on lower spec hardware, of course, is the 64 million dollar question. Lubuntu is well known as being optimised for low spec and KDE with the bells and whistles, traditionally, has not been in the same league whatsoever. But the latest versions of KDE have belatedly addressed this concern, and so as we expect the cutting edge release of Kubuntu is likely to include the very latest stable edition of KDE, we assume it will be a bit less of a resource hog than its predecessors.

This is the first time I have installed any of my computers with Kubuntu, as I already have plenty of experience with KDE on Debian. Only a computer that already has Lubuntu would be considered for Kubuntu. Anything running Debian will stay that way as I prefer Debian over Ubuntu for most things, the only reason I am making use of Lubuntu or Kubuntu is they are different enough from plain Ubuntu and include all the missing proprietary bits that Debian omits by default. Hence easier to get going on laptops or other computers with wireless and bluetooth etc.

Once again it is interesting to try the alternatives to Xubuntu which I have now completely abandoned. This is due to it being so slow to be updated, and consequently it has a very dated look either in Ubuntu or Debian form, although some other distros using XFCE by default such as Manjaro have managed to give it a very modern appearance.

Firefox Developer exhausts system resources

One week after reinstalling mainpc I had a repeat of the situation that caused the reinstallation. Firefox Developer, which is the main browser I use, somehow got into a situation where it was using full CPU, RAM and swap for a period. I use the KDE system load monitor widget on the panel to monitor what the system is doing on my computers that have KDE. The system slowed right down and I noticed all three bars on the widget were all the way up. After a period of the system being bogged down and almost impossible to use due to being maxed out in resources, Firefox Developer crashed (or at least the instance that has the most tabs open, the other instances stayed open) and then the bargraphs all dropped to almost nothing.

Unlike the previous occasion the /tmp space was not all consumed so everything is still working properly. Possibly this is because I put /tmp onto its own partition and possibly also because the system had 100 GB of swap available after the reinstall. All the disks had the usual amount of free space available.

When Firefox was reopened there were no obvious issues and the resource use stayed low. However it is worth noting that the open tabs won't all be reloaded at startup, they are reloaded when they are clicked on. I did go through them later to reload and saw no issues with resource use.

It looks like there is some sort of scenario where Firefox can "run away" and crash after using up all the free resources. The whole thing is a bit bizarre but it has happened twice in one week and so I will have to see what I can do to try to find out exactly what is going on. But this could be quite hard to achieve. However I can guess that it probably leaks memory. It probably doesn't release or reuse memory used by a tab when the tab is closed, so it eventually uses up all the memory in the system, crashes and releases it all, then when it reopens, of course it doesn't need all that memory that it had.

The thing you see in KDE's system activity monitor if you open it up (press Ctrl and Esc together) is a few processes called firefox-bin which are the individual browser windows, and a number of processes called Web which don't mean a lot but are using significant amounts of memory, CPU or whatever. When I dig further in, Web  turns out to be using Firefox library files, so it must have something to do with Firefox. The common factor in most cases is using libxul.so, a library that is installed as part of Firefox Developer. 

At any rate this seems to be yet another example of the enormous resource hog that web browsers just seem to all be by default. All the tabbed ones seem to just use ridiculous amounts of memory in the computer.

UPDATE: The process that crashes is called Web Content (as top shows it) and it may only crash a tab rather than the whole browser. I currently have a bug report lodged into the Bugzilla database to see if it can be addressed as a bug in the browser, as I have been able to replicate this with one particular web site which crashes Firefox Developer every time.

General update 2019-02-15

Last week I had some issues with mainpc resulting in it running out of /tmp space which of course is caused or impacted by running out of space on the install volume and caused a number of user files in /home I was working on to become corrupted. I haven't looked at the bigger question of how we can prevent issues like this from bringing down the whole system or how it actually happened. Instead I just chose to reinstall the system from scratch.

There was a delay to getting this done because issues with my internet here created problems for the Debian installer trying to connect to the local mirrors to download install files so in fact mainpc was down for something like 5 days but with the other computers available I was able to keep working to an extent with the main constraint being unable to access any files over the network shares from mainpc.

Key objectives of the reinstall include:

• Recover the entire free space on the SSD for swap file. Previously an attempt was made to allocate half of the swap to Gimp specific temporary/cache allocation. This proved difficult to implement so I decided to revert the full space (99.9 GB) back to swap as Gimp does use this space to cache as needed.
• Allocate /mnt to a separate partitition on the SSD like done to mediapc to ensure there is no possibility of a mount failure allowing files to be written to the SSD instead of a mounted volume on another disk filling up the install volume.
• Allocate /tmp to a separate partition to ensure there is no possibility of a filling up of the rest of the root volume causing a disk space crisis for /tmp or vice versa.

With the system back up and running having rejoined to /home on the RAID-1 array and therefore reusing my existing user profile I gave attention to software reinstallation. The previous installation used the Debian packages for Thunderbird which installed the Daily channel build and caused problems with extensions like Lightning being incompatible and therefore unavailable. I chose this time to download Thunderbird directly from their site and install it directly into my user profile to save space on future reinstalls and ensure it is the Release channel which allows me to use Lightning again.

mediapc has had a new R/W share created in samba to give access to the Video Archive folder which contains a volume of material not in the media share and therefore I can work on the material in that folder from mainpc for convenience. mediapc is about to get various video editors installed as mentioned in a previous post some time ago.

So questions still remain over managing disk space in some of the areas of a typical Linux install and maybe I can address these.

I had a look at rearranging screens because the arrangement was less than optimum for mediapc. Basically at eye level I have four screens: two for mainpc and one each for serverpc and mediapc. Three of those are vertical to save space and keep them as close to me as possible without having to turn around too much. The problem is for video editing on mediapc you want it to be a horizontal aspect ratio for best use of space. However because mainpc and serverpc are used the most the screen layout suits them best and is not really set up for anything else so after trialling an alternative layout I decided to leave things as they are, except for the two 3 metre DVI cables I purchased which will now not be needed but still have to be paid for. At the end of the day the layout really only can be optimised for the two most used computers so video editing will just have to be improvised or I remote to the computer doing the editing from mainpc.

Life with KDE [6]: Clean install serverpc/mediapc

As I was writing in my last post, I am working hard to reinstall both mediapc and serverpc from scratch. In both cases I was hoping to resolve hibernation problems. Both computers now have new Gigabyte GA-B250M-D3H boards in them so the outcomes should be identical.

However on resuming serverpc which has just been reinstalled with KDE over Debian 9.6 I have found that plasmashell is crashing at logon which means no user shell. plasmashell crashes are quite common and have a number of possible causes. If I want to spend some time trying to debug or reporting as a bug I could but so often many of these bugs are not resolved very rapidly, so not using hibernation is an obvious workaround.

So today I am reinstalling serverpc which will be much the same as it is before. As per usual, reusing my existing logon because of having /home on a separate disk volume, will save a lot of time and customisation but there is still a few hours of work reinstalling everything. When I remember I try to back up some of the system folders but of course I forgot to do it this time so I have a harder job. Actually on this blog I use the InstallMyPC tag for articles that give me steps to follow to reinstall the computers. Aaprt from those articles there are many other tasks that I am so proficient at that I don't need to look up any documentation, such as installing Samba and sharing the network drives on each computer.

These days I am more proficient with Linux and see less issues on my computers which in turn means less time spent reinstalling them, I have also found Debian to be the best distro overall so I am spending less time installing different distros like when I was playing with different shells and Xubuntu and stuff. My first try with KDE was a disaster because I found it so hard to adapt to, so I went back to XFCE at that point. But having made the effort the second time with KDE now I am going to stick with it. One computer will keep XFCE but everything else will run KDE now.

serverpc has the flatpak version of Gimp as do other computers I have. I expect to also use the flatpak version of Qgis as it easier to install and because it is an experimental option for the Qgis community, and that means I won't be running the development edition on serverpc now. Because I just need a reliable second option for the current version since mainpc started unexpectedly crashing just one particular project and I found serverpc with the same version of qgis was able to edit the project without any trouble. mediapc will however be installed with the development edition but I am not doing any serious work with the qgis development editions as it is too hard to run something that uses incompatible project files when it crashes and you have to use stable and it can't read the project files from the development edition.

Computing resources optimisation [2G]: Reinstall serverpc and mediapc

As we know when I upgraded everything last month I just put the disks back in with the new boards and just booted everything up and they just ran. I didn't reinstall either of the two new ones that I currently have running, serverpc and mediapc.

However as neither of these computers is able to hibernate, I have started reinstalling serverpc to see if I can get it to hibernate, and if this works, mediapc, which for some reason won't hibernate at the moment, will be reinstalled as well.

Both will be installed with KDE on Debian 9.6 , and reinstallation is not a really big job as neither of them has a lot of software installed, as those two are mainly used for specialised tasks.

Also it's been a useful time to get serverpc to be able to access all of its SSD swap space which is over 100 GB which will come in useful when doing really big jobs that exceed the 32 GB of memory that it has installed.

Hibernation in Debian seems to be quite reliable, and is enabled by default, one of my reasons for choosing it over Ubuntu or its variants, which have hibernation disabled by default. However there seem to be more issues with hibernation not working well when KDE is the desktop environment, compared to my experience with XFCE.

I would have installed mediapc first, since it doesn't have KDE at the moment, but as it doing the backups at the moment it is just easier to do serverpc first and then do mediapc later. I decided to leave serverpc's name as serverpc, and mediapc will stay with that name as well.

It is good that I don't need to enable UEFI on the two new boards as due to my negative experience with UEFI on Linux on the old serverpc, I am sticking to everything being BIOS for the time being. The exception being the NUC which remains UEFI.

The first attempt to hibernate on serverpc was a failure and the desktop environment would not load properly on resume so I flashed the BIOS with the latest version. This had the useful effect of getting rid of all the ACPI error messages at boot. It's interesting the BIOS was already at the second to latest version (Gigabyte F9) and putting it to the latest (F10) got rid of all those ACPI errors. There have been about six revisions of the BIOS for this computer and I was fully expecting to have quite an old version on this two year old board as it is so easy for the manufacturer to not bother updating the firmware at the factory and leave it to a user to fix.

To finish reinstalling serverpc I need to re-enable the root logon (which I haven't got around to doing on mainpc) to be able to get the RAID array online with my user profile so that is one step to be completed. However while resume from hibernation seems to be retrieving application data the KDE desktop environment often does not seem to be reloading properly as instead of the menus etc all you get is a black screen. This is obviously very odd and something I need to do more investigation into as regards KDE. However it seems to be a common issue and maybe it will be easy to resolve.

Firefox Multi Account Containers vs User Profiles [3]

After a bit of playing with a few settings I am returning to my expectation of multiple FF profiles to handle container isolation-like capabilities. The problem with containers is when you do need tracking information to be exchanged between Facebook and another site. With my Wordpress blogs they are set to auto publish to a Facebook page and without being able to selectively disable the containers they will not be able to authenticate with Facebook. I have found that the settings keep getting lost or turned off probably because the Facebook cookies are getting deleted or being isolated in the Facebook container which the Wordpress tab can't get access to.

Firefox has always supported multiple user profiles. There is a built in user profile manager which you can bring up by starting Firefox with the switch -P. This then gives you a list of current profiles and the ability to create delete or rename profiles, and to select a default. In this case since I have both standard Firefox and Quantum, there are profiles for both editions (Quantum's profile is called dev-edition-default). 

After completing the process of creating profiles via this screen, you'll want to make sure you have the default one selected as the one that FF will start up when it opens, because you want to start a specific profile with a custom shortcut (and you'll probably want to have custom themes, home tabs and bookmarks in it so you can tell it apart from the others, too).

To start a browser with a specific profile, you need to ensure you have the correct profile name to pass into the shortcut. You can type in "about:profiles" in the address bar of the browser to get a list of the profiles the browser knows about. However, the list is only updated each time you open the browser and that means if necessary you have to close all windows of that browser to get it to reload. In this case I had created my profile list with regular Firefox and because Quantum windows were still open I had to close them all to get Quantum to show me the profile list.

The command to start Firefox with a specific profile is firefox -P "ProfileName" and it opens that specific profile. Plain old FF with no parameters keeps on using the default. Quantum has some way of seeing there is a dev-edition-default profile and using that instead of the one regular FF is using, which I think is the result of a setting in Quantum's preferences, that tells it to start up with that specific path. If you are using Quantum alongside Firefox the command to start Quantum will be different. I have installed Quantum on some of my computers inside my home directory, instead of a system path, so that I don't have to reinstall it each time I reinstall the system. This is also impacted by the fact we install Quantum from a TGZ file we download, rather than from our distro's repositories as a DEB package. It also ensures that Quantum is able to update itself in our user account's name (i.e with the right permissions) when Mozilla tells the browser to update, as if it was installed in the system path e.g. /usr, only root would have rights to that path.

So in this case to ensure I am starting Quantum I need pass the whole path in the shortcut. With the command line as above it indeed starts up Quantum with a completely different window that has nothing: no shortcuts, theme or extensions. I can now completely customise that profile independently of any other. What I really do need is a custom colour, or maybe changing the string in the title bar. And that I will look at next time. But for now I don't need the multi containers because that window is only being used very specifically for that blog's Wordpress account. So that is how it will happen from here. The next thing is to add a custom shortcut in KDE Menu Editor and I will create a new submenu for browser profiles as well. Well I have been setting these profiles and shortcuts up and creating icons for them out of the profile pictures I use in FB so it is going pretty well and I need to install the Tab Session Manager extension into each profile to save the tabs and the NZ Rail Maps one will need the uget extension as well to handle the downloads. And so it goes.

HOWTO: Enable root login in KDE / Debian

UPDATE: Since I discovered Ctrl-Alt-F1 and found I could root login there and have no problems, I have not bothered modifying any KDE computer to enable the root login.

Last time I wrote that I needed to try a new user profile on serverpc because of issues resuming from hibernation. This has proved to be more involved than I expected because sddm automagically disables root login, and you can't login as yourself, go into a root shell and delete your account, because processes have locked your user login, preventing it from being modified.

After a lot of investigation I found the following instructions which enable root to appear on the KDE logon screen:

https://blog.libero.it/Laoblog2/13228972.html

• Basically, you need to login to a root shell and edit /etc/sddm.conf file. This file may not yet exist on your system, in which case you must create it. You then need to add or change these sections:

[Autologin]
Relogin=false 

[Users]
HideShells=/usr/sbin/nologin,/bin/false,/bin/sync
MaximumUid=65000
MinimumUid=0

It's possible the [Autologin] section may not be needed. The [Users] section is needed in full. The first line hides every system user except root because there are a whole pile of other system users you don't need to appear on the graphical login. The other two lines set the range of user accounts that can appear. Normally the default for MinimumUid is 1000 which of course is the first general user account in the system. Change that to 0 and it will take in root (and other system users, which get blocked by HideShells).

• Also in your root shell run passwd root to ensure a password has been created for root.

• You also need to edit /etc/pam.d/sddm and make the following changes:

Comment out the following line by putting a # character at the beginning of it

auth    required        pam_succeed_if.so user != root nopasswdlogin

If the following line is commented, uncomment it (remove any # character in front of it)

auth    sufficient      pam_succeed_if.so user ingroup nopasswdlogin 

Reboot the system and it should come up with Root enabled on the login screen (it will be highlighted in red instead of black).

• In addition the following step has been found to be necessary:

Comment out a line in /etc/pam.d/sddm that reads as follows

auth      required     pam_succeed_if.so user != root quiet_success

Fun with Buster / KDE over XFCE on Stretch

It's one thing to be able to install an alpha edition of Debian and it's another for it to be usable. But that's part of the whole process for an alpha edition of something.

But because running a Debian alpha is so much of a challenge, I can't do it with a rotated screen like I am attempting to do with my pc4, because I can't guarantee it will be possible to rotate the display with the video configuration of that computer. Therefore the screen has to be in regular landscape orientation and that means I have to find somewhere to have the display that it will fit within the footprint of my desk with the other screens, because at the moment it is vertical to save space.

The other issues with Alpha3 are also significant, and the ones that I have noticed the most so far are in the install process, whereby attempting to install KDE or LXQt as the desktop environment result in a system that will not boot up to that environment. Instead, you get a shell login screen, and you have to type in startx to bring up the desktop environment. XFCE is fine, so my next move will be to try putting KDE over the top of XFCE.

Trying that on serverpc running stretch has turned out to be an issue because, as was my previous experience just putting the breeze logon screen and sddm as the logon manager onto my Debian/XFCE computers (going into XFCE after logon), hibernation has become flaky. Since hibernation is reliable on mainpc running a clean install of KDE on stretch, serverpc's reinstallation from scratch with Debian/KDE is the obvious next move, and fortunately it isn't as time consuming as reinstalling mainpc because serverpc doesn't run a lot of stuff. On the Buster computer this issue won't exist because it won't be expected to hibernate anyhow.

After installing Buster again on pc4, with XFCE as the default desktop environment, I then attempted to install LXQT over the top of it. However, after configuring sddm (the default window manager for LXQt and KDE) as the display manager, the desktop failed to start and I was left with the command shell logon. This is basically a repeat of the issue when installing either KDE or LXQt as the windowing environment during the install. If you type startx then it will start up, apparently in lightdm, which indicates there is some sort of issue with sddm.

At the moment that is what I am left with, but then that is one reason it is an alpha, so I imagine there is probably already work happening to resolve these issues.

serverpc is still having issues after resuming from hibernation, the issues are that one screen fails to load the background and both screens fail to load the panels. So I am going to try setting up a new user profile, fortunately these panels don't have a lot of customisation. bedroompc has had x11vnc put onto it to replace Krfb because the latter can't handle a two homed computer (one with two network interfaces, the wireless and cable) and it picked the wrong interface to bind to so I couldn't remote to it with Remmina. So I have installed the latest version of x11vnc from  debian testing so it will be reliable and I can remote to that to write this blog because I am having problems with my internet again so this is written on a tethered connection on my phone. The cable is set up for internal network use only so that I can run VNC over it, and the internet connection for that computer is made using its internal wireless adapter, either to my wireless access point in the house, or to a tethered phone. So it will be a lot easier to use bedroompc for this than pc4 because I don't need to keep switching one of the KVMs over to pc4.