Warning: Fake initctl called, doing nothing

Este mensaje aparece al intentar instalar un paquete, en mi caso, openssh-server aunque también ocurre al intentar instalar otros servicios como myslqd. No crean los scripts de inicio y es, por tanto, imposible iniciarlos durante el arranque o posteriormente porque dichos scripts no han sido creados durante la instalación.

El mensaje se muestra al intentar instalar cualquier paquete que deba arrancar con upstart o initctl:

Warning: Fake initctl called, doing nothing

Se puede comprobar que ninguno de los servicios instalados tras este error está funcionando si hacemos:

$ service --status-all

y también:

$ initctl list

Por si aún no está claro que openssh-server no está funcionando, podemos comprobar que puertos están escuchando con:

$ netstat -nltp

Al parecer, el error se produce por una actualización que quedó incompleta. Después de revisar /var/log/apt/term.log , /var/log/dpkg.log no pude encontrar nada anómalo, apliqué la solución propuesta en este foro y se solucionó ejecutando estos dos comandos:

$ sudo mv /sbin/initctl /sbin/initctl.FAKE

$ sudo ln -s /sbin/initctl.REAL /sbin/initctl

y después limpiando la instalación del servicio que falla y reinstalando de nuevo, por ejemplo:

$ sudo apt-get purge openssh-server

$ sudo apt-get install --reinstall openssh-server

Ahora los scripts de inicio estarán disponibles y podrán ser ejecutados al iniciar el sistema.

Error 'Failed to fetch...' actualizando Ubuntu 11.04

Al intentar actualizar Ubuntu 11.04 con el gestor de actualizaciones, no se pueden descargar los paquetes a pesar de que hay conexión a Internet.

Aparece un recuadro con cada uno de los paquetes que no pueden ser descargados y la actualización se cancela. El error dice: "Failed to fetch http://...." y a continuación el sitio y nombre del paquete a descargar.

Para solucionarlo, simplemente pulsamos en el botón Configuración del Gestor de actualizaciones para elegir otro servidor desde el que descargar las actualizaciones.

Aquí se describe más detalladamente el procedimiento.

Velocidad de transferencia del disco duro

Para conocer la velocidad de transferencia del disco duro en Linux se puede utilizar el comando hdparm aunque también existen herramientas gráficas para comprobarlo.

Lo primero es conocer las características del disco instalado. Si nuestro disco está instalado como sda usamos el comando:

sudo lshw -C disk

Si el disco soporta SMART, la herramienta gráfica gsmartcontrol, instalable desde el Centro de software de Ubuntu proporciona información de los discos conectados y ofrece la posibilidad de ejecutar el algunos tests en busca de errores.

Los valores de los atributos que se muestran brindan una información muy interesante:

Finalmente, otra herramienta gráfica que ofrece información de los dispositivos de almacenamiento conectados es gnome-disk-utility. Se instalada desde el Centro de Software de Ubuntu y se ejecuta escribiendo palimpsest en una ventana del terminal.

Desde esta herramienta también podremos formatear un disco, comprobar el sistema de archivos, montar un volumen y realizar pruebas de rendimiento.

Se pueden realizar pruebas de rendimiento de lectura y de lectura/escritura. Al finalizar la prueba de lectura se muestra el resultado en una gráfica como esta:

Para ejecutar la prueba de lectura/escritura es necesario que la tabla de particiones esté completamente vacía.

Desde la consola también es posible realizar pruebas de rendimiento del disco. Utilizamos el comando hdparm pero para que los valores obtenidos sean fiables, debemos ejecutar el comando al menos tres veces.

El comando sería:

sudo hdparm -tT /dev/sda

El resultado también tiene en cuenta el rendimiento del procesador y la memoria pues las lecturas utilizan la caché y buffer del disco:

Para ejecutar la prueba tres veces, empleamos un bucle desde la consola:

Un factor a tener es cuenta es el tamaño del disco y el porcentaje de utilización. Para verlo, la mejor herramienta es el analizador de uso de disco o desde el terminal con el comando:

du -sx

Personalizar el escritorio de Ubuntu 11.10

