BIOSDEVNAME(1)

πŸ“¦
version 0.7.3.7.g495ab76 Β· 2 versions
, in centos-stream 10, opensuse-leap 16.0

πŸ’… 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 are physical or all_ethN
  • -P, --prefix [string] β€” the string used for embedded NICs in the physical policy. default is em ✨
  • -x, --nopirq β€” do NOT use the $PIR table 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 version x.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 0 on success, with the BIOS-suggested name printed to stdout 🌈
  • returns 1 on provided device name lookup failure πŸ™ˆ
  • returns 2 if system BIOS does not provide naming information. biosdevname requires system BIOS to provide naming information, either via SMBIOS or sysfs files
  • returns 3 if not run as root but requires root privileges πŸ‘‘
  • returns 4 if 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

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