Kernel panic on boot/reboot after defining pool

[GoogleCodeExporter]

What steps will reproduce the problem?

- installed latest Mavericks release on Hackintosh running Mavericks okay
- added ZFS GPT partition to three attached SATA drives per guide okay
- created RAIDZ pool comprising the three drives okay
- drive mounts on desktop okay
- reboot/restart and system hangs with attached screen (verbose mode enabled on 
boot)
- reboot in safe mode okay but of course ZFS is then unavailable

What is the expected output? What do you see instead?

Attached screen shot of kernel panic

What version of the product are you using? On what operating system

74.3.2 on Mavericks 10.9

Please provide any additional information below.

These were also in the messages log:

11/28/13 11:53:18.176 PM    com.apple.kextd[12] WARNING - Invalid signature -67062 
0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/zfs.kext"
11/28/13 11:53:18.000 PM    kernel[0]   zfs_context_init: 
footprint.maximum=1073741824, footprint.target=102711296
11/28/13 11:53:18.000 PM    kernel[0]   kobj_open_file: "/etc/zfs/zpool.cache", err 
2 from vnode_open
11/28/13 11:53:18.000 PM    kernel[0]   zfs_module_start: memory footprint 9633280 
(kalloc 9633280, kernel 0)
11/28/13 11:56:48.165 PM    com.apple.kextd[12] WARNING - Invalid signature -67062 
0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/zfs.kext"
11/28/13 11:56:48.000 PM    kernel[0]   zfs_context_init: 
footprint.maximum=1073741824, footprint.target=102711296
11/28/13 11:56:48.000 PM    kernel[0]   kobj_open_file: "/etc/zfs/zpool.cache", err 
2 from vnode_open
11/28/13 11:56:48.000 PM    kernel[0]   zfs_module_start: memory footprint 9633280 
(kalloc 9633280, kernel 0)
11/28/13 11:59:53.180 PM    com.apple.kextd[12] WARNING - Invalid signature -67062 
0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/zfs.kext"
11/28/13 11:59:53.000 PM    kernel[0]   zfs_context_init: 
footprint.maximum=1073741824, footprint.target=102711296
11/28/13 11:59:53.000 PM    kernel[0]   kobj_open_file: "/etc/zfs/zpool.cache", err 
2 from vnode_open
11/28/13 11:59:53.000 PM    kernel[0]   zfs_module_start: memory footprint 9633280 
(kalloc 9633280, kernel 0)

Original issue reported on code.google.com by stuart.m...@gmail.com on 29 Nov 2013 at 7:10

Attachments:

• IMG_1308.JPG

[GoogleCodeExporter]

Thanks for the screen shoot with the panic.  Unfortunately it does not tell us 
the load address of the kext, so it is close to impossible to decode the call 
stack.

Do you have the full panic file which should have been written after the system 
comes up again?

Another question: Is the log above from the boot attempt that crashed, or some 
latter one?

Original comment by googlelogin@bjoern-kahl.de on 29 Nov 2013 at 9:42

[GoogleCodeExporter]

Thanks for following up so promptly. I am attaching the zipped Diagnostic 
Reports - if I've pulled the wrong log(s) please let me know where would be 
most helpful.

The log extract above was taken around the same time - I'm attaching that also 
as you can see I booted into safe mode to get back to running. At which point I 
removed the zfs elements and repartitioned the three drives with disk utility 
to be part of a concatenated RAID, but that's far from what I hope to have with 
ZFS. I use ZFS on my NAS4Free server and it's fantastic. Hence my great wish to 
get this to play nicely with Mavericks...I would happily step back to Mountain 
Lion but that's a whole other kettle of Hackintosh worms ;-)

-- Stuart

Original comment by stuart.m...@gmail.com on 30 Nov 2013 at 12:06

Attachments:

