Archive

Manually mount a removable media under Solaris 10

This morning I had to install some SUNW packages in a remote Solaris 10 x86 system (a Sun Fire X4150). I had the packages in the installation DVD, so I tried to map the DVD as a virtual device using the SUN embedded Light Out Manager console (sun-elom).

Apparently the thing was working. When I mapped the DVD I head the DVD started to spin, but I couldn’t see the DVD mounted into the system: it should appear under /rmdisk (removable disk), but it didn’t.

I first ran volcheck -v, and then rmformat:

# volcheck -v
media was found

# rmformat
Looking for devices...
     1. Volmgt Node: /vol/dev/aliases/cdrom0
        Logical Node: /dev/rdsk/c1t0d0s2
        Physical Node: /pci@0,0/pci108e,4843@1d,7/storage@1/disk@0,0
        Connected Device: TSSTcorp CD/DVDW TS-T632A SR03
        Device Type: DVD Reader/Writer

     2. Volmgt Node: /vol/dev/aliases/rmdisk0
        Logical Node: /dev/rdsk/c3t0d0p0
        Physical Node: /pci@0,0/pci108e,4843@1d,7/storage@5/disk@0,0
        Connected Device: manufact product          1234
        Device Type: Removable

# ls -al /vol/dev/aliases/rmdisk0
lrwxrwxrwx   1 root     root          35 Apr 30 12:15 /vol/dev/aliases/rmdisk0 -> /vol/dev/rdsk/c3t0d0/unknown_format

So the removable DVD is rmdisk0, and its device file is /dev/rdsk/c3t0d0p0. Unfortunately (I don’t know why — using PCA I looked for a patch that could solve this, but didn’t see any), it seems that volfs couldn’t recognize the DVD format (unknown_format), so it didn’t mount it automatically.

I then tried to force volfs to mount it, using volrmmount, but it didn’t mount anything:

# volrmmount -i rmdisk0

I finally had to mount the device manually. To do this, first i had to disable volfs:

# svcadm disable -st volfs

I then checked the filesystem type of the virtual device (to also be sure that the system was actually seeing it correctly). To do that, I used the command fstyp and the device file returned by rmformat:

# fstyp -v /dev/dsk/c3t0d0p0
hsfs
CD-ROM is in ISO 9660 format
System id: Solaris
Volume id: OpenSolaris
Volume set id:
Publisher id:
Data preparer id:
Application id: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER & CDRECORD CD-R/DVD CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is 1
Volume set sequence number is 1
Logical block size is 2048
Volume size is 330857

The system could actually see the device, which filesystem is a hsfs. Knowing that, I could easily mount the device:

# mount -F hsfs /dev/dsk/c3t0d0p0 /mnt
# ls  /mnt
LICENSE            devices            reconfigure        solarismisc.zlib
archive.bz2        jack               release_notes.txt  system
bin                mnt                root               tmp
boot               platform           sbin
dev                proc               solaris.zlib

Once I had finished with the virtual device, I just had to unmount it and restart volfs:

# umount /mnt
# svcadm enable -s volfs

Fin de mi CPD

El fin de semana pasado he “desmantelado” mi “CPD” y he subido mis maquinas a la buhardilla. Ya vere lo que hago con ellas. Solo he dejado mi servidor (que alberga entre otras cosas esta web, el uTorrent bajo Wine, el servidor de ficheros y el drive DDS3 para backups) — ahora esta debajo de la cama de invitados ;-).

¿Google de pago?

Durante toda la mañana de ayer estuve (practicamente) sin poder usar Google. Al abrir Google me salia la pagina de siempre, pero cualquier busqueda que hacia me llevaba a una pagina que decia “We’re sorry…”, explicando que Google estaba recibidendo muchas consultas que se parecian a consultas emitidas por un virus o un spyware. Tras introducir el captcha (lo cierto es que a veces ni podia entenderlo de lo dificil que lo ponian), me daba las respuestas a mis consultas. Lo que pasa es que no siempre me permitia meter el captcha. A veces solo lo sentia, diciendome que buscara si tenia virus/spyware, o alguien de mi red.

Aqui tenemos mas informacion:

The CAPTCHA page you’re referring to is served by Google when we experience a quick spike in traffic on Google.com. A CAPTCHA image helps us determine whether traffic is coming from automated robot software or individual users. Please be aware that your network is receiving this page because our system is detecting automated querying coming from your network’s IP address.

Lo cierto es que estar sin google toda la mañana fue una experiencia dura. Cambie el buscador por defecto de mi Firefox a Yahoo!, pero tenia la impresion de no encontrar nada de lo que buscaba.