La mayoría de las características para personalizar el escritorio en Ubuntu 11.10 funcionando en modo 2D no están disponibles desde el menú de configuración del sistema. El fondo de escritorio, el papel tapiz y la posibilidad de elegir entre unos pocos temas son las únicas opciones disponibles desde el menú Configuración del sistema->Apariencia.

De los temas que están instalados:

ls /usr/share/themes

solo están disponibles algunos de ellos: Radiance, Ambiance y HighContrast.

MyUnity ofrece muchas posibilidades de personalización aunque están limitadas si Ubuntu está funcionando en modo 2D. Aún así, permite elegir alguno de los otros temas instalados.

Para instalar esta herramienta, añadir el repositorio:

sudo add-apt-repository ppa:myunity/ppa

sudo apt-get update

sudo apt-get install myunity

Esto añade la herramienta MyUnity al menú de Configuración del sistema.

Al configurar algunos de los temas puede desaparecer el icono de control de sesión (logout, configuración del sistema, aplicaciones al inicio, ...)

Para volver a restaurar este icono, basta con lanzar desde una ventana del terminal la aplicación de configuración por defecto: gnome-control-center y reestablecer alguno de los temas que vienen por defecto en esta aplicación. El icono reaparecerá.

Otra herramienta muy útil que añade un panel inferior con muchos gadgets opcionales e instalables es AWN (Avant Window Navigator). Junto con Docky, ambas están disponibles para descargar desde el Centro de software de Ubuntu.

OpenXenManager /usr/bin/env python2 no existe el archivo o directorio

Después de descargar e instalar OpenXenManager, cuando lanzamos el ejecutable con ./openxenmanager se produce un error:

/usr/bin/env: python2: No existe el archivo o el directorio

Este error está provocado porque el ejecutable python2 que es llamado desde el script openxenmanager no existe en nuestra versión de Ubuntu pues ha podido ser reemplazado por una versión más reciente.

Para solucionarlo, basta con editar el script openxenmanager y sustituir la línea:

#!/bin/bash
/usr/bin/env python2 window.py

Por esta otra:

#!/bin/bash
/usr/bin/env python window.py

Recuerda que debes tener instaladas python-glade2 y python-gtk-vnc. En esta guía se explica como realizar la instalación paso a paso.

Los números primos y la temperatura del procesador

El objetivo de este ejercicio es comprobar como sometiendo el procesador a una sobrecarga de tareas hace que su temperatura aumente. Vamos a necesitar varias herramientas, la primera, un test de tortura que permita intensificar el trabajo del procesador. Uno de los más conocidos tests de tortura es prime95.

Este programa usa tu ordenador para calcular números primos y participar en un proyecto de computación distribuida para la búsqueda de números primos (GIMPS). Como procedimiento para someter al procesador a una intensa demanda en coma flotante es también interesante pues puede funcionar indefinidamente y, además, exige un constante acceso a la memoria. Debido a este fuerte stress, el consumo del procesador y, en general del ordenador, también aumenta.

Las restantes herramientas necesarias para el ejercicio lo son para la observación del fenómeno. En primer lugar, necesitaremos un amperímetro para comprobar el consumo o mejor aún, un medidor del consumo eléctrico que se puede comprar en Lidl por 10 euros o en Amazon por 20 euros.

Además, será necesario observar como aumenta el uso de la CPU con una herramienta gráfica fácil de entender como gnome-system-monitor, que muestra también el uso de la memoria y, por último, para vigilar la temperatura, podemos instalar lm-sensors y sensors-applet.

Este último permite añadir un applet a la barra que muestra lecturas de los sensores de temperatura con el intervalo que establezcamos. Si se quiere conocer la temperatura de forma puntual e instantánea se puede usar acpi -t desde la línea de comando.

En una ventana del terminal lanzamos prime95 y visualizamos en el monitor del sistema como el uso de la CPU y memoria se intensifican, al tiempo que observamos el aumento de la temperatura y del consumo eléctrico.

Fallo fuente de alimentación

