In recent tests with openSUSE Leap 15.0 and with Tumbleweed, I have been testing out pam_kwallet. It seems to work pretty well. So I have since converted another Tumbleweed system to using pam_kwallet. However, I am not using pam_kwallet with Leap 42.3, on the grand principle that if it ain’t broke, don’t fix it.
Leap 15.0 should be released some time in May. So pam_kwallet is something you might want to think about when you install it.
What is pam_kwallet?
First things first, so I should first explain “kwallet”, sometimes called “kdewallet”. It is a protected place for storing passwords that are used by KDE applications. Typically, it is used for the WiFi passphrase, for web password and email passwords. This, of course, depends on what applications you are using for web browing and for email.
Yes, Ubuntu 16.04 is old hat. This was a recent re-release, but who cares with 18.04 just around the corner. But I decided to install anyway, and I’ll shortly explain why.
The problem with installing Ubuntu into an existing encrypted LVM, is that it doesn’t boot. You have to go into repair mode to fix it. The reason for this is that the file “/etc/crypttab” is not created by the install. And the system won’t boot unless that is created and the “initrd” file is generated so as to contain a copy of that file. That’s needed to handle the crypto early in the boot process.
What has changed?
I’ve done this before, and blogged about it. So what’s new?
Since my last post on Leap 15.0, Build 139.1 was released. It was time for a new install, so I downloaded the iso. And then I installed to a virtual machine.
I ran into some interesting bugs.
It told me that my EFI partition (at 33M) was too small. Well, I agree that’s small. But it is what an earlier build of 15.0 had created. It looks as if they have adjusted to a more reasonable size.
I told the installer to go ahead, in spite of the small EFI partition size. And I then ran into an additional bug. The installer said that some devices (the ones to which I was installing) did not exist. See bug 1082143 for details.
The installer allowed me to continue in spite of those errors. And the install was successful. So the errors were bogus.
A Tumbleweed install
Back to Tumbleweed. Actually, that Leap 15.0 is part of the background. I decided to try installing Tumbleweed into the same virtual machine where I had just installed Leap 15.0. However, this time I would allow it to delete everything on disk and make a fresh start.
Since my last post on 15.0, there have been several new beta releases. We have seen Build115.1, Build 124.1, Build 127.1, Build 128.1 and Build 129.1.
With that many builds, I have not been downloading them all. I have been updating my 15.0 systems. I am updating them in the same way that I update openSUSE Tumbleweed. That is, I am using
to update from the repos. My most recent install attempts have been with Build127.1, though most of my systems are now updated to the latest version.
Things are mostly going well with 15.0. The final release is still planned for May. But if you want to take a look at pre-release versions, then now is a good time to try.
What I have tested is mainly working well. There are still a few bugs in the partitioner, as used for install. Some of those bugs have already been fixed in the latest updates.
Build 109.3 of Leap 15.0 was announced on Friday. So I download and installed. With build 109.3, it is now announcing itself as a Beta release. Previous releases that I tested have indicated that they were Alpha releases.
I followed my usual practice of downloading with “aria2c”. I am using the download site download.opensuse.org/distribution/leap/15.0/iso/. I first used “wget” to download “openSUSE-Leap-15.0-DVD-x86_64-Build109.3-Media.iso.sha256” (the checksum file). I then verified its gpg signature. Next, I downloaded the iso itself. And I used “sha256sum” to verify the sha256 checksum. And, following that, I wrote the iso to an 8G USB flash drive. Read More…
I normally use openSUSE. But I also have Windows 8.1 on my main desktop. I rarely use it, but I do occasionally boot to Windows to install updates and to update the anti-virus (Windows Defender).
I have recently run into two annoyances with Windows.
I recently wanted to copy a small text file to the Windows partition. I have an entry in “/etc/fstab” to mount that partition at “/windows/C”. But it is flagged with the “noauto” option, so that it does not automatically mount on boot.
So I used the command (as root)
This has worked for me in the past. But this time, it gave me an error message complaining that the NTFS drive was hibernated and could not be safely mounted (unless mounting read-only).
Yesterday, I reported on GeckoLinux. And I found a few problems. I’m happy to say that the maintainer noticed my report, and has provided an updated release 423.180107 to correct those problems.
This time, just to be different, I tried the Plasma version instead of the XFCE version. I downloaded the iso, following the links at the GeckoLinux site. I then verified the download using the provided sha1 checksum.
To test, I planned only to use the downloaded iso as a virtual CDROM with a KVM virtual machine install.
I was already running “virt-manager”, so I used the menu option to define a new virtual machine. I set it to use 10G of virtual disk space, which should be sufficient for my testing. And I set it to use 2G of memory and to use 2 processors (from the 4-core processor in my main desktop system).
[Note: please see addendum at the end of this post.]
Gecko Linux is based on openSUSE. The new release was just announced, so I thought I would give it a try. The version number 423.180105, indicates that this is based on openSUSE Leap 42.3, and that this version was finalized on Jan 5th, 2018 (or 180105).
One of the limitations of the current Leap series of openSUSE releases, is that there is no live installer made available. There is, of course, a DVD based installer. So GeckoLinux is filling that gap by providing a live installer.
I downloaded “GeckoLinux_STATIC_XFCE.x86_64-423.180105.0.iso”, which is the live installer for the XFCE variant of GeckoLinux. After downloading, I verified the SHA1 checksum. And then I wrote the iso to a USB flash drive.
A quick summary for those in a hurry. I would have to call this a FAIL. I’ll give the details below. I ran into multiple failures using the recommended Calamares installer. The problems may be minor, and the maintainer of GeckoLinux will probably come out with an improved version that fixes these problems.
I notice, on Thursday Jan 4th, that Build 84.1 was available at the download site. So I download, and did some testing.
As is my usual practice, I used “aria2c” to download the iso, and I used “wget” to download the checksum file. I then verified the “gpg” signature on the checksum file, after which I used the checksum to verify the downloaded iso file.
My first test was to update an existing 15.0 system. For that, I wrote the iso to a USB flash drive. I then configured that flash drive as a repo. And, following that, I used “zypper dup” to bring the existing 15.0 system up to date. When I do this, I can see that most of the updated software comes from the local USB that I configured as a repo. Some updated software comes from the online repos. The “zypper” command seems to recognize that the repo on the local USB is to be preferred to the online repo, when the software is available in both places.
There have been several Tumbleweed snapshots over the last few days. But today we saw the first with a 2018 snapshot date. So I decided to do a test install.
As usual, I used “aria2c” to download the iso (“openSUSE-Tumbleweed-DVD-x86_64-Snapshot20180101-Media.iso”). I also downloaded the sha256 checksum file. I then verified the gpg signature on the checksum file. Then I verified the checksum on the iso, to make sure that I had a good download.