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.
There was a recent kernel update for opensuse 13.2, to kernel 3.16.7-13. And some people are having problems with that kernel.
The main problems seems to be with module compatibility. If you are using the nvidia graphics driver, and you installed it from the repos, then apparently it stops working after the kernel update. The workaround is to use the previous kernel (use the advanced options menu from grub), or to reinstall the driver.
Reports are that the kernel update will be re-released to correct this problem. So the really best solution may be to hold off installing this update until it is re-released.
I have installed the update on one system, without any problems. That system uses Intel graphics, so does not need an added driver. I am holding back on updating my system with nvidia graphics.
A few days ago I ran into a problem with my Tumbleweed install. In this post, I’ll describe what happened and how I investigated it.
I had just updated to the 20141225 snapshot. The availability of that snapshot had been announced on the factory mailing list. I updated using the command
# zypper dup
During the dialog for the update, I noticed that this included an updated kernel (3.18.1-1-desktop).
After the update, I rebooted to make sure that I was using the newly installed software. And that’s where I ran into problems. My Tumbleweed system is using an encrypted LVM. So, as expected, I was prompted for the encryption key during the boot. When I tried to type in the key, nothing happened. It looked as if the keyboard was not being read. Note that this system is using a generic USB keyboard. It’s actually a Dell keyboard, though the computer itself is a Lenovo.
I have successfully used “gparted” from the opensuse 13.2 live rescue image (if you can call that success). But I did run into some initial problems, which I will describe below.
Here’s a quick summary. If you want to use “gparted” on the live rescue system, then I recommend the following steps:
- logout, returning you to a login prompt (a “lightdm” prompt);
- login again, but select “Icewm” as the desktop to which you will login;
- open a terminal session in “icewm” by clicking the terminal icon near the bottom left;
- use the “su” command to become root (no password is needed);
- run “gparted” at the root command line.
Using from the “icewm” desktop works fine. But I first tried to use with the default XFCE desktop, and that ran into problems.
A brief note on konqueror.
It is crashing badly for me on opensuse factory and on opensuse 13.2-RC1.
It seems that there is some kind of conflict between konqueror and the other desktops (Gnome, XFCE and LXDE) that I usually install. If I install only KDE, then konqueror works well. But if I also install Gnome, XFCE and LXDE, then konqueror crashes on many sites.
If I switch konqueror to use the KHTML engine instead of the WebKit engine, then it is stable. But I’m not a fan of KHTML, so I prefer it with WebKit.
When 13.2 final is released, I guess I will install only KDE on my main desktop, so that I can have a stable konqueror. I’ll continue to install the other desktops (in addition to KDE) on my laptop and backup systems.
This problem has been reported as bug 901006.
There are several ways that we can keep our software up to date. In this post, I shall describe my own practices.
For background, I am currently running opensuse 13.1. And I normally use the KDE desktop. So I will be discussing updates from the perspective of the KDE user.
I suppose some folk find it strange that we would need to update our software. However, it’s a fact of technology, that all software has defects (often called bugs). These defects are discovered, over time, and many of them are corrected. So the main reason for updating is to incorporate these corrections (or bug fixes) into our systems.
I have briefly mentioned this in an earlier post.
When I look around, while running 13.1, I notice that there are some systemd user manager processes:
% ps -ef | grep '[/]systemd' root 377 1 0 10:29 ? 00:00:00 /usr/lib/systemd/systemd-journald root 418 1 0 10:29 ? 00:00:00 /usr/lib/systemd/systemd-udevd root 749 1 0 10:29 ? 00:00:00 /usr/lib/systemd/systemd-logind lightdm 3258 1 0 10:29 ? 00:00:00 /usr/lib/systemd/systemd --user root 3421 1 0 10:30 ? 00:00:00 /usr/lib/systemd/systemd --user rickert 3443 1 0 10:30 ? 00:00:00 /usr/lib/systemd/systemd --user
The last three of those are user manager processes, as shown by the “–user” flag to the process. There is also an additional process that seems to be PAM related:
% ps -ef | grep '[p]am' lightdm 3259 3258 0 10:29 ? 00:00:00 (sd-pam) croot 3423 3421 0 10:30 ? 00:00:00 (sd-pam) rickert 3447 3443 0 10:30 ? 00:00:00 (sd-pam)
RC1 (release candidate 1) was available on the download site yesterday. In this post, I shall give my impressions.
As is my usual practice, I downloaded the isos, and wrote them to USBs for testing. My main focus was on the install problems that we had seen with the earlier Beta1 release. Sad to say, some of those problems are still there.
Booting a live KDE system
My first test was to boot a 64-bit live KDE system. That went pretty well. I was pleased to see that the problems with Beta1 and some of the milestones have been corrected. In particular, “/boot” had the kernels needed for installing. While I have not tried installing from the live KDE image, it looks as if that would go well.
I have spent much of my day with installing the Beta release. Thorough testing will have to wait. For now, I will report on how the installing went.
The installing experience can reasonably be described as “interesting”. It is only a beta, so we expect things to go wrong. If we learn from our mistakes, then there could be a lot to learn from this.
I have three completed installations of the Beta. They all look as if they are smooth running systems, though I have not adequately tested them. But installing was another story entirely.
A quick note to opensuse users about ecryptfs. A recent patch to 12.3 caused ecryptfs to stop working. The patch messed up the pam configuration.
If you experience this, then after login you can use
to mount your Private directory. That’s a temporary fix for one session. If you use ecryptfs for your home directory, that might not solve your problem.
For a more permanent fix, login as root, and run
# pam-config -a --ecryptfs
which will fix the pam configuration.