Varias veces, cada vez con más frecuencia, al desconectar el cable de alimentación de mi HP SR1297ES y volverlo a conectar, la luz o led de la fuente de alimentación se queda parpadeando y el ordenador no arranca al pulsar el botón de encendido. El parpapedo o flash se acompaña de un sonido parecido al tick de un reloj.

Para conseguir arrancar el ordenador, tuve que desconectar la fuente de alimentación de la red, desconectar el conector P1 que va desde la fuente hasta la placa base, reconectar la fuente de alimentación a la red y mientras está conectada, volver a conectar P1.

Otras veces, desconectando el cable de alimentación que va desde la fuente a P1 de su conector ATX 20,  he puenteado PowerOK con un clip por la parte trasera del conector y cuando comienzan a girar los discos y el ventilador de la fuente, conectar el P1 a la placa base. Bastante arriesgado pero funciona. Cuando el ordenador haya encendido puedes desconectar el clip pero no lo pierdas, lo necesitarás la próxima vez.

Al parecer se debe a que la acumulación de polvo en la fuente de alimentación causa un cortocircuito que impide el arranque. Según he leído, se puede solucionar sin necesidad de comprar una fuente nueva con un simple secador de pelo usándolo para limpiar el interior de la fuente. Yo prefiero probar con un spray de aire comprimido.

No se muestran todos los interfaces de red

En una máquina virtual Ubuntu 11.10 Oneiric Ocelot con dos interfaces de red configurados como NAT (eth0) y Bridge(eth1), después de eliminar el interface de red en modo Bridge en VirtualBox, desparece de la máquina virtual Ubuntu y no muestran ni eth0 ni eth1, tan solo el interface local (lo).

Ejecutando:
# dmesg | grep eth0

se muestra:

[    2.874056] eth0: RTL8168d/8111d at 0xffffc90001874000, 08:00:27:02:ff:8f, XID 081000c0 IRQ 32
[    5.981326] udev: renamed network interface eth0 to eth1

y ejecutando:
# ifconfig -a

se muestra:

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:266 errors:0 dropped:0 overruns:0 frame:0
          TX packets:266 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:19124 (19.1 KB)  TX bytes:19124 (19.1 KB)

Se puede comprobar que el interfaz está realmente presente mediante:

# sudo lshw -C network

El archivo de configuración de dispositivos al inicio puede haberse modificado incorrectamente al cambiarse la configuración o eliminarse el adaptador de red en VirtualBox.

# cat /etc/udev/rules.d/70-persistent-net.rules

# This file maintains persistent names for network interfaces.

# See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.


# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:02:ff:8f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10ec:0x8168 (r8169)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:02:ff:8e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Si no muestra ningún dispositivo o muestra dos líneas, como en el ejemplo, debemos comprobar que la dirección MAC corresponde al interfaz eth* que realmente existe y eliminar cualquier otra entrada en el archivo. Si es así, hacer una copia de seguridad de este archivo de configuración y modificarlo para que muestre los dispositivos que realmente existen y su dirección MAC correcta asociados al interfaz eth correspondiente.

Después reiniciar:

# sudo init 6

Bluetooth falla en Oneiric Ocelot Ubuntu 11.04

Intentado enviar ficheros desde mi Nokia N97 a mi ordenador actualizado a la versión Oneiric Ocelot Ubuntu 11.10 desde Natty falla. Tampoco es posible examinar el dispositivo usando el adaptador Bluetooth aunque si que se detecta cuando se hace scan. Nada de esto ocurría en la anterior versión, Natty.

Si probamos desde el applet de gnome a examinar el dispositivo se monta en el sistema de ficheros el dispositivo pero al tratar de examinarlo con Nautilus se produce un error indicando que no ha podido ser montado.

No se pudo mostrar obex://[XX:XX:XX:XX:XX]Error: DBus error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)Seleccione otro visor e inténtelo de nuevo.

Se puede verificar que efectivamente no está montado accediendo desde la consola al punto de montaje por defecto:

#ls ~/.gvfs/N97

Este comando mostrará que el directorio no está montado.

Lanzando el applet de gnome desde la consola con:

#bluetooth-applet

para poder ver los errores se obtiene en la consola:

Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

