Hide Forgot
Description of problem: I would like to force the autodetection of the hardware with kudzu, because there is a misconfiguration in my system and it does't recognize my mouse nor my network card anymore. If I boot anoter partition those two devices are detected successfully. I did not find a way to force the configuration detection with kudzu and I think that this is something necessary in my case. I have seen a lot of other people wanting to force the redetection of their hardware. Sometimes things might get mixed up and a complete reconfiguration helps in those cases a lot. E.g. just a file like '/kudzu-reconfigure' in the root partition would tell kudzu to do the job. I really hope that this will be possible. Thanks, Daniel Version-Release number of selected component (if applicable): kudzu-1.1.95.15-1 How reproducible: Tried, but couldn't reproduce it. Steps to Reproduce: 1. Copy a whole server's root partition to another partiton 2. Boot from that other partition 3. Do not answer to the Kudzu configuration program at first boot. 4. reboot and the kudzu window in text mode doesn't appear anymore. This was the case once here but it normally does not behaves that way. Actual results: The hardware was wrongly detected and not working. Expected results: Nothing, it is quite normal due to the modifications, copy of /sys and so forth I did. However, we should be able to force the reconfiguration of Kudzu for all device of the computer in case something goes wrong, which is the case sometimes on a system. Additional info: I have tried to copy a working /etc/sysconfig/hwconf from the working partition for the same server to the partition that is wrongly detected. That did not work neither. I tried to delete that hwconfig file but in that case it is stated that kudzu tries to redetect the hardware by the already currently configured devices in the modules but not to reconfigure them, unfortunately.
rm -f /etc/sysconfig/hwconf ; kudzu is the standard way to 'reconfigure' everything. It may notice some things are already configured (by entries in modprobe.conf, etc.)
Hello. Thanks for that explanation. When I run 'kudzu' alone, or with the deletion of the hwconfig file before, like suggested, nothing happens. It just waits 5 seconds and returns to the shell without any wondow opened. The same after reboot. Does this mean that it has successfully detected the configuration in the other files ? In that case it means that it has not reconfigured anything, which is my problem. Isn't there another way to force the reconfiguration, by not looking the currently configured files, but by really checking the hardware ? Regards, Daniel
If it returns, it means that anything that it thought needed configuration (scsi adapters, video adapters, network adapters, etc) appeared to already be configured, by examining modprobe.conf. There's really not a switch for changing that part of the behavior.
I looong to see that switch integrated.. I have had that problem already since a long time with previous version of RedHat (on 7.2 already). I would suggest adding an option in the command line arguments and maybe also allow having a '/kudzu-reconfigure' file detection in the root directory so that kudzu would force the reconfiguration at boot up, and deleting that file afterwards automatically. Thanks a lot. Regards, Daniel
The question is, what sort of changes are you seeing that aren't getting caught in the 'normal' behavior? (Note that much of the configuration is going away in any case.)
I'm not sure to have understood the question, but I have the mouse which is wronlgy detected, and also the network card. I know that they work, because when I boot another partition, then these same devices are taken into account properly and work well.
What sort of mouse and network card?
The mouse is a Logitech wheel mouse optical. The network card is a Via 6103 10/100 Ethernet (802.3u). They are detected as: class: USB bus: PCI detached: 0 driver: ehci-hcd desc: "VIA Technologies, Inc. USB 2.0" vendorId: 1106 deviceId: 3104 subVendorId: 1849 subDeviceId: 3104 pciType: 1 pcidom: 0 pcibus: 0 pcidev: 10 pcifn: 3 - class: NETWORK bus: PCI detached: 0 device: eth0 driver: via-rhine desc: "VIA Technologies, Inc. VT6102 [Rhine-II]" vendorId: 1106 deviceId: 3065 subVendorId: 1849 subDeviceId: 3065 pciType: 1 pcidom: 0 pcibus: 0 pcidev: 12 pcifn: 0 -
That's not the mouse, that's the USB host controller. There is no configuration to be done for USB mice on any OS that uses the 2.6 kernel; it should 'just work', and if it doesn't, that's likely a kernel bug in the USB stack somewhere. What isn't configured right about the network card - entry in modprobe.conf? Something else?
In the working system, the network card is detected with the same attribues in hwconfig. However, the mouse is in this file seen properly as 'Logitech USB- PS/2 Optical Mouse'. Sorry for the USB controller, I did take the USB device that was nearer of something like a mouse. It was not present in the file in fact. BTW it is not really serious that it doesn't work. I can reinstall everything on that drive. I just wanted to let you know about the lack of this kudzu option to force the reinstallation of all drivers, as it's a long time I am waiting for it. But If you are interested for yourself to this particular problem I have, here is the output of /etc/modprobe.conf: alias usb-controller uhci-hcd alias eth0 via-rhine alias snd-card-0 snd-via82xx options snd-card-0 index=0 install snd-via82xx /sbin/modprobe --ignore-install snd-via82xx && /usr/sbin/alsactl restore >/dev/null 2>&1 || : remove snd-via82xx { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-via82xx alias usb-controller1 ehci-hcd Here, eth0 is defined the same way than on the working modprobe.conf file.
I'm confused - if it's in modprobe.conf, how is the network card not working?
Humm.. something weired is happening here. I am now able to reproduce the problem. If I boot this degraded software raid 1 disk (which causes hardware detection problems), and boot it as primary master, then everything is detected fine. However, if I boot that same drive on hdd instead of hda, with another raid disk booting grub, and running the failing partition from there, then this hardware detection problem happens, and the mouse is just blocked. When I try to start the network, that error happen: Bringing up interface eth0: via-rhine device eth0 does not seem to be present, delaying initialization. Any idea ?
When it doesn't work, does it show up in lspci?
Yes, it does: 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
Does the HWADDR in ifcfg-eth0 match the hwaddr of the card?
There is no HWADDR in that file. I think that there was one before, but I have removed it as a message indicating the unmatch of the MAC address appeared.
I still think that the force option would have been interesting in that case, and thus is proves that it might be useful to implement it. Would that be possible ?
I have re-done the whole backup process on another drive and exactly the same problem happens. However, that time I had the kudzu window opening at boot up and I just went through everything. It's interesting to note that the network card has been removed and reconfigured. The mouse is still not working and still not detected in the hwconfig file. The network card still doesn't work. This time, this is not only an autodetection force option lacking, but a hardware detection error. All the symptoms are exactly the same as before. In /etc/modprobes I had only that line: alias usb-controller uhci-hcd So yes, if you can help I would be glad. I remind and emphasis that the same drive, again, put on another IDE port as master and booting up from there, everything works fine! That is something strange.. If I place that root partition on the secondary slave as /dev/md22 it fails, but works as primary master. Would this have something to do with a software RAID problem ? Else, at boot-up, with all partitions, this message is displayed at the very beginning of the root partition boot-up: PCI: cannot allocate ressource region 1 of device 0000:00:0a Thanks for any help. Regards, Daniel
As the current development code does very little in the way of configuration (in fact the UI itself is completely removed), changes to that code very likely won't be made. As stated, the mouse before has nothing to do with configuration, per se - it appears to be a driver error. Can you attach /var/log/dmesg after booting in this 'broken' configuration?
Created attachment 120853 [details] /var/log/dmesg
I did try something else: doing the same backup but that time on a hda device instead of an md device. The result is exactly the same, with the same problems, so it doesn't come from the software raid. As I had to go through the kudzu configurator at first boot up of that new backup, I noticed that time that the other server's video card was asked to be removed successfully, but it also asked to remove the Via network card, which in this circumstance is exactly the same brand and model on the remote server and on the backuped server. The hardware mac address is different, and this is maybe why kudzu wanted to remove that device and where the problem happened. However the network card is still displayed in the hwconf, even if it was removed with kudzu's question. Also, it is to notice that it didn't ask for reconfiguring of that netword card, which makes me think that the driver is not really there but only present in the hwconfig file. The same applies to the mouse: I have been asked to remove all VIA USB controllers, but never asked to reconfigure them. Apparently, the mainboard is also the same on the server and on the backup server and the problem probably comes from here. The system thinks through hwconfig that the USB drivers are there, but they have been removed by kudzu and thus it doesn't work anymore. What do you think ? I attached the dmesg file of the buggy partition as asked.
That's the entirety of it? It seems to show that it doesn't load any external modules; perhaps /var/log/messages would have more details.
Yes, it is. Nothing removed from that file. I attach hereby a part of /var/log/messages. I did redo a backup and this time I removed the hwconfig file before rebooting the partition. Strangely, the kudzu window didn't appear that time, but the problem still remains the same. What do you think about my last comment ?
Don't see it attached, maybe I'm commenting too soon. Going back to the start: ... Nothing, it is quite normal due to the modifications, copy of /sys and so forth I did. .... Did you actually *copy* /sys from one machine to another, or are you still mounting it? That won't work - perhaps I'm misreading what you said. Also, are you rebooting the same kernel in all cases?
Created attachment 120857 [details] /var/log/messages for last boot up with failing configuration Looking to that file, I now understand what happens. It seems that there are problems to load some drivers which are not present anymore on the system. This comes I think from the fact that grub is booted from another drive which has one kernel definition which is not on the backup's one. I don't know really why this is the case, but that's probably the reason. It could however still boot up the proper kernel, because that one is on the same partition than the grub config file (/boot), however the /lib/modules doesn't contain that directory and this is the reason of the problem. I wish I would have looked earlier into that file. Sorry for that, Bill. Thanks for your great support, you helped me a lot to figure out what was happening and I am thankful to you for that. It helps me a lot, you can't immagine. Kind regards, Daniel
OK, I'm going to close this - if you get the same kernel in both grub and on the copied image, I believe things should behave more in-line with your expectations.
Ok good. The grub and kernels are loaded properly. The only thing is that the directory under /lib/modules is not the same name than the kernel name defined in grub. Do you know what makes the modules directory to be loaded properly ? is it just the kernel name which must be the same on the /lib/modules or is there any other command to specify what modules directory to load from ?
It needs to match; it implies you have a different kernel version installed on the filesystem than what's installed in grub. Reinstalling the kernel RPM should do this.
Ok, thank you for all this information very useful, and all your work to help me! Best wishes, Daniel