Bug 1057817
| Summary: | "error: argument --network: invalid VERSION value" if /etc/debian_version exists | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom Watson <tsw-rh> |
| Component: | fedup | Assignee: | Will Woods <wwoods> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | tflink, tsw-rh, wwoods |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | fedup-0.8.0-4.fc19 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-04-24 07:42:44 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: | |||
|
Description
Tom Watson
2014-01-25 02:12:39 UTC
fedup inherits its proxy config from yum (which just lets libcurl do the work), so there's no obvious reason they should work differently. Also, the error message you mention usually happens well before any attempt to access the network. So I'm not sure this has anything to do with proxies? Could you attach /var/log/fedup.log from the proxied system? Also, what happens if you run "rpm -V python-libs fedup"? Any output there would indicate that something is wrong with the files on your system. I did the following: [root@twatson2012 log]# rpm -V python-libs fedup [root@twatson2012 log]# fedup --network 20 usage: fedup <SOURCE> [options] fedup: error: argument --network: invalid VERSION value: '20' [root@twatson2012 log]# cat /var/log/fedup.log cat: /var/log/fedup.log: No such file or directory Looks like no log was created by the fedup action. I have gotten other instances of fedup to create logs. In this case, I removed the older ones and ran the fedup command as shown above. Somehow it is aborting pretty early in the process (my guess). More information:
If you have the file 'debian_version' in the /etc directory, it causes this failure. I had it there for some testing, thus the failure.
You might want to check this at some time! The error message is VERY unclear!
>>>>>
[tsw@twatson2012 etc]$ fedup --network 20
you must be root to run this program.
[tsw@twatson2012 etc]$ su
Password:
[root@twatson2012 etc]# mv debian_ver.not debian_version
[root@twatson2012 etc]# exit
exit
[tsw@twatson2012 etc]$ fedup --network 20
usage: fedup <SOURCE> [options]
fedup: error: argument --network: invalid VERSION value: '20'
<<<<<
Ah! I think /etc/debian_version confused python's "platform" module such that it:
a) thinks you're running something other than Fedora, and
b) gives a "version" that isn't a number.
What happens if you replace /etc/debian_version and run this?
python -c 'from platform import *; print linux_distribution()'
without /etc/debian_version you would get something like:
('Fedora', '19', 'Schr\xc3\xb6dinger\xe2\x80\x99s Cat')
What do you get if /etc/debian_version is there? And can you attach (or just paste the contents of) /etc/debian_version?
I should be able to fix that error message pretty easily.
The file /etc/debian_version has a single line, something like:
>>>>>
6.0.7
<<<<<
This is what it had when it errored out on me. It seems that you look for files with 'version' in the name and expect things. The contents of 'debian_version' seem to trip up the code and make it get all flustered.
I removed the file on the machine here (with proxy, which I thought was the problem), and the 'fedup' from 19 to 20 worked just fine. Of course I needed to add 'selinux=0' to the line in the grub configuration, but that is another matter.
On a Debian (yuck, but I have to deal with it) I get:
tsw@machine:~$ python -c 'from platform import *; print linux_distribution()'
('debian', '6.0.7', '')
On my just (yesterday) updated Fedora machine:
[tsw@twatson2012 Jan27]$ python -c 'from platform import *; print linux_distribution()'
('Fedora', '20', 'Heisenbug')
If I put back in the debian_release file:
[tsw@twatson2012 Jan27]$ cat /etc/fedora-release
Fedora release 20 (Heisenbug)
[tsw@twatson2012 Jan27]$ cat /etc/debian_version 6.0.7
[tsw@twatson2012 Jan27]$ python -c 'from platform import *; print linux_distribution()'
('debian', '6.0.7', '')
So, it seems that the 'linux_distrubution' routine prefers debian releases and quits there. Bummer, it should be the other way around.
Hope this helps.
fedup-0.8.0-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/fedup-0.8.0-4.fc19 fedup-0.8.0-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedup-0.8.0-4.fc20 Package fedup-0.8.0-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fedup-0.8.0-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3270/fedup-0.8.0-4.fc20 then log in and leave karma (feedback). fedup-0.8.0-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. fedup-0.8.1-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedup-0.8.1-1.fc20 fedup-0.8.1-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |