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…
It has been a while since I last installed Tumbleweed. I decided that it was time to again check the installer.
The Tumbleweed system that I already have installed had desktops KDE, Gnome, XFCE and LXDE. But for recent intstalls (as with Leap 42.2), I have been going with KDE, Gnome, XFCE, LXQt, FVWM and MATE. So it seemed reasonable for the new Tumbleweed install to follow the same path. I also added Enlightenment for experimenting.
As usual, I downloaded via the command line. The install was for snapshot 20161128. I chose to download both the DVD iso and the rescue iso.
For the rescue iso, the commands that I used were:
wget http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-Rescue-CD-x86_64-Snapshot20161128-Media.iso.sha256 gpg --verify openSUSE-Tumbleweed-Rescue-CD-x86_64-Snapshot20161128-Media.iso.sha256 aria2c -V -R http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-Rescue-CD-x86_64-Snapshot20161128-Media.iso sha256sum -c openSUSE-Tumbleweed-Rescue-CD-x86_64-Snapshot20161128-Media.iso.sha256
And, for the DVD iso, I similarly used:
wget http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20161128-Media.iso.sha256 gpg --verify openSUSE-Tumbleweed-DVD-x86_64-Snapshot20161128-Media.iso.sha256 aria2c -V -R http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20161128-Media.iso sha256sum -c openSUSE-Tumbleweed-DVD-x86_64-Snapshot20161128-Media.iso.sha256
I’ve simplified my life, so I am no longer doing regular monthly installs. But I still do occasional installs.
In this case, the occasion was a topic at opensuse forums:
A user was not sure how to install without a network. So I decided to do an install, to make sure that this was still possible.
I began by downloading the latest snapshot. I first used
to download the sha256 checksum file. That’s a small file (654 bytes), and I find it easier to use “wget” for small files. I then verified that file, using
gpg --verify openSUSE-Tumbleweed-DVD-x86_64-Snapshot20160813-Media.iso.sha256
The file itself has a gpg signature, so checking that signature is sufficient to verify the download.
I’ve been doing an install each month, mostly to test for problems with the installer. For this month, I download snapshot 20160412. There have been more snapshots since then, but this was the one that I installed yesterday.
The live rescue CD
I also downloaded the live rescue CD at the same time. I must have started the download too soon after publication. This was the slowest download that I have done. Normally, the iso for a rescue CD downloads in a few minutes. For this download, “aria2c” was giving me an estimated download time of around 58 hours and worse. The download site was obviously busy and no mirrors were yet available.
The slow download continued for a while. Then it gave me an error indicating that the download had failed.
This month’s install was interesting.
My original plan was to install from the KDE live iso. So I downloaded “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20160307-Media.iso” and wrote that to a USB. It booted up nicely, and ran well. Among other things, that suggests that the problems with persistent storage on the usb device have been fixed. It created a hybrid partition that was mounted as “ext4” instead of the “btrfs” that had been giving problems with the persistent hybrid partition.
Early today, there was a Tumbleweed update to snapshot 20160128. So I took a look at both the live rescue system and at updating my computers that are running Tumbleweed in one of their partitions.
Live rescue iso
There has been a problem with the live rescue iso for a month or two. As far as I know, it works fine if you burn the iso to a CD. But writing it to a USB flash drive has been troublesome.
On reading the email notification of the update (or publishing of this snapshot), it seemed to hint that the problem had been fixed. So I downloaded the iso, and wrote to a 4G USB.
Alas, the problem is still there. What you notice, is that it seems to hang during boot. If you look at the messages, they indicate problems starting journald.
For this month, I used an external drive. It’s an old ATA 80G drive that I have mounted in a USB disk enclosure. I connected the external drive to my laptop, so that I could do more testing of WiFi and NetworkManager.
I installed snapshot 20160107. I did that install yesterday. And a few hours later, snapshot 20160108 was announced. Well never mind that. I was testing for install problems.
To install, I downloaded the DVD installer (64-bit), and wrote that to a USB flash drive using the “dd_rescue” command.
I plugged installer USB into my laptop. At this stage, the external drive (the install destination) was not connected. This was deliberate. That drive is bootable. When I tell my system to boot from USB, I am not given a choice of USB. So, to avoid any ambiguity, I made sure that the installer USB was the only one connected. I should add that my laptop uses legacy booting.
I last looked at NetworkManager when it was at version 1.0.0. It is now at version 1.0.6, and with some changes that persuaded me to do some more testing.
To test, I setup a connection and then did some tests. I repeated this for KDE/Plasma 5, for Gnome and for XFCE. It is also possible to run “nm-applet” and a polkit daemon in Icewm, where configuring the network is similar to what happens with XFCE (which also uses “nm-applet”).
Between series of tests, I cleared out all configuration. To do this, I booted a different system (booting a live CD would also work), and then mounted the root file system for Tumbleweed. That way, I could clear out the saved configuration while Tumbleweed was not actually running.
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”.
I still have a lot to test following that Tumbleweed update. I did encounter some issues. I’ll comment on those here.
Crash during update
On one system, the update completed. But I could not logout from the desktop. So I used CTRL-ALT-BACKSPACE to crash the desktop, then rebooted on the sddm login screen.
On another system, where I was using “gdm” as login manager, the desktop seemed to crash in the middle of the update, leaving a blank screen. I logged in remotely (using “ssh”) to see what was happening. The desktop session appeared to have disappeared (I checked processes that I owned, and none were running except those from the ssh login).