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 checked the download site for openSUSE 15.0. And I noticed that there was a newer version available. This one is Build 65.1. My previous look at 15.0 had been for Build 48.1.
As you might expect, I downloaded the iso for the DVD installer. I also downloaded the sha256 checksum file. I then verified the gpg signature on the checksum file, and used the checksum file to verify the download of the iso.
The next step was to “burn” the iso to a USB device. I used a 4G USB flash drive for that purpose.
After downloading, I first decided to update the openSUSE 15.0 from my previous install to a KVM virtual machine. I configured the installer USB as a local repo. And I then brought the system up to date with
After updating, and rebooting, the system seemed to run well. Or, so I thought. But after booting again today, I noticed that it had no network. It seems that the update changed the network setup. The ethernet interface is now “eth0”. It was previously “ens3”. So I had to reconfigure for the new interface name before I could make an ethernet connection. I used Yast network settings to reconfigure.
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.