I have an FC1 box that tracks the testing repository. With the latest updates it got part way through updating, failed on cpp (unpacking failed) - disk was mostly empty. This set of updates applied so far also broke up2date entirely
Traceback (most recent call last): File "/usr/sbin/up2date", line 1198, in ? sys.exit(main() or 0) File "/usr/sbin/up2date", line 316, in main sources = sourcesConfig.getSources() File "sourcesConfig.py", line 169, in getSources File "sourcesConfig.py", line 32, in __init__ File "sourcesConfig.py", line 61, in load File "sourcesConfig.py", line 128, in parseYum NameError: global name 'up2dateUtils' is not defined
On Tuesday 24 February 2004 04:18, Alan Cox wrote:
I have an FC1 box that tracks the testing repository. With the latest updates it got part way through updating, failed on cpp (unpacking failed)
- disk was mostly empty. This set of updates applied so far also broke
up2date entirely
Traceback (most recent call last): File "/usr/sbin/up2date", line 1198, in ? sys.exit(main() or 0) File "/usr/sbin/up2date", line 316, in main sources = sourcesConfig.getSources() File "sourcesConfig.py", line 169, in getSources File "sourcesConfig.py", line 32, in __init__ File "sourcesConfig.py", line 61, in load File "sourcesConfig.py", line 128, in parseYum NameError: global name 'up2dateUtils' is not defined
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116637
Hi,
I have an FC1 box that tracks the testing repository. With the latest updates it got part way through updating, failed on cpp (unpacking failed) - disk was mostly empty. This set of updates applied so far also broke up2date entirely
One thing which always did puzzle me is why, unlike Windows, neither RH or Fedora ever checks to see if you have enough room for any install. Surely if the rpm included the unpacked size and then did a quick check to ensure there is enough unpacking and installing space, failed RPM installs would be far less frequent.
TTFN
Paul
Hello Paul,
One thing which always did puzzle me is why, unlike Windows, neither RH or Fedora ever checks to see if you have enough room for any install.
Maybe it is a good idea to make this inquiry on the rpm-list, with an appropriate subject of course.
Leonard.
On Tue, 24 Feb 2004, Leonard den Ottolander wrote:
Hello Paul,
One thing which always did puzzle me is why, unlike Windows, neither RH or Fedora ever checks to see if you have enough room for any install.
Maybe it is a good idea to make this inquiry on the rpm-list, with an appropriate subject of course.
Oh but rpm does check for enough room, "always" has (dunno of the first perl-implementations back in RHL 2 days but...). You *can* turn it off but then you get to blame yourself if it fails.
- Panu -
Hi,
Maybe it is a good idea to make this inquiry on the rpm-list, with an appropriate subject of course.
Oh but rpm does check for enough room, "always" has (dunno of the first perl-implementations back in RHL 2 days but...). You *can* turn it off but then you get to blame yourself if it fails.
Try installing RH8 on a machine with a 2.8Gb HD with everything selected. I think the same thing fails under RH9 as well.
TTFN
Paul
Hi Paul,
Try installing RH8 on a machine with a 2.8Gb HD with everything selected. I think the same thing fails under RH9 as well.
That is a problem with the installer, which forgets to compensate for the temporary images it has to write to disk. You could file a bug under anaconda (if it hasn't already been done).
Leonard.
On Feb 24, 2004, PFJ paul@all-the-johnsons.co.uk wrote:
One thing which always did puzzle me is why, unlike Windows, neither RH or Fedora ever checks to see if you have enough room for any install.
Err... Both up2date and rpm do.
On Tue, 24 Feb 2004, PFJ wrote:
I have an FC1 box that tracks the testing repository. With the latest updates it got part way through updating, failed on cpp (unpacking failed) - disk was mostly empty. This set of updates applied so far also broke up2date entirely
One thing which always did puzzle me is why, unlike Windows, neither RH or Fedora ever checks to see if you have enough room for any install. Surely if the rpm included the unpacked size and then did a quick check to ensure there is enough unpacking and installing space, failed RPM installs would be far less frequent.
It does check for disk space before doing installation. If you find that it fails, report a bug against the proper component (anaconda, rpm, up2date, whatever), or your best guess to what component is at fault.
I've done many installations in which I was short on disk space, and was promptly informed that I could not continue - before anything began installing. It also refused to install for me once due to not having enough free inodes on /, so it doesn't just check disk space, but also free inodes.
Alan Cox (alan@redhat.com) said:
I have an FC1 box that tracks the testing repository. With the latest updates it got part way through updating, failed on cpp (unpacking failed) - disk was mostly empty. This set of updates applied so far also broke up2date entirely
Traceback (most recent call last): File "/usr/sbin/up2date", line 1198, in ? sys.exit(main() or 0) File "/usr/sbin/up2date", line 316, in main sources = sourcesConfig.getSources() File "sourcesConfig.py", line 169, in getSources File "sourcesConfig.py", line 32, in __init__ File "sourcesConfig.py", line 61, in load File "sourcesConfig.py", line 128, in parseYum NameError: global name 'up2dateUtils' is not defined
Please try the new 4.1.21-3, thanks.
Bill
On Tue, Feb 24, 2004 at 04:29:51PM -0500, Bill Nottingham wrote:
File "sourcesConfig.py", line 61, in load File "sourcesConfig.py", line 128, in parseYum NameError: global name 'up2dateUtils' is not defined
Please try the new 4.1.21-3, thanks.
Looks good.
Alan -- "The question of whether computers can think is just like the question of whether submarines can swim." -- Edsger W. Dijkstra