Bug 342703

Created attachment 183904 [details]
Screenshot illustrating updater issue

Related is the 'audacious' entry:   I do not want to ever upgrade that until the bugs in the new one is fixed....same issue, The updater won't let me turn off permanently items I don't want or in the case of the kernel, I don't need.

Please attach screenshot, the old one was hit by bug #345100.

Created attachment 185648 [details]
Screenshot illustrating updater issue

Please read carefully...this is NOT the original screenshot which is long gone. I have NOT YET upgraded to the latest kernel upgrade (22.13) because it just got to my system and I haven't had time and it replaced the updater display which used to say exactly the same thing as this screen shot except for the version (22.12) which is installed.   The problem with unwanted (in this case Audacious) updates remains also.  That particular program is broken and I had to reinstall an earlier version but the updater insists on updating it and I have no way to turn it off.   So as you can see, I have two issues, a kernel that is installed but the updater doesn't recognize because there is also an earlier version installed and I will not remove or allow to be removed because this destroys my raid controller driver and some kernels won't allow it to be reloaded.  The entire beta cycle and one GM release prevented full use of 2.5 TB of my raid5 controller/drives.  I don't want to lose it again by an 'update' destroying a functioning kernel and erasing it.  Thus, the backup kernel MUST stay and the updater MUST recognize that the newer kernel is installed and not be preoccupied with the fact there is also an older one installed as a backup.   Again, the screenshot IS REPRESENTATIVE of the problem.

Yesterday in opensuse mail list I posted the following which is decidedly applicable to this bug.  It is posted here because it adds information to this bug and because it is quite probable that you don't have time to read the user mail lists;

QUOTE
I feel like taking my favorite deity's name in vain so he would smite me
off of the face of the earth because I couldn't be madder in hell than I
am now at openSuSE's updater program.

I have a raid disk controller that is not directly supported by any
kernel issued by openSuSE.   Worse, there are kernels that will not
compile the source of the controller card so when I get a kernel that
will both compile and is compatible with the Rocket Raid Corporation
rr174x controller that allows me to have a 2.5TB raid5 hardware array
PLUS any software (MD) array(s) I want to define with a total of 9
drives on my system, I don't want things automatically screwed up by
anyone or anything.   I recently compiled  2.6.22.13-0.3-bigsmp and the
driver for my controller assimilated itself nicely and I added the new
kernel and modules to the appropriate directories and to GRUB menu.lst
and rebooted and everything worked.   As did the previous kernels (2
deep) which gives one a warm fuzzy feeling considering that from 10.2
through the 2nd released kernel of 10.3GM,  I had to do without my
hardware controller and to get stuff off of those drives, I had to
physically reinstall a drive with 10.2 on it that allowed the controller
to work.  

Shortly after rebooting, the updater said it had a security patch on the
new .13 kernel and (I know, I should know better than to trust anything
by now), it was small, a patch and I said, go ahead, it isn't installing
a new kernel, just requires a reboot to load it into memory after the
update.....Yeah, right!....It not only ate my GRUB configuration files
and replaced them, it also destroyed (by erasure) all of the other linux
kernels in /boot, their syms AND all of the modules AND sources in /lib
for those versions!!!!!   Dammitalltohellanyway!!!!

It is about dammed time this automatic with no recourse destruction by
update of erstwhile functioning systems stops and the updater and Yast
updates give us the OPTION to KEEP copies of our current
configuration.   Somewhere back around 7-9, this was the default, and
that was when drive space was expensive....now, there is no excuse to
not at least make it an option at a very minimum.   Thankfully the
kernel did boot and was still functional with my controller or I would
have weeks of work ahead of me rather than hours or perhaps days
recompiling from source and reinstalling the backup sources and boot images.

Get with it openSuSE!!!!   If my name was Bill Gates, I'd be spending a
few million, maybe billion, on lawyers about now regardless of whether
or not 'free software' is exempt from destroying peoples work or not.  
I am that mad that if I were indeed him, I'd go from richest man in the
world to poorest, paying lawyers to induce management at openSuSE once
and for all to opt for what is right rather than what is expedient.

Richard
(a very pissed off dude right now)

Could you enable the kernel patches to save the former kernel, boot menu ..., please?