#hcitool scan
Scaning ...

detecta el dispositivo Bluetooth, en mi caso un Nokia N97.

#lsusb | grep -i bluetooth

Informa del adaptador Bluetooth conectado al puerto usb, en mi caso:

0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

Parece tratarse de un fallo conocido y aún abierto. Después de buscar he probado con la solución provisional descrita y, al menos en mi caso, funciona:

Instalo obexfs con:

#sudo apt-get install obexfs

#sudo mount -t fuse "obexfs#-bXX:XX:XX:XX:XX:XX" /media/N97

donde XX:XX:XX:XX:XX:XX es la MAC de mi dispositivo.

Ubuntu 11.04 no se inicia en modo gráfico con drivers de NVIDIA

En Ubuntu 11.04 y después al pasar a Ubuntu 11.10 oneiric, después de muchas de las actualizaciones automáticas, no consigo que se inicie el modo gráfico y la pantalla se queda en negro. El único modo de acceder al sistema es mediante alguna de las consolas de texto [CTRL] + F2 por ejemplo.

Buscado información en los logs, se observa que no hay ningún error en /var/log/kern.log referido a los drivers de NVIDIA pero, sin embargo, en /var/log/Xorg.0.conf aparece un error indicando 'failed to load nvidia drivers'

Parece que esto ocurre cada vez que se actualiza el núcleo en algunas de las actualizaciones automáticas.

En mi caso, observando el fichero de actualizaciones: /var/log/dkpg.log veo que la versión anterior linux-image-2.6.38-10-generic 2.6.38-10.46 ha sido sustituida por linux-image-3.0.0.14-generic 3.0.0.14.23

Para volver a tener el entorno gráfico siempre he seguido el mismo procedimiento:

#sudo apt-get remove --purge nvidia-*

#sudo Xorg -configure

#sudo sh NVIDIA-Linux-x86-290.10.run

Obviamente, hay que sustituir el driver NVIDIA-Linux-x86-290.10.run por el que te hayas descargado de la página de NVIDIA
Si lo prefieres puedes descargarte previamente la última versión de los repositorios de Ubuntu usando:

#sudo apt-get install nvidia-current

Iniciar Ubuntu siempre en modo texto

Para que Ubuntu se inicie siempre en modo texto, tenemos que modificar el grub.

Editamos el fichero de la configuración por defecto de grub:


#sudo nano /etc/default/grub
Sustituye la línea:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
y cámbiala por:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash text"
Reescribe el grub en el sector de arranque del disco:

#sudo update-grub
La próxima vez que reinices el entorno gráfico no se iniciará. Si quieres hacerlo, puedes usar:

#startx

Fuente

Reemplazar disco duro en un portátil por SDHC (micro-SD)

Como experimento, he sustituido el disco duro de un portátil TOSHIBA con Intel Centrino de los que distribuye la Junta de Andalucía a los centros TIC, concretamente uno modelo PTM50E-07302KLX, por un adaptador SATA 2.5" para SDHC, es decir, he sustituido el disco duro, un TOSHIBA HDD2D34 y en su lugar he puesto una SDHC de 8GB de clase 10.

Para comprobar el funcionamiento, he instalado Ubuntu 10.10 en la micro SDHC de 8GB clase 10 con un adaptador para SATA y ejecutado un test de benchmarking con System Profiler and Benchmark tool.

El equipo tiene un procesador es un T1300 @ 1600GHz, 2M caché con 512MB de memoria.
Después de ejecutar varios test, estos son los resultados con el Ubuntu 10.10 instalado en la micro-SDHC:

CPU Blowfish: 20.11 (cuanto menos, mejor)
CPU CryptoHash: 61.77 (cuanto menos, mejor)
CPU Fibonacci: 5.94 (cuanto menos, mejor)
CPU N-Queens: 13.98 (cuanto menos, mejor)
FPU FFT: 10.47 (cuanto menos, mejor)
FPU Raytracing: 28.21 (cuanto menos, mejor)

Los resultados de los mismos tests con el disco duro de origen, un TOSHIBA HDD2D34 de 40GB son los siguientes:

