Failure to boot (encrypted) since the 5th of october 2018 (master)

[prometheanfire]

System information

Type	Version/Name
Distribution Name	Gentoo
Distribution Version	latest
Linux Kernel	>4.18.12 (last kernel build with zfs built-in that worked)
Architecture	x86_86
ZFS/SPL Version	after 05/10/2018 at 00:00 (time of build from master)

Describe the problem you're observing

Failure to boot / import (encryption enabled if it matters) since zfs/kernel built on the 5th of october. initramfs built an hour ago works fine, not the kernel.

Describe how to reproduce the problem

not sure if encryption is needed, but maybe that?

Include any warning/errors/backtraces from the system logs

None found so far.

[prometheanfire]

https://photos.app.goo.gl/wNebep23XcWTEGu49

crypto_comp_decompress?

[prometheanfire]

further, it's a static kernel with zfs built in, so maybe that's it?

[gcs-github]

The oddity that strikes me in your trace here is that you're seeing issues under pstore, which is the Linux component in charge of storing dmesg traces in case the linux kernel crashes, or hits BUGs. It can do so in RAM or EFI vars for example. That shouldn't be ZFS-related.

[behlendorf]

I don't see anything ZFS related on the console either. Perhaps you could try rolling back the kernel and using the latest ZFS to isolate the problem.

[prometheanfire]

good point, I can try with 4.18.12 and zfs master. I did do some light bisecting, (but my technique sucks).

I'm currently on 4.18.14 with zfs master from 05/10/2018. So I think it's 4cbde2e and NOT d7e4b30 like I originally though. I am guessing that it causes problems for static kernels.

The copy-builtin seems to be having issues maybe, it didn't copy everything when I tried last.

[prometheanfire]

# cat /sys/module/zfs/version
0.8.0-rc1_50_g0aa5916a
# uname -a
Linux slaanesh 4.18.14-gentoo #3 SMP PREEMPT Mon Oct 15 13:36:20 CDT 2018 x86_64 Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz GenuineIntel GNU/Linux

This was after manually copying some stuff. Debugging the copy-builtin stuff now.

[prometheanfire]

Gentoo modifies a Makefile, causing the scripts/make_gitrev.sh script to fail. Since copy-builtin has set -e enabled it will then bail without copying anything.

git diff-index HEAD
:100644 100644 82d155dd31ac4341c5bb8cbfdc8867ffb09b8684 0000000000000000000000000000000000000000 M	module/Makefile.in
# where we modify
use debug || sed -e 's/^subdir-m += zpios$//' -i "${S}/module/Makefile.in"

This would fix it, but I'd rather have the git-rev defined, even if dirty.

diff --git a/scripts/make_gitrev.sh b/scripts/make_gitrev.sh
index 04be0959..b9b5273b 100755
--- a/scripts/make_gitrev.sh
+++ b/scripts/make_gitrev.sh
@@ -40,12 +40,12 @@ rm -f "$file"
 #
 # Check if git is installed and we are in a git repo.
 #
-git rev-parse --git-dir > /dev/null 2>&1 || exit
+git rev-parse --git-dir > /dev/null 2>&1 || exit 0
 
 #
 # Check if there are uncommitted changes
 #
-git diff-index --quiet HEAD || exit
+git diff-index --quiet HEAD || exit 0
 
 rev=$(git describe 2>/dev/null) || exit