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.
A quick reminder that Leap 15.0 is still at the alpha pre-release stage.
Today, I decided to experiment with upgrading. I have openSUSE Leap 42.3 installed in a virtual machine under KVM. So I cloned that virtual machine, using the “virt-clone” command (as root). I then proceeded to upgrade it to Leap 15.0.
This is intended to be a throw-away. I’ll delete that upgraded virtual machine after a few days of testing. I may repeat the entire procedure when 15.0 is closer to final release.
I first booted the clone VM, to make sure that it could boot into Leap 42.3.
Next, I shutdown that VM. Then on the “hardware details” screen of the viewer, I configured the virtual DVD device to use the DVD installer iso for Leap 15.0. I also checked the box to enable the boot menu (under “boot options”).
The next Leap version, 15.0, is still showing as an alpha release. Still, I was happy to see the install iso for Build 79.1 show up at the download site last Wednesday. At around the same time, there was an update message on the factory mailing list, reporting the current status of Leap 15.0.
According to that update message, the current aim is for a final release in May of 2018. That seems more realistic than the earlier (Feb/March) suggestion.
When I noticed that the iso was available, I of course downloaded it. I followed my usual practice for this:
wget http://download.opensuse.org/distribution/leap/15.0/iso/openSUSE-Leap-15.0-DVD-x86_64-Build79.1-Media.iso.sha256 aria2c -V -R http://download.opensuse.org/distribution/leap/15.0/iso/openSUSE-Leap-15.0-DVD-x86_64-Build79.1-Media.iso gpg --verify openSUSE-Leap-15.0-DVD-x86_64-Build79.1-Media.iso.sha256 sha256sum -c openSUSE-Leap-15.0-DVD-x86_64-Build79.1-Media.iso.sha256
In turn, those commands download the sha256 checksum and the iso itself. Then they verify the gpg signature on the checksum file, and the checksum of the downloaded iso file.
I installed Ubuntu 17.10 shortly after it was released. And I posted a review. I recently heard that it has a serious problem. Apparently one of the kernel drivers can corrupt the BIOS of some computers.
The Ubuntu bug discussion thread is HERE.
At this point, it is unclear whether other distros are affected. Some folk are concerned that it might also be a problem for openSUSE Tumbleweed. See the discussion HERE.
I have Ubuntu 17.10 installed in two places. It is installed in a virtual machine under KVM. And it is installed on my Lenovo ThinkServer. As far as I can tell, the ThinkServer is not one of the vulnerable machines. In any case, I have not found a problem.
There are times when you want to have several versions of openSUSE on the same computer. For example, on one of my computers I have:
- openSUSE Leap 42.3 (this is what I mainly use);
- openSUSE Tumbleweed (for a look at the bleeding edge);
- openSUSE Leap 15.0 (alpha release of the next Leap version).
So how do I manage those, so that I can boot whichever I want?
I’ll note that, in part, this is an update of an earlier post. I’ll describe how I am handling this situation.
I’ll start with what will happen if you just install these versions willy-nilly, and go with the installation defaults.
In a UEFI box, the installer creates a directory “/boot/efi/EFI/opensuse”. That’s really directory “\EFI\opensuse” in the EFI partition (which uses the FAT file system). EFI boot files are installed in that directory, and NVRAM entries for “opensuse” and “opensuse-secureboot” are created. The “opensuse” boot entry uses “grubx64.efi” to boot the system. The “opensuse-secureboot” entry uses “shim.efi”. If secure-boot is disabled in your firmware, either of those should work. If secure-boot is enabled, then only the “opensuse-secureboot” entry will work.
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.