CPU Blowfish: 20.15 (cuanto menos, mejor)
CPU CryptoHash: 62.11 (cuanto menos, mejor)
CPU Fibonacci: 5.89 (cuanto menos, mejor)
CPU N-Queens: 13.97 (cuanto menos, mejor)
FPU FFT: 10.51 (cuanto menos, mejor)
FPU Raytracing: 28.23 (cuanto menos, mejor)

Los tests anteriores han sido hechos con hardinfo 0.5.1 y no parecen mostrar mucha diferencia ya que están destinado a medir y comparar el procesador.

Los resultados con hdparm son los siguientes:
Con disco duro TOSHIBA:
#sudo hdparm -Tt /dev/sda
Timming cached reads: 2022 MB in 2.00 seconds = 1011.18 MB/seg
Timming buffered disk reads: 94 MB in 3.04 seconds = 30.95 MB/seg

Con tarjeta SDHC 8GB clase 10:

#sudo hdparm -Tt /dev/sda
Timming cached reads: 1874 MB in 2.00 seconds = 937.07 MB/seg
Timming buffered disk reads: 28 MB in 3.17 seconds = 8.85 MB/seg

Concluyendo: la tarjeta es ciertamente más lenta con bastante diferencia. Otra cosa es el consumo. Con una SDHC la batería puede llegar a duplicar su autonomía.

Los resultados de hdparm con un disco WDC WD6401AALS-00L3B2 de 3.5" son los siguientes:

Timming cached reads: 1228 MB in 2.00 seconds = 613.75 MB/seg
Timming buffered disk reads: 332 MB in 3.17 seconds = 107.06 MB/seg

Más herramientas de benchmarking

UNITY no funciona después de actualización automática teniendo drivers de NVIDIA

Después de una actualización automática, al reiniciar el sistema, el escritorio está visible y operativo pero se  ha iniciado con Ubuntu clásico en lugar de UNITY que era el escritorio por defecto que estaba configurado.

Para comprobar si el driver gráfico y el hardware instalado es capaz de ejecutar UNITY puedes escribir el comando:

#/usr/lib/nux/unity_support_test -p



Si no se puede iniciar el modo gráfico de ninguna forma, podemos intentar recuperar la configuración segura accediendo a un terminal desde el modo de recuperación y escribiendo:

#sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.copia
#sudo cp /etc/X11/xorg.failsafe /etc/X11/xorg.conf


Se pueden ver cuáles han sido las últimas actualizaciones en el fichero /var/log/dpkg.log

En mi caso, las únicas actualizaciones que considero que han podido cambiar la configuración establecida están relacionadas con la instalación de mesa-dri puesto que ninguna otra aparece en el fichero relacionada con el sistema gráfico.

En todo caso, solución pasó por reinstalar el driver de NVIDIA. Paso a paso:

En primer lugar, abrir una consola de texto con CTRL-ALT-2 o acceder al sistema usando el modo de recuperación y desactivar en el entorno gráfico escribiendo:

#sudo telinit 3

A continuación, eliminamos todo rastro del driver antiguo:

#sudo apt-get remove --purge nvidia-*

Configuramos las X de nuevo con:

#sudo Xorg -configure

y por último reinstalamos el driver que deberemos tener previamente descargado en algún directorio:

#sudo sh NVIDIA-Linux-x86-285-05-09

La versión del driver puede variar en función de la tarjeta gráfica o de la versión de Ubuntu.

Chromium bloqueado en pantalla completa

En Ubuntu 11.04, con dos monitores configurados con diferente resolución, el navegador Chromium se queda bloqueado en modo pantalla completa al maximizarlo en el segundo monitor.

Parece ser un fallo de Compiz debido a que Chromium carece de barra de menu, en este link se reporta el bug.

 Hay varias alternativas para poder solucionarlo. Se mencionan en el comentario #34.

Una de ellas, consiste en iniciar chromium con un directorio de configuración temporal, diferente del habitual del usuario, por ejemplo:

#mkdir /tmp/chromium

#/usr/bin/chromium-browser --user-data-dir=/tmp/chromium

Mientras está ejecutándose el navegador, abrimos otra ventana del terminal y copiamos la configuración creada por defecto de forma temporal al sitio del usuario.

#cp -R /tmp/chromium/* ~/.config/chromium

Con esto, reemplazamos la configuración del usuario que impedía cambiar el modo de pantalla completa por la configuración por defecto del navegador.

Otra posible opción consiste en crear un panel en el segundo monitor de forma tal que el navegador no se podrá mostrar a pantalla completa en este monitor.

Para crear un panel en el segundo monitor, crearlo en el primero y moverlo al segundo tal como se describe aquí.

Instalar Microsoft Fingerprint reader en Ubuntu 11.04

El procedimiento seguido está descrito aquí.

Aún no tiene soporte para las aplicaciones Gnome que hacen uso de los privilegios de administrador como Synaptic o Update pero se describe un atajo para solucionarlo de forma temporal.

Configurar un monitor como primario en un sistema con dos monitores

En una instalación de Ubuntu 11.04 con dos monitores, por ejemplo, al conectar un monitor externo a un portátil, se quiere configurar como primario uno de los dos monitores.

Usamos:

#lspci | grep VGA

para conocer el modelo de nuestra tarjeta gráfica

A continuación,

#xrandr --prop

para conocer el nombre asignado a cada uno de las salidas de la tarjeta gráfica. En mi caso, VGA-0, DVI-0 y S-video

Para establecer como primario el monitor conectado a la salida DVI-0, utilizamos el comando:

#xrandr --output DVI-0 --primary

Este cambio no es permanente, quiere decir, que al reiniciar el sistema gráfico, los cambios se perderán.

Una posible solución sería incluir este comando en las aplicaciones al inicio:

Sistema->Preferencias->Aplicaciones al inicio

y crear una nueva tarea al inicio donde ejecutaremos el comando.

Más info en este post.

bad geometry al montar un disco usb en Ubuntu

Al conectar un disco duro usb que contiene información valiosa se muestra el siguiente mensaje al hacer dmesg:

EXT4-fs (sdc): bad geometry: block count 156282966 exceeds size of device (156282965 blocks)

Este dispositivo fue formateado cuando estaba conectado al puerto SATA y de hecho, cuando lo conecto a un puerto eSATA, la información es accesible sin problemas.

Lo cierto es que todo indica que el número real de bloques del dispositivo es 156282966, esto se puede comprobar haciendo:

#sudo dumpe2fs /dev/sdc | less

En cambio, al ejectuarlo y buscar el último inode se puede observar que el último grupo ocupa desde los bloques 156270592 hasta el 156282965, ejecutando

#sudo e2fsck -v /dev/sdc

encuentra errores: puede ser que el superbloque, o la tabla de particiones, estén corruptos!

Si tratamos de montarlo:

#sudo mount /dev/sdc /mnt/tmp

devuelve error: superbloque incorrecto

El error también se muestra cuando ejecutamos:

#sudo fsck.ext4 /dev/sdc

Devuelve:

El tamaño del sistema de ficheros (de acuerdo con el superbloque) es de 156282966 bloques
El tamaño físico del dispositivo es de 156282965 bloques

Para mostrar información del sistema de ficheros se puede utilizar mke2fs con la opción -n, esto mostrará dónde se encuentran las copias de respaldo del superbloque:

#sudo mke2fs -n /dev/sdc

Para comprobar la tabla de particiones en el dispositivo usamos:

#sudo sfdisk -l /dev/sdc

La información que muestra es la siguiente:

Disco /dev/sdc: 77825 cilindros, 255 cabezas, 63 sectores/pista
sfdisk: ERROR: el sector 0 no tiene una firma msdos
/dev/sdc: tipo de tabla de particiones no reconocido
No se ha encontrado ninguna partición

Ya sabía que el disco no tenía creada ninguna partición

Máximo permitido: 1250263725

Después de probar varias opciones, entre ellas, reescribir una nueva tabla de particiones con:

#sudo sfdisk -f /dev/sdc -O PT.save < PT.txt

