Como ignorar a atribuição de / dev / cdrom a um dispositivo específico?

1

Eu tenho um pen drive HDSPA da Vodafone para banda larga móvel, um HUAWEI model K3520 (em alguns lugares também designados E169 eu acho) que funciona muito bem no Ubuntu 10.04 "Lucid" ( amd64 ). Este dispositivo é automaticamente montado como um dispositivo de CD-ROM pelo Ubuntu - supostamente pelo daemon HAL, hald - ou seja, a "partição" contendo o software específico do dispositivo.

O conteúdo da partição montada automaticamente (ao inserir o bastão em uma porta USB):

ubuntu@lucid:~$ ls -lh /media/VMC\ LITE*/
total 37M
-r-------- 1 ubuntu ubuntu   70 2008-03-13 19:39 Autorun.inf
-r-------- 1 ubuntu ubuntu  36M 2008-04-14 19:28 helper.exe
-r-------- 1 ubuntu ubuntu 316K 2008-03-13 17:33 setup.exe
ubuntu@lucid:~$ 

O link simbólico /dev/cdrom é atribuído a partir do dispositivo de CD-ROM em /dev/sr0 para o dispositivo /dev/sr1 após a detecção do pendrive,

ubuntu@lucid:~$ ls -lh /dev/cdrom
lrwxrwxrwx 1 root root 3 2011-04-27 22:48 /dev/cdrom -> sr1
ubuntu@lucid:~$ ls -lh /dev/sr*
brw-rw----+ 1 root cdrom 11, 0 2011-04-27 22:34 /dev/sr0
brw-rw----+ 1 root cdrom 11, 1 2011-04-27 22:48 /dev/sr1
ubuntu@lucid:~$ 

que embora não seja um impedimento sério, no entanto, é um aborrecimento. Por exemplo, no console isso força a especificação de eject -d /dev/sr0 para abrir a bandeja do CD-ROM, em vez de um simples eject ; supostamente, outros programas que desejam usar a unidade de CD-ROM original exigirão a especificação explícita do dispositivo, em vez de "assumir" que o link simbólico /dev/cdrom aponte para o dispositivo "correto".

Eu tentei seguir as instruções de um thread do Arch Linux sobre hald , criando minha própria configuração como /etc/hal/fdi/policy/cdrom.fdi com o seguinte conteúdo:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="block.storage_device" string="/org/freedesktop/Hal/devices/storage_model_CDDVDW_SH_S223C">
      <merge key="volume.policy.should_mount" type="bool">true</merge>
      <merge key="volume.policy.desired_mount_point" type="string">cdrom</merge>
    </match>
  </device>
  <device>
    <match key="storage.vendor" string="HUAWEI">
      <match key="storage.model" string="Mass Storage">
        <match key="storage.bus" string="usb">
          <match key="storage.drive_type" string="cdrom">
            <merge key="volume.policy.should_mount" type="bool">false</merge>
          </match>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

em uma tentativa mal-sucedida de "coerência" hald para sempre atribuir /dev/sr0 a /dev/cdrom em vez de montar automaticamente o pen drive USB na inserção.

Eu percebi que eu poderia usar gconf-editor para alternar a chave /apps/nautilus/preferences/media_automount , mas isso afetaria a mídia all - que não é bem o que eu estou procurando, embora dada a baixa impacto deste "aborrecimento" pode ser um compromisso aceitável.

No entanto, estou vendo algumas informações sobre a configuração do hald pode gerar os resultados desejados - ignorando a atribuição de /dev/sr1 (o pendrive) a /dev/cdrom e mantendo assim o link simbólico de /dev/cdrom to /dev/sr0 (a unidade de CD-ROM).

    
por jbatista 28.04.2011 / 00:21

2 respostas

1

A nomenclatura dos dispositivos de cdrom é configurada em /etc/udev/rules.d/70-persistent-cd.rules. Na minha versão do arquivo existem quatro linhas que criam o cdrom, cdrw, dvd e dvdrw links simbólicos, todos apontando para a mesma unidade:

SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"

O que essas linhas fazem? Eles testam algumas coisas com o operador == e então eles adicionam ( += ) um symlink ou set ( = ) a variável de ambiente GENERATED.

Você deseja inserir um novo teste lá, para que seu dispositivo HSDPA seja ignorado.

Você precisa encontrar um atributo exclusivo do seu dispositivo. Você pode correr lsusb no terminal e veja se você encontrar o seu HSDPA lá. E você também pode perguntar ao próprio udev, por ex. com

udevadm info --export-db | less

(Em "less" você pode pesquisar com a tecla / e sair com q.) Tente encontrar um atributo exclusivo, como ID_SERIAL, ID_VENDOR_ID ou ID_MODEL_ID. Os números hexadecimais em ID_VENDOR_ID e ID_MODEL_ID são os mesmos números da saída de lsusb .

Se você encontrou algo único, insira um novo teste nas linhas do udev, comparando a desigualdade com o operador != :

SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_SERIAL}!="_USB_DISK_Pro_075A06420103-0:1", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"

Salve o arquivo, ejete o pendrive, conecte-o novamente e espere que ele esteja funcionando.

    
por elmicha 10.05.2011 / 19:59
0

Isso tem algo a ver com a criação de algumas regras do udev para o seu dispositivo. Não sou especialista no assunto, mas você pode querer pesquisar sobre esses links:

Isso é tudo que sei. Espero que ajude.

    
por Noe Nieto 08.05.2011 / 08:09