I did another install of 42.3 on Thursday. I guess I’m a tad slow reporting that. This install was for Build 0283. I installed it on my main desktop. At the moment, I am still running 42.2 on that computer. I installed 42.3 on a separate area of the disk.
I do plan to soon switch to running 42.3 full time. That’s the best way of testing this beta release. The final release is due in about one month.
Downloading and installing
I followed my usual procedure. I used “aria2c” to download the iso for the DVD installer. I used “wget” to download the sha256 checksum file. Then I verified the gpg signature on the checksum file, and verified that the checksum matched the downloaded iso.
The next step was to write the iso file to a USB flash drive. I used “dd_rescue” for that. Then I booted the USB, and installed 42.3
Installation itself went well. Everything worked about as expected. Following the install, I booted into 42.3, and did a little final tweaking. And I also added additional software that is not on the install media but is in the repos.
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 don’t often post about Windows, because I mainly use linux. But this is a Windows post. I should mention that the computer involved is a UEFI box, since that might be relevant.
My main desktop has both Windows 8.1 and openSUSE 42.2. On Friday, I attempted to install the May updates for Windows. The updates are the two listed in the subject line above.
The updates failed.
They seemed succeed. I got the message to restart windows to complete the update. So I rebooted. Then I saw the messages about “working with updates”. At around the 30% mark, it rebooted. Then, on reboot, it continued until the 100% mark. That looked good.
But then a message:
We couldn’t complete the updates
Don’t turn off your computer
I’m a bit slow in reporting this. I saw the announcement on May 5th, and I downloaded and installed on that same date. This was for build 0184 of 42.3. This was followed a few days later by build 0229. And yesterday we saw build 0243.
I downloaded the install DVD for build 0184 from the download site. That site should have the current build during the testing phase. As of the time of this posting, you can find build 0243 there.
As usual, I downloaded with “aria2c”. I also downloaded the sha256 checksum file (I used “wget” for that download). I verified the gpg signature on the checksum file. And then I made sure that the downloaded iso matched the checksum.
If you install Ubuntu on a computer with secure-boot enabled, then it will probably boot. And maybe that’s all you want.
If so, you probably won’t be concerned about what I am describing here.
However, secure-boot is supposed to verify many of the steps in the boot path. And that’s where I see Ubuntu as broken.
I’m basing this on tests that I have done on Ubuntu-17.04 and Ubuntu-gnome-17.04.
First a brief summary of the problems that I am seeing:
- Ubuntu will boot without checking a signature on the kernel.
- Under some circumstances, Ubuntu will complain about a bad signature, and refuse to boot, even though secure-boot has been disabled.
I have already reviewed Ubuntu-17.04. However, the Ubuntu folk (i.e. Canonical) had already announced that, starting with 18.04, they would switch their mainline version from the Unity desktop to the Gnome desktop. So I decided to also test out the 17.04 version of Ubuntu with Gnome desktop.
I installed Ubuntu-gnome in an already existing encrypted LVM. The machine that I used actually has two hard drives, with an encrypted LVM on each drive. So this was a different LVM from the one that I used for the mainline Ubuntu (with unity). Currently, both versions of Ubuntu are installed on that machine.
Ubuntu 17.04 was announced a few days ago. I had already decided that I would install it, and do a little testing. So, once I saw the announcement, I started a download.
To download, I followed the links from the announcement to the download page. From there, I selected the torrent download. I was using the “vivaldi” browser, and it gave me several options with the torrent link. I chose the option to open the file. And that started the download with “ktorrent”.
I also downloaded “SHA256SUMS.desktop” and “SHA256SUMS.desktop.gpg”. Next, I checked the gpg signature with
gpg --verify SHA256SUMS.desktop.gpg SHA256SUMS.desktop
which showed that I had a good download of the checksum file. After the torrent download had completed, I checked its validity with
sha256sum -c SHA256SUMS.desktop
That reported that the downloaded iso file was ok. It also reported that some files did not exist. I ignored that. It was just that the checksum file had checksums for other isos that I had not downloaded.
Recently, openSUSE Tumbleweed updated Gnome to version 3.24. So I decided to give it a test. And I ran into some “problems”. This post will discuss those problems.
Gnome under Wayland
My oldest Tumbleweed system was installed in November 2014. And that’s where I first tested Gnome. At the time, I was using “sddm” for logins. Selecting “Gnome” on the login menu gave me a Gnome session running under X11. This was as expected. There was also a menu item for “Gnome-Wayland”. Selecting that gave me Gnome running under Wayland for managing the graphics.
I later switched to using “gdm” as login manager. And, with “gdm”, selecting “Gnome” gave me a Wayland session.
Next, I tried on my laptop. Tumbleweed was installed there on March 14 this year. I was already configured to use “gdm” for logins there. But, try as I did, I was unable to get a Wayland session for Gnome.
[Update: See update notes at the end of this post]
I still have Solus installed, although it is not something that I regularly use. Check HERE for my report on installing.
Today, I booted into Solus. And then I did a check for updates. It showed several. And one indicated a kernel update, but that was attached to a strange package name.
I applied the updates. And then I checked to see what kernel version had been installed. And there was no kernel there at all. The kernel had been deleted. Fortunately, I had a backup copy of the kernel, so I copied that into place. And then I rebooted. And the system froze on the login window. Perhaps all of the kernel modules had also been deleted, leaving a crippled system.
So it looks as if my Solus installation is now broken beyond repair.
I’m now wondering if this was a bad April fools joke. Or was this an intrusion into the Solus site to generate a faulty update?
At this stage, I am puzzled and looking for more information.
It looks as if I misunderstood the situation.
Apparently Solus had changed its naming convention for kernels. So I simply did not recognize that there was a kernel, since the new name was not even close to what I was looking for.
It has been a few months since I last tried installing Tumbleweed. I wanted to install on my laptop, to test the latest version of NetworkManager.
The install went pretty well. The most obvious problem was a black screen on the first boot of the newly installed system. But that was not as bad as it sounds. I’ll give more details below. The install was for snapshot 20170314.
As is my usual practice, I used “aria2c” to download the iso, and I used “wget” to download the sha256 checksum file. Both were the 64-bit versions.
I downloaded both the DVD installer and the live rescue CD.
After downloading, I used
gpg --verify filename.sha256
to verify the gpg signature on the checksum file (where “filename” depends on whether this was for the live CD or the DVD installer.
I then used
sha256sum -c filename.sha256
to verify the checksum of the downloaded iso file.
After download, I wrote both isos to USB devices. My typical command for this is
dd_rescue filename.iso /dev/sdd
where “/dev/sdd” is the device where the USB shows up. I used a 4G USB device for the live rescue CD, and an 8G USB for the DVD installer.
I then booted the live rescue CD on two systems. It booted up without any difficulty. On the first boot, a hybrid partition was created, where any changes made can be saved to disk. Read More…