Open GoogleCodeExporter opened 9 years ago
Thanks for the report.
The output from diskutil looks weird. It lists all your disks as
FDisk_partition, but these should all be GUID_partition_scheme. While you can
use FDisk partitions in a ZFS pool, auto mounting is only supported with the
GUID partition scheme.
How did you performed step 3 in your list of steps? Did you gave the partition
names to the zpool command, or full disk names?
What is the output of "zpool status -v" after import?
Can you check if you have a /System/Library/Filesystems/zfs.fs entry?
Original comment by googlelogin@bjoern-kahl.de
on 11 Dec 2013 at 10:39
Ok so I had step by step typed up for you and well it bombed. In short....:)
Also of note, this is a early 2009 (4,1) mac pro dual xeon currently with 24
gigs of ram, so I think I can rule out memory issues :)
Can you check if you have a /System/Library/Filesystems/zfs.fs entry? YES
Prior to any reboot if I format the drive according to the Getting started
guide:
diskutil partitiondisk /dev/disk2 GPTFormat ZFS %noformat% 100%
Started partitioning on disk disk2
Creating partition map
[ + 0%..10%..20%..30%..40%..50%..60%..70%..80%..90%..100% ]
Finished partitioning on disk disk2
/dev/disk2
#: type name size identifier
0: GUID_partition_scheme *9.4 GB disk2
1: EFI 200.0 MB disk2s1
2: ZFS 9.0 GB disk2s2
I get the expected results no problem on all 7 drives.
I create the Zpool, I have done it with drives and partitions prior to
reformatting Mavericks.
After reformatting, I created the pools with just drive, thought I read that
somewhere on the web.
sudo zpool create data raidz2 disk0 disk1 disk2 disk3 disk5 disk6 disk7
After reboot of mac Pool is gone and DiskUtil list looks like my first post.
zpool import -f data - works and I see my raid and the data.
So my next step was to reformat drives again diskUtil looks correct with
GUID_partition_scheme and zfs
sudo zpool create data raidz2 disk0s2 disk1s2 disk2s2 disk3s2 disk5s2 disk6s2
disk7s2
My zpool was their no errors on status, my test data was intact.
Rebooted.
and mac rebooted, and rebooted, I could not see the crash message but just keep
rebooting.
Next my brilliant idea was to go back to lion and start fresh, forgot to backup
the doc I spent writing you this morning....
So got lion up and running installed MacZFS-74.3.2b.pkg, it like the install,
diskutil looked great, did import no problem test data intact.
Reboot, crash. was able to take picture of screen, not sure if their is
anything that would be helpful.
Reinstalled OS Lion....again :) Installed MacZFS-74.3.0.pkg, diskutil list
looked great.
Rebooted.
Zpool Mounted no import needed, data is their. SUCCESS
I am not updated to Mountain Lion MacZFS-74.3.0.pkg is working fine and my test
data is their.
It has got to be something in the new version.
Granted my problem is solved by going back to Mountain Lion but I would like to
be at Mavricks at some point.
Is their anything I can provide you that may help anyone else?
James
Original comment by mustn...@gmail.com
on 12 Dec 2013 at 8:56
just chiming in to say i'm running into the same issue on Mavericks.
Tried reinstalling, reformatting drive, etc.
All appears fine, read/writes are fast, but after restarting the machine the
zpool disappears.
I've also tried installing the startup scripts.
Software OS X 10.9 (13A603)
Processor 3.33 GHz 6-Core Intel Xeon
Memory 8 GB 1333 MHz DDR3 ECC
here is my zfs.fs file if that helps: http://cl.ly/T0aF
Original comment by m...@mike-tucker.com
on 17 Dec 2013 at 7:23
Attachments:
Hello ,
I have OS X 10.8 and ZFS is working more than a year without any problem. After
i install new 10.9 and install latest package MacZFS-74.3.2b.pkg and reboot i
get Kernel Panic.
To boot i login in safe mode and delete the zfs.kext from
System/Library/Extensions . Tried older versions but they are not compatible
with OS X 10.9.
After installation i can import my ZFS pool and everything is working normally
until i reboot the machine ):
Original comment by valentin...@gmail.com
on 17 Dec 2013 at 9:22
Dear valentin.hristev,
can you attach one of the panic logs you got after reboot?
Should be in /Library/Logs/DiagnosticReports/ or /Library/Logs/CrashReporter/
The older version (since 74.3.0 at least, probably 74.2 also) are technically
compatible with 10.9, only the installer was a safety check that stops the
install process for 10.9.
Thanks
Björn
Original comment by googlelogin@bjoern-kahl.de
on 17 Dec 2013 at 9:46
@ "mail@mike-tucker.com", comment #3:
Your zfs.fs is not the one for the latests MacZFS-74.3.2
Can you post the output of "pkgutil --pkgs | grep -e zfs" ?
Thanks
Björn
Original comment by googlelogin@bjoern-kahl.de
on 17 Dec 2013 at 9:52
I'm also having a similar issue. After a reboot, my ZFS pool doesn't show up
and it's holding my photo library hostage. I also upgraded to Mavericks and
74.3.2, and all was fine until a recent reboot ( I don't reboot often, so I'm
not sure when I fried things, but I'm guessing it was the 74.3.2 move). My
disks are below. One of the two 4 TB drives I had in my pool shows up as ZFS
and the other (drive 0 I'm guessing) looks odd.
I'm using an Early 2009 Mac Pro with 2 2.93 quad Xeons and 12 GB of RAM on OS X
10.9.1 (13B42).
davids-mac-pro:~ david$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *4.0 TB disk0
1: 0xEE 2.2 TB disk0s1
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_HFS Macintosh HD 837.9 GB disk1s2
3: Apple_Boot Recovery HD 650.0 MB disk1s3
4: Microsoft Basic Data 161.4 GB disk1s4
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_CoreStorage 4.0 TB disk2s2
3: Apple_Boot Boot OS X 134.2 MB disk2s3
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Internal Backup *4.0 TB disk3
/dev/disk5
#: TYPE NAME SIZE IDENTIFIER
0: Apple_partition_scheme *2.0 TB disk5
1: Apple_partition_map 32.3 KB disk5s1
2: Apple_HFS My Book 2.0 TB disk5s3
/dev/disk6
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk6
1: EFI EFI 209.7 MB disk6s1
2: ZFS 4.0 TB disk6s2
davids-mac-pro:~ david$
Original comment by shinya...@gmail.com
on 16 Feb 2014 at 2:08
The partition type showing as "0xEE" means the GPT structure on disk got
damaged by something. MacZFS is never writing to the GPT, so I don't know how
you ended up in this situation.
Recovery will be tricky but doable. I suggest we meet in IRC or on Skype for a
step-by-step investigation and (hopefully) recovery. Please contact me by mail
for finding a time slot (I am in CET (UTC+1)).
Original comment by googlelogin@bjoern-kahl.de
on 16 Feb 2014 at 9:44
Re: mustng69 (comment #2) and alentin.hristev (comment #4)
The reboot issue has been fixed recently, it was caused by a bug in MacZFS's
ioctl handler, see issue 126.
Original comment by googlelogin@bjoern-kahl.de
on 16 Feb 2014 at 9:51
Thanks for the response. I am home today and tomorrow until early evening
before I fly out for work and leave the computer in question. I am on EST
(UTC-5). Let me know what time works for you.
Original comment by shinya...@gmail.com
on 16 Feb 2014 at 4:36
OS: 10.9.4
Installed 74.3.3
DISK: Firewire 800 2TB drives /dev/disk4 /dev/disk6 used for simple zpool
All of the pools are gone and will not mount after reboot.
Looks like the same issue as before. Prior to this had 74.3.0 installed without
any issue even after OS upgrade.
sh-3.2# cat Info.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>zfs</string>
<key>CFBundleIconFile</key>
<string></string>
<key>CFBundleIdentifier</key>
<string>org.maczfs.zfs.fs</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>zfs</string>
<key>CFBundlePackageType</key>
<string>KEXT</string>
<key>CFBundleShortVersionString</key>
<string>maczfs_74-3-3-0-ge37cf7b</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>74.3.3</string>
<key>IOKitPersonalities</key>
<dict/>
<key>OSBundleLibraries</key>
<dict>
<key>com.apple.kpi.bsd</key>
<string>8.0.0</string>
<key>com.apple.kpi.libkern</key>
<string>8.0.0</string>
<key>com.apple.kpi.mach</key>
<string>8.0.0</string>
<key>com.apple.kpi.unsupported</key>
<string>8.0.0</string>
</dict>
</dict>
</plist>
Original comment by skylane...@gmail.com
on 10 Oct 2014 at 6:20
Hi skylane67f, thanks for the report.
See below for instructions on how to get your pool back.
It is not entirely clear what the root cause of the problem is, but it seems
something is reinitializing the disk with a MBR partitioning scheme (also
called BIOS or DOS scheme) behind the users back. It is not the MacZFS driver
itself, since it does only know about GPT partition and does not contain code
to write a proper MBR partition table.
*How to get your pool back:*
The basic idea is to recreate the correct GPT partition scheme.
This is possible, since the GPT partition scheme includes a backup copy, which
is under normal conditions not damaged when some legacy software (re)formats a
disk with the MBR scheme.
*Tools needed:*
* the gdisk utility, for example available from MacPorts or directly from here:
http://sourceforge.net/projects/gptfdisk/ . The right file is gdisk-0.8.8.pkg
(or newer).
* the default Apple Terminal.app utility
You will need administrator access to the box, and I recommend doing the
following at the physical console, not over a remote connection.
*The steps are:*
# open Terminal.app to get a command line. Everything following will be done
at the command line.
# determine the disk that needs fixing: run "diskutil list". Note down the
disk path, it will be something like "/dev/disk1". I will use "$disk" as a
placeholder below.
# run sudo gdisk $disk <-- replace with your disk path!
This will probably complain about inconsistencies and that it loaded the backup copy, which is exactly what we want.
# with in gdisk, do: (All commands are single-letter commands and must be
submitted with `<enter>`. Most commands do not produce any output.)
# type "p" (+ `<enter>`) to view the current (inconsistent) partition data. Note: some gdisk versions show the loaded (healthy) backup copy here, not the corrupted primary copy, so the information is not reliable)
# type "r" to go to the recovery menu
# type "c" to copy the backup table over the primary table
# type "v" to verify the table. If the system complains about checksum errors, then abort. The disk will then need a more thorough analysis and fixing.
# usually "v" does not complain or just warns about some unallocated space. That is perfectly fine.
# type "w" to write the recovered partition table to disk. This exits the gdisk tool.
# verify using "diskutil list" that the partition table has been fixed.
# Repeat with any other disk that needs fixing
# Done. Reboot to make sure the Kernel will use the fixed table and not the
corrupted old one.
Note:
Above steps are the shorted transcript from an IRC session to fix the disk from
commenter 10. Use with caution and do not write the new table to the disk, if
you have doubts about the auto-recovered partition table as show by the "v" or
"p" command.
Use at your own risk.
Original comment by googlelogin@bjoern-kahl.de
on 11 Oct 2014 at 9:19
Original issue reported on code.google.com by
mustn...@gmail.com
on 11 Dec 2013 at 6:27