I did eventually move the data, repartition as ext4 and move the data back to them. I've had no issues mounting non-CoreStorage HFS+ drives and partitions on Arch myself. If it was encrypted the process will take a while but "diskutil cs list" will show you the progress as a percentage. It should still be journaled which will keep it read-only, if you want to toggle that you can do so in Disk Utility. If it wasn't encrypted it should already be back to a standard GPT partition layout and you can try to mount it again in Arch. You can check its status afterwards with the same "diskutil cs list" command. (Where X is the disk number and Y is the partition number). Next you would run: diskutil cs revert /dev/ diskXsY If it indicates Yes then you'll be in good shape to proceed. The output should show your CoreStorage volumes and all, one of them is its Revertible status. Open up the terminal and do a: diskutil cs list You would need to boot to a disk that isn't the one in mind, preferably internet recovery (if available, command-option-r on reboot). This would also get rid of decryption if you're using it and you would have to wait until the decrypt is finished (plugged into power and booted into OS X, even recovery). Mount the disk: mount /dev/sdXn -t hfsplus -o ro,sizelimit=NĪnother option is to get rid of CoreStorage if an OS X machine is available to you.Press q several times to exit the program If you don't know your drive's logical sector size, check the output of the second first number reported by fdisk -l on the line shown below: That's the value for N we'll use for -o sizelimit=N when mounting the HFS volume. The partition indicated looks awfully close to (but slightly smaller) than the real partition size of 623463232 sectors reported by fdisk -l earlier.īecause the TestDisk output uses sectors, we'll need to multiply it by the drive's logical sector size (typically 512 or 4096 bytes) to get the HFS volume size in bytes. Select Intel for MBR or EFI GPT for GPT formatted drivesĪfter a few moments it should print it the partitions found:.Launch TestDisk with testdisk /dev/sdX, and then OK to select the drive.Be wary - selecting the wrong options in testdisk can damage your partition table! The testdisk utility can scan for partitions, hinting at where the HFS partition really ends. You can pass -o sizelimit=N to mount to manually specify the HFS volume size and fix this, but how does one get the magic value for N? Per the spec, when mounting a partition the secondary header is expected to be to be exactly 1024 bytes from the partition's end, but with CoreStorage wrapping the HFS volume that's no longer the case so it aborts. HFS+ uses two volume headers, one 1024 into the device and the secondary 1024 from the end of the device. You can verify if this is the case with the output of fdisk -l: It's likely that the HFS volume is not mounting because the HFS partition is wrapped in a CoreStorage volume (the default since OS X 10.10). Using sudo mount -t hfsplus -o ro,loop,offset=409640,sizelimit=879631488 /dev/sda2 /mnt/mac gets rid of hfsplus: invalid secondary volume header in dmesg | tail hfsplus: invalid secondary volume header perf interrupt took too long (2503 > 2495), lowering kernel.perf_event_max_sample_rate to 50100 cfg80211: Exceeded CRDA call max attempts. cfg80211: Calling CRDA to update world regulatory domain Running dmesg | tail gives: cfg80211: Calling CRDA to update world regulatory domain In some cases useful info is found in syslog - try Missing codepage or helper program, or other error When I run sudo mount -t hfsplus /dev/sda2 /mnt/mac I get this error: mount: wrong fs type, bad option, bad superblock on /dev/sda2, ![]() I'm having some problems with mounting an hfs+ partition on Arch Linux.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |