Montowanie partycji HFS + na Arch Linux

Mam problemy z zamontowaniem partycji hfs + w Arch Linux.

Po uruchomieniu sudo mount -t hfsplus /dev/sda2 /mnt/macpojawia się ten błąd:

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.

Bieganie dmesg | taildaje:

[ 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

Czy istnieje sposób na zamontowanie tej partycji?

EDYCJA :

Korzystanie sudo mount -t hfsplus -o ro,loop,offset=409640,sizelimit=879631488 /dev/sda2 /mnt/macpozbywa hfsplus: invalid secondary volume headersiędmesg | tail

— ZuluDeltaNiner
źródło

Odpowiedzi:

Prawdopodobnie wolumin HFS nie jest montowany, ponieważ partycja HFS jest owinięta w wolumin CoreStorage (domyślny od OS X 10.10). Możesz sprawdzić, czy tak jest w przypadku danych wyjściowych fdisk -l:

HFS + wykorzystuje dwa nagłówki woluminów, jeden 1024 do urządzenia, a drugi 1024 z końca urządzenia . Zgodnie ze specyfikacją, podczas montowania partycji dodatkowy nagłówek powinien znajdować się dokładnie 1024 bajty od końca partycji, ale z CoreStorage owijającym wolumin HFS, który już nie jest, więc przerywa. Możesz przejść -o sizelimit=Ndo, mountaby ręcznie określić rozmiar woluminu HFS i to naprawić, ale jak uzyskać magiczną wartość N?

testdiskNarzędzie może skanować do partycji, sugerując gdzie partycja HFS naprawdę kończy. Zachowaj ostrożność - wybranie niewłaściwych opcji w dysku testowym może uszkodzić tablicę partycji!

Uruchom TestDisk za pomocą testdisk /dev/sdX, a następnie, OKaby wybrać dysk
Wybierz Inteldla MBR lub EFI GPTdla dysków sformatowanych GPT
Naciśnij, Analysea następnieQuick Search
Po kilku chwilach powinien wydrukować znalezione partycje:

Wskazana partycja wygląda okropnie blisko (ale nieco mniej) niż rzeczywisty rozmiar partycji 623463232 sektorów zgłoszony fdisk -lwcześniej.

Ponieważ dane wyjściowe TestDisk używają sektorów, będziemy musieli pomnożyć je przez rozmiar sektora logicznego dysku (zwykle 512 lub 4096 bajtów), aby uzyskać rozmiar woluminu HFS w bajtach. To jest wartość, Nktórej użyjemy -o sizelimit=Npodczas montowania woluminu HFS.

Jeśli nie znasz rozmiaru sektora logicznego dysku, sprawdź wynik ~~drugiego~~ pierwszego numeru zgłoszonego przez fdisk -lw poniższym wierszu:
Naciśnij qkilka razy, aby wyjść z programu
Zamontuj dysk: mount /dev/sdXn -t hfsplus -o ro,sizelimit=N

— Stewart Adam
źródło

Od użytkownika edmonde : Ten przepis działał dla mnie świetnie, ale musiałem go ulepszyć, używając logicznego rozmiaru sektora (pierwsza z dwóch liczb, w moim przypadku 512 w porównaniu z 4096) w przeciwieństwie do rozmiaru sektora fizycznego, aby obliczyć całkowity rozmiar woluminu. Nie jestem pewien dlaczego, ale zadziałało świetnie.

— fixer1234

To naprawiło mój problem. Inne zasoby sugerowały użycie offsetparametru, który nie działał w połączeniu z tym, ale użycie tylko sizelimit ustawionej liczby bajtów (bajtów * sektorów) działało jak urok, nawet dla partycji innych niż CoreStorage

— cdeszaq

To mi nie działa. Dostaję mount failed: Unknown error -1i nic dmesg. hfsplusjest zdecydowanie załadowany.

— Dan

+1 naprawione przez użycie logicznego rozmiaru sektora

— Jake

To rozwiązanie działało dla mnie dobrze do czasu aktualizacji systemu OSX, która przestała działać. Czy ktoś jeszcze miał ten problem? Jakakolwiek rada?

— Vik

Inną opcją jest pozbycie się CoreStorage, jeśli dostępna jest maszyna OS X. Pozbyłby się również deszyfrowania, jeśli go używasz i musiałbyś poczekać, aż deszyfrowanie zostanie zakończone (podłączone do zasilania i uruchomione w OS X, nawet odzyskiwanie).

Będziesz musiał uruchomić komputer z dysku, który nie jest tym, o którym mowa, najlepiej odzyskiwanie przez Internet (jeśli jest dostępne, polecenie-opcja-r przy ponownym uruchomieniu). Otwórz terminal i wykonaj:

diskutil cs list

Dane wyjściowe powinny pokazywać woluminy CoreStorage i wszystkie, jeden z nich ma status Odwracalny. Jeśli wskazuje Tak, będziesz w dobrej formie, aby kontynuować. Następnie uruchomisz:

diskutil cs revert /dev/ diskXsY

(Gdzie X to numer dysku, a Y to numer partycji).

Możesz sprawdzić jego status za pomocą tego samego polecenia „diskutil cs list”. Jeśli nie był zaszyfrowany, powinien już wrócić do standardowego układu partycji GPT i możesz spróbować zainstalować go ponownie w Arch. Nadal powinien zostać zapisany w dzienniku, co spowoduje, że będzie on dostępny tylko do odczytu, jeśli chcesz przełączać to w Narzędziu dyskowym.

Jeśli został zaszyfrowany, proces ten potrwa chwilę, ale „lista diskutil cs” pokaże postęp w procentach.

Sam nie miałem problemów z montażem dysków i partycji innych niż CoreStorage HFS + w Arch. W końcu przeniosłem dane, dokonałem podziału jako ext4 i przenieśliłem dane z powrotem do nich.

— Cory T.
źródło