FedoraThis forum is for the discussion of the Fedora Project.
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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Updating hwdata (hardware data related to several processes including XFree86) from 0.101-1 to 0.103.1-1 replicated the failure that I have been seeing. After a clean installation of FC1, the order of updates was (1) update kernel to .2174 and reboot, (2) update XFree86 to 4.3.0-55 and reboot and (3) update hwdata to 0.103.1-1 and reboot, which was unsuccessful.
The screen output was as follows (ignoring the typos, of course):
After poking around /usr/share/hwdata on my FC1 Dell (the Athlon is still stuck and poking around is a lot easier under x), a few things struck me:
mjp:
Are you using a graphics card with a GeForce FX 5200 chipset like me?
Are you using a Logitech optical wheel mouse through the PS/2 port by using the USB to PS/2 converter supplied with the mouse like me?
The files /usr/share/hwdata/pci.ids and /usr/share/hwdata/pcitable do contain references to GeForce FX 5200 and /usr/share/usb.ids contains a reference to the Logitech optical wheel mouse. Again, in my case, the mouse is not connected as a USB device, but as a PS/2 device. For clarity, the mouse and keyboard are actually connected to a Linksys KVM switch and then to the Athlon system.
When I tested FC2 test 1, it initially (before any updates) ran OK/buggy and detected my SATA drives (which was the point of the test). After updating the system, it kept getting stuck at the command line login prompt after failing to configure X. Like your current description, running startx from command line didn’t help. The problem seemed to be the mouse, so I connected an old PS/2 Microsoft Intellipoint mouse and reran startx without success. The log files said something about failing to configure the mouse and included some references to the console mouse services. Hence the question about the mouse.
As a side note, I see other active threads about FC2 test 1 failing to start x. FC2 test 1 may be troubled by the same apparent hwdata problem that is hitting me/you.
WhatsHisName,
I have onboard video (Sis 730). The mobo is a k7sem, with a 1.4ghz Athlon.
However you've mentioned some things that we have in common.
1) I too have a kvm 2 port switch (Belkin) connecting my two systems and the keyboard and mouse are connected through the switch.
2) I too have had errors, even before this, about the mouse console services. My mouse is a 6 year old+ msft intellimouse.
It really seems that these problems we are having aren't on our end but on this newer kernel. It almost sounds like this is a driver issue in some regards. I can't imagine this particular upgrade being more than just a minor upgrade. It's possible one of these rpms are just corrupt.
Here's something that was kind of odd, I know after I had upgraded the kernel and source (.2174) by itself, I then tried to update more of the updates alone. I did not reboot at this time. It might have been xfree86 that I was able to update.
But, after that, I picked a few more updates and up2date was able to retrieve these packages but when it tried to install them I kept getting a rpm unpackage error. Up2date was not able to open these packages for installation. This happened twice for me and then after that I tried to reboot the system thinking that maybe this would help; and that's when all the trouble started.
I don't know if this helps out or not. I might try and look around a little more and then either tommorrow or Saturday I will reinstall the OS and see what happens. From what you're telling me, it might not be a bad idea just to skip this particular kernel upgrade and just wait for the next one. Maybe whatever problems .2174 is causing will be fixed on the next one.
I do have a question though? Are these updates coming from RedHat and are they supported by RedHat or is this a little different because Fedora is more or less "experimental" in that it changes so rapidly. In other words if this is coming from Red Hat, would they be aware of these issues.
Well thanks for the input.
There was an interesting interview with Jeremy Hogan of Red Hat regarding Fedora/RHEL (see http://www.linuxquestions.org/questi...5&pagenumber=1). You get the impression that Fedora is the proving ground for RHEL, but in somewhat the same way that RHL9 was.
I wasn’t expecting this level of instability in Fedora after running RHL9. Before the current problem happened, it was my impression that you could always fall back on an older kernel when things go wrong. My system is absolutely dead once the startx failure sets in. Of course, that may just be the result of my inexperience with linux and that a more technically savvy person could get it back on its feet. For me, reinstallation of FC1 is the only option.
So unless someone has a good suggestion, I too will be reinstalling and avoiding some updates.
You really have to wonder when things like this happen whether Red Hat is just “poisoning the milk” to get us to spring for RHEL.
WhatsHisName,
Thanks for the link, I'll check out this article. What you said about falling back to a previous kernel; that's what I don't understand why this is affecting ALL of the prior kernels. It almost seems like, anything that is on the same partition is affected. My Slackware distro is on a different drive and it is Not affected. In fact, I compiled the 2.6 kernel about a month ago and it is even doing the same thing. Go figure (it is on the same drive and partition that FC1 is).
I think from now on I will be more careful with up2date; particularly with kernel upgrades. Unless it is a major kernel upgrade(going from 2.4 to 2.6) I may just show some patience and go without.
I understand that companies must be profitable to function but I sure hope open source stays pretty much "free". I was even considering trying out Suse Linux but it's latest version can't be downloaded in iso form like most of the other distros (at least on linuxiso.org).
One other thing you mentioned; about being inexperienced. How do you think you get experience, not when everything is working. When I've learned the most was when things broke down. I like to look at these times as learning experiences. That's the only reason I haven't tried a reinstall yet. I was hoping to poke around the system and get feedback from other users to see if it could be fixed the "hard" way.
What people have told me is that there is no way you can know everything where IT is concerned, but just know how you can get the problem solved ASAP.
Let me know if you come up with anything and good luck.
WHN, this is weird stuff:
>Checking for new hardware /etc/rc5.d/S05kudzu: 4159 Segmentation fault /usr/sbin/kndzu $KUDZU_ARGS -t 30 [Failed]
>Updating /etc/fstab [OK]
>Applying iptables firewall rules: [OK]
>Setting network parameters: [OK]
>Bringing up loopback interface:
Kudzu queries the hardware, compares it to tables in hwdata and writes its discoveries in /etc/sysconfig/hwconf.
I would look in /etc/sysconfig/hwconf to see what kudzu wrote, if there's something wrong there, it will perpetuate throughout the system.
I have a feeling network tries to query loopback and waits forever because kudzu has scrambled it's info.
One point/question about kernel updates:
Does up2date 'install' or 'update' the new kernel?
With 'install'you have at least one good kernel, rather than a new one overwriting parts of the old one.
GOOD: rpm -ivh newkernel-ofsomekind
BOLD: rpm -uvh kernel-leapoffaith
As usual, I only have time for vague generaliations, sorry.
RHELL, No bodily excretion (got to be careful, the FCC might be listening)!
Listed below is an abbreviated version of /etc/sysconf/hwconf. Except for the first and last entries, they have been abbreviated to only the descriptions. I can post the intact listing, if needed, but it is 7 printed pages long. The log file stops abruptly at the mouse.
One thing to note is that several components are being configured under the VIA KT400 chipset, but should be configured under the VIA KT600 chipset. (It is my understanding (and I could be wrong) that the major differences between the chipsets have a lot to do with the use of DDR memory.) Others in this forum using the Asus A7V600 motherboard have reported the same situation under linux, but it doesn’t seem to cause any serious problems (other than not being able to see the SATA drives under FC1, but visible under FC2 test 1).
>"RHELL, No bodily excretion (got to be careful, the FCC might be listening)!"
Sorry, I will try not to generaliate in public again. DOH! I just did.
Since hwinfo is the last thing you installed and kudzu seg. faults, there may be something wrong with that file. It may also specify a driver other than the one you need, check /etc/modules.conf and the README for you Nvidia drivers.
The ISA bridge seems to be a mystery, but you probably don't have anything there, so I doubt it's relevant.
Ignoring kudzu for a minute, since it locks up in networking:
Type 'ifconfig' (no arguments) and see if local loopback is really set up. We gotta get past that anyway, so we can break something else.
The easiest way to fix that is 'redhat-config-network'
The problem with running ifconfig or redhat-config-network is that the system locked up and did not revert to the command prompt login. When I powered down the computer and restarted it, the file system appeared to be mounted as read only (i.e., a stream of error messages went by stating that the target files are read-only) and the system eventually locked up. None of the installed kernels would start. The hwconf file was retrieved under linux rescue, not after login in at the command line. At least FC2 test 1 got me back to the command line prompt when it failed.
This is the first time that I have run into a problem where linux does not revert to the command line login prompt after a major startup failure. It’s just weird. FC1 just rolled up into a fetal position and said “Go away and stop bothering me!”. So, I spent the weekend loading WinXPpro onto it, which has been its own little bundle of joy (don’t worry, it going to be dual boot).
mjp,
Were you able to reinstall FC1 plus selectively install updates over the weekend and get a functional system back?
WhatsHisName,
I have reinstalled FC1 and downloaded about 40 of the updates. I still have about 94 left. Everything is functional and I have not had any problems getting back into the system. However, I have not installed the hwdata update.
For now I'm just going to go slow with some of these updates, slowly installing them and maybe waiting until the end to try and install hwdata.
I'm just wondering if some of these updates are just corrupt for all systems or if it is a hardware specific issue depending on one's individual system.
I'll let you know if I have any problems as I do the updates.
I'm back to square one again. I had downloaded about half of the updates.
I skipped the hwdata update for the time being. The batch that I downloaded when the problems started again were these (without the version nos.):
nptl-devel, nscd, nss_ldap, pam_krb5, pango,pango-devel. I also had to
add to this group glibc-devel and glibc-headers.
As I was installing this group I got this message: "There was a fatal RPM install error. The message was: There was a rpm unpack error installing the package pango-devel (version no.)".
After I okayed the screen, the install then ended. When I checked to see what updates had been installed it showed this particular update as still being available so I tried to install it again. But when I opened up the up2date screen, the screen window opened up but I could not see any writing or any fonts on it. This happened when I initially had the problem.
So I tried to log out to see if this would correct the problem. When I got to the username login screen, the cursor was flashing but I could not input my username. This, too, happened the first time when all the problems started.
I then went to reboot, still in runlevel 5 and it seemed to boot up ok but when it got back to the username login screen the same situation happened.
I haven't tried to go back into runlevel 3 yet so I have to see if the same kind of error messages start all over again. I don't know if this info is helpful or not.
What I might even do is repartion the FC1 partition and include a boot partition this time (I don't have one now: I just have a root and swap) and then reinstall and download the updates that worked and then image the boot, root partition. Hopefully, this will save having to reinstall these updates each and every time if it crashes again.
I did have an image made of the FC1 root partion but grub was nowhere to be found, nor was I able to get the system to find it, when I copied the image back after I reinstalled FC1. So I can only guess that I also need to image the boot partition as well. Now is as good a time to try something like this. Since I'm already in unchartered territory I might as well add something else to my repertoire.
I do have a question about these FC1 updates: Are they coming from the same place (site) that the Red Hat 8 & 9 updates came from? I don't recall having these kinds of problems with Red Hat updates in the past.
I just did a runlevel 3. I get these error messages as I boot up: umount: invalid argument, umount : /initrd not mounted, umount2: invalid argument and umount 2: /initrd not mounted, plus it mentioned something about pango-devel but the screen went by too quickly to pick it all up.
When I got to the command login prompt I was able to login as root and then I did a startx. I WAS able to get to the desktop, however any icons or any menu items had no fonts to them. In other words, you could see the icons but there was no description as to what they were. This also included the menu that you access on the taskbar, as well.
I really don't have any more time today to check into this, but I did not get any error messages concerning respawning. I don't know if this just opens another can of worms or not.
Well that's the latest for now.
Once, I got to the icon-without-fonts stage. I’m still struggling with the WinXP upgrade (version conflict problems following upgrade, which are sooooo much fun!) and haven’t been able to get back to FC1. Plans are to dump the FC1 install and just start again with a freshly formatted partition.
You have a good idea about making a copy of a functioning Ext3 partition, rather than having to start at the beginning every time. I was making 60GB Ext3 partitions for testing, but dropping that to about 10GB would make copying it a snap. You can always stretch it to a larger size with partitionmagic if you get a good one made.
More bad news to report, but making copies of the working ext3 partitions has made a big time difference.
To make a long story short, when I installed FC1 as a desktop and updated everything except hwconf in 6 rounds of selective updating, the system ran fine. When I then updated hwconf, the system failed to boot and locked up shortly after the “new hardware” probing failed.
On the off chance that the mirror I am using had a defective copy of hwconf, I went directly to Red Hat and found updates for kudzu and hwconf. Kudzu is the Red Hat Hardware Probing Tool, which is what seems to be triggering my lockups. So I started the update and went for a cup of coffee while that awesome 7kB/sec download finished. When I shut down linux, the system locked up on the way down and would not reboot to X.
I restored the previous ext3 partition (the same one used to start the kudzu/hwconf update) and went back for a selective update of kudzu at Red Hat (and another cup of coffee). It rebooted OK, so I went back to Red Hat again for the hwconf update and went to the john while it downloaded. The system locked up during the reboot with the following stuff on the screen:
Init: Entering runlevel 5
Entering non-interactive setup
Checking for new hardware/etc/rc5.d/S05kudzu: line 97: 4436 Segmentation fault /usr/sbin/kndzu $KUDZU_ARGS -t 30 [Failed]
Updating /etc/fstab [OK]
Applying iptables firewall rules: [OK]
Setting network parameters: [OK]
Bringing up loopback interface:
The system stopped responding at this point, same as before, but with a new segmentation fault.
Suggestions?
P.S. If you guys at Red Hat (you know, the ones responsible for kudzu (say no more, nudge nudge, hint hint, wink wink, know what I mean)) would like a little more information, you can reach me at hwconf-sux@spamex.com before March 5 (auto-expire date).
WhatsHisName,
Here is a suggestion/curiosity. We are all having certain problems based on the idea that AFTER we upgrade to the .2174 kernel then when certain updates are downloaded, problems arise.
I wonder what would happen if we FIRST upgraded all the updates and then upgraded to .2174. I don't know if you can or should do this, but we are assuming that the source of the problem is one or more or the updates.
Could it be that the updates are ok and it's the kernel source (.2174) that is
the problem. Once again, I don't know if this is the case but at least it's worth considering all the possibilites.
If this is the case then why not just wait for the next kernel upgrade, they seem to come out pretty frequently on FC1 and take it from there.
Just something worth thinking about.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
(don’t worry, it going to be dual boot).
