Lo hice y lo entendí

El blog de Vicente Navarro
14 oct

Disk might not be spun down properly. Update shutdown utility.

Ahora mismo estoy usando el kernel 2.6.22.6 en todos mis sistemas Linux. En uno de ellos con discos SATA de vez en cuando, al ejecutar el comando halt, me aparece este error unas décimas de segundo antes de apagar:

DISK MIGHT NOT BE SPUN DOWN PROPERLY. UPDATE SHUTDOWN UTILITY
For more info, visit http://linux-ata.org/shutdown.html

Bueno, en realidad sé exactamente lo que pone porque lo he buscado en las fuentes del kernel, porque no da tiempo a leerlo entero, sino que más bien es un rápido flash del que únicamente se queda en la mente algo así como “el disco no se ha parado bien”. El mensaje lo podemos encontrar en drivers/ata/libata-scsi.c:

/* XXX: This is for backward compatibility, will be
 * removed.  Read Documentation/feature-removal-schedule.txt
 * for more info.
 */
if ((qc->dev->flags & ATA_DFLAG_SPUNDOWN) &&
    (system_state == SYSTEM_HALT ||
     system_state == SYSTEM_POWER_OFF)) {
        static unsigned long warned = 0;

        if (!test_and_set_bit(0, &warned)) {
                ata_dev_printk(qc->dev, KERN_WARNING,
                        "DISK MIGHT NOT BE SPUN DOWN PROPERLY. "
                        "UPDATE SHUTDOWN UTILITY\n");
                ata_dev_printk(qc->dev, KERN_WARNING,
                        "For more info, visit "
                        "http://linux-ata.org/shutdown.html\n");

Como el propio mensaje indica, tenemos que acudir a: Serial ATA (SATA) shutdown info, donde podremos obtener una explicación del problema.

Antes de apagar un disco duro, tenemos que guardar lo que contiene la caché y aparcar las cabezas de lectura/escritura para que no aterricen sobre la superficie magnética, lo que podría dañarla. Es raro que tal cosa ocurra, en cualquier caso, ya que si se apaga el sistema de golpe, la controladora del disco es capaz de aparcar la cabeza sin corriente externa para evitar problemas, pero no es aconsejable en absoluto hacerlo así. Puede hacer ruidos extraños y reducir la vida del disco.

En Linux, para hacer esto, tenemos los drivers IDE/ATA de toda la vida, los que en el “make menuconfig” encontramos en:

Device Drivers → ATA/ATAPI/MFM/RLL support (CONFIG_IDE)

Este driver, aunque funciona bien, tiene muchos hacks para permitir compatibilidad hacia atrás con viejos dispositivos. Así que cuando aparecieron los discos SATA, los desarrolladores decidieron partir con una implementación limpia del estándar ATA, en principio para acoger los drivers de SATA pero en la que también se van añadiendo drivers PATA. Ese driver, en el “make menuconfig” lo encontramos en:

Device Drivers → Serial ATA (prod) and Parallel ATA (experimental) drivers (CONFIG_ATA)

y la página del proyecto es, precisamente, linux-ata.org: Serial ATA (SATA) for Linux.

Este nuevo driver trata los discos SATA como si fueran discos SCSI, tal y como leemos en la descripción de estos drivers en la ayuda del kernel:

CONFIG_ATA:

If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or
any other ATA device under Linux, say Y and make sure that you know
the name of your ATA host adapter (the card inside your computer
that "speaks" the ATA protocol, also called ATA controller),
because you will be asked for it.

NOTE: ATA enables basic SCSI support; *however*,
'SCSI disk support', 'SCSI tape support', or
'SCSI CDROM support' may also be needed,
depending on your hardware configuration

Pues bien, en los drivers IDE de toda la vida se lanzaban los comandos FLUSH CACHE y STANDBYNOW antes de apagar el sistema. Sin embargo, el nuevo driver se basa en SCSI y en sistemas SCSI varios hosts pueden acceder a un mismo disco, por lo que aparcar sus cabezas antes de la parada del sistema puede molestar a otro host que aún esté usando ese disco. Por tanto, en el nuevo driver (<=2.6.21) el comando STANDBYNOW no es lanzado durante la parada.

El driver del kernel 2.6.22 se actualizó para que se lanzaran los comandos FLUSH CACHE y STANDBYNOW antes de: power off, suspend-to-ram y suspend-to-disk, pero desafortunadamente, la inmensa mayoría de implementaciones del comando shutdown de las diferentes distribuciones aún no son compatibles con este cambio.

Por ejemplo, hasta ahora, algunas implementaciones de shutdown lanzaban el comando STANDBYNOW explicítamente, sin cubrir casos como el sleep-to-disk.

Por tanto, la situación actual queda así:

  1. El shutdown lanza un FLUSH CACHE (no en todas las distribuciones)
  2. El shutdown lanza un STANDBYNOW y para el disco
  3. La parada del kernel comienza
  4. El driver SATA lanza un FLUSH CACHE
  5. El driver SATA lanza un STANDBYNOW (nuevo con el 2.6.22)

Primer problema: algunas distribuciones no guardan la caché del disco antes de pararlo. Segundo problema: los pasos 4 y 5 podrían arrancar de nuevo un disco ya parado.

En definitiva, es necesario actualizar el comando shutdown en todas las distribuciones, cosa que ninguna de ellas ha hecho aún.

En Debian hay un bug abierto para que modifiquen este problema: #426224 Please update shutdown to support libata drivers in newer kernels

En Ubuntu también hay un bug: #114683 New libata/scsi spindown functionality in 2.6.22 requires changes in userland shutdown(8), con interesante información en la discusión, que, curiosamente, ha sido cerrado como inválido porque “a Ubuntu no le afecta el problema” (¿no dicen los desarrolladores del driver SATA que ninguna distribución ha arreglado el problema aún?):

As discussed with the libata upstream, we don’t need to change our /sbin/reboot utility at all. The 2.6.22 kernel will notice that we have made no attempt to flush the caches or shutdown the disk, and will perform it for us.

Hace poco, también salió el tema en la bitácora del usuario chavi en Barrapunto: Aparcando el disco duro, que, entre otras cosas, nos indica que podemos encontrar los paquetes sysv-rc, sysvinit y sysvinit-utils que solucionan el problema en Debian entre los paquetes no oficiales de Roland Stigge.

:wq

10 oct

Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG

Al final de Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux, decíamos que la parte de los gráficos es la que más trabajo supone y que por eso lo dejábamos para una entrada separada. Así que, sin más dilación, pongámonos a ello. No está de más, por cierto, recordar que yo trabajo en una Debian Etch con un kernel personalizado 2.6.22.6.

El procesador gráfico que lleva la VIA EPIA EX10000EG es el UniChrome™ Pro II, integrado en el chipset CX700M2. Según VIA, este chipset es capaz de:

Integrated VIA UniChrome™ Pro II 3D/2D AGP graphics with MPEG-2/4 and WMV9 video decoding acceleration

No tengo ni idea de si tales afirmaciones son ciertas en Windows (no he probado esta placa con dicho sistema operativo) o son fruto de la benevolencia de alguien en el departamento de marketing de VIA, pero veamos hasta dónde podemos sacarle punta a dichas afirmaciones en Linux.

En principio, leyendo la Operating Guide de la placa, vemos que, aunque sea sobre el papel, VIA nos manifiesta un fuerte compromiso con el soporte de Linux en sus placas:

Linux Driver Support

VIA EPIA EX mainboards have a very high degree of support under Linux.

Support and drivers are provided through various methods including:

  • Drivers provided by VIA
    • Using a driver built into a distribution package
    • Visiting VIA Arena website at www.viaarena.com for latest updates on a monthly basis
  • Installing a third party driver (such as the ALSA driver from the Advanced Linux Sound Architecture project for integrated audio)

For OEM clients and system integrators developing a product for long term production, other code and resources may also be made available. You can submit a request either through the Developers portal on VIA Arena, or through your VEPD support contact. Alternatively, VIA can work further towards providing additional drivers to suite your specific needs.

Como hemos visto en entradas anteriores (Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux, Sobre las VIA EPIA (III): Linux en una SP8000E), en las que nos hemos dejado absolutamente todos los elementos del hardware configurados a la perfección, podemos aceptar la afirmación anterior sin titubeos.

Sin embargo, aún nos queda configurar los gráficos en esta placa, y nos vamos a encontrar con varios problemas. El primero es que según leemos en la página de man(4) del driver via actual (7.1) de X.Org, este chipset no está soportado aún:

DESCRIPTION
       via is an Xorg driver for VIA chipsets that have  an integrated Unichrome graphics engine.
 
       The via driver supports the CLE266, KM/N400, K8M/N800, PM/N800  and  CN400  chipsets  from
       VIA,  including  2D acceleration and the Xv video overlay extensions.  Flat panel, TV, and
       VGA outputs are supported, depending on the hardware configuration.
 
       3D direct rendering is available using experimental drivers  from  Mesa  (www.mesa3d.org).
       There  is  also  an  XvMC client library for hardware acceleration of MPEG1/MPEG2 decoding
       (available on the CLE266, PM/N800, K8M/N800, and CN400 chipsets) that uses the Direct Ren-
       dering  Infrastructure  (DRI).   The  XvMC  client library implements a non-standard "VLD"
       extension to the XvMC standard.  The current Direct Rendering Manager (DRM) kernel  module
       is available at dri.sourceforge.net.

Si nos pasamos al driver openChrome, nos encontramos con que tenemos que usar la rama experimental para tener soporte del chipset CX700M2 pero que, desafortunadamente, aún no soporta aceleración MPEG2/4 por XvMC.

Nos queda el driver oficial de VIA. Cuando hice la tanda anterior de artículos alrededor de la SP8000E, dado que encontré buen soporte del procesador gráfico tanto en el driver oficial de X.Org como en el openChrome, ni me preocupé en probarlo, ya que en muchos foros leía comentarios bastante negativos al respecto. Sin ir más lejos, en The Different Unichrome family display drivers podemos leer:

The VIA proprietary drivers

The proprietary drivers from VIA contain support for most chipsets, mpeg2 and mpeg4 acceleration, but are of low quality and often unstable. In addition, the 3D driver leaves your system open for attack by malicious clients, and furthermore, applications that accelerate mpeg2 and mpeg4 must be run as root, which is a very bad idea if they contain vulnerabilities (and they do). Avoid using these drivers unless you know what you are really doing! The drivers can be found here. Also, these drivers are distribution specific and a driver for different distribution other than yours might not work.

El desarrollador del driver unichrome.sf.net (que no funciona en chipsets modernos como el CN400 o el CX700, por cierto), Luc Verhaegen, también dice:

Despite VIA’s failure to properly understand and cooperate with Free and Open Source Software communities, this driver is very important. Thanks to VIA’s code releases, however irregular, entangled and buggy, a lot is known about the unichromes, and it is possible to do just about anything you want with them.

Por cierto, Luc tuvo un rifirafe con la moderadora de los foros de VIA, Fiona Gatt en VIA stops providing source: XF40070 is binary only y XF40070 topic locked: Last post removed tras decir en su diario lindezas sobre el driver de VIA tales como:

So, let us review where VIAs stands with respect to free software:

  • Complete and prolonged (3y+) inability to work with actual free software developers.
  • Crappy code and sporadic releases, totally unfit for direct use.
  • Very bad handling of licensing, with proprietary licenses popping up once in a while.
  • An NDA that, when VIA says so, forces signee to breach the GPL.
  • Distributes tarball with the binary “libddmpeg.so” and labels the lot as “open source” in direct violation of The Open Source Definition.
  • No longer distributes a DRI driver now, after having provided DRI binaries for a bit inside their “open source” tarballs. This used to be all source at one point.

En esta ocasión, y puesto que la aceleración de vídeo es importante en mis pruebas, es impensable no probarlo. Así que, ¡vamos allá!.

Sigue leyendo »

06 oct

Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux

Continuando con Sobre las VIA EPIA (IV): Placas con procesador C7 / La EX10000EG, vamos a ver las cosas que tenemos que tocar en nuestro Linux (en mi caso Debian Etch con un kernel 2.6.22.6 personalizado) para sacar el máximo provecho de esta placa.

Sigue leyendo »

02 oct

Sobre las VIA EPIA (IV): Placas con procesador C7 / La EX10000EG

Un amigo tiene en la cabeza un proyecto en el que usará varias VIA EPIA EX10000EG para reproducir vídeo en Linux y me ha cedido una de ellas a sabiendas de que yo no iba a poder pasar sin cacharrear un poco con ella y contarle todo lo que fuera descubriendo. Así que en ello estamos, contando.

Sobre las VIA EPIA y el formato Mini-ITX en general y sobre la VIA EPIA SP8000E en particular ya hablé largo y tendido en tres entradas anteriores:

Las EPIA EX (EX10000EG y EX15000EG, una fanless y la otra con ventilador, como siempre), con chipset CX700M2, eran, hasta hace muy poco, las más nuevas de las placas VIA EPIA de formato Mini-ITX. Recientemente aparecieron las SN (chipset CN896, con PCIe), LT (chipset CX700, que es como el CX700M2 pero sin decodificador de TV) y LN (chipset CN700). A día de hoy, las únicas con chipset CX700M2 son las EX, aunque las LT también se pueden pedir con CX700M2 por encargo ( y me imagino que para volúmenes grandes). Las EX también son las únicas con salida DVI.

El que las EX sean de momento las únicas EPIA en la que el conector DVI reemplace al VGA me parece muy sorprendente. El conector apenas ocupa un poco más, y si no se tiene un monitor con entrada DVI, siempre se puede usar un convertidor como éste que me venía en la caja de otra tarjeta de vídeo (y probado con éxito con la EX10000EG):

Convertidor DVI-VGA

Y ahondando más en el tema, es especialmente llamativo que esto ocurra incluso en las SN, tope de gama actual, con su procesador C7 de hasta 1.8GHz (con ventilador) y su flamante chipset CN896, que permite un FSB de 800MHz (sólo en combinación con el procesador de 1.8GHz) e incluye el procesador gráfico VIA Chrome9™HC, con soporte de DX9 y certificado para Windows Vista Home Basic, la versión que no incluye el Windows Aero, claro.

Sigue leyendo »

23 sep

Mostrar un árbol de los paquetes instalados que dependen de otro en Debian

De la época que estuve usando Gentoo recuerdo con especial cariño dos cosas: la flexibilidad y la posibilidad de personalización durante el compilado de los parámetros USE, y las herramientas de gestión de paquetes de Portage: el emerge y el equery del Gentoolkit.

El emerge viene a ser una unión de los comandos de Debian dpkg, apt-get, apt-cache y apt-build. Nigún misterio por esa parte…

Sin embargo, el equery que, como su propio nombre indica, se usa para hacer queries a la base de datos de paquetes, resulta muy útil. Por ejemplo, se puede obtener la lista de paquetes que dependen de uno dado (ejemplo copiado de Gentoolkit):

# equery depends pygtk
[ Searching for packages depending on pygtk... ]
app-office/dia-0.93
dev-python/gnome-python-2.0.0-r1
gnome-extra/gdesklets-core-0.26.2
media-gfx/gimp-2.0.4
x11-libs/vte-0.11.11-r1

También nos permite obtener un árbol de dependencias de un paquete dado, pero en este caso no se trata de los paquetes de los que depende el paquete, sino de sus dependencias:

# equery depgraph cdrtools
Displaying dependencies for app-cdr/cdrtools-2.01_alpha37
`-- app-cdr/cdrtools-2.01_alpha37
 `-- sys-libs/glibc-2.3.4.20040808 (virtual/libc)
  `-- sys-kernel/linux-headers-2.4.22 (virtual/os-headers)
   `-- sys-apps/baselayout-1.10.4
    `-- sys-apps/sysvinit-2.85-r1
     `-- sys-apps/gawk-3.1.3-r1
      `-- sys-apps/util-linux-2.12-r4
          `-- sys-apps/sed-4.0.9
        `-- sys-libs/ncurses-5.4-r4
            `-- sys-apps/pam-login-3.14
            `-- sys-libs/pam-0.77-r1
                 `-- sys-libs/cracklib-2.7-r10
               `-- sys-apps/miscfiles-1.3-r1
              `-- app-arch/gzip-1.3.5-r1
              `-- sys-apps/portage-2.0.50-r10

En Debian, a menudo quiero eliminar un paquete y las dependencias no me lo permiten:

 # dpkg -P libxine1
dpkg: dependency problems prevent removal of libxine1:
 totem-xine depends on libxine1 (>= 1.1.2-5).
dpkg: error processing libxine1 (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libxine1

Es posible que esté tan convencido de querer eliminar el paquete que me decida incluso a eliminar sus dependencias:

# dpkg -P totem
dpkg: dependency problems prevent removal of totem:
 gnome-desktop-environment depends on totem (>= 1.4.3).
dpkg: error processing totem (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 totem

Pero claro, llegados a este punto, me temo que el gnome-desktop-environment no lo quiero eliminar. De momento, los paquetes ya me los ha dejado marcados como que no los quiero instalados para aprovechar la mínima ocasión para eliminarlos:

# dpkg -l | egrep -v ^ii                                                                 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name             Version              Description
+++-================-====================-============================================
pi  libxine1         1.1.2+dfsg-4         the xine video/media player library, binary 
pi  totem            2.16.5-3             A simple media player for the Gnome desktop

Como a mí me da manía dejarlos así, pues en este punto haría un “apt-get --reinstall install libxine1 totem” para que vuelvan a estar en estado ii.

La forma elegante de prever y al mismo tiempo tantear si podríamos borrar el paquete sería haber usado el “dpkg -P” con una de las tres opciones que evitan que la acción se haga en realidad:

       --no-act | --dry-run | --simulate
              Do everything which is supposed to be done, but  don't  write  any  changes.
              This  is  used  to  see what would happen with the specified action, without
              actually modifying anything.
 
              Be sure to give --no-act before the action-parameter, or you  might  end  up
              with  undesirable  results. (e.g. dpkg --purge foo --no-act will first purge
              package foo and then try to purge package --no-act, even though you probably
              expected it to actually do nothing)

Pero bueno, esta forma de trabajar por tanteo me parece un atraso tras haber visto lo que puede hacer el equery.

Sigue leyendo »

15 sep

Ejemplos de scripting en Windows: Añadir la fecha y la hora al nombre de un fichero

Siempre he tenido la idea de que la shell de Windows era terriblemente limitada, no sólo por las funcionalidades propias del CMD (algo mayores que las del viejo COMMAND.COM, en cualquier caso) sino también por la ausencia de esos viejos amigos del intérprete de comandos que tanto facilitan la vida en UNIX: grep, awk, sed, etc. Por eso, entre otras cosas, me gusta tanto el Cygwin, porque me permite tener toda la potencia de la shell de UNIX en Windows.

Pero para ser sincero, hablando de scripting en Windows, he de reconocer que he visto hacer cosas muy interesantes con VBScript e incluso de vez en cuando ves algún script de CMD que te llama mucho la atención, como me pasó hace unos días.

Tenía una aplicación en Windows que iba escribiendo en un fichero de log de esos que van rotando. Lo típico, la aplicación va escribiendo en un fichero logfile.log que cuando llega a un tamaño es renombrado a logfile.log.old reemplazando al anterior con ese mismo nombre y genera un nuevo logfile.log.

Pues bien, yo necesitaba recoger esos .old durante varios días apuntando la hora exacta a la que se había guardado, una tarea trivial en UNIX: Pones un script como el siguiente en el cron para que se ejecute cada minuto y un logfile.log.old se convierte en un logfile.log.200709141929 en un santiamén:

#!/bin/sh
if [ -f logfile.log.old ]
then
   mv logfile.log.old logfile.log.$(date +%Y%m%e%k%M)
fi

En el CMD de Windows esto no es tan sencillo, para empezar porque los comandos date y time de Windows no se puede decir que sean lo más versátil del mundo: ¡Sólo aceptan el parámetro /t!

C:\>date /t
14/09/2007

C:\>time /t
19:51

Sigue leyendo »

13 sep

Fuentes de alimentación ATX: Arrancar una fuente fuera de la caja

Es posible que alguna vez os hayáis visto con la necesidad de probar una placa base con su memoria y su procesador y tal vez disco duro, unidad óptica, etc., fuera de una caja. En servicios técnicos y tiendas como la del tendero digital seguro que tienen que hacerlo de vez en cuando para probar tal placa base o tal componente. En nuestras casas es más raro, aunque puede presentarse alguna vez el caso.

Suponiendo que tenemos una fuente de alimentación ATX disponible, esto no supone mayor problema, de forma que podamos montar fácilmente un entorno de pruebas similar al de estas fotos (encontradas aquí y aquí):

Placa base sin caja 1 Placa base sin caja 2

No tiene mayor complicación…. excepto por un elemento clave… ¡El interruptor!

Sí, porque a diferencia de las viejas fuentes AT que llevaban un interruptor conectado a la propia fuente, las fuentes ATX necesitan que les llegue la señal de encendido de la placa base. Esto permite cosas tan interesantes como arrancar el ordenador con el teclado, a una hora determinada, después de perder la alimentación o por Wake on LAN… El interruptor de la caja ahora es un sencillo pulsador con retorno que le da la señal de encendido a la placa base. Como muchos ya sabréis, si lo dejas pulsado varios segundos, el ordenador se apaga.

Sigue leyendo »

10 sep

NTFS-3G: preserving times for ‘foo’: Operation not permitted

Pocos se acordarán ya de la que fue una de las primeras entradas de este blog, La pesadilla de compartir partición entre Linux y Windows. En ella, contaba cómo hacía poco había empezado a usar el driver NTFS-3G para compartir particiones entre Linux y Windows y que justo ese día había salido el NTFS-3G 1.0.

Pues bien, desde entonces vengo usando el NTFS-3G continuamente, habiendo visto cómo el driver cada vez funciona mejor y más rápido. Szabolcs Szakacsits, el principal desarrollador del proyecto, tiene todos mis agradecimientos por haber conseguido algo que se había hecho esperar tanto (soporte seguro de lectura y escritura de NTFS en Linux) y con tanta calidad.

En fin, el caso es que desde el principio me venía fijando en que cuando hacía según qué operaciones de escritura en la partición NTFS usando un usuario distinto de root me encontraba con el error:

cp: preserving times for 'foo': Operation not permitted

Y los ficheros se creaban con la fecha actual en lugar de la suya. Por ejemplo:

$ ll torvalds-says-linux.au
-rw-r--r-- 1 supercoco users 41493 2006-10-27 21:24 torvalds-says-linux.au
$ cp -p torvalds-says-linux.au /mnt/e/
cp: preserving times for `/mnt/e/torvalds-says-linux.au': Operation not permitted
$ ll /mnt/e/torvalds-says-linux.au
-rwxrwxrwx 1 root root 41493 2007-09-10 22:31 /mnt/e/torvalds-says-linux.au

Esto no ocurre con root:

# ll torvalds-says-linux.au
-rw-r--r-- 1 supercoco users 41493 2006-10-27 21:24 torvalds-says-linux.au
# cp -p torvalds-says-linux.au /mnt/e/
# ll /mnt/e/torvalds-says-linux.au
-rwxrwxrwx 1 root root 41493 2006-10-27 21:24 /mnt/e/torvalds-says-linux.au

Tenía pendiente investigar la causa pero no le estaba dando mucha importancia. Hasta que hace unos días pasé todas las fotos de la tarjeta de memoria de la cámara de fotos y a continuación me di cuenta de que los ficheros habían perdido la fecha y hora correctas, algo que me molestó mucho. No es una pérdida irreparable, porque dichos datos siguen estando en la cabecera Exif de las fotos, pero sí fue muy molesta.

En realidad la solución estaba a tiro de Google en forma de hilo de los foros de NTFS-3G y con contestación del propio szaka (Szabolcs Szakacsits): cp: preserving times for ‘file’: Operation not permitted.

El problema estaba en que yo montaba la partición poniendo lo siguiente en el /etc/fstab:

/dev/sdb6  /mnt/e ntfs-3g rw,defaults,umask=000,locale=en_US.ISO-8859-15    0       0

y resulta que si se especifica una de las opciones uid, gid o [udf]mask, es el propio FUSE el que verifica dichas opciones y gestiona los permisos.

Teniendo en cuenta que ntfs-3g funciona con el setuid de root:

# ll /usr/bin/ntfs-3g 
-rwsr-xr-- 1 root fuse 40440 2007-08-08 19:50 /usr/bin/ntfs-3g

Extracto del man de ntfs-3g:

If ntfs-3g is set setuid-root then non-root users will be also able to mount block devices
or via /etc/fstab if the 'user' or 'users' mount(8) option is specified. The ntfs-3g  pro-
cess drops the root privilege after successful mount and runs unprivileged afterwards.

FUSE hace lo correcto según el estándar POSIX al rechazar la operación, como nos cuenta Szabolcs:

I have the result of the investigation. FUSE is right. Things worked
as they should. The operation indeed mustn't be permitted in such cases
according to the POSIX standard.

Namely utimes(2) doesn't permit changing the time stamps because the
effective uid of the cp process doesn't equal the uid of the file
__AND__ the new time stamps are not the current time, __EVEN_IF__
the user has write permission to the file. This is how POSIX wants.

Por tanto, si quitamos el umask=000 que, en cualquier caso, es el valor que se toma por defecto, FUSE no hará las comprobaciones y las horas y fechas se escribirán correctamente, aunque no estemos con el usuario root.

Esta es la línea de mi /etc/fstab ahora:

/dev/sdb6  /mnt/e ntfs-3g rw,defaults,locale=en_US.ISO-8859-15    0       0

Por cierto, ¿a alguien le ha llamado la atención el fichero que he usado de prueba? El fichero de audio (formato au) torvalds-says-linux.au es muy antiguo y al reproducirlo oímos a Linus Torvalds pronunciar Linux. Pronunciación que se usa de referencia desde entonces. Se puede reproducir en un sistema Linux con OSS simplemente haciendo:

cat torvalds-says-linux.au > /dev/audio

Supuso una enorme alegría para mí la primera vez que conseguí configurar una tarjeta de sonido en Linux y oír a Linus. Yo encontré el fichero en uno de mis viejos CDs de InfoMagick. Hoy en día está en múltiples sitios y formatos. Por ejemplo, en la página de Paul Slanden.

06 sep

Configurar un sistema Debian diskless

En la entrada anterior, Iniciar una instalación de Debian por red, introducíamos los sistemas diskless. Basándonos en la infraestructura detallada en dicha entrada, el arrancar una Debian completa desde la red sólo supone unos sencillos pasos más.

En concreto, si ya somos capaces de arrancar la instalación de Debian por la red, alterando el fichero de configuración del PXELINUX podemos lograr que el sistema que arranca de la red use el kernel que nos interese y, a continuación, montar por NFS el sistema de ficheros que tendremos preparado en otra máquina.

El primer paso es crear una instalación de Debian dentro de un directorio del servidor de arranque (en mi caso /exports/peggy, donde peggy es el nombre del sistema que arrancará Debian de la red) usando el útil comando debootstrap

# mkdir -p /exports/peggy
# debootstrap --arch i386 etch /exports/peggy http://ftp.es.debian.org/debian/

El debootstrap no instala un kernel por defecto, así que entramos en la nueva instalación con chroot para instalar uno:

# chroot /exports/peggy
# apt-get install linux-image-686 libc6-i686
# exit

Ahora vamos a crear un nuevo fichero de configuración para el PXELINUX. Como podemos leer en la documentación del PXELINUX, el fichero default, que es el que ya tenemos, es el último que se intenta cargar. Antes de eso, el gestor de arranque por red trata de usar un fichero con un nombre como 01-<direccion MAC en minúsculas y con guiones como separadores de bytes>. Por ejemplo, si la dirección de nuestro sistema es 00:41:64:ED:29:D3, necesitaremos un fichero con el nombre 01-00-41-64-ed-29-d3 en /var/lib/tftpboot/pxelinux.cfg/.

Sigue leyendo »

05 sep

Iniciar una instalación de Debian por red

El conjunto de piezas de PC más pequeño que sirva para hacer algo es: CPU, placa base con procesador de vídeo integrado (opcionalmente con una CPU integrada también, como en el caso de las VIA EPIA) y fuente de alimentación.

Con esta configuración necesitaríamos arrancar de la red para poder hacer algo y estaríamos hablando de un sistema diskless.

Si queremos que el sistema sea autónomo, además de las piezas anteriores, necesita un sistema de almacenamiento propio (disco duro, memoria USB, unidad óptica, disquetera) del que arrancar, que normalmente será un disco duro. Supongamos que tenemos un sistema mínimo sólo con un disco duro, queremos instalarle Debian y no tenermos una unidad óptica externa ni nada que podamos usar para hacer la instalación estándar. En ese caso, necesitaremos arrancar la instalación por red.

Es un proceso bastante sencillo, aunque necesitaremos una cierta infraestructura en otro sistema ya instalado del que el sistema a instalar obtendrá todo lo necesario. La máquina a instalar ha de soportar arrancar desde la red por PXE, una combinación de DHCP y TFTP que permite asignar una dirección IP al sistema cliente y a continuación pasarle los ficheros necesarios para que lo haga.

En mi caso, como el router ADSL que uso ya es servidor de DHCP, es deseable evitar posibles interferencias al montar un nuevo servidor DHCP a pesar de que, según la Wikipedia, esto en teoría se podría evitar:

The PXE Client/Server Protocol was designed so it can be used in the same network as an existing DHCP environment without interference

Por ello, y como el PC destinado a servidor de arranque tiene dos interfaces de red, uno normalmente sin usar (eth0) y otro conectado al router (eth1), yo prefiero independizar ambas redes, de tal forma que si conectamos con un cable cruzado la toma de red del sistema a instalar con el interfaz sin usar, estamos listos para comenzar la configuración del sistema.

Sigue leyendo »

Tema LHYLE09, creado por Vicente Navarro