Bug 225674 - system update reinstalls current kernel and removes prior kernel
Summary: system update reinstalls current kernel and removes prior kernel
Status: RESOLVED WORKSFORME
Alias: None
Product: openSUSE 10.2
Classification: openSUSE
Component: YaST2 (show other bugs)
Version: RC 5
Hardware: PC Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Stefan Schubert
QA Contact: Jiri Srain
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-04 04:06 UTC by Felix Miata
Modified: 2006-12-11 20:34 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
y2logRPM (110.87 KB, text/plain)
2006-12-04 04:31 UTC, Felix Miata
Details
y2log.SuSEconfig (8.18 KB, text/plain)
2006-12-04 04:34 UTC, Felix Miata
Details
y2log zipped (408.63 KB, application/zip)
2006-12-04 04:44 UTC, Felix Miata
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Miata 2006-12-04 04:06:29 UTC
To reproduce:
1-install most recent kernel manually
2-reboot
3-run system update

Actual results:
1-existing kernel and initrd are replaced with the same kernel
2-previous kernel left by manual installation of latest kernel is removed

Expected results:
1-existing kernel and initrd remain untouched by the update
2-prior kernel remains installed

I experienced this twice in two days. The first time was a recent update, probably to about rc2 with the 2.6.18.2-31-default kernel that I updated to 2.6.18.2-33 before starting the update. Following discussion of the behavior on the factory mailing list, I installed alpha4 purely to test this, and the 2.6.18_rc5_git6-2 was removed.
Comment 1 Felix Miata 2006-12-04 04:31:55 UTC
Created attachment 108036 [details]
y2logRPM
Comment 2 Felix Miata 2006-12-04 04:34:29 UTC
Created attachment 108037 [details]
y2log.SuSEconfig
Comment 3 Felix Miata 2006-12-04 04:44:46 UTC
Created attachment 108038 [details]
y2log zipped
Comment 5 Stefan Schubert 2006-12-11 11:24:04 UTC
You have multiple kernel-defaults in the rpm DB:
2006-12-03 21:56:14 <2> m7ncd(4016) [rpm] RpmDb.cc(buildIndex):297 Multiple entries for package 'kernel-default' in rpmdb
....
doUpgrade available: SKIP no candidate for I__s_[S0:0][package]kernel-default-2.6.18.2-33.i586
ResolverUpgrade.cc(doUpgrade):367 installed I__s_[S0:0][package]kernel-default-2.6.18_rc5_git6-2.i586, candidate U__s_@[S2:1][package]kernel-default-2.6.18.2-33.i586

So kernel-default-2.6.18.2-33.i586 will be installed for update again.

This case is so special that we cannot handle it. If you want to keep your kernel you will have to lock it. 
Yes there is a bug concerning locking and permanent holding this state in the system too.
Comment 6 Felix Miata 2006-12-11 20:34:42 UTC
Your explanation is only slightly clearer than mud. If the upgrade process finds a match between any installed kernel and the kernel it intends to install, it should either find nothing to do regarding kernels, or ask for user input about what it proposes to do. This is certainly not currently resolved properly as WORKSFORME.