I’m no longer doing monthly installs of Tumbleweed. But I do installs when there is a reason.
In this case it was another computer. And what use is a computer without some form of linux?
My wife purchased a new laptop for use with Windows 10. So I got the previous laptop as a hand-me-down. I already have a laptop with Windows 7, and also dual-booting to openSUSE. So I did not need another Windows 7 system. So this became my linux laptop.
Around two months ago, another computer died. That was an older desktop — the one with an nVidia graphics card. That older desktop is now in computer heaven (otherwise known as the electronics recycling center). With the arrival of this hand-me-down, I’m now back to my former number of computers. But this one has Intel graphics, so I no longer have anything with nVidia graphics.
I wanted to use an encrypted LVM for this install. And I find it more convenient to prepare the disk ahead of time.
I saw the announcement of the new Solus release on Distrowatch. So I decided that it was time to take another look at Solus.
I used the available torrent to download “Solus-2017.01.01.0-Budgie.iso”. I then separately downloaded the sha256 checksum file, because that was not part of the torrent download. And I noticed a file “Solus-2017.01.01.0-Budgie.sha256sum.sign” which looked as if it might be a gpg signature for the checksum. So I downloaded that, too.
Unfortunately, I could not find the gpg key that I would need to check the signature. So I had to just trust the checksum. Just before composing this post, I did another search for the gpg key, and finally came up with a link. So I added that to my keyring, and was finally able to verify the checksum file. The needed key still does not appear to be on the public keyservers. But at least I could find it with a google search.
To install, I wrote the iso file to a USB flash drive, with
# dd_rescue Solus-2017.01.01.0-Budgie.iso /dev/sdd
(note that “/dev/sdd” is the device usually used by a USB flash drive on my main desktop).
Ubuntu 16.04, in several different varieties, came out last week. So I decided to give the kubuntu variant a try. I planned to install in an existing LVM. I knew, from previous experience, that this could be tricky. And, to make it more tricky, I wanted “/boot” to be inside that encrypted LVM.
It didn’t quite work out. I am successfully booting it using the grub2-efi from opensuse. I was unable to get the grub-efi from kubuntu to work.
I planned to install this to replace an experimental Tumbleweed. I had originally set that up a year ago, to test using opensuse with “/boot” part of the encrypted LVM. That test is now well past, and the opensuse bugs have been fixed. So that disk space was free for kubuntu.
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 installed snapshot 20151218. The install was done on Monday morning.
I had recently replaced the hard drive on my main desktop, so this was a new install to replace what I had installed on the previous drive. I had already created partitions, including an encrypted LVM with space for several root file systems, a swap file system and a home file system. So I wanted to install Tumbleweed into the encrypted LVM.
Up until now, I have avoided “btrfs”, except for a brief trial with a beta release of 13.1. It is about time for more serious testing. So I decided to use “btrfs” for the root file system with this Tumbleweed install. Apparently, “btrfs” works best if “/boot” is part of the root file system. So this meant no separate unencrypted “/boot”.
For this month, I decided to install the 20150903 Tumbleweed snapshot. I planned to install on an external drive, and to install only KDE (i.e. Plasma 5).
This install turned out to be a disaster. But that’s why I do these monthly installs. I have reported the problems as bug 944662.
The downloading went well. I used “aria2c” to download “openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150903-Media.iso”. And I used “wget” to download the checksum file “openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150903-Media.iso.sha256”. I then used “gpg” to verify the signature on the checksum file. And I used “sha256sum” to compare the checksum of the downloaded iso with that in the checksum file. All went well.
A week ago, I saw an announcement for Mageia 5, and I decided to take a closer look. My first look at Mandrake linux was around 1999, where I installed it for a brief test. It was later renamed to “Mandriva” to avoid trademark conflicts. And Mageia was forked from Mandriva. Recently, Mandriva appears to have closed down, leaving Mageia as what remains from the earlier Mandrake.
Mandrake was originally based on RedHat linux, but Mandriva later diversified that. And linux has changed a lot since my earlier 1999 test install.
I initially downloaded “Mageia-5-LiveDVD-KDE4-x86_64-DVD.iso”. That was actually an accident. I had intended to download the DVD installer, but did not look closely at the name. I had instead downloaded the live KDE iso. I’ll note that this can be used for installing, though I later downloaded “Mageia-5-x86_64-DVD.iso” and used that for my test install.
I have been doing monthly installs, mostly to test for any install problems. For the May install, I used the 20150508 snapshot, with the 64-bit DVD installer image written to a USB.
The indications are that Tumbleweed will soon be switching from KDE 4 to Plasma 5. So I was waiting for that switch before doing this month’s install. But they say that a watched pot never boils. And likewise, it seems that a watched software project never matures. So I decided to stop watching and just install what was there.
The target machine
My recent installs have been to an external drive that I connected to my laptop. For this install, I instead chose to install directly to the internal hard drive of that laptop. And maybe it’s just as well, for I ran into a problem that would not have shown up if installing to an external drive. The installer messed up on the boot setup.
I mainly wanted to try the recent kubuntu release, because it is using the new Plasma 5 as its desktop. I downloaded the iso “kubuntu-15.04-desktop-amd64.iso” using “ktorrent”. Supposedly, torrents check the validity of the download, but I rechecked the sha256 checksum to be sure. It was fine.
I then copied to a USB flashdrive, using the “dd_rescue” command in opensuse. That went well. I later booted and tested as a live system, where it seemed to do okay. But I wanted to run it after installing, for better testing. So I did an install. Read More…
I noticed a report on the release of Debian 8 at DistroWatch. I’ve tried a number of linux distros in the past, but never Debian. So I decided to give it a try.
The Debian site suggested the first DVD in their series. So I downloaded “debian-8.0.0-amd64-DVD-1.iso”. I normally prefer to use a meta-link for downloading. But I could not find one for the Debian iso, so I used a torrent link instead. Clicking on that link, my browser offered to use “ktorrent”. And that worked out pretty well. The download speed came close to the max that my ISP provides. After the download was complete, “ktorrent” continued to upload to other torrent users. The upload speed was never more than around 10% of my ISP upload max speed.