Page 2 of 3

Re: Looking for testers of 1.8.0

PostPosted: Wed Oct 10, 2018 6:43 pm
by lundman
It's always been a mess for me, as I have show .dot files enabled. I don't know much about the installer system but its all in github if you want to take a look at it. "openzfsonosx-installer" repo

Re: Looking for testers of 1.8.0

PostPosted: Sun Oct 14, 2018 2:55 pm
by sputnik13
I have not tried 1.8.0 yet... a bit wary to do so because with 1.7.4 beta on Mojave I kept getting "SPL: waiting for kernel to init" (or something really similar) on boot and it doesn't move past that, requiring me to manually delete the kexts and then reinstall Mojave just to get booted. I tried 1.7.4 beta with a VM just now and couldn't reproduce. Has anyone seen the above error with 1.7.4 beta and also tried 1.8.0? If there was a good way to recover the system without reinstalling MacOS, I'd like to give 1.8.0 a try, but found that if I just delete the pkg files (using pkgutil from the installer terminal window) then reboot without reinstalling Mojave, I get kernel panics.

Re: Looking for testers of 1.8.0

PostPosted: Sun Oct 14, 2018 3:48 pm
by lundman
Now that is interesting. BTW, if you boot into recovery and delete the kext, then make sure to generate a new prelink kernel, you can boot normally again without reinstalling.

"SPL: waiting for kernel to init"

That is concerning. Before with mojave it would panic when the system boots "too quickly" so that current_process() would return NULL. I added that check to make it wait for the kernel to finish setting up before we carry on. But your experience sounds like we are in fact stopping the boot process, waiting for something that wont happen until after spl.kext is loaded.

Re: Looking for testers of 1.8.0

PostPosted: Mon Oct 15, 2018 1:21 am
by sputnik13
I'm not sure how to generate a prelinked kernel as you said. If you can point me to how I can do that, I'd be happy to test 1.8.0 to see whether the problems still persists.

Re: Looking for testers of 1.8.0

PostPosted: Mon Oct 15, 2018 3:07 am
by lundman
I have a fix done a different way, where we don't stall waiting. Can you handle source and compile yourself, or do you prefer binary?

To fix, boot into recover, cd /Volumes/NameOfYourBootDisk/Library/Extensions/ ; rm -rf spl.kext zfs.kext ; kextcache -i /Volume/NameOfYourBootDisk

Normally when you change anything in /Library/Extensions, it will automatically rebuild the kext cache, but when you boot recovery, it is recovery boot on "/" so you have to manually specify the name of the mac disk.

Re: Looking for testers of 1.8.0

PostPosted: Mon Oct 15, 2018 8:02 am
by sputnik13
Thank you for the instructions, binary would be better but I can handle the compile too, just need pointers on what to build and how, I'm not familiar with xcode/macos builds.

Re: Looking for testers of 1.8.0

PostPosted: Mon Oct 15, 2018 1:43 pm
by lundman
I can send you binaries quite easily, if you can copy them into place by hand. Do you have SIP kext signing off? Suppose it's only seconds for me to sign them too..

Re: Looking for testers of 1.8.0

PostPosted: Mon Oct 15, 2018 1:55 pm
by lundman
Ok, so you should copy the kexts over from the dmg;

sudo rsync -ar /Volumes/dmgname/64/spl.kext/ /Library/Extensions/spl.kext/
sudo rsync -ar /Volumes/dmgname/64/zfs.kext/ /Library/Extensions/zfs.kext/

It will still print the same message, but with numbers now, as in:
printf("SPL: waiting for kernel init3...\n");

this is a debug build, so it uses more memory, but its a quick test to see if it fixes the boot.

Re: Looking for testers of 1.8.0

PostPosted: Mon Oct 15, 2018 7:35 pm
by sputnik13
I was able to try 1.8.0 with the custom kexts and it prints

"SPL: waiting for kernel init1"

Good part is the kextcach -i worked perfectly, I wish I'd known that before I reinstalled three times on Saturday.

Re: Looking for testers of 1.8.0

PostPosted: Mon Oct 15, 2018 7:46 pm
by lundman
I created a wiki entry for it, hopefully will help others recover from boot problems:

https://openzfsonosx.org/wiki/Boot_loop#Boot_Loops

So, are you saying you get one "SPL: waiting for kernel init1" and then.. it hangs? crashes? Now we start SPL as per normal, but stop other-threads from calling wait() in spl-condvar before it is ready - so the main thread will always complete (you see the ("SPL: Loaded module v%s-%s%s, (ncpu %d, memsize %llu, pages %llu)\n") right? )