• DiagnosticReports.zip
• [All Messages.log](https://storage.googleapis.com/google-code-attachments/maczfs/issue-126/comment-2/All Messages.log)

[GoogleCodeExporter]

Thanks for the zipped log files.  While not the ones I was looking for, one 
(pcscd_2013-11-28-235829_...) contained the needed info: MacZFS was loaded at 
0xffffff7f80b1e000 to 0xffffff7f80b9efe3.

None of the addresses in the panic screenshot fall into that range.  This means 
the crash happens *outside* the MacZFS code.  While this does not exclude that 
it is MacZFS' fault, it means that some other part of the kernel crashed.  
Finding out if and how this relates to specific actions (not) taken by MacZFS 
will be very difficult.

However it is possible that the log I used now is not the one really describing 
the situation at the crash.  Can you check "/Library/Logs/DiagnosticReports" 
for files name "*.panic"? if you have one, please also attach.

Another question:

Is it possible that the system booted with an old prelinked kernel, effectively 
running the MacZFS-74.3.2 zfs binary against a MacZFS-74.3.1 (or older) kext?  
That combination would panic due to a bug in the ioctl handler of all MacZFS 
releases prior to 74.3.2 which is unfortunately triggered by the new 
version-check of the ioctl interface.

Original comment by googlelogin@bjoern-kahl.de on 1 Dec 2013 at 12:27

[GoogleCodeExporter]

Sadly there are no .panic files being generated. In an effort to figure out 
where the problem might be I did some research over on openzfs (who seem to 
link to your site too which is confusing) and manually uninstalled the ZFS 
components per the wiki before running their build script.

This allowed me to create a ZFS pool however I the partition operation wiped 
out the EFI so when the pool was created the Finder complained about an unknown 
disk offering to format it which I declined. I was then able to manually mount 
the zfs pool from command line and copy files. This survived restarts without 
kernel panic but did not auto mount and again getting the unknown disk message 
which had to be ignored and again manual steps. Tedious.

I saw you very recently updated the 74.3.2 with "b" so figured I would test 
that out.

I reformatted the three drives comprising my raidz pool and ran the initial 
partition command:

diskutil partitiondisk /dev/disk2 GPTFormat ZFS %noformat% 100% 
diskutil partitiondisk /dev/disk2 GPTFormat ZFS %noformat% 100%
diskutil partitiondisk /dev/disk2 GPTFormat ZFS %noformat% 100%  

No errors and diskutil list looked good. This time I figured I would try a 
restart again before creating any pools to see what happened. Kernel panic as 
before. So it seems just the presence of ZFS partition is hanging, before even 
getting to the mounting of any created pool.

If I boot into safe mode and erase the disks with disk utility back to regular 
plain journaled then I can restart without safe mode without a hang.

So I'm not sure what if any symbiosis there is between MacZFS here and OpenZFS 
and what it is about the ZFS partition causing the problem.

For now I've set up a disk utility RAID but that's concatenated - it boots and 
mounts just fine.

In case I hadn't made it clear, I'm not trying to use the ZFS volume as a boot 
or system drive - all that is being done with the SSD as dev0. All drives are 
internal mobo connections (no USB, no SATA cards).

Original comment by stuart.m...@gmail.com on 1 Dec 2013 at 4:50

[GoogleCodeExporter]

Thanks for the detailed info.  Much appreciated.
It is unhelpful that no Panic Reports are generated.  This might be due to the 
fact that this is not a pure Apple system.  As far as I understand, generating 
Panic Reports is done in part by Apple's boot infrastructure, i.e. the part 
that manages NVRAM.

I do not understand how the mere presence of an ZFS partition can cause a panic 
when no pools are defined.

Unfortunately, I don't see how I can help here.

Regarding MacZFS vs. ZFS-OSX (not OpenZFS, which doesn't have its own code 
base, it's a coordinating action facilitating exchange and collaboration 
between all ZFS implementations except Oracle's): ZFS-OSX is expected to 
replace MacZFS in the next 3-6 months.  It is driven by the same team as MacZFS 
and is a complete rewrite based on ZoL instead of Solaris.

Original comment by googlelogin@bjoern-kahl.de on 1 Dec 2013 at 11:11

[GoogleCodeExporter]

Well thanks for giving it a shot. I appreciate the "mackintosh" element is a 
wild card but my Mac Pro 2.1 got orphaned by Mountain Lion and Mavericks and I 
have to say twice the performance for a third of the cost is very impressive. I 
may just wait out the ZFS updates for now and revisit once Mavericks is older. 
I do greatly appreciate your time.

Original comment by stuart.m...@gmail.com on 1 Dec 2013 at 3:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This issue report shows the same backtrace (see original report) as issue 129.  
Both are on a Hackintosh, so tagging this for now as hackintosh.

Original comment by googlelogin@bjoern-kahl.de on 18 Dec 2013 at 9:59

[GoogleCodeExporter]

I found this in "hackintosh" land relating to NVRAM and trying to get iMessage 
to work -

http://www.insanelymac.com/forum/topic/286350-filenvram-112-released/

It may well be that installing this as detailed would then generate a kernel 
panic log as a 'pure' Mac would do that could help diagnose further. 
Unfortunately at the moment I don't have enough time for science experiment but 
maybe someone else on a Hack can install this and see if their black screen 
output is now accompanied by a .panic log file

Original comment by stuart.m...@gmail.com on 18 Dec 2013 at 10:16

[GoogleCodeExporter]

having exactly the same issue on a mac pro running 10.9.1; so this isn't a 
mackintosh issue.

after creating the pool and a reboot, automatic kernel panic.

Original comment by casa...@gmail.com on 7 Jan 2014 at 11:45

[GoogleCodeExporter]

I can also attest that this is not a hackintosh issue.

I completely uninstalled MacZFS on my Mac Mini (2012) running 10.9.1.
Rebooted.  Installed MacZFS 74.3.2b.
Rebooted.
Attached 4 USB disks (I'm well aware of the USB issues) and formatted them.

Once I created a ZFS RAIDZ pool, the volume mounted correctly.  I rebooted 
again and get constant reboots/kernel panics unless the drives are unplugged on 
restart.  Even when the system is running, once those disks are plugged in, the 
system freezes and kernel panics.

Original comment by tjp...@gmail.com on 11 Jan 2014 at 9:15

[GoogleCodeExporter]

Thanks for the update.  Unfortunately it is still not clear what is the root 
cause for the instability. 
I added a helper script to collect some more information about the installed 
ZFS version(s) and panic logs.  Can you download the "collect-maczfs-state.sh" 
script and run it in a terminal?  It will produce a file 
"collect-mazfs-state-info.txt" in its current directory.  Can you attach that 
file here?  You can check and edit the file before upload if you want.

Original comment by googlelogin@bjoern-kahl.de on 14 Jan 2014 at 12:32

[GoogleCodeExporter]

I have a recently built hackintosh running 10.9.1 smoothly and have the exact 
same issue. ZFS install. 3 drives in a raidz pool. All drives connected to 
internal motherboard SATA. Mounts the drive. When I reboot, the computer hangs 
with the grey screen.

I also noticed another problem. When the ZFS drives were first mounted and 
accessible I copied over a large amount of data which then made the computer 
freeze after a few minutes.

Original comment by ipod.ash...@gmail.com on 14 Jan 2014 at 11:17

[GoogleCodeExporter]

I have the same problem, Mac Pro 4,1 OSX 10.9.1

The drives in my zpool are in a multiport eSATA enclosure, there are 5 set up 
IAW the setup instructions for tank and dozer
I have attached the output of collect-maczfs-state.sh and 4 panic logs

any suggestions welcome

Original comment by cacotter...@gmail.com on 19 Jan 2014 at 7:43

Attachments:

• ZFS.zip

[GoogleCodeExporter]

I'm hitting the same exact error on a 2007 Mac Pro.  I've attached my script 
output.

Original comment by a...@aligature.com on 5 Feb 2014 at 2:57

Attachments:

• collect-mazfs-state-info.txt

[GoogleCodeExporter]

I checked and I found some issues with your collect-maczfs-state.sh looking in 
the right spot for kernel panics on mavericks.  I reran and it found 3/3 kernel 
panics indicated ZFS.  Here are new uploads.

Original comment by a...@aligature.com on 5 Feb 2014 at 3:26

Attachments:

• collect-mazfs-state-info.txt
• Kernel_2014-02-04-221028_curie.panic

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sorry, I forgot I'm running 10.8.5 on this machine.  Here's a copy of the 
diagnostic script that should work on any system where the panics are located 
at "/Library/Logs/DiagnosticReports".

Original comment by a...@aligature.com on 5 Feb 2014 at 3:31

Attachments:

• collect-maczfs-state.sh

[GoogleCodeExporter]

MacPro4,1 with 10.8 and 10.9.1, same problem on both as these folks. Kernel 
panic on reboot with ZFS formatted drives in the internal bays.

Original comment by joconno...@gmail.com on 5 Feb 2014 at 8:08

[GoogleCodeExporter]

Fixed in commit e03a8bb.

Release target: 74.3.3 (February/March)

This was cause by a wrong comparison in an error code path (handling a race 
condition) in the ioctl handler.  This was difficult to diagnose, since it only 
happens under certain load, unfortunately also at system start with the 
(obsolete) MacZFS launchd scripts installed.  Thanks to cacotter500, his 
comment #14 guided me on the right track by including the launchd scripts the 
attachment.

Work around:

Uninstall the three launchd scripts "com.bandlem.mac.zfs.*" in 
"/Library/LaunchDaemons".  I could only reproduce the problem after installing 
the scripts.

Original comment by googlelogin@bjoern-kahl.de on 15 Feb 2014 at 12:55

• Changed state: Fixed
• Removed labels: hackintosh

[GoogleCodeExporter]

Issue 132 has been merged into this issue.

Original comment by googlelogin@bjoern-kahl.de on 15 Feb 2014 at 12:56

[GoogleCodeExporter]

It sounds like you have a release planned in the somewhat near future. Also it 
sounds like this bug affected people under certain loads not just at startup. 
Do you recommend trying to run a build of the latest trunk code or waiting for 
the next release? I'm a developer myself so I would be comfortable following 
the build instructions. Mostly I'm wondering if the trunk is stable at this 
point. Thanks!

Original comment by a...@aligature.com on 15 Feb 2014 at 1:28

[GoogleCodeExporter]

You can try, the branch maczfs_74-3-release is considered stable.

However, you'll need an older system like Lion maybe Mountain Lion to compile 
the code.  Compiling under Mavericks is not supported and doesn't work due to 
incompatible changes in the system header files (patches welcome).  (Main 
development system is Snow Leopard.)

If you want to try, please checkout the maczfs_74-3-release branch and build by 
 saying "make -f Makefile-maczfs ARCH_AVAIL=x86_64 install" in the root 
directory of the checkout.  Depending on the compiler(s) installed, you may 
need to point it to Apple's default compiler and linker "CC=/usr/bin/gcc".  The 
"make install" will create a new directory "instbase" and places the new 
version in that folder.  Use sudo and ditto to move into the real system 
directories or run from the instbase folder.

Original comment by googlelogin@bjoern-kahl.de on 15 Feb 2014 at 2:07

[GoogleCodeExporter]

I'm having some issues building.  Something strange failing in stdio.h.  I'm on 
IRC asking about it at the moment.

Original comment by a...@aligature.com on 15 Feb 2014 at 4:34