BIOSDEVNAME(1)
π BIOSDEVNAME(1) β bestie edition
okay so this is a page from the General Commands Manual, and it's about a lil tool called biosdevname. buckle up, it's actually iconic π«Ά
β¨ NAME β¨
biosdevname β gives you the BIOS-given name of a device, no cap
πΈ SYNOPSIS πΈ
biosdevname [options] [args]...
π¦ DESCRIPTION π¦
so the way this works is literally so simple: biosdevname takes a kernel device name as an argument, and hands you back the BIOS-given name it "should" be. that's it. that's the whole vibe check π
the quotes around "should" are doing a lot of heavy lifting here, bestie. that's the original's energy, not mine.
π OPTIONS π
-i,--interfaceβ treat[args]as ethernet devs π§-d,--debugβ turn on debugging, we love a paper trail-p,--policy [physical|all_ethN]β pick your policy, options arephysicalorall_ethN-P,--prefix [string]β thestringused for embedded NICs in the physical policy. default isemβ¨-x,--nopirqβ do NOT use the$PIRtable for mapping PCI device to slot. some BIOS have incorrect values, so yeah, this is the "my BIOS is lying to me" escape hatch π-s,--smbios [x.y]β require a minimum SMBIOS versionx.y, no old BIOS energy allowed
π POLICIES π
the physical policy is the current default, but here's the tea: when you're invoking biosdevname in udev rules, you should always specify the policy you want, because the default has changed over time. do not rely on the default, bestie, it will betray you π
the physical policy uses this scheme:
em<port>[_<virtual instance>]
for embedded NICs, and:
p<slot>p<port>[_<virtual instance>]
for cards in PCI slots π
now the all_ethN policy β it makes a best guess at what the device order should be, with embedded devices first, PCI cards in ascending slot order, and ports in ascending PCI bus/device/function order breadth-first. honestly? ambitious.
π¨ but β this policy does not work if your PCI devices are hot-plugged or hot-pluggable, including the virtual functions on an SR-IOV device. in a hot-plug scenario, each separate udev instance gets invoked in parallel while the device tree is still being populated with new devices. each udev instance sees a different PCI tree, and thus cannot provide consistent enumeration. so keep this policy limited to only scenarios where all PCI devices are present at boot (cold-plug). periodt.
β EXIT CODES β
- returns
0on success, with the BIOS-suggested name printed to stdout π - returns
1on provided device name lookup failure π - returns
2if system BIOS does not provide naming information.biosdevnamerequires system BIOS to provide naming information, either via SMBIOS or sysfs files - returns
3if not run as root but requires root privileges π - returns
4if running in a virtual machine π₯οΈ
π SEE ALSO π
http://linux.dell.com/wiki/index.php/Oss/libnetdevname
http://linux.dell.com/files/biosdevname/
git://linux.dell.com/biosdevname.git
π₯ RELATED PROGRAMS π₯
the dmidecode package contains two tools that are genuinely so useful for debugging BIOS features that biosdevname uses β specifically dmidecode to read the SMBIOS Type 9 and Type 41 tables, and biosdecode to read the PCI IRQ Routing Table. please, please include the output of each of these programs in any bug reports π«Ά it's giving "help me help you".
πΈ AUTHOR πΈ
biosdevname was written by Matt Domsch <Matt_Domsch@dell.com> π
this manual page was written by Rudy Gevaert <Rudy.Gevaert@UGent.be>, for the Debian project (but may be used by others) π
okay that's the whole page!! it came from the General Commands Manual and it's dated Nov 28, 2010 β yes she's an elder millennial, we still stan her π β¨ π¦
π¦ where this page comes from
- centos-stream 10: biosdevname 0.7.3-19.el10 Β· GPL-2.0-only AND GPL-2.0-or-later
- opensuse-leap 16.0: biosdevname 0.7.3.7.g495ab76-160000.2.2 Β· GPL-2.0-only
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms