Bug 139762
Summary: | Fails to upgrade eth0:1 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Emerson House <ehbase-linux> | ||||||||
Component: | kudzu | Assignee: | Bill Nottingham <notting> | ||||||||
Status: | CLOSED WORKSFORME | QA Contact: | David Lawrence <dkl> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 3 | CC: | rvokal | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | i686 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2005-09-23 21:21:17 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: | |||||||||||
Attachments: |
|
Description
Emerson House
2004-11-17 21:37:33 UTC
well, the question is: how did the string eth0:1:1 come in the config file the first place?? Gosh, I'm reporting the bug because it appears to have occured during the upgrade process. The problem manifested itself immediately after the upgrade although it worked immediately before the upgrade. this is very, very strange... how did you upgrade? with anaconda, which means, you booted from the FC3 install CD, or with yum/rpm/up2date?? Using anaconda, I booted the rescue iso, chose linux and then did a FTP install from mirrors.kernel.org. I have eth0:1 configured because I am running multiple subnets on the same interface. I assume this is the typical reason people enable additional interfaces on the same hardware. But most people don't do this. The eth0 interface worked fine and upgraded without problem. I thought there would be a significant minority of users who might face the same problem. But if this affects only me and not other users that have multiple interfaces configured then it is not important. maybe anaconda touched the ifcfg-eth0:1 file?? Not sure why this was assigned to kudzu; it doesn't rewrite DEVICE= lines. Can you attach your current ifcfg files? Do you have the old one/can you reproduce this at will? Created attachment 107019 [details]
eth0:1 script with DEVICE string fixed.
Created attachment 107020 [details]
eth0 script unmodified
Created attachment 107021 [details]
wlan0 script unmodified
I haven't tried this yet as I have to compile a prism2_usb module to get it
working.
Attached ifcfg-eth0:1, ifcfg-eth0 and ifcfg-wlan0. Only ifcfg-eth0:1 was modified manually. However I saved after running system-config-network to make sure it worked and that seems to have updated the timestamp on all files. The problem is reproducible with the eth0:1:1 DEVICE string. I have not tried making a clean install of FC2, configuring eth0:1 and then doing an upgrade to FC3. You might want to wait to see if anyone else encounters this first. You could try running system-config-network with the eth0:1:1 DEVICE string as that produces a system error. Apologies for the lack of response. kudzu doesn't have any code to write ifcfg-XXX files, and certainly none that runs on upgrade. I haven't seen any other reports of this, so I'm not sure what could be causing it. If it still happens on a stock install, please file a new bug. In the meantime, I'm closing this due to local unreproducibility. |