Bug 60905
Summary: | kernel upgrade failed - lilo test? | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Isaiah Weiner <iweiner> |
Component: | up2date | Assignee: | Adrian Likins <alikins> |
Status: | CLOSED DUPLICATE | QA Contact: | Jay Turner <jturner> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | cturner, gafton, mihai.ibanescu, pjones, srevivo, taw |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-03-08 22:51:22 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Isaiah Weiner
2002-03-08 20:45:25 UTC
Is there a copy of the lilo.conf it tried to use lying around anywhere? The problem lies in a customized message graphic. The filename was changed, and a symlink made. The actual LILO error message is very helpful, is there any chance of making the up2date error message more helpful? I'll take a look to see if the error can be more helpful. A failure is a failure though, and I'd rather avoid getting up2date in the game of diaganosing bad lilo config files. The action error messaging for dep cases like you described for packages on the skip lists should be greatly improved in newish versions of the client (2.7.40 or so...) whats up with the kernel-source rpm? why's it complaining it so much? In cases where the lilo test fails, I write the original lilo.conf back into place as /etc/lilo.conf. The "new" lilo's are deleted however, so there isnt one lying around. I assume the current lilo works correctly? Is there any way you can use the failure message lilo (or any other program) gives you as the failure message? The machine is an IBM T20 ThinkPad, so it needs special ALSA modules, which the owner forgot to remove. The existing lilo does correctly work. The client version is 2.7.11-7.x.1, by the way. >Is there any way you can use the failure message lilo (or any other program)
>gives you as the failure message?
Possibly, I'll look into it.
You mention an error related to a boot messages file. What was the error message (and how did you discover that?) The generated lilo.conf's looks okay to me so far, but I'll keep playing. Put an entry in lilo.conf that has the message file be something that is a symlink to something that doesn't exist. So perhaps it points to /boot/message, but /boot/message is a symlink to /boot/message-custom, and /boot/message-custom doesn't exist. When you run lilo you should get the fatal 'file doesn't exist' error. I discovered it by completing the kernel upgrade manually so I could upgrade X. ah. when up2date was ran the first time, the existing lilo.conf pointed to a dead symlink? If the existing lilo.conf is broken, the chances that the one up2date replaces it with are extremely high. It's assume that the installed lilo is working, so thats where the failure comes from at least. I think I'll see if I can start `lilo -t` the existing lilo.conf before I do anything, might save some debug time. Correct - between the last successful lilo running and the package upgrade attempt the file went away. Cool, thanks for looking at it. Might it be possible to continue with the kernel upgrade anyway, and notify the user that LILO didn't successfully run? The bootloader munging doesnt happen until after the transaction set has ran (I can't run a lilo -t until the kernels are in place and on the file system). The depenency error is an artifact of an woefully inadequate action error reporting scheme. This should actually be improved significantly in current clients ( 2.7.42 for example). Basically, if anything fails that isnt one of the couple of exceptions the action knows about, it says it's a dep error. Lame, and hopefully better versions of this will hit the street soon. Of course, that raises the question of is a kernel install without a bootloader install a sucess or a failure. The answers seems to be "sorta". I seem to have several of those cases. Attempting to come up with a sane way to communicate a "sorta" failure now. *** This bug has been marked as a duplicate of 61512 *** |