Tengo una unidad de respaldo que he configurado para que no se monte 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 al salir
Esta mañana abrí mi computadora portátil para ir a trabajar y encontré la unidad en este estado gris 'medio expulsado':
Puedo hacer clic con el botón derecho y seleccionar 'Expulsar "Copia de seguridad de TB", pero no sucede nada. Desconecté mi computadora portátil del muelle en casa y me fui a trabajar. No obtuve errores al desconectar.
Ahora estoy en el trabajo y el ícono todavía está allí en estado gris, a pesar de que la unidad ya no está conectada. 'Expulsar' todavía no hace nada.
Supongo que podría solucionarse si reinicio o simplemente vuelvo a conectar y monte la unidad cuando llegue a casa.
La unidad no aparece en Disk Utility en este momento.
Estoy en Mavericks 10.9.5
¿Alguna idea de cómo solucionarlo 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.
killall Finderen una Terminal?Respuestas:
Además de reiniciar el sistema, es probable que haya media docena de formas directas, confiables y perfectamente apropiadas para completar el proceso de desconexión completa de una unidad que se detuvo inesperadamente de forma prematura en el momento del desmontaje. Me vinieron a la mente dos comandos de terminal que harían el trabajo de inmediato, y los conozco lo suficientemente bien como para no sentir la necesidad de revisar las páginas del manual antes de escribir. Dicho esto, mi consejo es tratar la situación ... reiniciando el sistema. Deje que el sistema operativo ejecute la miríada de comprobaciones de integridad de apagado y arranque y procedimientos de seguridad de tiempo de arranque de varios pasos y funciones de recuperación que ni siquiera sabemos que existan. Si bien soy lo suficientemente aventurero para montar imágenes de disco de archivos de sombra en el kernel [
/usr/sbin/hdik], Difiero a la autoridad de la estructura del sistema de archivos local cuando se trata de vigilar la integridad de mis unidades de respaldo.Sugiero además que antes de participar en cualquier acción directa en el disco, verifique el registro de SuperDuper. Si algo hubiera salido terriblemente mal, SuperDuper lo habría anunciado en ese momento, así que esa no es la razón para echar un vistazo. Lo sugiero por la extraña posibilidad de encontrar una pista sobre la fuente del problema.
Del mismo modo, considere verificar
/var/log/diskarbitrationd.logsu opinión sobre los acontecimientos recientes y la oportunidad de una mayor iluminación. (Naturalmente, no mencionaré echar un vistazo al contenido de/etc/fstab).editar :: información suplementaria
Los dos comandos que se me ocurrieron fueron
umount﹡ ydiskutil.Revisé la documentación para
umountasegurarme de que mi memoria de su uso era razonablemente precisa. Me enfrenté a la revelación de que, durante unos veinte años más o menos, había pasado por alto la sección de NOTAS de las páginas del manual, completamente citada a continuación:¿Qué puedo decir? Debido a la naturaleza compleja y entretejida de mi capacidad cognitiva residual, puedo fallar con frecuencia.
En cuanto a diskutil, el comando en particular me hubiera emitido resultó ser uno válido:
diskutil unmountDisk force [device]. Querrá consultar las páginas del manual para conocer las opciones de uso completo y la sintaxis.Con respecto a la inexistencia de
/var/log/diskarbitrationd.log: aparentemente, tontamente descuidaste crearlo ... Oh ... espera ...A veces [ver ¶ cuatro, arriba] olvido que este o aquel proceso en segundo plano que estoy ejecutando no es parte de una instalación predeterminada del sistema operativo. Ese fue el caso aquí con el demonio del servidor de arbitraje de disco, ubicado en
/usr/sbin/diskarbitrationd. No tiene sentido que te molestes con eso ahora.Si lo desea 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 while mientras hace clic en el nombre del dispositivo junto con los nombres de volumen sangrados debajo de él. Luego use la
Verify Diskopción en la pestaña Primeros auxilios para verificar si la unidad tiene errores.﹡ No es un error tipográfico.
fuente
/var/log/diskarbitrationd.logno existe./etc/fstabes exactamente como lo dejé. El registro de SuperDuper no muestra ningún problema (ahora agregué esto a la pregunta)