A raiz de esto se me occurrio una idea: Google podria cobrar por el uso corporativo/masivo de su buscador. Por ejemplo:

  • por encima de 500 consultas al dia (digo 500 por definir un umbral razonable), que sea de pago: x€ por consulta, bonos de consultas, tarifa plana por volumen de consultas,…),
  • por debajo del umbral, gratias (para familias). Supongo que la gente de Google ya lo habran pensado y que por alguna razon no lo querran hacer (¿todavia?).

apt-get error: public key not available

Este fin de semana me paso el siguiente error tras añadir una linea en el /etc/apt/sources.list:

# apt-get update
[...]
Reading package lists... Done
W: GPG error: http://www.virtualbox.org etch Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 390EC3FF927CCC73
W: You may want to run apt-get update to correct these problems

Tras buscar un poco por google, encontre como solucionar el error, importando la clave publica que faltaba, de la siguiente manera:

# gpg --keyserver hkp://subkeys.pgp.net --recv-keys 390EC3FF927CCC73
gpg: directory `/root/.gnupg' created
gpg: can't open `/gnupg/options.skel': No such file or directory
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: requesting key 927CCC73 from hkp server subkeys.pgp.net
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 927CCC73: public key "innotek GmbH (archive signing key) " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
# gpg --export --armor 390EC3FF927CCC73 | apt-key add -
OK

Podemos verificar que la clave se ha importado con:

# apt-key list
/etc/apt/trusted.gpg
--------------------
[...]
pub   1024D/927CCC73 2007-06-04
uid                  innotek GmbH (archive signing key) 
sub   2048g/F0C31E29 2007-06-04

Mirror de un lvol en LVM de Linux

Para quien venga de HP-UX, resulta facil mirrorear un lvol bajo LVM: con un lvextend -m. En Linux, el lvextend -m simplemente no funciona…

De hecho el comando lvcreate si tiene una opcion -m, y esa si que funciona (lo he probado)! Pero con el lvextend no la coje.

Me he bajado las fuentes de lvm2. En commands.h he descubierto el comando lvconvert que no conocia:

alegrome# lvconvert
  Exactly one of --mirrors or --snapshot arguments required.
  lvconvert: Change logical volume layout

lvconvert [-m|--mirrors Mirrors [--corelog]]
        [--alloc AllocationPolicy]
        [-d|--debug]
        [-h|-?|--help]
        [-v|--verbose]
        [--version]
        LogicalVolume[Path] [PhysicalVolume[Path]...]

lvconvert [-s|--snapshot]
        [-c|--chunksize]
        [-d|--debug]
        [-h|-?|--help]
        [-v|--verbose]
        [-Z|--zero {y|n}]
        [--version]
        OriginalLogicalVolume[Path] SnapshotLogicalVolume[Path]

Este comando si que parece funcionar. Probemos a mirrorear un lvol:

# lvconvert -m 1 /dev/vg02/lvweb
  Logical volume lvweb converted.

Miremos con un lvdisplay lo que nos ha hecho el comando:

alegrome# lvdisplay -m lvweb
  --- Logical volume ---
  LV Name                /dev/vg02/lvweb
  VG Name                vg02
  LV UUID                9I4wK7-2hn7-j4dI-o5yT-ngYx-8Wtd-m3no6q
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                200.00 MB
  Current LE             50
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:6

  --- Segments ---
  Logical extent 0 to 49:
    Type                mirror
    Mirrors             2
    Mirror size         50
    Mirror log volume   lvweb_mlog
    Mirror region size  512.00 KB
    Mirror original:
      Logical volume    lvweb_mimage_0
      Logical extents   0 to 49
    Mirror destinations:
      Logical volume    lvweb_mimage_1
      Logical extents   0 to 49

A notar ahi: Type = mirror.

Como se puede ver, el lvweb ahora si esta en mirror. La verdad es que no he visto esto documentado en ningun sitio (¿alguien ha visto mas sobre esto?).

Para quitar el mirror (reducir), se haria asi:

# lvconvert -m 0 /dev/vg02/lvweb
  Logical volume lvweb converted.

# lvdisplay -m lvweb
  --- Logical volume ---
  LV Name                /dev/vg02/lvweb
  VG Name                vg02
  LV UUID                9I4wK7-2hn7-j4dI-o5yT-ngYx-8Wtd-m3no6q
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                200.00 MB
  Current LE             50
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:6

  --- Segments ---
  Logical extent 0 to 49:
    Type                linear
    Physical volume     /dev/hdh4
    Physical extents    18370 to 18419

Con lvs vemos el estado del mirrorring

alegrome# lvs lvweb
  LV     VG   Attr   LSize Origin Snap%  Move Log         Copy%
  lvweb  vg02 mwi-ao 200M                    lvweb_mlog   12.22

En Attr, la “m” es de mirror.

Este post viene originado por un comentario de Rubik a un post de Ivan sobre “Crear un raid 1 a partir de un disco con datos sin formatear“.. Gracias a ambos.




Close
Powered by ShareThis