Montaje de partición HFS + en Arch Linux

Tengo algunos problemas con el montaje de una partición hfs + en Arch Linux.

Cuando ejecuto sudo mount -t hfsplus /dev/sda2 /mnt/macme sale este error:

mount: wrong fs type, bad option, bad superblock on /dev/sda2,
   missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

Correr dmesg | tailda:

[ 6645.183965] cfg80211: Calling CRDA to update world regulatory domain
[ 6648.331525] cfg80211: Calling CRDA to update world regulatory domain
[ 6651.479107] cfg80211: Calling CRDA to update world regulatory domain
[ 6654.626663] cfg80211: Calling CRDA to update world regulatory domain
[ 6657.774207] cfg80211: Calling CRDA to update world regulatory domain
[ 6660.889864] cfg80211: Calling CRDA to update world regulatory domain
[ 6664.007521] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
[ 6857.870580] perf interrupt took too long (2503 > 2495), lowering kernel.perf_event_max_sample_rate to 50100
[11199.621246] hfsplus: invalid secondary volume header
[11199.621251] hfsplus: unable to find HFS+ superblock

¿Hay alguna manera de montar esta partición?

EDITAR :

Usando sudo mount -t hfsplus -o ro,loop,offset=409640,sizelimit=879631488 /dev/sda2 /mnt/macse deshace de hfsplus: invalid secondary volume headerendmesg | tail

linux mount arch-linux hfs+ ZuluDeltaNiner
fuente

Respuestas:

Es probable que el volumen HFS no se monte porque la partición HFS está envuelta en un volumen CoreStorage (el valor predeterminado desde OS X 10.10). Puede verificar si este es el caso con la salida de fdisk -l:

HFS + usa dos encabezados de volumen, uno 1024 en el dispositivo y el 1024 secundario desde el extremo del dispositivo . Según la especificación, cuando se monta una partición, se espera que el encabezado secundario sea exactamente 1024 bytes desde el final de la partición, pero con CoreStorage ajustando el volumen HFS, ese ya no es el caso, por lo que aborta. Puede pasar -o sizelimit=Na mountespecificar manualmente el tamaño del volumen HFS y corregir esto, pero ¿cómo se obtiene el valor mágico N?

La testdiskutilidad puede buscar particiones, insinuando dónde termina realmente la partición HFS. Tenga cuidado: ¡seleccionar las opciones incorrectas en testdisk puede dañar su tabla de particiones!

Inicie TestDisk con testdisk /dev/sdX, y luego OKpara seleccionar la unidad
Seleccione Intelpara MBR o EFI GPTpara unidades con formato GPT
Presione Analysey luegoQuick Search
Después de unos momentos, debería imprimir las particiones encontradas:

La partición indicada se ve terriblemente cercana (pero un poco más pequeña) que el tamaño de partición real de 623463232 sectores reportados fdisk -lanteriormente.

Debido a que la salida de TestDisk usa sectores, necesitaremos multiplicarla por el tamaño del sector lógico de la unidad (típicamente 512 o 4096 bytes) para obtener el tamaño del volumen HFS en bytes. Ese es el valor Nque usaremos -o sizelimit=Nal montar el volumen HFS.

Si no conoce el tamaño del sector lógico de su unidad, verifique la salida del ~~segundo~~ primer número informado fdisk -len la línea que se muestra a continuación:
Presione qvarias veces para salir del programa
Monta el disco: mount /dev/sdXn -t hfsplus -o ro,sizelimit=N

Stewart Adam
fuente

Del usuario edmonde : Esta receta funcionó muy bien para mí, pero tuve que ajustarla usando el tamaño del sector lógico (el primero de dos números, en mi caso 512 versus 4096) en lugar del tamaño del sector físico para calcular el tamaño del volumen total. No estoy seguro de por qué, pero funcionó muy bien.

fixer1234

Esto solucionó mi problema. Otros recursos sugirieron usar un offsetparámetro, que no funcionó cuando se combinó con esto, pero usar solo sizelimit el número de bytes (bytes * sectores) funcionó de maravilla, incluso para particiones que no son CoreStorage

cdeszaq

Esto no funciona para mi. Llego mount failed: Unknown error -1y nada en dmesg. hfsplusDefinitivamente está cargado.

Dan

+1 solucionado mediante el uso de tamaño de sector lógico

Jake

Esta solución funcionó bien para mí hasta después de una actualización en OSX que dejó de funcionar. ¿Alguien mas ha tenido este problema? ¿Algún consejo?

Vik

Otra opción es deshacerse de CoreStorage si tiene disponible una máquina con OS X. Esto también eliminaría el descifrado si lo está utilizando y tendría que esperar hasta que finalice el descifrado (conectado a la alimentación y arrancado en OS X, incluso recuperación).

Tendría que arrancar en un disco que no es el que tiene en mente, preferiblemente recuperación de Internet (si está disponible, command-option-r en el reinicio). Abre la terminal y haz un:

diskutil cs list

El resultado debe mostrar sus volúmenes de CoreStorage y todo, uno de ellos es su estado Revertible. Si indica Sí, estará en buena forma para continuar. Luego correría:

diskutil cs revert /dev/ diskXsY

(Donde X es el número de disco e Y es el número de partición).

Puede verificar su estado después con el mismo comando "diskutil cs list". Si no estaba encriptado, ya debería volver a un diseño de partición GPT estándar y puede intentar montarlo nuevamente en Arch. Todavía debería estar registrado, lo que lo mantendrá de solo lectura, si desea alternar, puede hacerlo en la Utilidad de Discos.

Si fue encriptado, el proceso tomará un tiempo, pero "diskutil cs list" le mostrará el progreso como un porcentaje.

No he tenido problemas para montar unidades y particiones que no sean CoreStorage HFS + en Arch. Eventualmente moví los datos, los repartí como ext4 y los devolví a ellos.

Cory T
fuente