My install of Tumbleweed for May

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.

I already have opensuse 13.2 on that laptop.  I also had a second install of 13.2, using the MATE desktop.  So I wanted to replace MATE with Tumbleweed, but retain the original 13.2 KDE install.

In the partitioning section of the install, I clicked “Create partitioning” and then selected “Custom partitioner”.  On the next screen, I clicked “Import mount points”.  There, I was able to select the mount points from my prior MATE system.  I accepted that for the partitioning.  The partitioner wanted to reformat the root file system (actually part of an encrypted LVM) as “ext4”, and to reformat “/boot” as “ext2”.  These were the same file system types as I had used with MATE, so all looked good.  Reformatting of “/” and “/boot” (if there is a separate “/boot”) is standard.

I’ll note here that the disk uses legacy MBR partitioning, and “/boot” was “/dev/sda5”, which is a logical drive within the extended partition.  This normally should not be a problem.

Pretty much everything else for the install went well, with the exception of the boot setup.


After setting up partitioning and initial user accounts, I was presented with a summary screen.  I clicked on the “Booting” heading so that I could configure booting.

The initially presented boot options were:

  • do not boot from MBR
  • set the active flag for the boot partition
  • boot from “/boot”
  • boot from the extended partition
  • install generic boot code in the MBR

That was as expected, but not what I wanted.  So I unchecked “boot from extended partition”, I unchecked “set the active flag” and I unchecked “install generic boot code”.

There are reasons that I make these choices.  I have seen reports of problems when more than one of the “boot from” options is checked.  And I did not want that.  And I saw no reason to replace the Windows provided generic boot code.

Normally, one cannot boot from “/dev/sda5” (the partition for “/boot”) since it is a logical partition.  But I could boot that way, because I already had a suitable chain-load entry in my grub2 setup for opensuse 13.2 also on the same hard drive.  So that was the best choice for me.  And by unseeing “set the active flag”, I ensured that I could boot into my 13.2 grub2 menu to select the chain-load entry.

After configuring boot, I went on to select which software to install.  Then I came back to the boot settings, to make sure that they took.  Unfortunately they didn’t.  The choice to set the active flag had again been set, as had the choice to write generic boot code into the MBR.

I again changed to what I wanted, and saved the changes.  Then I checked again, and again those values had been forced back to what I did not want.

This is surely a bug, as it is bound to make the installed system unbootable.  I have since reported as bug 930341.

I allowed the install to proceed, knowing that it would be unbootable.  So, after the install was done, I had to fix that by booting from a USB and setting the active flag back to what would work.  The installer had set the active flag on the extended partition, but there was no boot code in that partition.

Final result

After fixing the booting, I was able to boot the newly installed system.  And it mostly seemed to be good.  I switched from NetworkManager to “wicked” for network configuration.  I’ll change it back later, when I am ready to experiment with NetworkManager.

Once I had a network connection, I installed Plasma 5 to replace KDE.  It still appears to be Plasma 5.2, so that it has problems that are supposedly fixed in 5.3.  I’ll postpone a full review of Plasma 5 until there is a better version available.

So that was my Tumbleweed install for this month.


Tags: , ,

About Neil Rickert

Retired mathematician and computer scientist who dabbles in cognitive science.

3 responses to “My install of Tumbleweed for May”

  1. Jimbo says :

    You can install newest stable versions of Plasma 5 (currently 5.3) using openSUSE’s KDE repository. Read more about it in the wiki:

    However, in my experience Plasma version 5.3 did not fix any of the issues I had with 5.2 (sound and graphics issues mainly). Feature wise, one big annoyance that I have come across with Plasma 5 so far is the inability to disable system sounds.

    At this state, I would be really disappointed if Tumbleweed switched from KDE 4 to Plasma 5.


    • Neil Rickert says :


      I’ll probably wait for it to arrive on Tumbleweed. And yes, I’m already aware that 5.3 won’t solve all of the problems with 5.2.

      It has been made pretty clear that Tumbleweed will switch to Plasma 5. So I guess you are going to be disappointed.


Trackbacks / Pingbacks

  1. Plasma 5.3 on opensuse Tumbleweed | Thoughts on computing - 2015/05/17

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: