Cómo corregir el estado 'medio expulsado' de una unidad no conectada

2

Tengo una unidad de respaldo que tengo configurada para no montar automáticamente (a través de la edición /etc/fstab )

Uso Superduper para montar la unidad, hacer copias de seguridad durante la noche y luego desmontar en la salida

Esta mañana abrí mi computadora portátil para ir a trabajar y encontré la unidad en este estado 'medio expulsado' de color gris:

Puedohacerclicconelbotónderechoyseleccionar'Expulsar"Copia de seguridad de TB"', pero no sucede nada. Desenchufé mi computadora portátil del muelle y me fui a trabajar. No tengo errores al desconectar.

Ahora estoy en el trabajo y el ícono aún está en gris, aunque la unidad ya no está conectada. 'Expulsar' todavía no hace nada.

Supongo que podría solucionarse solo si reinicio o simplemente reconecto y monto la unidad cuando llegue a casa.

La unidad no se muestra en la Utilidad de Discos en este momento.

Estoy en Mavericks 10.9.5

¿Alguna idea de cómo solucionar sin reiniciar? ¿Algún problema potencial cuando vuelva a montar el disco esta noche?

Los registros de SuperDuper no muestran ningún problema:

| 03:24:02 AM | Info | PHASE: 4. And Finally...
| 03:24:02 AM | Info | ...ACTION: Scheduling TB Backup to eject when SuperDuper! quits
| 03:24:02 AM | Info | ......COMMAND => Ejecting TB Backup
| 03:24:02 AM | Info | Copy complete.
    
pregunta Anentropic 24.07.2015 - 10:51

1 respuesta

1

Además de reiniciar el sistema, probablemente haya media docena de formas sencillas, confiables y perfectamente adecuadas para completar el proceso de detatching completo de una unidad que inesperadamente se detuvo prematuramente en el punto de desmontaje. Tuve dos comandos terminales que harían que el trabajo saliera de mi mente inmediatamente, y los conozco lo suficientemente bien como para no sentir la necesidad de volver a revisar las páginas de manual antes de teclear. Dicho esto, mi consejo es lidiar con la situación reiniciando el sistema. Deje que el sistema operativo ejecute la miríada de controles de integridad de apagado y arranque, así como procedimientos de seguridad y funciones de recuperación en varios pasos que ni siquiera tenemos idea de que existan. Aunque soy lo suficientemente aventurero para montar imágenes de disco de archivos de sombra en el kernel [ /usr/sbin/hdik ], me refiero a la autoridad de la estructura del sistema de archivos local cuando se trata de vigilar la integridad de mis unidades de respaldo.

También sugiero que antes de realizar cualquier acción directa en la unidad, compruebe el registro de SuperDuper. Si algo se hubiera ido, Terrible, Terriblemente mal, SuperDuper lo habría anunciado en ese momento, por lo que esa no es la razón para echarle un vistazo. Lo sugiero ante la extraña posibilidad de encontrar un indicio sobre el origen de la falla técnica.

Del mismo modo, considere la posibilidad de verificar /var/log/diskarbitrationd.log para su toma en los eventos recientes y la oportunidad de mayor iluminación. (Naturalmente, no mencionaré echar un vistazo de pasada al contenido de /etc/fstab .)

editar :: información complementaria

Los dos comandos que se me ocurrieron fueron umount ﹡ y diskutil.

Revisé la documentación de umount para asegurar que mi memoria de uso fuera razonablemente precisa. Me enfrenté a la revelación de que, por más o menos veinte años, había pasado por alto la sección de NOTAS de las páginas de manual, citada a continuación:

  

Debido a la naturaleza compleja e interconectada de Mac OS X, el desmontaje puede fallar con frecuencia. Se recomienda que diskutil (1) (como en, '' diskutil desmonte   / mnt '') se utilizará en su lugar.

¿Qué puedo decir? Debido a la naturaleza compleja e interconectada de mi capacidad cognitiva residual, puedo fallar con frecuencia.

En cuanto a diskutil, el comando en particular que habría emitido resultó ser válido: diskutil unmountDisk force [device] . Querrá consultar las páginas del manual para conocer la sintaxis y las opciones de uso completas.

Con respecto a la no existencia de /var/log/diskarbitrationd.log : aparentemente, tontamente descuidaste crearlo ... Oh ... espera ...

A veces [ver ¶ cuatro, arriba] olvido que este o ese proceso en segundo plano que tengo en ejecución no es parte de una instalación predeterminada del sistema operativo. Ese fue el caso aquí con el daemon del servidor de arbitraje de disco, ubicado en /usr/sbin/diskarbitrationd . No tiene sentido que te molestes ahora.

Si le interesa y, a su conveniencia, considere usar la Utilidad de Discos para examinar el esquema de partición y el sistema de archivos de la unidad de respaldo. Si existe más de un volumen en el dispositivo, lo que probablemente no sea así para una unidad de respaldo, mantenga presionada la tecla ⌘-Comando mientras hace clic en el nombre del dispositivo junto con los nombres de volumen sangrados debajo de él. Luego use la opción Verify Disk en la pestaña Primeros auxilios para verificar si hay errores en la unidad.

﹡ No es un error tipográfico.

    
respondido por el Doc G. 24.07.2015 - 13:03

Lea otras preguntas en las etiquetas