(In reply to comment #5 from Thomas Goettlicher)
> Could you enable the kernel patches to save the former kernel, boot menu ...,
> please?
> 

I don't know to whom this was directed and the needinfo flag isn't set so I will only say that I am not aware of any KERNEL patches that will allow this.   It is my belief that the updater, both the autoupdater and the YOU both call rpm behind the scenes with a -U and the rpms have a script that executes this anti-social behavior.

If you install manually using rpm -iv <kernel>, this behavior does not exist, the old kernel, modules, etc are preserved and GRUB is  properly updated by ADDING the new kernel to the boot options as it should.   This is the preferred behavior with something so critical as a kernel replacement whether it is a patch or a full version upgrade.

IF there is a KERNEL patch somewhere to save the former kernel when updates occur when launched by the autoupdater program or by YOU, please point me in the right direction, tell me what changes I need to make to ensure these patches are loaded or compiled (if necessary because I already do that for the disk driver).  

A baby step in the right direction would be to make this the DEFAULT behavior for kernels and a big step in the right direction for ALL updates (remember when zypper was deleted/broken leaving no way to update further).

If this was a request to Novell to add/enable such a feature, I second the motion.

This is not a kernel issue.

The update stack needs to understand that for some packages (like the kernel), it should use -i instead of -U when invoking rpm. (The packages might be automatically expired later, but not before the system has been rebooted.)

I actually quite agree, I find the behaviour very frustrating; it wipes modules from the running kernel image (try bringing up an IP/Sec tunnel after an update has been done), and doesn't allow a fail-back to the last kernel version if it doesn't work, not to mention what happens when the system fails during the update itself. It's based on the flawed assumption that systems get rebooted after every update immediately.

I agree this has to be solved. At the patch level, i was told we have a solution (a special patch flag, which the update stack is able to handle). At the package update level ('zypper install kernel-default') we should provide a way to install the new kernel with rpm -i instead of -U.

For zypper (commands based on packages) the only way to go I see is to introduce a special parameter. You may want to have multiple version of one library from different reasons (program requiring old version of a library etc).

Regarding update: I think that the solver should be able to handle this situation when evaluating a patch. However, I don't know if we can evaluate it via currently existing dependencies. Stefan, do you have any idea?

(In reply to comment #9 from Jiri Srain)
> For zypper (commands based on packages) the only way to go I see is to
> introduce a special parameter.

I'd say it should be the default. I'm not sure whether the updating of kernel (installing the new and removing the old one right away) makes sense at all.

> You may want to have multiple version of one
> library from different reasons (program requiring old version of a library
> etc).

AFAICS, the libraries are not an issue now as we package different major versions  with different package names. The only issue is the kernel. (BTW: Why don't we package also the kernel with the version string in the package name??)

(In reply to comment #9 from Jiri Srain)
> For zypper (commands based on packages) the only way to go I see is to
> introduce a special parameter. You may want to have multiple version of one
> library from different reasons (program requiring old version of a library
> etc).
> 
> Regarding update: I think that the solver should be able to handle this
> situation when evaluating a patch. However, I don't know if we can evaluate it
> via currently existing dependencies. Stefan, do you have any idea?
> 

    Just a thought: Once zypper/YOU sees that the update involves a kernel, change
    the call to RPM to -I from the normal -U and tell the resolver to IGNORE
    dependencies conflicts caused by retaining older modules.   These modules are
    essentially self contained in the appropriate directories and would not be
    called by the new kernel anyway as it has its' own versions, often duplicates
    but stored in its' own directories in the /lib/modules<version> structure.  So
    what if they are duplicates...ignore.   Only the kernels themselves care and
    only if they are activated at boot by grub due to a choice by the operator.

(In reply to comment #10 from Ján Kupec)
> I'd say it should be the default. I'm not sure whether the updating of kernel
> (installing the new and removing the old one right away) makes sense at all.

The biggest concerns are: 
- space needed, as new kernel requires creation of new initrd
- how to identify the number of kernels to keep

(In reply to comment #12 from Stanislav Visnovsky)
> (In reply to comment #10 from Ján Kupec)
> > I'd say it should be the default. I'm not sure whether the updating of kernel
> > (installing the new and removing the old one right away) makes sense at all.
> 
> The biggest concerns are: 
> - space needed, as new kernel requires creation of new initrd
> - how to identify the number of kernels to keep
> 

This shouldn't be a worry with the super large drives now available.   For space concious installations, make it an OPTION to continue to use the current method of UPDATE rather than ADD during the installation of new kernels.  For pruning of old kernels, a separate utility could be written but it need not be part of the automatic updater or YOU program, but part of the utility support packages developed and released later as support for GRUB menu maintence perhaps.  If the GRUB menu maintence program saw you were deleting references to installed kernels, it could offer to clean things up for you.

(In reply to comment #12 from Stanislav Visnovsky)
> (In reply to comment #10 from Ján Kupec)
> > I'd say it should be the default. I'm not sure whether the updating of kernel
> > (installing the new and removing the old one right away) makes sense at all.
> 
> The biggest concerns are: 
> - space needed, as new kernel requires creation of new initrd

I agree. So we need a fallback to "update" instead of "parallel install" in
such case. This should be handled in libzypp i guess, with a callback(s) for
interaction from the apps ("Not enough space to install the new kernel while
keeping the old one, do you want to update the running kernel?").

> - how to identify the number of kernels to keep

This should be probably left on the user. Advanced users will know what kernels
the don't need anymore and how to remove them (e.g. with rpm -e).

But for common users, our package managers should provide a way to remove them
(yast packager and zypper rm) and the documentation (User guide, wiki, etc.)
should contain an advice for them "Once your system works all right with the
new kernel, and you make no use of the older versions, you can safely remove
all the other kernel versions".

It should be a reasonable default to at least not de-install the currently running kernel. Latest + last to keep around would be a sane, older kernels could be "expired".

I think that there are too much point which I cannot decide.
Klaus could you please overtake here ?

For libzypp. we only need the possibility to install multiple versions of a package. Its not for the software management stack to actually decide over install/upgrade, thats a user decision.

I do agree with comment #15 (leave running kernel installed) and we certainly need other 'cleanup' policies for any packages installed in multiple versions. One might want to keep the 'running glibc' installed, etc.
But all this is policy outside of the stack itself.

The details of this should be discussed on opensuse-softwaremgmt and not in bugzilla.

Reassign to zypper maintainer. Zypper should have an option to decide on install vs. update.

Jano, please discuss the details on mailing list. 

Current solution is to put the packages which should be installed in parallel into /etc/zypp/zypp.conf:

---------8<--------------
##
## Packages which are parallel installable with
## diffent versions
##
multiversion = kernel-default,kernel-default-base,kernel-default-extra
---------8<--------------

Fixed in libzypp 5.3.0