Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 902441
Summary: | Fedup upgrade of 17 to 18 does not install a new kernel and KDE login fails | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Panos Kavalagios <Panos.Kavalagios> | ||||||||
Component: | fedup | Assignee: | Will Woods <wwoods> | ||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 18 | CC: | tflink, wwoods | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | i386 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2013-01-25 19:40:18 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Panos Kavalagios
2013-01-21 17:02:17 UTC
The kernel issue might be related to Bug 820351 The KDE issue is explained in Bug 888085 and Bug 892061. Only the kernel issue remains a mystery, as there is no way that F18 had a lower version number than F17 kernel. There must be some kind of exception. Created attachment 687289 [details]
Log file /root/upgrade.log
Created attachment 687290 [details]
Log file /root/upgrade.log.syslog
Oops sorry! Ignore the attached logs. They are old and from previous upgrade. It seems that fedup leaves no logs after the job is done. (In reply to comment #5) > Oops sorry! Ignore the attached logs. They are old and from previous > upgrade. It seems that fedup leaves no logs after the job is done. It does, actually. Try /var/log/upgrade.log. (In reply to comment #2) > Only the kernel issue remains a mystery, as there is no way that F18 had a > lower version number than F17 kernel. There must be some kind of exception. Actually, that's also incorrect. The F17 kernel has been newer than the F18 kernel at certain points. That's bug 904112. *** This bug has been marked as a duplicate of bug 904112 *** I also checked /var/log and there was nothing with newer date there. I'll check again :) My system had 3.6 F17 kernel before the upgrade and it was out in the updates 3.7 for F18. That's very newer in the minor number than previous release kernel and I'm not sure it is related to bug 904112. It simply doesn't make any sense. I have just upgraded my desktop and after logging in, no F18 kernel and when checking updates there is one there: # yum check-update kernel.x86_64 3.7.4-204.fc18 updates kernel-devel.x86_64 3.7.4-204.fc18 updates kernel-headers.x86_64 3.7.4-204.fc18 updates # rpm -q kernel kernel-3.6.10-2.fc17.x86_64 kernel-3.6.11-5.fc17.x86_64 kernel-3.7.3-101.fc17.x86_64 why it asks for this update and it was not performed few minutes before that I have issued the fedup command? It is 3.7.4-204 > 3.7.3-101, isn't it? My check for updates should have been empty after the upgrade. From the /var/log/upgrade.log the proof that fedup didn't get the upgraded F18 kernel at all and made nvidia module to complain: Jan 26 18:45:51 charon upgrade[947]: checking RPM transaction... Jan 26 18:45:53 charon upgrade[947]: non-fatal problems with RPM transaction: Jan 26 18:45:53 charon upgrade[947]: kernel-uname-r = 3.7.4-204.fc18.x86_64 is needed by kmod-nvidia-3.7.4-204.fc18.x86_64-1:304.64-2.fc18.4.x86_64 Created attachment 688759 [details]
Log file /var/log/upgrade.log
Indeed, the log file found in /var/log.
|