GentooThis forum is for the discussion of Gentoo Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
hey, everytime i run emerge to install a package, i get this output:
Code:
Wrong number of fields in NEEDED.ELF.2: �8)�>]�o��N���1g�����l��+z��!}�N�8���Iv�+���9yvK������y�@�����_JWq��)Y����
Sh�$�number of fields in NEEDED.ELF.2: �S����<�8A����/B:�
Wrong number of fields in NEEDED.ELF.2: ��p�VTڶ��-���=���
Wrong number of fields in NEEDED.ELF.2: T�z<�Z��χ�~���7�'�b~(Z����"�e���
Wrong number of fields in NEEDED.ELF.2: .^��B��� �G��<�:m�����^�d����yꉷB���J���`��ve���bD�N��B&��
It doesn't cause installs or compilations to fail, but it's just tiresome to see it EVERYTIME i install a package. Does anyone know what causes this, and how i can get rid of it? Thanks
Last edited by fedoralinuxjunkie; 11-11-2009 at 11:03 PM..
I am not sure, but, what version of portage are you using?
Code:
emerge --version
I've seen this mentioned somewhere in relation to portage 2.2, which is really not ready for production though a number of persons are using it without major problems. If you are using portage 2.2.x you should go back to 2.1.x (which doesn't support @sets, but otherwise it works the same mostly).
If you don't want to go back, I suggest you to look into the gentoo-portage-dev mailing list and search around there, so at least you can get some hints on what's going on about that message.
well, about 2 hours after the time of my writing that post, my computer locked up during an emerge for no reason at all, and it broke the system, so i'm thinking about maybe not going back to Gentoo...thanks anyway though, if i do reinstall, i'll remember that
It depends on what does "locked up" mean. But if it was a "hard lock", and you had to shut down the computer physically, then that's a symptom of a hardware problem.
Before you go and say "every other OS works ok" just stop and think that you are not doing heavy compiling in other OSes, and compiling is one of the most intensive i/o operation you can do in a computer. Faulty ram is one of the most common problems that arise in Gentoo while remaining undetected in any other OS.
In any case, most livecd's ship a memtest86 option in the boot menu, it won't hurt to check your ram with it, though the problem could lie in a number of other places, that's just one of them.
GNOME actually started the lockup...I was writing a blog, and I was going to pull up the terminal to check the progress, but it wouldn't come up, so I tried all the other windows, and none of them would come up, so I'm guessing GNOME started the lockup...Firefox didn't lock up the whole time I was writing that blog though...So I think I'll reinstall Sabayon (that's the one I was using), and check my RAM with memtest86 and read a little more on Gentoo...thanks
I see. I assumed you were still at the command line and compiling stuff.
Hardlocks on the apps side are ideally not possible, so when that happens it's usually either hardware or a buggy kernel module. When in X, the graphics driver can be an issue, but it can be any 3rd party kernel module in any case. The ones shipped within the kernel are less likely to produce such nasty bugs.
In the hardware department, the first things I always check when getting this kind of problem are: ram (as said), temperatures (cpu, gpu and hd) and the health of hard disks (smartmontools can help with that, some manufacturers also offer their own tools to check their drives).
Just to simplify the testing environment, try to avoid setting desktop effects or things like that, you can as well run "tail -f /var/log/messages" on an xterm, all the kernel messages are usually logged in there, so if you are lucky and something is dumped there just the moment before the machine freezes it might give us some tips about whats going on (or not, it depends on what the exact problem is).
Yeah, FGLRX has caused issues in the past with some of my kernels (i have a high performance ATI card), but this time it just seemed like a random error...I've decided to reinstall Sabayon on my next day off though ...Do you think maybe my use of both the Entropy package manager and Portage both may have had some kind of effect that caused this? (Entropy is Sabayon's default package manager, but I prefer Portage)...Also, checking on the whole Portage version, it was 2.2...
About portage vs. entropy, I can't answer that because I could be misguiding you. I don't know what's recommended or supported on Sabayon, and it's been a very long time since I tested that distribution.
However, and letting aside how friendly or unfriendly portage and entropy are to each other, that shouldn't ever cause a freeze on your box.
About the portage version, 2.2 is masked for a reason as said. It's not ready for production and shouldn't be used if what you want is a stable system. Again, and regardless on how portage mess up your packages or fails to do some things, that's nothing to do with your box freezing hard.
Hard locks can happen from time to time when using fglrx nowadays still, so, as long as it doesn't happen again, you shouldn't worry too much. The rest is your just fs getting screwed. Each time your box locks hard and you have to force a hardware reset your fs can break, and when that happens, what will happen is completely random to put it plainly. It's rare for it to break to an irrecoverable status (unless you are using some experimental fs), however it is possible. Not common, not even probably, but possible. Shit happens which is why we all do backups
In the next hard lock (if it comes to happen), try to use alt+sysrq+u to force an umount on all the drives, that will prevent fs breackage. Then use alt+sysrq+b to reboot. These will only work if the relevant option is enabled in your kernel AND the kernel didn't die completely. If it works, your fs's should be completely ok on the next reboot, because they were unounted before doing a hard reboot, hence preserving their integrity.
if never came up as masked...it ran through with the update...thanks for those tips, this will really help me when I go for CompTIA Linux+ Certification (I'm currently in college for CompTIA A+)
Portage 2.2.x is masked due to very well known bugs in some new features, like package sets and the preserve-libs feature. Probably many more.
"Why" is not masked for you is another question. Maybe you unmasked it and don't remember doing so. Maybe you used Sabayon on that install and in that case I don't have a clue on the default Sabayon settings. Sabayon is well knows for being an early adopter for experimental features, which sometimes can cause instability. That's one of the reasons why we like to parrot around that "Sabayon is not Gentoo".
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.