Red Hat Bugzilla – Bug 61301
up2date-2.7.11-6.x.1 - up2date -u causes download of packages but no install
Last modified: 2015-01-07 18:55:20 EST
this was happening in bug 61119 but is definitely unrelated to the 6.2/cpan issues,
so it's getting a new report. Simply, packages to be installed are fetched but
never installed. This was true with the up2date -u back in bug 61119, is true
now that I've done a -Fvh to get those rpm's (but not kernel*) updated, and
is still true with --force, with and without a package parameter. I'll attach the
log to keep the emails smaller :) As can be seen in the upcoming attachment,
the /var/spool/up2date files that result look fine, just nothing done afterwards to
perform installation. All the -v's in the world didn't help explain things, of course,
but I'm still looking forward to an up2date version where they'd make a difference
and would love to test anything (people/alikins?) along those lines :)
Created attachment 48727 [details]
the relevant up2date calls, etc.
does /boot show the approriate files for those kernels (ie, did the package
get installed, but the db is hosed?)
What happens after a `rpm --rebuilddb`?
Can you install those packages manaully with rpm? If not.
whats it complain about?
My guess is there is something that is making those package installs
fail (no space on /boot?) and rpm is silently skipping them. If you
try it with rpm dirrectly, it might throw a error message to stderr.
If thats the case, it's gonna have to wait for the next rpm and up2date
releases (new code is being added to remove some of the cases where rpm
fsck - not sure how it got that way, but up2date's config had retrieveOnly=1
It's sort of a config migration bug.
The old style up2date that shipped in 6.2 had "retriveOnly=1" by default. When
version gets updated to the 2.x versions, it attempts to migrate the config, so
keeps that setting.
I say "sort of a bug" because it rights because it preserves the users existing
config, but "a bug" because it's kind of stupid and annoying for the current
It seems to be more unexpected than expected.
At least, when I see "retriveOnly=1" set for 6.2 boxes, that is typically the