Bug 192775 - Smart has no (or broken) support for Fedora-style kmod packages
Smart has no (or broken) support for Fedora-style kmod packages
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: smart (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-22 17:34 EDT by Kevin Kofler
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-23 21:47:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kevin Kofler 2006-05-22 17:34:39 EDT
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.
Comment 1 Axel Thimm 2006-05-23 16:19:19 EDT
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.
Comment 2 Kevin Kofler 2006-05-23 16:53:17 EDT
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.
Comment 3 Ville Skyttä 2006-05-23 16:59:08 EDT
(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.
Comment 4 Kevin Kofler 2006-05-23 17:02:56 EDT
And any solution for the i686 vs. i586 confusion? Or does making the packages 
multi-version "magically" make that disappear?
Comment 5 Ville Skyttä 2006-05-23 17:09:02 EDT
(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.
Comment 6 Axel Thimm 2006-05-24 03:23:49 EDT
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?
Comment 7 Axel Thimm 2006-05-24 03:32:37 EDT
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.
Comment 8 Kevin Kofler 2006-05-24 03:52:39 EDT
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.
Comment 9 Axel Thimm 2006-05-24 04:23:10 EDT
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.
Comment 10 Kevin Kofler 2006-05-24 04:26:18 EDT
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. ;-)
Comment 11 Kevin Kofler 2006-05-24 04:28:39 EDT
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.)
Comment 12 Kevin Kofler 2006-05-24 04:43:50 EDT
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.
Comment 13 Axel Thimm 2006-05-24 04:50:02 EDT
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
Comment 14 Kevin Kofler 2006-05-24 04:55:11 EDT
> 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...
Comment 15 Axel Thimm 2006-05-24 05:44:23 EDT
Can you try

smart install --explain kmod-ntfs

(after uninstalling the one that smart should install)

Maybe that sheds some light on it.
Comment 16 Kevin Kofler 2006-05-24 06:16:41 EDT
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?)
Comment 17 Axel Thimm 2006-05-24 06:30:39 EDT
>    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.
Comment 18 Kevin Kofler 2006-05-24 06:37:32 EDT
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).
Comment 19 Axel Thimm 2006-05-25 08:04:16 EDT
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
Comment 20 Kevin Kofler 2006-05-25 08:43:51 EDT
> 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.
Comment 21 Kevin Kofler 2006-05-25 08:45:34 EDT
I'll report this upstream, hoping they can figure it out.
Comment 22 Kevin Kofler 2006-05-25 09:32:44 EDT
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!
Comment 23 Axel Thimm 2006-05-25 10:16:27 EDT
Maybe some mirrors/metadata weren't carrying yet kernel 2122 for i686?
Does the issue reappear when you switch back to the first mirror?
Comment 24 Kevin Kofler 2006-05-26 02:18:56 EDT
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.
Comment 25 Axel Thimm 2006-07-08 06:56:25 EDT
(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?
Comment 26 Kevin Kofler 2006-07-08 17:24:02 EDT
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.
Comment 27 Kevin Kofler 2006-08-17 20:04:33 EDT
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.
Comment 28 Kevin Kofler 2006-08-17 20:05:39 EDT
PS: tested with smart-0.42-35.fc5
Comment 29 Axel Thimm 2006-08-17 20:40:10 EDT
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. :)
Comment 30 Axel Thimm 2006-08-17 20:45:02 EDT
BTW did you try nuking /var/lib/smart/config and then recreate it with

yes | smart update
Comment 31 Axel Thimm 2006-08-17 20:50:15 EDT
Yes, you did, forget about comment #30 ...
Comment 32 Kevin Kofler 2006-08-17 21:45:55 EDT
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.)
Comment 33 Kevin Kofler 2006-08-17 21:49:13 EDT
(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.)
Comment 34 Axel Thimm 2006-08-18 05:28:44 EDT
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.
Comment 35 Kevin Kofler 2006-10-23 21:47:12 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.