在Arch Linux上挂载HFS +分区

我在Arch Linux上安装hfs +分区时遇到一些问题。

运行时出现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

— ZuluDeltaNiner
source

Answers:

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 /dev/sdX，然后OK选择驱动器
选择Intel用于MBR或EFI GPTGPT格式化的驱动器
按Analyse然后Quick Search
片刻之后，它应该将找到的分区打印出来：

指示的分区看上去比fdisk -l早期报告的623463232扇区的实际分区大小非常接近（但略小）。

由于TestDisk输出使用扇区，因此我们需要将其乘以驱动器的逻辑扇区大小（通常为512或4096字节），以获得以字节为单位的HFS卷大小。这就是安装HFS卷时N将使用的值-o sizelimit=N。

如果您不知道驱动器的逻辑扇区大小，请检查以下行中报告的~~第二个~~ 第一个数字的输出fdisk -l：
按q几次退出程序
挂载磁盘： mount /dev/sdXn -t hfsplus -o ro,sizelimit=N

— 斯图尔特·亚当
source

来自用户edmonde的建议：此配方对我来说非常有效，但是我不得不使用逻辑扇区大小（在我的情况下为512与4096，是两个数字中的第一个）来调整它，而不是使用物理扇区大小来计算总卷大小。我不确定为什么，但是效果很好。

— fixer1234 '16

这解决了我的问题。建议使用其他offset参数的其他资源，该参数与该参数结合使用时不起作用，但仅使用sizelimit设置为字节数（字节*扇区）的方法，即使对于非CoreStorage分区也是如此，非常引人入胜

— cdeszaq

这对我不起作用。我得到了mount failed: Unknown error -1，什么也没有dmesg。hfsplus肯定是加载。

— 丹

通过使用逻辑扇区大小来固定+1

— 杰克

在OSX更新停止该工作之前，该解决方案对我来说一直很好。其他人有这个问题吗？有什么建议吗？

— Vik

如果您可以使用OS X计算机，则另一种选择是放弃CoreStorage。如果您正在使用它，它也将摆脱解密，而您必须等到解密完成（插入电源并引导进入OS X，甚至恢复）。

您将需要引导至不打算使用的磁盘，最好是Internet恢复（如果可用，请在重新引导时使用command-option -r）。打开终端并执行以下操作：

diskutil cs list

输出应显示您的CoreStorage卷，并且全部，其中之一是其可恢复状态。如果显示“是”，那么您将处于良好状态。接下来，您将运行：

diskutil cs revert /dev/ diskXsY

（其中X是磁盘号，Y是分区号）。

之后，您可以使用相同的“ diskutil cs list”命令检查其状态。如果未加密，则应该已经回到标准的GPT分区布局，您可以尝试再次将其安装在Arch中。它仍应记录在日志中，以使其保持只读状态。如果要切换，可以在“磁盘工具”中进行。

如果已加密，则该过程将花费一些时间，但“ diskutil cs list”将以百分比形式显示进度。

我自己在Arch上安装非CoreStorage HFS +驱动器和分区没有任何问题。我最终确实移动了数据，将其重新分区为ext4并将数据移回了它们。

— 科里·T
source