View previous topic :: View next topic |
Author |
Message |
OldTango l33t
Joined: 21 Feb 2004 Posts: 718
|
Posted: Mon Jan 14, 2013 8:58 pm Post subject: [SOLVED] Help Understanding Portage and Emerge |
|
|
I recently built a new system and in the process experienced, a lot of problems trying to install a stable Gentoo-System. You can see other forum posts HERE and HERE for more details. The problems have been driving me crazy trying to understand just what is (maybe still) or was going on. So I decided I would take a look at the source files in /usr/portage/distfiles in an attempt to try and make sense out of it. Because most of the main problems were coming from internal compiler error: Segmentation fault when emerging packages, the first file I wanted to look at was gcc-4.5.4.
I tried to open the file directly from /usr/portage/distfiles using Gnomes Archive Manager only to receive (the same one shown below) an error. So I copied the file to my home directory making sure I had permissions to open the file and tried again. The Gnome Archive Manager gave me the same error and refused to extract the file. So I opened a terminal and manually extracted the file with
Code: | tar -xjf gcc-4.5.4.tar.bz2
tar: Skipping to next header
bzip2: Data integrity error when decompressing.
Input file = (stdin), output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.
tar: Child returned status 2
tar: Error is not recoverable: exiting now
| this time the file was extracted but I got this error in the process. It appears the file is corrupt.
I am assuming (please correct me if I am wrong here) that when a package is emerged, if it is not in /usr/portage/distfiles it is automatically downloaded to that location. I am also assuming that during the download phase the file integrity is also checked. If this is the case why would the emerge process continue on, and try to build a package that is bad or corrupted. Shouldn't portage and or emerge stop at this point and refuse to continue until the problem is resolved?
The files come in compressed correct? So doesn't emerge or portage have to extract them as well and won't it encounter the same errors?
I would think that on critical packages like gcc the emerge process would always bail on an error like this.
Is there a way to check all the packages in /usr/portage/distfiles for corruption?
TIA
Last edited by OldTango on Sun Feb 03, 2013 8:53 pm; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54099 Location: 56N 3W
|
Posted: Mon Jan 14, 2013 9:20 pm Post subject: |
|
|
OldTango,
internal compiler errors are almost always hardware issues.
Distfiles are indeed normally compressed. They are fetched as required by ebuilds and left in your distfiles folder until you clean them out.
Emerge does a file size check and several hash checks. The probability of getting an undetected corrupt file is vanishingly small.
You have a higher chance of winning the Euromillions lottery.
emerge uses tar to unpack things as tar can cope with many compression techniques without being prompted.
is normally enough. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Tue Jan 15, 2013 12:49 am Post subject: |
|
|
look for strict and stricter in man make.conf section FEATURES |
|
Back to top |
|
|
OldTango l33t
Joined: 21 Feb 2004 Posts: 718
|
Posted: Sun Feb 03, 2013 8:53 pm Post subject: |
|
|
To say the least this has been the most enlightening if not frustrating problem I have ever had to solve in my years of working with computers. However I have managed to finally solve the problem and my computer is now 100% stable and performing extremely well. As it turns out it was the RAM causing the problem. Making it even more difficult to solve was the fact that the RAM itself isn't faulty or bad. For reasons I have yet to identify the RAM refused to work as expected with my hardware, biso settings and linux. Like most of us, I like as much power and performance as possible and I may have been able to tweak (over-clock) the bios to run the RAM properly, stability is my first concern.
Even though I was hoping for advise on how to best diagnose the problem I have to thank NeddySeagoon for his insistence on NeddySeagoon wrote: | OldTango,
internal compiler errors are almost always hardware issues. | While I have had many of these errors in the past this is the first hardware related one I have had.
An older document, yet a very informative one on how to identify and solve these errors can be found HERE.
If your an AMD fan like me, have a look at THIS and in combination with your Motherboard's recommended RAM, it may help in selecting the correct modules best suited for your setup.
Check THIS out, along with their other articles on tuning gcc with AMD processors.
NeddySeagoon wrote: | Emerge does a file size check and several hash checks. The probability of getting an undetected corrupt file is vanishingly small.
You have a higher chance of winning the Euromillions lottery. | Based on this and my recent run of luck maybe I should but a ticket................
krinn wrote: | look for strict and stricter in man make.conf section FEATURES |
Thanks for the information. A useful feature I wasn't yet aware of.
If you really want to stress test your hardware install Gentoo Linux.............................
Thanks to all for their help. |
|
Back to top |
|
|
|