Tumbleweed install for March 2016
This month’s install was interesting.
My original plan was to install from the KDE live iso. So I downloaded “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20160307-Media.iso” and wrote that to a USB. It booted up nicely, and ran well. Among other things, that suggests that the problems with persistent storage on the usb device have been fixed. It created a hybrid partition that was mounted as “ext4” instead of the “btrfs” that had been giving problems with the persistent hybrid partition.
But I did not install. There was no installer on the desktop. I briefly looked around to see if I could find an installer elsewhere, but I did not find one. So maybe the live media are now for test runs only. Interestingly, I was able to install from live media for the krypton version, as reported previously.
Following that earlier download, there was a 10 day hiatus in Tumbleweed releases. As reported on the factory mailing list, this was because the i586 versions were failing to boot. So the Tumbleweed team took time off to investigate and resolve that problem. Snapshot 20160317 was the first release after that hiatus.
I downloaded the DVD iso (64bit) on Friday. As usual, I downloaded with “aria2c”. And I also downloaded the sha256 checksum, this time with “wget”. I verified the gpg signature on the checksum file, and then used the checksum file to verify the iso download. I wrote that to a USB flash drive, and was ready to try an install.
First, the good news. I noticed a change in the install page for setting up a user account. There was now a prominent checkbox for picking up the user entries from a previous install on the same computer. I welcome this change. I’ve been using that option for most of my installs, but until now it was hidden. You had to click a change button (to change the encryption used for the password/shadow database) before you could find it. Putting this option where it is more readily visible is a good change.
I installed to an external hard drive. This was the same hard drive that I have often used. I was expecting to see the same problem that I saw in my January install. And, indeed, that problem did show up. However, there was an additional problem. This time, there was a failure during the attempt to install the bootloader.
I told the installer to continue, in spite of the error. After the install had completed, I investigated. It turned out that the problem was, in some ways, similar to one that I encountered in January. In that install, I ran into the problem that the installer used a device-id with a special character, and that messed up “/etc/crypttab”. I fixed it by using an alternative device-id.
For this month’s install, the installer decided to use a device-id for the argument on where to install the bootloader. And that also ran into a problem with the same special character. I’ve added a note about that to my bug report (from the January install, bug 961275).
I then went about rescuing the system. I went into rescue mode with a chroot into the newly installed system. I first fixed “/etc/crypttab” since that problem was still there. This time I used the uuid of the encrypted lvm in “/etc/crypttab”. I then ran “mkinitrd” to rebuild the “initrd” after changing “crypttab”. And then I ran
grub2-install --force /dev/sdb2
using the device name instead of the device-id. And that went quite smoothly.
After that repair, I tried booting into the system. And booting went well. The system ran well.
I tried setting up a WiFi connection with NetworkManager in KDE. It turns out the the problems with this have now been fixed (more or less). Perhaps they were already fixed for my February install, but I didn’t check properly.
After setting up the connection, I used the connection editor (right click on the network tray icon). Editing the connection, I went to the WiFi security page. There’s a place there to enter the network key. At the right of that entry space, there are two icons. One of those looks like an eye, and the other looks like a floppy disk.
Unfortunately, the two icons were on top of one another. So I could mainly see the one that looked like a floppy disk. But clicking it gave the actions for the icon that looked like an eye.
Maximizing the connection edit window, or unmaximizing it if it is already maximized, results in a better non-overlapping placement of the icons. I could now see that the eye icon controls visibility (whether the network key is visible or all xxx), while the floppy disk icon controls where the network key is installed. The default was “Store password for this user only (encrypted)” which puts the key in “kwallet”. I switched that to “Store password and make it available to all users (not encrypted)”, which puts the password in a file in “/etc/NetworkManager/system-connections”. Although it is not encrypted, that file is readable only by root. As the person who setup the connection, I can also see it via the connection editor.
The result is that the network connection is made on login, without needing the “kwallet” password. The connection is made on login to any desktop. I tested this with a login to Icewm after reboot. If I later make this a shared connection, then any user will be able to connect with any desktop. But neither other users nor I will then be able to see or change the network key without first giving the root password.
Although this is not the default setup for KDE, it is what I recommend.
Time zone issues
I also ran into problems with the timezone settings. I have suspected problem for some time, but I had not investigated them.
This time I investigated.
As background, I also have Windows 7 on that computer. I have the CMOS clock set to use UTC (universal coordinated time). And I have Windows 7 set to work with the clock set to UTC.
After install, my first boot was into the BIOS settings for the computer. There, I checked the time setting. The CMOS clock was set to Eastern time (EDT or US/Eastern). This was not right. During install, I had told the installer to use Central time (US/Central, CDT, America/Chicago). And I had checked the box for the CMOS clock to be set to UTC. Before I started the install, the clock was already at UTC. But the installer changed that.
After install, the timezone settings for the installed system were correct. But the CMOS clock was wrong. Until I fixed the clock, it did not show the correct time. The installer did setup “ntp”. But apparently a 4 hour error is more than the ntp daemon will correct.
It looks to me as if the installer is initially deciding to use EST (the installer default), and is initially assuming that the CMOS clock is set to local time (probably assumed because there is a Windows system on the computer). And it seems that it is setting the CMOS clock that way before it asks for timezone settings.
I have reported this as bug 971854.
That’s my install report for this month.