SUSE 11.1 Automatic Updates Break module compilation

English Install/Boot/Login
1

Hi, First let me say that although I have 23 years as a corporate application developer and DBA, including being a USER of environments like HPUX and AIX, I am a relative newbie in Linux-land, particularly in administering Linux (doing this for fun at home, call me crazy).
(old-cpu, you may recognize me as you have been helping me with my pesky sound problem).
Anyway, I am using SUSE 11.1 RC1 (latest version downloaded and installed on 12/5). I have hosed myself twice, first by running zypper dup, and the 2nd time by allowing the automatic updates to run. On both occasions, my network devices (wired and wireless) stopped working. When I tried to make and install again, the make bombed because basically the rule for “modules” was missing in the directory where the make was looking. I discovered that the update had changed the version from 2.6.27.7-4-default to (I think) 2.6.27.7-8-default, but all the kernel code still resided in the 2.6.27.7-4-default directory structure. I tried renaming the /usr/src/2.6.27.7-4-default directory to ./2.6.27.7-4-default, and changing the symbolic link /usr/src/linux-obj. Then the make completed successfully, but the executables didn’t work.

On both occasions, I didn’t know enough to fix the discrepancy, so I simply re-installed from scratch.

So my question is: Is it a standard expectation that users/testers of factory installs shouldn’t use the automatic updates? I read somewhere that there was a posting about this, but I don’t know where to find it. The automatic updates will work after the final release, right?

Thanks in advance for helping me to understand.

2

Think of it like this, the software needed to drive a device like the wireless requires a driver and a kernel module. It’s the kernel module that get’s broken.

Whenever you update/upgrade the kernel, the previous module built on the old kernel won’t work anymore and has to be rebuilt. It’s usually fairly easy to recover.

When the OEM video repos are posted, we generally don’t have to worry as they will include the matching kernel modules & that is 98% automatic.

3

When it comes to factory, IMHO one never knows what will work. :slight_smile: …

Its only during the past couple of years, that I started installing alpha, beta and RC versions of openSUSE on a Test PC. … I only started doing that because of a pet peeve about external NTFS hard drives not automounting, and I’ve been raising bug reports on practically every openSUSE version since on that (as its still not functioning properly). But there is now attention on this issue, and I’m hopeful this will eventually be functional (perhaps by openSUSE-11.2).

I only update from one alpha version to the next, or from one beta to the next, or from one RC version to the next, when I am done my testing and when I do not care if my test box gets trashed.

As for my main PC, I never install pre-release test versions. In fact, my main PC is still on openSUSE-10.3 ! (mainly due to one of my favourite apps NOT running well on openSUSE-11.0. ).

I did install openSUSE-11.1 RC1 on a brand new Dell laptop (purchased a few weeks ago), because I needed the 2.6.27 kernel (which comes with openSUSE-11.1 RC1) for the wireless to function. And RC1 is functioning reasonably well, … for example I used the laptop (with dual head mode) at the office last week in support of a fairly senior level presentation.

BUT that laptop is an exception, and I am NOT updating the factory software on it, as it is NOT intended to be a test platform. It functions, and I will leave “well enough” alone. When openSUSE-11.1 GM comes out, and when I read of no breakage with 11.1 GM, I’ll likely install 11.1 GM on that laptop.

As for my main PC (still running 10.3), I still have not decided if I will update to 11.1 immediately, or wait a few weeks. I note 11.1 GM is scheduled for release on 18-Dec-08, and hence the temptation to install 11.1 on my 10.3 PC will be a big temptation, as I will have time to do so over the Christmas break.

4

Thanks for the clarification guys. Makes perfect sense.

5

Ok, yes, your strategy is not a bad one. However, I think if everybody would use it problems would not get visible. For a RC I would assume the update version should work otherwise it should be a beta x. I do understand of course that still errors can happen and of course take this as a feature of an RC. However, an RC should be stable close to the point where it could be officially released. And a RC should be tested in any possible way and using the automated update belongs definitely to this. If what happend to the RC last week would happen in the official release, many people are likely to turn away from Linux at least SuSE. Regarding versioning I do it differently. On most of my machines two desktops and a notebook I use two intallation partitions. One for a stable version and one for the next step and yes, you are right, right now 10.3 has the majority in the stable versions.

Cheers,

kuf

6

A lot depends, I think, on one’s goal when it comes to testing.

Some testers like to test everything they can possibly find. And report on it. Hence the moving configuration that can result from constant updates does not perturb them. Rather its more sauce for the goose.

But we are not all in that boat. Not all of us like that dish. Not all of us like lots of sauce.

Some of us prefer to focus on one specific area, and leave the rest of the testing to others.

I’m in the later group. … and like many, I contribute the little that I can in this and other ways, in the hope that while small, its still a contribution.