Description of problem: Smart does completely the wrong thing in the presence of Fedora-style kmod packages such as those in Livna: 1. It wants to upgrade them instead of installing them multi-version. 2. It wants to upgrade the i686 kmod with an i586 one, and replace the (running!) i686 kernel with the i586 version. The first issue is mainly an annoyance. However, the only way to work around it seems to be to enter each and every kmod package one is interested in to the "multi-version" list. Or can this be wildcarded? Because adding every single package can work at an individual user level, but preconfiguring things that way won't really work, because kernel modules can get added to Extras or Livna at any time. The second issue is much worse. While it is relatively easy to work around (deselect the affected packages and select the i686 module by hand), it can really screw things up. Version-Release number of selected component (if applicable): smart-0.41-31.fc5 How reproducible: Always Steps to Reproduce: On an i686 system: 1. Install a kmod package for an older kernel from Livna. 2. Run the smart GUI. 3. Try "upgrade all". Actual results: Smart wants to upgrade the kmod with an i586 version, and replace the i686 kernel with the i586 one. Expected results: Smart installs the i686 kmod for the new kernel, leaving the old one in place and not touching the i586 versions at all.
That's a known problem. As you mention smart cannot do any globbing, and the kmod scheme requires special treatment. Livna can add an additional config snippet under /etc/smart/distro.d/ and manage its kmods there. This will fix half your issues. Wrt the random cross-kernel upgrading: IMHO this is a generic flaw in the "kmod" scheme or any other scheme abandoning uname-r-in-name. This either needs to be addressed in the scheme itself or every depsolver needs to treat these kind of kernel module rpms with special handling.
Well, it's not just that it's cross-kernel, it's that it's cross-architecture! Uname -r alone in the name wouldn't actually help with that.
(In reply to comment #1) > Livna can add an additional config snippet under /etc/smart/distro.d/ Already committed and built earlier today. A new livna-release package containing this will appear in the next push.
And any solution for the i686 vs. i586 confusion? Or does making the packages multi-version "magically" make that disappear?
(I suppose Axel meant to Cc Thorsten's non-ignored mailbox...) I have used modules packaged with the current scheme with smart (and the soon-to-appear config) for quite a while, and stuff has worked well for me. There were some bugs in the kmod implementation which could have bitten in some situations (and did bite some users) but those should be fixed in the latest package and packaging proposal incarnations. About the i686 vs i586 issue, I haven't encountered it, but then again my systems are running x86_64 except for one UP i686 which happens to be the only one that uses yum instead of smart at the moment.
smart should not replace the running kernel. Did you allow the operation to proceed? smart's wording is sometimes confusing, e.g. it doesn't distinguish between upgradinging and installing, therefore the kernel is listed along with the packages to upgrade even though it's flagged as multi-version (but check again that on your system the kernel is indeed flagged as such). I suspect the i586 vs i686 issue happens on the choice of the kmod level and propagates then to the kernel. What kmod did you try to install and what does smart say if you explicitely ask to smart install foo@i686? Maybe the i686 kmod isn't available anymore?
P.S. Kevin can you try the above with the updated livna-release package? It will not be able to install/upgrade anything for older kernels (that's the minimal price of dropping uname-r, same for yum/apt/pirut/pup/*carpets/rpm), but it will make sure that newer kernels don't kill your older kernel & kernel module setup.
I didn't allow the operation to proceed, but it did mark the i686 kernel with the [x] icon when opening the details in the tree view, so I assumed it was really going to remove it. Replacing the running kernel with the i586 version wasn't something I was going to risk, so I canceled at that point. The module was kmod-ntfs, and there were both the @i586 and @i686 versions (with the same EVR) in the repo, it picked the wrong one. I'll try out what happens with the updated livna-release ASAP.
Could you try w/o the gui, so that you can paste in/attach any output you'll get? Also check the output of smart flag --show multi-version and send that in, too, if something looks suspicious. It should contain for instance the simple entries "kernel" or "kernel-smp", "kernel-xen0" etc. matching the kernel you are running. And last, but not least, is this a disposable machine? I'd like to suggest to proceed with the kernel "upgrade" - if it's listed in the multi-version flagged packages it shouldn't pose any issue. But according to Murphy you may just be triggering some unknown bug in smart and it may eat your old kernels, so only do so, if you like reinstallations.
While this isn't a 99.999% uptime server, it isn't a disposable machine either (It is my primary computer. My other computer is an old 266 MHz laptop still running FC2.), so I'd prefer not hosing it. ;-)
Output of smart flag --show multi-version: multi-version GFS-kernel GFS-kernel-bigmem GFS-kernel-hugemem GFS-kernel-kdump GFS-kernel-largesmp GFS-kernel-smp GFS-kernel-suspend2 GFS-kernel-suspend2-bigmem GFS-kernel-suspend2-hugemem GFS-kernel-suspend2-kdump GFS-kernel-suspend2-largesmp GFS-kernel-suspend2-smp GFS-kernel-suspend2-xen0 GFS-kernel-suspend2-xenU GFS-kernel-xen0 GFS-kernel-xenU cman-kernel cman-kernel-bigmem cman-kernel-hugemem cman-kernel-kdump cman-kernel-largesmp cman-kernel-smp cman-kernel-suspend2 cman-kernel-suspend2-bigmem cman-kernel-suspend2-hugemem cman-kernel-suspend2-kdump cman-kernel-suspend2-largesmp cman-kernel-suspend2-smp cman-kernel-suspend2-xen0 cman-kernel-suspend2-xenU cman-kernel-xen0 cman-kernel-xenU dlm-kernel dlm-kernel-bigmem dlm-kernel-hugemem dlm-kernel-kdump dlm-kernel-largesmp dlm-kernel-smp dlm-kernel-suspend2 dlm-kernel-suspend2-bigmem dlm-kernel-suspend2-hugemem dlm-kernel-suspend2-kdump dlm-kernel-suspend2-largesmp dlm-kernel-suspend2-smp dlm-kernel-suspend2-xen0 dlm-kernel-suspend2-xenU dlm-kernel-xen0 dlm-kernel-xenU gnbd-kernel gnbd-kernel-bigmem gnbd-kernel-hugemem gnbd-kernel-kdump gnbd-kernel-largesmp gnbd-kernel-smp gnbd-kernel-suspend2 gnbd-kernel-suspend2-bigmem gnbd-kernel-suspend2-hugemem gnbd-kernel-suspend2-kdump gnbd-kernel-suspend2-largesmp gnbd-kernel-suspend2-smp gnbd-kernel-suspend2-xen0 gnbd-kernel-suspend2-xenU gnbd-kernel-xen0 gnbd-kernel-xenU kernel kernel-bigmem kernel-bigmem-devel kernel-bigmem-unsupported kernel-devel kernel-hugemem kernel-hugemem-devel kernel-hugemem-unsupported kernel-kdump kernel-kdump-devel kernel-kdump-unsupported kernel-largesmp kernel-largesmp-devel kernel-largesmp-unsupported kernel-smp kernel-smp-devel kernel-smp-unsupported kernel-source kernel-sourcecode kernel-suspend2 kernel-suspend2-bigmem kernel-suspend2-bigmem-devel kernel-suspend2-bigmem-unsupported kernel-suspend2-devel kernel-suspend2-hugemem kernel-suspend2-hugemem-devel kernel-suspend2-hugemem-unsupported kernel-suspend2-kdump kernel-suspend2-kdump-devel kernel-suspend2-kdump-unsupported kernel-suspend2-largesmp kernel-suspend2-largesmp-devel kernel-suspend2-largesmp-unsupported kernel-suspend2-smp kernel-suspend2-smp-devel kernel-suspend2-smp-unsupported kernel-suspend2-unsupported kernel-suspend2-xen0 kernel-suspend2-xen0-devel kernel-suspend2-xen0-unsupported kernel-suspend2-xenU kernel-suspend2-xenU-devel kernel-suspend2-xenU-unsupported kernel-unsupported kernel-xen0 kernel-xen0-devel kernel-xen0-unsupported kernel-xenU kernel-xenU-devel kernel-xenU-unsupported kmod-cm2020 kmod-cm2020-hugemem kmod-cm2020-kdump kmod-cm2020-smp kmod-cm2020-xen0 kmod-cm2020-xenU kmod-em8300 kmod-em8300-hugemem kmod-em8300-kdump kmod-em8300-smp kmod-em8300-xen0 kmod-em8300-xenU kmod-fglrx kmod-fglrx-hugemem kmod-fglrx-kdump kmod-fglrx-smp kmod-fglrx-xen0 kmod-fglrx-xenU kmod-madwifi kmod-madwifi-hugemem kmod-madwifi-kdump kmod-madwifi-smp kmod-madwifi-xen0 kmod-madwifi-xenU kmod-ndiswrapper kmod-ndiswrapper-hugemem kmod-ndiswrapper-kdump kmod-ndiswrapper-smp kmod-ndiswrapper-xen0 kmod-ndiswrapper-xenU kmod-ntfs kmod-ntfs-hugemem kmod-ntfs-kdump kmod-ntfs-smp kmod-ntfs-xen0 kmod-ntfs-xenU kmod-nvidia kmod-nvidia-hugemem kmod-nvidia-kdump kmod-nvidia-legacy kmod-nvidia-legacy-hugemem kmod-nvidia-legacy-kdump kmod-nvidia-legacy-smp kmod-nvidia-legacy-xen0 kmod-nvidia-legacy-xenU kmod-nvidia-smp kmod-nvidia-xen0 kmod-nvidia-xenU (This is with the new livna-release.)
Even with the new livna-release, it still wants to install the i586 kernel. It wants to add the new kmod-ntfs now (not replace the old one), but it still picks the i586 one, and that requires replacing the i686 kernel with the i586 one. (You can't install both the i586 and i686 version of the same kernel at the same time, which is probably why it wants to remove the i686 one.) Output of LANG=en_US.UTF-8 smart upgrade: Loading cache... Updating cache... ######################################## [100%] Computing transaction... Upgrading packages (2): kernel-2.6.16-1.2122_FC5@i586 kmod-ntfs-2.1.26-6.2.6.16_1.2122_FC5@i586 Removed packages (1): kernel-2.6.16-1.2122_FC5@i686 13.2MB of package files are needed. 2.0MB will be freed. Confirm changes? (Y/n): At that point, I picked "n" because that's obviously NOT OK.
The removal of the kernel is due to smart thinking it has to switch from i686 to i586. These two pakcages can't coexist, if it were a kernel "upgrade" it shouldn't try to Remove the old one. E.g. the kernel is multi-version, not "multi-arch". The question still remains why smart insists on going i586. Can you try smart install kmod-ntfs@i686
> The removal of the kernel is due to smart thinking it has to switch from i686 > to i586. These two pakcages can't coexist That's what I thought. > smart install kmod-ntfs@i686 That works as expected. Lade Zwischenspeicher... Update Zwischenspeicher... ######################################## [100%] Berechne Vorgang ... Erneuere Pakete (1): kmod-ntfs-2.1.26-6.2.6.16_1.2122_FC5@i686 101.6kB an Paketdateien sind benötigt.228.4kB wird benutzt. Ãnderungen anwenden? (J/n) : j Hole Pakete.. -> http://ftp.upjs.sk/pub/.../kmod-ntfs-2.1.26-6.2.6.16_1.2122_FC5.i686.rpm kmod-ntfs-2.1.26-6.2.6.16_1.2.. ######################################## [100%] Ãbermittle Transaktion ... Bereite vor ... ######################################## [ 0%] 1:Installiere kmod-ntfs ######################################## [100%] Sichere Zwischenspeicher...
Can you try smart install --explain kmod-ntfs (after uninstalling the one that smart should install) Maybe that sheds some light on it.
smart install kmod-ntfs does the right thing too. (It picks the i686 version.) It's only smart upgrade which wants to pick the i586 version. This looks more and more like something which should be forwarded upstream, it doesn't seem to have anything to do with Fedora or the Fedora kmod scheme, but with packages available for both i586 and i686. Output of LANG=en_US.UTF-8 smart install --explain kmod-ntfs: Loading cache... Updating cache... ######################################## [100%] Computing transaction... Upgrading packages (1): kmod-ntfs-2.1.26-6.2.6.16_1.2122_FC5@i686 Upgrades: kmod-ntfs-2.1.26-6.2.6.16_1.2111_FC5@i686 101.6kB of package files are needed. 228.4kB will be used. Confirm changes? (Y/n): Output of LANG=en_US.UTF-8 smart upgrade --explain: Loading cache... Updating cache... ######################################## [100%] Computing transaction... Upgrading packages (2): kernel-2.6.16-1.2122_FC5@i586 Upgrades: kernel-2.6.16-1.2096_FC5@i686 kernel-2.6.16-1.2111_FC5@i686 Required By: kmod-ntfs-2.1.26-6.2.6.16_1.2122_FC5@i586 (installed) kmod-ntfs-2.1.26-6.2.6.16_1.2122_FC5@i586 Upgrades: kmod-ntfs-2.1.26-6.2.6.16_1.2111_FC5@i686 Requires: kernel-2.6.16-1.2122_FC5@i586 (installed) Removed packages (1): kernel-2.6.16-1.2122_FC5@i686 13.2MB of package files are needed. 2.0MB will be freed. Confirm changes? (Y/n): (By the way, something needs to be done about the German translation, "Updates" is translated with "Erneuerungen" even here where it's used as a verb. Shall I report that as a bug upstream?)
> Required By: > kmod-ntfs-2.1.26-6.2.6.16_1.2122_FC5@i586 (installed) Is this true? According to this output your rpm database already has kmod-ntfs in i586 installed. In this case smart operates proper, it tries to follow your wish to have i586 kmod with the matching kernel. What does smart fix say? I suspect it will try to either remove the i586 kmod or install the kernel for i586 to fix the currently broken dependencies. The question then remains as to why the i586 kmod got on your system in the first place. To understand this I suggest to remove all kmods from you system and try again.
I guess that actually means "about to be installed", not "installed". kmod-ntfs-2.1.26-6.2.6.16_1.2122_FC5@i586 is not installed, it is listed just below as being about to be installed, the only version actually being installed being kmod-ntfs-2.1.26-6.2.6.16_1.2111_FC5@i686 (notice "2111" and "@i686"). "rpm -q kmod-ntfs" only lists "kmod-ntfs-2.1.26-6.2.6.16_1.2111_FC5" (notice "2111" again, not "2122" as in the offending @i586 package).
Can you perform a last check with rpm -q --qf '%{name}-%{version}-%{release}@%{arch}\n' -a | grep i586 This should be empty. I don't know why smart decides to go i586 on your box, I can't imagine anything in the kmod bits to trigger this (BTW is this only with ntfs, or do you have other kernel modules that upgrade properly? In that case maybe it is the specific package that confuses smart). As a last shot in the dark check /proc/cpuinfo and also nuke /var/lib/smart/* and have smart refetch the metadata. The latter will ensure that smart wasn't locked into some funny state when perhaps there were only i586 kmods available. Anyway I don't expect any insight from these actions - as said, it's a last shot in the dark. If you are willing to allow uploading of your rpm database and smart's /var/lib folder then please report this bug at smart's tracker with a URL where these can be found: http://tracker.labix.org/issue?@template=item&project=smart
> This should be empty. It is. I don't have any other kernel modules from repositories installed, just kmod-ntfs and a locally built kernel-module-qc-usb-2.6.16-1.2122_FC5-0.6.3-0.iva.3.kk (i686 arch) based on an old FC4 RPM from the ivazquez repo. The cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 3 cpu MHz : 737.143 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1476.50 Nuking /var/lib/smart/* and rebuilding the metadata hasn't helped either.
I'll report this upstream, hoping they can figure it out.
Now switching to a third Fedora mirror (while still keeping the same Livna mirror) suddenly made the problem disappear. This is really strange. I changed the Fedora mirror when rebuilding the metadata and the problem was still there, and now with a third mirror, it disappeared, and I didn't even change the Livna mirror!
Maybe some mirrors/metadata weren't carrying yet kernel 2122 for i686? Does the issue reappear when you switch back to the first mirror?
Sadly, the actual explanation is that the mirror which "worked" doesn't yet carry any 2122 kernel, so smart doesn't have the option of installing the i586 version with that mirror. A bug hiding another. Sigh... I hate stale mirrors.
(In reply to comment #21) > I'll report this upstream, hoping they can figure it out. Did you report this or get any further info on the issue? It's the only report of this kind and I cannot reproduce it. Also note that there was a smart update 2 weeks ago, maybe this issue has been fixed?
Sorry, I was pretty busy these days, so I didn't get around to looking any more into this. (I'm now primarily using Synaptic again, which is what I've been using for a long time. Panu's resurrection of apt-rpm is nice. But that's very OT here.) I'll be very busy this weekend, maybe next week. Sorry for that.
I decided to make use of the latest kernel upgrade to test this again (at least I didn't have to downgrade/remove packages to test that way, every time-saving is welcome ;-) ). Sorry for sitting on this for that long. Sadly, this still happens, so I'll have to take it upstream. I don't understand why this appears to happen only on my machine.
PS: tested with smart-0.42-35.fc5
Can you please test the following? First please show the output of rpm -q --qf '%{name}-%{epoch}:%{version}-%{release}@%{arch}\n' kmod-ntfs Then try smart install kmod-ntfs@i686 (don't confirm) and smart install kmod-ntfs@i586 (don*t confirm) If this doesn't enlighten us any further please add it to the bug report to smart upstream. :)
BTW did you try nuking /var/lib/smart/config and then recreate it with yes | smart update
Yes, you did, forget about comment #30 ...
Could it be that I had an i586 package installed at some point (I don't remember, I could have installed some RPM built on Mandrake at some point, and these are or at least used to be i586), and that the RPM database shows some trace of that, confusing smart? (This is a system upgraded all the way from RHL 7.3, so there were lots of packages once installed.)
(Note that I did check that I don't have any i586 packages installed now, see comment #20, and I just redid the check to make sure.)
Hm, RH7.3 upgrade with Mandriva packages included? Not that smart should get confused, but RH7.3-RH9 had bogus rpm eating up your rpm database. Maybe the database is currupted. Please try recreating the database: rm -f /var/lib/rpm/__* rpm --rebuilddb The latter may take a while, don't panic. Nuke the smart metadata afterwards (also yum and apt, just in case they have also been presented with a distorted picture of the rpmdb contents, but of course this doesn't affect smart) and check again. Also please perform the steps in comment #29.
Well, I'm sorry to be of no more help here, but I just moved to a new computer with a fresh install of Fedora (and I didn't have the time to investigate this before the switch), so we'll probably never figure out whatever weird state my system was in. So I'm closing this, if nobody else can reproduce it, chances are it was my system which was screwed up somehow, not Smart. This doesn't seem to happen on my new system in any case.