Bug 52147
Summary: | r-c-n device detection. | ||
---|---|---|---|
Product: | [Retired] Red Hat Public Beta | Reporter: | Ed McKenzie <eem12> |
Component: | redhat-config-network | Assignee: | Phil Knirsch <pknirsch> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | roswell | CC: | harald, pknirsch, rvokal |
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: | 2001-08-30 19:13:12 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
Ed McKenzie
2001-08-21 02:15:04 UTC
Kudzu will already have configured the hardware aspects of it, so you should only need to configure the device... True, but if I click through the dialogs to see what the settings are, it just shows 'eth0' as the device type, and when I exit it deletes my eth0 line in /etc/modules.conf. Browsing shouldn't be destructive! :) It should not delete settings - this needs to be fixed. We (Red Hat) really need to fix this before next release. This is really strange. I have the same card at home and i have not had a single problem with that. It also puzzles me as RCN shares the /etc/modules.conf with other tools and uses it as it's source of information for network cards, so if kudzu detects a new card and makes all the required entries i just can't see where it fails. Also you probably have quit RCN with the OK button. This logically stores the information in the way that RCN sees the world, so if for some reason untraceable for me RCN doesn't see a device it will store it that way. If you could offer more information about what your system exactly looked like and if you can reproduce it so that we can reproduce it as well i'd really appreciate it. Otherwise it's close to impossible to fix this problem. Thanks, Read ya, Phil OK, after closer inspection of the affected machine i found the problem to be in a corrupt system configuration which RCN relies on. To be more specific, the machine has a 2.4 and a 2.2 kernel installed, runs with the 2.4 kernel but /boot/module-info is still symlinked to the 2.2 module-info file. /etc/modules.conf on the other hand contains the 2.4 alias for the Realtek 8139 driver (8139too), whereas the modules-info (which RCN uses to determine among other things the description and module name of the device) does only contain the 2.2 driver (rtl8139). So RCN is really at a loss here. It simply can't combine these conflicting sources of information and therefor breaks. I am currently thinking about a fix, although this is a foobared configuration. I am therefore closing the bug now as NOTABUG but will try to provide a RCN version that can cope with these kinds of broken configuration. Read ya, Phil From your description of the problem, it sounds to me like either a.) initscripts is broken for not fixing /boot links at startup, or b.) kernel rpms are broken for assuming the last-installed kernel is the only one being used. Just MHO, but perhaps this bug should be fixed at the source rather than in rcn? Completely agree with you: Upon bootup the system config files should all reflect the current state, especially the /boot files and some of the /etc files. Some of these things can be easily done and are already (couple of /boot files), but /boot/module-info is obviously still missing. If i have time i might look into fixing it at the source. Read ya, Phil |