Installing opensuse 13.1M4

Milestone 4 became available on Friday.  So, of course, I downloaded it and did some installs.  I have not yet had much time using it, so this post is mostly about installing.

The downloading was smooth, as usual.  After download, I copied the iso to a USB using “dd_rescue”.

Installing the 64bit DVD image

My first install was with the 64bit DVD image.  That went very smoothly.  There were no problems that I can recall.  It was as straightforward an install as one might hope.

While setting options for the install, I went into the boot section.  The default command line wanted to use “resume=/dev/mapper/cr_swap”.  This is for resuming from hibernation.  I changed that string to “noresume” because my swap partition is randomly encrypted and resuming won’t work with that.

Later, checking the installed system, I could see that the grub menu did indeed use “noresume”.  This is an improvement of M3 and over opensuse 12.3, where those install time settings were ignored.  So kudos to the factory team for resolving this problem.

The second stage of installing — the part that happens after the first boot, also went smoothly.  There were no hiccups on the network setup.  The network started the first time and has not given me any problems.  And the KDE desktop started without problems.  However, I’ll say a bit more about desktops, including KDE problems, later in this post.

The 32bit DVD image

My second install was for the 32 bit DVD image.  This install also went very smoothly.  Again, I changed the “resume=device” to “noresume”, and again that change was honored.  Likewise, the network started without problems.

The one big problem was with KDE.  It seemed to be in a loop with the plasma shell crashing.  In case this was video-driver related, I rebooted and this time used “nomodeset”.  I still had similar looping.  So it looks as if KDE is broken for 32bit systems.

Installing a live KDE stick

For my third install, I wanted to try the live KDE image, written to a USB.  I was expecting problems, as this had been a problem install for earlier 13.1 releases.  So most of my time was spent experimenting with workarounds for the problems.  I’ll discuss those later.  Let me first get to the actual install.

My live KDE install was relatively successful.  I was installing on a UEFI box, set for secure-boot.  The partitioner recognized that it was UEFI, and proposed a partitioning that included mounting the EFI partition at “/boot/efi”.  The first problem that I noticed was that the install overview page reported that the wrong booter had been selected.  It seems that the install wanted to use grub2, yet knew that was wrong.  It was easy to switch to grub2-efi, and that removed the error messages.  This problem — selecting the wrong booter — seems to be because I had previously booted the live system on a non-UEFI box, where grub2 would have been appropriate.  It seems to have remembered that, and become confused.

While in the booting section of install, I set the grub2-efi distributor line to “openSUSE_alt 13.1”.  That is, I added the “_alt”.  The purpose of this is to be able to avoid a  name conflict in the EFI settings of the box.  Later checks, after the install completed, showed that this setting was honored.  That is a change from earlier 13.1 milestones and from 12.3.  So, again, kudos to the factory team for fixing this.

As the actual install started, there was a popup message reporting a UI error.  I did not write down the message.  As best I can recall, it said that there was an error setting up the progress bar.  I dismissed the error message, and installation proceeded.  But it was a blind install.  There was no progress report at all — basically a blank gray Yast window.  After a while, the progress bar suddenly appeared.  That seemed to be after the installer had “moved to the installed system” for installing the booter.  And things went smoothly from there.

The computer booted nicely into the new system.  The UEFI boot seemed to have been setup correctly, using the name “opensuse_alt-secureboot”.  I had to settle the usual argument between Windows and opensuse as to which controls booting, but that’s a UEFI firmware issue on my box, rather than an opensuse issue.

The kernel

The kernel version for the 64bit install is 3.10.1-3.g0cd5432-desktop.  I did not check the 32bit install, but it is probably the same, except it will be the default kernel rather than the desktop kernel.

Using KDE

KDE comes in as version 4.10.97, and apparently that is a release candidate for 4.11.  So we should be at KDE 4.11 by the time that 13.1 is released.

On my 64bit box, KDE seemed at first to be running correctly.  However, when I tried to login to KDE with a newly created user account, it never completed the login.  I had to edit “.kde4/share/config/kwinrc” and add a line “Enabled=false” to the compositing section.  After that, the next login worked fine.  I did not have problems with my usual account, but I already had desktop effects disabled there in my desktop configuration from running previous versions.  I should add that this was with an Nvidia graphics card using the nouveau driver.  As far as I know, this is a nouveau driver problem, and it might not affect all Nvidia cards.

I have already mentioned that KDE is a disaster on my 32bit system.

Gnome

I logged into Gnome as a check.  This was on the first installed computer where I had installed from the 64bit DVD.  Gnome is at version 3.9.1, and seems to be running smoothly.  But I did not spend much time in Gnome.

Those live USB problems

Here’s a rundown on the problems using a live USB:

  • First boot after creating the USB — the directory “/boot” looks messed up.  Many of the files have length zero.  Since installing from live media just copies the running live file system to the hard drive, that will leave bad content in “/boot” of the installed system, and result in an unbootable system.
  • Second boot after creating the USB — the directory “/boot” is empty.  So that is even worse.  The problem seems to be a malfunction of the overlayfs used, as also discussed in an earlier post.

There is a successful workaround.  The first boot creates a hybrid partition (an ext4 partition with label “hybrid”).  It will be partition 3 on that USB.  And the problem is related to the overlay of the “/boot” in the hybrid partition and the “/boot” on the live image.  So, after I had booted once, to create the hybrid partition, I shut down that live system.  Then, on another linux system, I mounted that hybrid partition.  For me, that was “/dev/hdd3”.  In general, it will be “/dev/hdX3” for some “X”.  With that hybrid partition mounted, I removed the “boot” directory in that partition.  And, thereafter, the live USB seems to have behaved normally.

Ruby Yast

The M4 release uses the new ruby Yast.  To be clear, this is not a new Yast.  It is the old Yast, rewritten in the Ruby language.  We do hope this is the first step toward Yast enhancements.  At present, it is good to see that it is mainly working well.  There was the one problem of no progress bar for my live KDE install.  It has been fine for everything else.

Overall, things are reasonable for this stage of the pre-release schedule for 13.1.  The problems with live media will be a serious issue that needs addressing.

Advertisements

Tags: , ,

About Neil Rickert

Mathematician and computer scientist who dabbles in cognitive science.

Trackbacks / Pingbacks

  1. Notes on 13.1M4 | Thoughts on computing - 2013/08/22
  2. Grub broken - 2013/09/23

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: