Little Known Kernel Boot Options - Hardware Manipulation | SUSE Communities

Little Known Kernel Boot Options – Hardware Manipulation


Attention…this is a tip, and only a tip. Had this been a real AppNote or 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 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 harddware from probing results or even tell the kernel to use a specific X11 set up. The syntax is as follows:



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.

"<device_class> <vendor_id> <device_id>"  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.

"<unix_device_file>"  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 <device_class> was 0c04 , the <vendor_id> was 0x10df and the <device_id> was 0xfe00. On the boot command line I entered:



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:



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.

(Visited 1 times, 1 visits today)


  • Anonymous says:

    I am running Suse 11.0 on a Compaq laptop, and was trying to get wifi to work. After several OS reinstalls and close calls, I gave up. That is, until today. After reading a blog I tried something that did not work and it hosed up my operating system again. It is a software setting I assigned in KNetwork Manager related to ath5k. Now I get a kernel panic every time I try to load a module associated with IRQ 23.(I have done this in the past and had to reinstall the OS, but there has to be an easier way to fix dynamic kernel driver issues). Is there anyway, using GRUB or via USB/CD, to prevent hardware probing on boot for IRQ 23 (or GSI 23, Link[Z012], ath5k_pci, 0000:07:00.0 registed as ‘phy0’)? I have tried to boot failsafe and Xen, but no luck. I also tried to repair/rescue system but no errors were found. Any help would be greatly appreciated.

    –Westly Schmidt

  • Leave a Reply

    Your email address will not be published.