Apesar da maioria dos dispositivos necessitados pelos pacotes no BLFS
        e além serem configurados adequadamente pelo udev usando as regras padrão instaladas pelo LFS
        em /etc/udev/rules.d, existem casos
        onde as regras precisam ser modificadas ou estendidas.
      
Observações de Usuário(a): https://wiki.linuxfromscratch.org/blfs/wiki/aboutdevices
          Se existirem múltiplas placas de som em um sistema, [então] a placa
          de som "padrão" se torna aleatória. O método para estabelecer a
          ordem da placa de som depende se os controladores são módulos ou
          não. Se os controladores da placa de som forem compilados
          internamente no núcleo, [então] o controle é via parâmetros de
          linha de comando do núcleo em /boot/grub/grub.cfg. Por exemplo, se um sistema
          tiver ambas, uma placa FM801 e uma placa PCI SoundBlaster, [então]
          o seguinte pode ser acrescentado à linha de comando:
        
snd-fm801.index=0 snd-ens1371.index=1
        
          Se os controladores da placa de som forem construídos como módulos,
          [então] a ordem pode ser estabelecida no arquivo /etc/modprobe.conf com:
        
options snd-fm801 index=0
options snd-ens1371 index=1
      Os dispositivos USB geralmente tem dois tipos de nós de dispositivo associados com eles.
O primeiro tipo é criado pelos controladores específicos do dispositivo (por exemplo, usb_storage/sd_mod ou usblp) no núcleo. Por exemplo, um dispositivo USB de armazenamento em massa seria /dev/sdb; e uma impressora USB seria /dev/usb/lp0. Esses nós de dispositivo existem somente quando o controlador específico do dispositivo estiver carregado.
O segundo tipo de nós de dispositivo (/dev/bus/usb/BBB/DDD, onde BBB é o número do barramento e DDD é o número do dispositivo) é criado mesmo se o dispositivo não tiver um controlador de núcleo. Ao usar esses nós de dispositivo USB "crus", um aplicativo consegue trocar pacotes USB arbitrários com o dispositivo, isto é, contornar o possivelmente existente controlador de núcleo.
O acesso a nós de dispositivo USB crus é necessário quando um aplicativo do espaço do(a) usuário(a) estiver atuando como um controlador de dispositivo. Entretanto, para o aplicativo abrir o dispositivo com sucesso, as permissões tem de ser configuradas corretamente. Por padrão, devido a motivos de segurança, todos os dispositivos USB crus são de propriedade do(a) usuário(a) root e do grupo usb; e tem permissões 0664 (o acesso de leitura é necessário, por exemplo, para o lsusb funcionar e para os aplicativos acessarem hubs USB). Os pacotes (tais como SANE e libgphoto2) contendo controladores de dispositivo USB do espaço do(a) usuário(a) também embarcam regras do udev que mudam as permissões dos dispositivos USB crus controlados. Isto é, as regras instaladas pelo SANE mudam as permissões para escaneadores conhecidos, porém não para impressoras. Se um(a) mantenedor(a) de pacote se esqueceu de escrever uma regra para o seu dispositivo, [então] informe um defeito para ambos, o BLFS (se o pacote estiver lá) e o(a) desenvolvedor(a), e você precisará escrever sua própria regra.
Existe uma situação quando tal controle de acesso refinado com regras do udev pré-geradas não funciona. Nomeadamente, os emuladores de PC, tais como o KVM; o QEMU; e o VirtualBox, usam nós de dispositivo USB crus para apresentar dispositivos USB arbitrários para o sistema operacional convidado (observação: remendos são necessários para a finalidade de fazer com que isso funcione sem o obsoleto ponto de montagem /proc/bus/usb descrito abaixo). Obviamente, os(as) mantenedores(as) desses pacotes não podem saber quais dispositivos USB serão conectados ao sistema operacional convidado. Você pode, ou escrever você mesmo(a) regras do udev separadas para todos os dispositivos USB necessários; ou usar o grupo padrão abrangente "usb", membros do qual podem enviar comandos arbitrários para todos os dispositivos USB.
Antes do Linux-2.6.15, o acesso de dispositivo USB cru era realizado não com nós de dispositivo /dev/bus/usb/BBB/DDD, porém com pseudo arquivos /proc/bus/usb/BBB/DDD. Alguns aplicativos (por exemplo, o VMware Workstation) ainda usam somente essa técnica obsoleta e não conseguem usar os novos nós de dispositivo. Para eles funcionarem, use o grupo "usb", porém lembre-se de que os(as) membros(as) terão acesso irrestrito a todos os dispositivos USB. Para criar a entrada fstab para o obsoleto sistema de arquivos usbfs:
usbfs  /proc/bus/usb  usbfs  devgid=14,devmode=0660  0  0
        
          Adicionar usuários(as) ao grupo "usb" é inerentemente inseguro, já que eles(as) conseguem contornar as restrições de acesso impostas por intermédio dos nós de dispositivo USB específicos do controlador. Por exemplo, eles(as) conseguem ler dados sensíveis a partir de unidades rígidas USB sem estarem no grupo "disk". Evite adicionar usuários(as) a esse grupo, se puder.
          O ajuste fino dos atributos de dispositivo, tais como nome e
          permissões do grupo, é possível criando-se regras extras do
          udev, casando com algo como isto.
          O fornecedor e produto pode ser encontrado procurando-se nas
          entradas do diretório /sys/devices ou
          usando-se o udevadm
          info depois que o dispositivo tenha sido anexado.
          Veja-se a documentação no diretório atual do udev do /usr/share/doc para detalhes.
        
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="05d8", SYSFS{idProduct}=="4002", \
  GROUP:="scanner", MODE:="0660"
        
          A linha acima é usada somente para propósitos descritivos. As regras do udev da escaneadora são colocadas no lugar quando se instalar o SANE-1.0.32.