donde PT.txt contiene una sola línea que indica lo siguiente:

#partition table of /dev/sdc
unit: sectors
/dev/sdc1 : start=                1, size=1250263724, Id=83

donde 1250263724 es el número de sectores menos 1, que se calcula multiplicando el número de bloques por 8.

Hecho esto, se crean cuatro particiones en el disco.

Para solucionar el problema, lo que haremos será cambiar el tamaño del sistema de ficheros para que coincida con el tamaño del dispositivo con:

#sudo resize2fs -f /dev/sdc 156282965

el nuevo valor es el indicado en dmesg como el tamaño real del dispositivo.

Información sobre el procedimiento
Información general sobre la recuperación de particiones

Instalar un nuevo disco duro en Ubuntu

Conectar el disco duro y asegurarse de que éste es detectado por la BIOS al iniciar el equipo. Para determinar cómo Ubuntu recono reconoce el disco, usamos el comando:

# sudo lshw -C disk

Busca en la lista de discos conectados el disco recién añadido y escribe el nombre del dispositivo que aparece junto a logical name, ese será el nombre por el que Ubuntu reconocerá el nuevo disco.

Particionando el disco
Elige si prefieres una única paritción o si utilizarás varias particiones. Iniciar el particionado en modo gráfico con palimpsest o:

Sistema->Administración->Utilidad de discos

Realizar el particionado haciendo click derecho sobre el dispositivo. Si se va a utilizar todo el disco, seleccionar la opción No particionar. .

A continuación formatear el volumen.

Elegir el sistema de archivos, ext3 o ext4 o fat32 si se piensa en que el disco sea compatible con Windows

A continuación, crear el punto de montaje. Normalmente en /media

# sudo mkdir /media/nevera

Realizar una copia de seguridad del fichero /etc/fstab y editarlo con:

# sudo nano /etc/fstab

 Incluir la siguiente línea:

/dev/sdb                    /media/nevera                    defaults                    0                2

El número 2 al final de la línea indica que debe realizarse una pequeña comprobación del sistema de archivos con cada inicio del sistema.

Guardar el archivo y montar el dispositivo con:

# sudo mount -a 

Reiniciar y comprobar si el dispositivo se monta correctamente.

Conocer el uid y gid de un usuario

A veces puede resultar necesario conocer el uid y gid del usuario. Utiliza el comando:

# id

Devuelve información sobre el usuario actual. Si quieres conocer el uid y gid de todos los usuarios del sistema, tendrás que visualizar el fichero passwd:

# cat /etc/passwd


Para copiar todo un directorio con sus subdirectorios a otro:

# cp -arvf origen destino

Obtener el offset para montar un disco formateado en HP MediaVault

Este post está directamente extraído de un artículo de Steven Pritchard. Un disco montado en un HP MediaVault MV2010 tiene formato reiserfs pero éste no comienza al inicio del disco sino que el sistema de ficheros se ubica tras un offset. El procedimiento para averiguarlo consiste en localizar una cadena de texto en el dispositivo que indica el inicio. La cadena a localizar es "ReIsErFs", "ReIsEr2Fs" ó "ReIsEr3Fs".

Para localizarla se puede utilizar el programa hexedit.

# sudo apt-get install hexedit

Suponiendo que tenemos conectado el disco duro en /dev/sdb

# hexedit /dev/sdb

Pulsar el tabulador para cambiar al campo de visualización ASCII, pulsar / para buscar e introducir la cadena a buscar, en nuestro caso "ReIsErFs"

El editor hexedit indica en la última línea la posición u offset donde la cadena ha sido encontrada. Por ejemplo, en 0x2685A034. Por tanto, el inicio del superbloque estará ubicado en 0x2685A000. Ahora ya tenemos el offset donde se encuentra la cadena, el inicio del sistema de ficheros estará situado 64K antes.

Para montar el sistema de ficheros:

# losetup -o $[646291456 - 65536] /dev/loop0 /dev/sdb
# mkdir /mnt/tmp
# mount -r -t reiserfs /dev/loop0 /mnt/tmp

El sistema de ficheros quedará accesible en /mnt/tmp