Bug 1057817 - "error: argument --network: invalid VERSION value" if /etc/debian_version exists
Summary: "error: argument --network: invalid VERSION value" if /etc/debian_version exists
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup
Version: 19
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-25 02:12 UTC by Tom Watson
Modified: 2014-08-15 02:43 UTC (History)
3 users (show)

Fixed In Version: fedup-0.8.0-4.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-24 07:42:44 UTC


Attachments (Terms of Use)

Description Tom Watson 2014-01-25 02:12:39 UTC
Description of problem:
I'm using (or attempting to) fedup to upgrade from F19 to F20.  I did this on my home machine with no problems, but here at work, I access tings thru a proxy.  The environment variables are nicely defined and 'yum' can fetch packages OK, but 'fedup' appears to zone out.

Version-Release number of selected component (if applicable):
fedup.noarch                        0.8.0-3.fc19

How reproducible:
Always, but only on proxy walled machines.

Steps to Reproduce:
1.  # fedup --network 20

I have entered this exact command on non proxy machines and it works fine.
I have the following proxy environment variables set:
http_proxy=
ftp_proxy=
https_proxy=

'yum' can access repositories just fine.

Actual results:
# fedup --network 20 --debug --verbose
usage: fedup <SOURCE> [options]
fedup: error: argument --network: invalid VERSION value: '20'


Expected results:
Nice updates, but at least not 'invalid version number'

Additional info:
On another machine (no proxy here):
# fedup --network 20
setting up repos...
default-installrepo/metalink                             |  18 kB     00:00     
default-installrepo                                      | 3.6 kB     00:00     
default-installrepo/group_gz                             | 210 kB     00:00     

(just the beginning of the messages.  I already had this machine at Fedora 20, so there was no need to continue.  I assume that this is proper.
Version on second machine:
fedup.noarch                       0.8.0-3.fc20

Comment 1 Will Woods 2014-01-27 15:32:52 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.

Comment 2 Tom Watson 2014-01-27 23:08:42 UTC
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).

Comment 3 Tom Watson 2014-01-28 00:30:33 UTC
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'
<<<<<

Comment 4 Will Woods 2014-01-28 17:41:35 UTC
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.

Comment 5 Tom Watson 2014-01-29 01:11:28 UTC
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.

Comment 6 Fedora Update System 2014-02-28 22:22:18 UTC
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

Comment 7 Fedora Update System 2014-02-28 22:22:31 UTC
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

Comment 8 Fedora Update System 2014-03-01 14:06:39 UTC
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).

Comment 9 Fedora Update System 2014-04-24 07:42:44 UTC
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.

Comment 10 Fedora Update System 2014-06-04 16:49:11 UTC
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

Comment 11 Fedora Update System 2014-08-15 02:43:45 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.