Монтирование раздела HFS + в Arch Linux

У меня проблемы с монтированием раздела hfs + в Arch Linux.

Когда я бегу, sudo mount -t hfsplus /dev/sda2 /mnt/macя получаю эту ошибку:

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.

Бег dmesg | tailдает:

[ 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

Есть ли способ смонтировать этот раздел?

РЕДАКТИРОВАТЬ :

Использование sudo mount -t hfsplus -o ro,loop,offset=409640,sizelimit=879631488 /dev/sda2 /mnt/macизбавляется от hfsplus: invalid secondary volume headerвdmesg | tail

linux mount arch-linux hfs+ ZuluDeltaNiner
источник

Ответы:

Вероятно, том HFS не монтируется, потому что раздел HFS обернут в том CoreStorage (по умолчанию начиная с OS X 10.10). Вы можете проверить, так ли это, с выводом fdisk -l:

HFS + использует два заголовка тома: один 1024 на устройстве и дополнительный 1024 на конце устройства . Согласно спецификации, при монтировании раздела вторичный заголовок должен находиться точно в 1024 байтах от конца раздела, но с CoreStorage, обертывающим том HFS, это уже не так, поэтому он прерывается. Вы можете перейти -o sizelimit=Nк, mountчтобы вручную указать размер тома HFS и исправить это, но как получить магическое значение для N?

testdiskУтилита может сканировать для разделов, намекая на то, где раздел HFS действительно заканчивается. Будьте осторожны - неправильный выбор параметров в testdisk может повредить вашу таблицу разделов!

Запустите TestDisk с помощью testdisk /dev/sdX, а затем OKвыберите диск
Выберите Intelдля MBR или EFI GPTдля дисков в формате GPT
Нажмите Analyse и затемQuick Search
Через несколько секунд он должен распечатать найденные разделы:

Указанный раздел выглядит очень близко (но немного меньше), чем реальный размер раздела 623463232 секторов, о котором сообщает fdisk -l ранее.

Поскольку выходные данные TestDisk используют сектора, нам нужно умножить его на размер логического сектора диска (обычно 512 или 4096 байт), чтобы получить размер тома HFS в байтах. Это значение дляN мы будем использовать -o sizelimit=Nпри монтировании тома HFS.

Если вы не знаете размер логического сектора вашего диска, проверьте вывод ~~второго~~ первого числа, fdisk -lуказанного в строке, показанной ниже:
Нажмите q несколько раз, чтобы выйти из программы
Смонтируйте диск: mount /dev/sdXn -t hfsplus -o ro,sizelimit=N

Стюарт Адам
источник

От пользователя edmonde : Этот рецепт отлично работал для меня, но мне пришлось настроить его, используя размер логического сектора (первое из двух чисел, в моем случае 512 против 4096), а не размер физического сектора для расчета общего размера тома. Я не уверен, почему, но это работало отлично.

fixer1234

Это исправило мою проблему. Другие ресурсы предлагали использовать offsetпараметр, который не работал в сочетании с этим, но с использованием только sizelimit установки количества байтов (байтов * секторов) работал как прелесть, даже для разделов не-CoreStorage

cdeszaq

Это не работает для меня. Я получаю mount failed: Unknown error -1и ничего в dmesg. hfsplusопределенно загружен.

Дан

+1 исправлено с использованием логического размера сектора

Джейк

Это решение работало нормально для меня до тех пор, пока обновление OSX не прекратило эту работу. У кого-нибудь еще была эта проблема? Любой совет?

Vik

Другой вариант - избавиться от CoreStorage, если вам доступна машина с OS X. Это также избавит от дешифрования, если вы используете его, и вам придется подождать, пока расшифровка не будет завершена (подключено к питанию и загружено в OS X, даже восстановление).

Вам нужно будет загрузиться с диска, который вам не подходит, желательно с восстановлением через Интернет (если доступно, команда-option-r при перезагрузке). Откройте терминал и выполните:

diskutil cs list

Вывод должен показать ваши тома CoreStorage и все, одним из них является его статус Revertible. Если это означает Да, то вы будете в хорошей форме, чтобы продолжить. Далее вы запустите:

diskutil cs revert /dev/ diskXsY

(Где X - номер диска, а Y - номер раздела).

После этого вы можете проверить его состояние с помощью той же команды «diskutil cs list». Если он не был зашифрован, он должен вернуться к стандартной компоновке раздела GPT, и вы можете попытаться снова смонтировать его в Arch. Он все равно должен регистрироваться в журнале, который останется доступным только для чтения, если вы хотите переключиться, что вы можете сделать это в Дисковой утилите.

Если он был зашифрован, процесс займет некоторое время, но «diskutil cs list» покажет вам прогресс в процентах.

У меня не было проблем с монтированием дисков и разделов не CoreStorage HFS + на Arch. В конце концов я переместил данные, переделил их как ext4 и вернул данные обратно к ним.

Кори Т
источник