In my previous post, I reviewed the GeckoLinux version of openSUSE 15.2. Since then, the GeckoLinux project has release their rolling distribution, based on openSUSE Tumbleweed. For the announcement check HERE.
So I downloaded the iso, and verified the sha1 checksum. Then I proceeded to do an install.
As previously, I installed only in a virtual machine. I setup the virtual machine to use UEFI booting. The downloaded iso was configured as a virtual CDROM drive. Booting from that, the live Gecko rolling release came up.
I’m normally a user of KDE/Plasma. But this time, I instead downloaded the live media for the MATE desktop. I rarely use MATE — I think the last time was with openSUSE 13.2. So this was a good time to try it on Tumbleweed.
Running the live media, there was an Install icon on the desktop. Double click on that brought up the Calamares installer. I told the installer to erase the disk and start over with a clean installation.
I noticed a new release of Leap 15.2Alpha. And, surprisingly, it comes with a 5.3 kernel — specifically kernel 5.3.0-rc5. There’s a mailing list discussion of this on the factory mailing list.
It turns out that this was seen as a good way of testing some of the new features of the 5.3 kernel. When Leap 15.2 is released (tentatively planned for May 2020), it is hard to guess whether it will have a 5.3 kernel or an older kernel.
For now, as a volunteer tester of Leap 15.2, I have not run into any problems with the new kernel.
This seemed like a good time for another install of Leap 15.2Alpha. This time I installed into a KVM virtual machine with an existing encrypted LVM, and using UEFI booting.
To use the existing LVM, I provided the encryption key when prompted by the installer. Then, at the partitioning stage, I chose to use the expert partitioner, starting with existing partitions (rather than with the proposed partitions).
At this point there was an option to import mount points. I used that, so that I was using the same partition that I had previously used with Leap 15.1 on that virtual machine.
The install went well. The installed system seems to be running well. So there’s not actually much to say, except for the use of the 5.3 kernel.
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.