Bug 172732 - Impossible to force kudzu to reconfigure all devices
Summary: Impossible to force kudzu to reconfigure all devices
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kudzu
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-08 20:02 UTC by Daniel
Modified: 2014-03-17 02:56 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-11-09 21:17:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
/var/log/dmesg (9.53 KB, text/plain)
2005-11-09 20:03 UTC, Daniel
no flags Details
/var/log/messages for last boot up with failing configuration (13.00 KB, text/plain)
2005-11-09 21:15 UTC, Daniel
no flags Details

Description Daniel 2005-11-08 20:02:29 UTC
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.

Comment 1 Bill Nottingham 2005-11-08 20:05:42 UTC
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.)

Comment 2 Daniel 2005-11-08 20:41:02 UTC
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



Comment 3 Bill Nottingham 2005-11-08 20:52:59 UTC
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.


Comment 4 Daniel 2005-11-08 21:08:16 UTC
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


Comment 5 Bill Nottingham 2005-11-08 21:10:12 UTC
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.)

Comment 6 Daniel 2005-11-08 21:20:36 UTC
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.


Comment 7 Bill Nottingham 2005-11-08 21:21:40 UTC
What sort of mouse and network card?

Comment 8 Daniel 2005-11-08 21:33:47 UTC
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
-



Comment 9 Bill Nottingham 2005-11-08 21:36:31 UTC
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?

Comment 10 Daniel 2005-11-08 21:49:17 UTC
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.


Comment 11 Bill Nottingham 2005-11-08 22:10:13 UTC
I'm confused - if it's in modprobe.conf, how is the network card not working?

Comment 12 Daniel 2005-11-08 22:31:27 UTC
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 ?


Comment 13 Bill Nottingham 2005-11-08 22:32:33 UTC
When it doesn't work, does it show up in lspci?

Comment 14 Daniel 2005-11-08 22:37:29 UTC
Yes, it does:
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)



Comment 15 Bill Nottingham 2005-11-08 22:52:30 UTC
Does the HWADDR in ifcfg-eth0 match the hwaddr of the card?

Comment 16 Daniel 2005-11-08 22:55:49 UTC
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.


Comment 17 Daniel 2005-11-08 23:41:45 UTC
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 ?



Comment 18 Daniel 2005-11-09 13:46:24 UTC
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

Comment 19 Bill Nottingham 2005-11-09 18:21:53 UTC
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?

Comment 20 Daniel 2005-11-09 20:03:24 UTC
Created attachment 120853 [details]
/var/log/dmesg

Comment 21 Daniel 2005-11-09 20:04:33 UTC
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.



Comment 22 Bill Nottingham 2005-11-09 20:21:44 UTC
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.

Comment 23 Daniel 2005-11-09 20:52:09 UTC
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 ?



Comment 24 Bill Nottingham 2005-11-09 21:12:44 UTC
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?

Comment 25 Daniel 2005-11-09 21:15:38 UTC
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

Comment 26 Bill Nottingham 2005-11-09 21:17:10 UTC
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.

Comment 27 Daniel 2005-11-09 21:24:39 UTC
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 ?


Comment 28 Bill Nottingham 2005-11-09 21:33:07 UTC
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.

Comment 29 Daniel 2005-11-09 21:38:03 UTC
Ok, thank you for all this information very useful, and all your work to help 
me!

Best wishes,
Daniel



Note You need to log in before you can comment on or make changes to this bug.