Em alguns casos, faz sentido desabilitar o udev completamente e criar dispositivos estáticos. Servidores são um exemplo dessa situação. Um servidor precisa da capacidade de manusear dispositivos dinâmicos? Somente o(a) administrador(a) do sistema pode responder a essa pergunta, porém, em muitos casos, a resposta será não.
          Se dispositivos dinâmicos não forem desejados, então dispositivos
          estáticos precisam ser criados no sistema. Na configuração padrão,
          o script de inicialização /etc/rc.d/rcS.d/S10udev monta uma partição
          tmpfs sobre o diretório
          /dev. Esse problema pode ser
          ultrapassado montando-se a partição raiz temporariamente:
        
          Se as instruções abaixo não forem seguidas cuidadosamente, [então] o seu sistema poderia se tornar não inicializável.
mount --bind / /mnt
cp -a /dev/* /mnt/dev
rm /etc/rc.d/rcS.d/{S10udev,S50udev_retry}
umount /mnt
        Neste ponto, o sistema usará dispositivos estáticos até a próxima reinicialização. Crie quaisquer dispositivos adicionais desejados usando o mknod.
          Se você quiser restaurar os dispositivos dinâmicos, [então] recrie
          os vínculos simbólicos /etc/rc.d/rcS.d/{S10udev,S50udev_retry} e
          reinicialize novamente. Dispositivos estáticos não precisam ser
          removidos (console e null sempre são necessários), pois eles são
          cobertos pela partição tmpfs. O uso
          do disco para dispositivos é desprezível (cerca de 20–30 bytes por
          entrada).
        
          Se o processo inicial da inicialização não configurar o dispositivo
          /dev/dvd adequadamente, [então] ele
          pode ser instalado usando-se a seguinte modificação para as regras
          padrão do udev. Como o(a) usuário(a) root, execute:
        
sed '1d;/SYMLINK.*cdrom/ a\
KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd", OPTIONS+="link_priority=-100"' \
/lib/udev/rules.d/60-cdrom_id.rules > /etc/udev/rules.d/60-cdrom_id.rules