Around two months back, I experimented with kubuntu-19.04. I’m not intending to post on that. But, while testing, I noticed a padlock icon in the system tray. It turned out to be the icon for Plasma Vault.
Checking, I found that Plasma Vault was available for openSUSE. At that time, I was using Leap 15.0 and testing the pre-release version of Leap 15.1. So I installed Plasma Vault in both, for testing. And I also installed in openSUSE Tumbleweed. As the name suggests, it is part of KDE Plasma 5.
In brief, Plasma Vaults allows you to have a directory with encrypted files. You see the files as plain text (unencrypted). But what is actually stored on disk is encrypted.
The image above is a screenshot from clicking on that tray padlock. It shows two vaults (directories).
Installing Plasma Vaults results in a directory “Vaults” under my home directory. It was initially empty until I created some vaults. You can see the option there, to create a new vault.
Ubuntu-18.04 was announced yesterday. I had been waiting for this. So I soon started a download. I used torrent for the download. I also downloaded the checksum file and its gpg signature. After the download completed, I verified the gpg signature for the checksum file, and then I verified the checksum for the install iso.
My earlier install of 16.04 was intended as a trial run for 18.04. As in that case, my plan was to install in an existing encrypted LVM. I expected this to be easy. But it wasn’t.
The install went smoothly enough. But the installed system would not boot. I was never prompted for the encryption key.
I eventually got it working. Having found out where I went wrong, I did another install, this time to a KVM virtual machine. And that install worked out very well. So that’s what I will describe.
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?
It was time for another Tumbleweed install.
This time, I decided to use KVM and install Tumbleweed into a virtual machine.
As is my usual practice, I went to the Tumbleweed download site. There, I found the latest image for snapshot 20170913. I downloaded the DVD iso image (64-bit version) using “aria2c”. And I downloaded the sha256 checksum file using “wget”.
Next, I used “gpg” to verify the signature on the sha256 checksum file. And then I used “sha256sum -c” to verify the checksum of the DVD iso file.
My goal here is to attempt to describe the technical details of the situation. I’ll discuss my personal position (I favor Apple) on my other blog, and add a link here.
Let me be clear at the outset. I do not have any inside information on this. What I know comes from public news reports. I have been attempting to understand the issues based on that. It is entirely possible that I have some of the details wrong.
This is about an iPhone, used by the San Bernardino Terrorists. The FBI wants access to that iPhone to help in their investigation. It is entirely reasonable for the FBI to want access.
For this month, I used an external drive. It’s an old ATA 80G drive that I have mounted in a USB disk enclosure. I connected the external drive to my laptop, so that I could do more testing of WiFi and NetworkManager.
I installed snapshot 20160107. I did that install yesterday. And a few hours later, snapshot 20160108 was announced. Well never mind that. I was testing for install problems.
To install, I downloaded the DVD installer (64-bit), and wrote that to a USB flash drive using the “dd_rescue” command.
I plugged installer USB into my laptop. At this stage, the external drive (the install destination) was not connected. This was deliberate. That drive is bootable. When I tell my system to boot from USB, I am not given a choice of USB. So, to avoid any ambiguity, I made sure that the installer USB was the only one connected. I should add that my laptop uses legacy booting.
I saw a Distrowatch announcement of a new release of KaOS, so decided to give it a try. From there, I followed the link to the release announcement.
My previous experience with KaOS was in April, where it failed to install. This time, I had a better experience.
KaOS is a rolling KDE based distro. It is using plasma 5. The new version came with a beta release of plasma 5, so gives me an early look of what I can soon expect to see in opensuse Tumbleweed. The downloaded system uses a release-candidate for Plasma 5.4.
I check the torrent link, but that seemed to be for an earlier release. My understanding is that torrent downloads are provided by users, and I probably looked before they had set it up for the new release.
[update: please check the comments]
I finally got around to signing a kernel. That went pretty well. So I thought that I would describe what I did.
This post presupposes a little knowledge of digital certificates. If you are looking for a quick introduction, try my post on my other blog.
My test machine has opensuse Tumbleweed. But it also has Mint 17.1 (updated from the Mint 17 that I installed). UEFI booting has been working well with Tumbleweed. But I installed Mint without secure-boot support, so I had to leave secure-boot disabled to boot it.
In more detail, I installed Mint in legacy MBR booting mode, because I did not want to clutter the UEFI name space. That worked fine. I could then UEFI boot it anyway, either with the generated grub menu for Tumbleweed or with a “configfile” command that I added to that menu. But secure-boot did not work, because the installed Mint kernel was not signed by an accepted key (it was not signed at all, it seems).
The TrueCrypt home page now says:
The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
The page now offers advice that Windows users should switch to BitLocker, and gives advice on how to do that.
If you are a linux user, the best choice would be to use LUKS encryption.
There are rumors floating around as to what is behind this. But maybe the developers are just deciding that the original need for TrueCrypt has passed, now that most recent systems have their own way of handling encrypted disks.
Personally, I chose LUKS for encryption on linux. So the apparent end of TrueCrypt does not affect me.
According to an announcement that I saw today, it is now possible to use “cryptsetup” with “truecrypt” volumes.
The announcement was on the lizards mailing list, and also showed up in opensuse forums.
I have not tested this. The “man” pages for “cryptsetup” do explain how to use it to access a truecrypt volume. There is currently no support for creating a “truecrypt” volume with “cryptsetup”.
The other way of using “TrueCrypt” is to install “realcrypt” from the packman repos (also not tested).