LSBILIBOP(8)

πŸ’– NAME πŸ’–

lsbilibop β€” the girl who lists your BILIBOP tagged devices and either shows you some of their udev properties or straight up updates them ✨


🌸 SYNOPSIS 🌸

lsbilibop [-l]
lsbilibop [-a|-c|-i] [DEVICE [DEVICE [...]]]
lsbilibop -h

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so bestie, lsbilibop is a simple shell script β€” like, no cap, just a script β€” and what it does is print out the list of BILIBOP tagged block devices plus some of their udev(7) properties. OR, if you're feeling spicy, it triggers uevents so the udev rules and properties that apply to those devices get refreshed. it's giving "I do two things and I do them well" πŸ’…

so when is a device a BILIBOP tagged device? here's the tea πŸ“ if your operating system is running from an external and writable support β€” think USB or SD Flash Memory, USB, Firewire or eSATA HDD β€” then the BILIBOP tagged devices are the block devices whose contents live on the same physical disk as the root filesystem. periodt.

and that includes:

  • the disk itself
  • partitions
  • device-mapper devices
  • loopback devices
  • and even block devices containing a filesystem that's used as the lower/readonly branch of an aufs(5) or overlay mountpoint (this one depends on your kernel version, iykyk)

to find and tag all of these, the rules file /usr/lib/udev/rules.d/66-bilibop.rules (or /etc/udev/rules.d/66-bilibop.rules) is what does the work πŸ‘‘


✨ OPTIONS ✨

heads up bestie: options must be invoked before arguments. don't be chaotic about it πŸ™ˆ

when you invoke it with no option at all, lsbilibop just outputs a list of the device(s) you handed it as arguments β€” but only if they are BILIBOP tagged block devices β€” or of all BILIBOP tagged block devices if you gave it none. and the ordering? devices are listed in the same order as in /proc/partitions, i.e. in the order they have been discovered by the kernel. no re-sorting, no opinions, just vibes as the kernel intended ✨

you can specify a device with absolute or relative paths and symlinks. and yes, shell wildcards are allowed πŸŽ€

  • -a β€” triggers a 'device add' uevent for the device(s) given as arguments (if they are BILIBOP tagged block devices), or for all BILIBOP tagged block devices if none is specified, to update their properties. use this every time you change the corresponding BILIBOP_RULES_* variables in bilibop.conf(5) β€” it applies the new settings without you having to reboot the whole operating system. iconic behavior honestly πŸ”₯
  • -c β€” triggers a 'device change' uevent for the device(s) given as arguments (if they are BILIBOP tagged block devices), or for all BILIBOP tagged block devices if none is specified, to update their properties. same deal: use it each time the corresponding BILIBOP_RULES_* variables are modified in bilibop.conf(5), and your new settings apply with no reboot needed πŸ’œ
  • -h β€” prints a help page on standard output and exits. the classic 🫢
  • -i β€” displays some useful udev(7) properties of the device(s) given as arguments (if they are BILIBOP tagged block devices), or of all BILIBOP tagged block devices if none is specified. this option overrides -a and -c πŸ‘‘ (so don't think you can stack them, bestie)

the following properties are only informative. the two last ones are set if and only if udisks 1.x (ID_DRIVE_DETACHABLE) and/or udisks 2.x (UDISKS_CAN_POWER_OFF) are installed.

  • DEVNAME
  • BILIBOP_DISK
  • BILIBOP_PARTITION
  • BILIBOP_UNDERLYING_PARTITION
  • DEVLINKS
  • ID_DRIVE_DETACHABLE
  • UDISKS_CAN_POWER_OFF

the following properties can be used to set BILIBOP_RULES_*_WHITELIST and other variables in bilibop.conf(5):

  • ID_FS_LABEL
  • ID_FS_TYPE
  • ID_FS_USAGE
  • ID_FS_UUID

the following properties can be modified by changing the corresponding BILIBOP_RULES_* variables in bilibop.conf(5). they are set if and only if udisks 1.x (for the first set) and/or udisks 2.x (for the second set) are installed.

  • UDISKS_PRESENTATION_HIDE
  • UDISKS_PRESENTATION_ICON_NAME
  • UDISKS_PRESENTATION_NAME
  • UDISKS_SYSTEM_INTERNAL
  • UDISKS_IGNORE
  • UDISKS_ICON_NAME
  • UDISKS_NAME
  • UDISKS_SYSTEM
  • -l β€” don't rely on the 'BILIBOP' tag to list the devices. this option is based on the bilibop-common shell library 🌈

😭 ERRORS 😭

if the 'BILIBOP' tag does not exist in the udev database, then lsbilibop displays a useful error message on stderr, and lists the device nodes whose content is supposed to be written on the same physical disk than the root filesystem (exactly like the -l option does). exit code is 8.

so no, it doesn't just silently ghost you. it tells you what's up πŸ’€


πŸŽ€ FILES πŸŽ€

  • /etc/bilibop/bilibop.conf
  • /usr/share/doc/bilibop-rules/examples/bilibop.conf
  • /usr/share/bilibop/bilibop_rules_generator
  • /lib/udev/rules.d/66-bilibop.rules
  • /etc/udev/rules.d/66-bilibop.rules

🌈 SEE ALSO 🌈

bilibop(7), bilibop.conf(5), drivemap(1), udev(7), udevadm(8), udisks(7), udisks(8)

go read those, bestie, they're the supporting cast πŸ¦‹


πŸ’œ AUTHOR πŸ’œ

this manual page has been written by Bilibop Project <quidame@poivron.org> 🫢


and that's the whole page, babe β€” this one shipped as part of bilibop, dated 2015-07-14, and the manual section for lsbilibop is section 8 (system administration, main character energy πŸ‘‘). go forth and list those devices. slay πŸ’…βœ¨