* Note * In a previous post I said I wanted to do more to be involved with the Linux community. I work (as well as play) in the various distributions so tips and tricks are important to me. I thought I would pass along another tip I had written for another board as I continue to grow here at Linux.com. Hope it helps if anyone has run or does run into this little issue….
A little background…this was specifically handled on SUSE/SLES (SUSE Linux Enterprise Server). Some commands may differ on other distros but the principles are the same.
– – – – –
Attention…this is a tip, and only a tip. Had this been a real article it would be filled with lots of additional verbage and fancy graphics. However since this is only a tip I’ll do my best to keep it short and sweet…dishing out only the meat and potatoes.
This tip is about a little known boot option you can pass to the kernel when dealing with hardware. Most folks are used to passing values such as “noapci or acpi=off” to control power management, or utilizing “insmod” to preload specific drivers and pass options to the kernel at boot.
Every now and then as an engineer or administrator...or even a user…you come across a piece of hardware that is cantankerous or moody and does not initialize correctly. Perhaps it is feeding back bogus information to the kernel interrupting your boot process? Or, perhaps you have the operational need to skip that piece of hardware during the boot process altogether?
By using elements of the command hwinfo you can control the way the kernel probes and uses hardware when bootstrapping itself.
Quick overview of the hwinfo command…from the man pages:
hwinfo is used to probe for the hardware present in the system. It can be used to generate a system overview log which can be later used for support.
I actually use hwinfo quite a bit. The amount of detail it has in its output is significant. Even more so, you can break it down into sections; meaning if you were just interested in your storage controllers and devices you can issue hwinfo –storage or say for network devices hwinfo –network. An example of the type of information that is reported can be seen here:
hwinfo --storage
55: PCI d00.1: 0c04 Fibre Channel
[Created at pci.312]
UDI: /org/freedesktop/Hal/devices/pci_10df_fe00
Unique ID: Wnna.s9DjCGI6b+3
Parent ID: H0_h.260ECCsJIMD
SysFS ID: /devices/pci0000:00/0000:00:06.0/0000:0d:00.1
SysFS BusID: 0000:0d:00.1
Hardware Class: storage
Model: "Hewlett-Packard Company Zephyr-X LightPulse Fibre Channel Host Adapter"
Vendor: pci 0x10df "Emulex Corporation"
Device: pci 0xfe00 "Zephyr-X LightPulse Fibre Channel Host Adapter"
SubVendor: pci 0x103c "Hewlett-Packard Company"
SubDevice: pci 0x1708
Revision: 0x02
Driver: "lpfc"
Memory Range: 0xfded0000-0xfded0fff (rw,non-prefetchable)
Memory Range: 0xfdec0000-0xfdec00ff (rw,non-prefetchable)
I/O Ports: 0x5400-0x54ff (rw)
Memory Range: 0xd4240000-0xd427ffff (ro,prefetchable,disabled)
IRQ: 138 (1 event)
Module Alias: "pci:v000010DFd0000FE00sv0000103Csd00001708bc0Csc04i00"
Driver Info #0:
Driver Status: lpfc is active
Driver Activation Cmd: "modprobe lpfc"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #16 (PCI bridge)
You can quickly see the type of classification, model, vendor, device location, module driver and whether it is active. Invaluable information can be garnered from this. How many times have you been to a site to get a driver and suddenly you are not sure what model of card you have, hwinfo will probe and get you that information. Now, onto the boot options. Using a feature of hwinfo we can control probing at boot. You do so with the command hwprobe. This controls environmental variables. You can tell the kernel to add or remove hardware from probing results or even tell the kernel to use a specific X11set up. The syntax is as follows:
hwprobe=[+-]::[:]
The quick rundown is as follows:
“hwprobe=” flags the kernel to know she’ll have to do some hardware work here.
“+-” tells the kernel to add (+) or remove (-) hardware from the probing.
” ” are the identifying elements of the piece of hardware you wish to add or remove. You can consider it similar to your first, middle and last name.
“” is an optional parameter (to be fair I have never used this piece).
In the encounters I have used hwprobe I have been more interested in removing hardware. An example I have here is the fibre channel card. During some imaging sessions the team discovered that the SAN attached servers were wanting to use the LUNs as their destination disks. A quick workaround was to remove the fibre channel cards from the boot probe. From the output of hwinfo –storage (see above) I found that the was 0c04 , the was 0x10df and the was 0xfe00. On the boot command line I entered:
hwprobe=-0c04:0x10df:0xfe00
That was it. I was off to the races. Upon boot the kernel did not probe the fibre channel hardware, the cards did not come active and I was able to image the box to the local storage. It should be noted that just like your name, you could work from first, middle, last and only hand off your middle and last if you so chose. Or you could give just your last name in a particular setting. hwprobe can do that as well. If you are not sure of one of the three ids you can substitute a wildcard. For instance let’s say you weren’t sure of the class or vendor and only knew the device_id. You would simply enter:
hwprobe=-*:*:0xfe00
It is a good hardware manipulation technique should you find yourself in a hardware based situation. Believe it or not there is a small bit of documentation included on your SUSE box should you want to explore hwprobe a bit more in depth. It is located at: /usr/share/doc/packages/hwinfo/README. And remember…this is Linux country, on a quiet night you can hear Windows reboot.
