Bug#915886: enum-extract.pl output
This script fails because the include file passed to it doesn't exist: cd /var/lib/dkms/zfs/0.7.12/build sudo ./scripts/enum-extract.pl node_stat_item /lib/modules/4.19.0-1-amd64/build/include/linux/mmzone.h Can't open /lib/modules/4.19.0-1-amd64/build/include/linux/mmzone.h: No such file or directory at ./scripts/enum-extract.pl line 26. The include (mmzone.h in this case) doesn't exist because 'build' points to the CPU specific include directory and not the 'common' include directory: ls -l /lib/modules/4.19.0-1-amd64/build lrwxrwxrwx 1 root root 37 Dec 11 21:24 /lib/modules/4.19.0-1-amd64/build -> /usr/src/linux-headers-4.19.0-1-amd64 ls -l /lib/modules/4.19.0-1-amd64/build/include total 44 drwxr-xr-x 715 root root 36864 Dec 19 21:13 config drwxr-xr-x 3 root root 4096 Dec 19 21:13 generated I don't think the extraction script is the problem. It appears the problem is in the 'zfs-dkms' configure script because it doesn't look for include files under '/lib/modules/4.19.0-1-amd/*source*.
Bug#915886: Probable work-around
The issue is that Debian delivers Linux headers in two directories, each of which is linked under /lib/modules. On my system, with 4.14, these symlinks are under /lib/modules/4.14.0-3-amd64: cd /lib/modules/4.14.0-3-amd64 ls -ld build source lrwxrwxrwx 1 root root 37 Jan 25 2018 build -> /usr/src/linux-headers-4.14.0-3-amd64 lrwxrwxrwx 1 root root 38 Jan 25 2018 source -> /usr/src/linux-headers-4.14.0-3-common The zfs-dkms 'configure' script assumes the Linux include files are accessible via the 'build' symlink but that only provides access to amd64 CPU dependent files. All the rest of the linux header files are accessible via 'source' which points to the 'common' header files. That breaks the zfs-dkms build when 'dkms' runs the 'configure' command. The work-around creates a symlink to /usr/src/linux-headers-4.14.0-3-common/include/linux under linux-headers-4.14.0--amd64 so the configure script can find the files it needs: cd /usr/src/linux-headers-4.14.0-3-amd64 ln -s /usr/src/linux-headers-4.14.0-3-common/include/linux . Now 'build/include/linux' points to the linux headers: ls -l /lib/modules/4.14.0-3-amd64/build/include/ total 76 drwxr-xr-x 698 root root 69632 Dec 19 09:54 config drwxr-xr-x 3 root root 4096 Dec 19 09:54 generated lrwxrwxrwx 1 root root 52 Dec 19 11:22 linux -> /usr/src/linux-headers-4.14.0-3-common/include/linux Substitute your kernel version du jour for 4.14.0-3. I've only tested this with 4.14 so YMMV with other kernel versions.
Bug#915886: NR_FILE_PAGES is present
I checked the Linux headers and each kernel defines NR_FILE_PAGES as a member of the node_stat_item enumeration in include/linux/mmzone.h. I'm running on MX-17, which is derived from Debian Stable, and the headers are in: /usr/src/linux-headers-4.14.0-3-common (using 4.14.0-3 as my current kernel). So, the kernel include files appear to be correct. As a point of reference, I still have ZFS 0.7.6 running on my primary server and the older ZFS doesn't check for NR_FILE_PAGES at all in its configure scripts. That's new behavior that's been introduced later and is now in 0.7.12. (I saw the added code while grepping for NR_FILE_PAGES). Seems like that logic is the place to look for this bug. Please LMK if I can help run experiments or try solutions. I have the broken ZFS 0.7.12 on a VM, also running MX-17, that I use to test major upgrades before putting them on my main machine. Thanks, Ben
Bug#915886: Additional Debug Data
I'm also hitting this bug so I've collected the data requested by Rich: b@mx17:~$ dpkg -l | egrep '^ii perl-' ii perl-base 5.24.1-3+deb9u5 amd64minimal Perl system ii perl-modules-5.24 5.24.1-3+deb9u5 all Core Perl modules ii perl-openssl-defaults:amd64 3 amd64version compatibility baseline for Perl OpenSSL packages b@mx17:~$ ls -l /usr/share/perl/5.24*/Getopt/Std.pm -rw-r--r-- 1 root root 8790 Nov 29 06:11 /usr/share/perl/5.24.1/Getopt/Std.pm -rw-r--r-- 1 root root 8790 Nov 29 06:11 /usr/share/perl/5.24/Getopt/Std.pm As you can see, my box has GetOpt and yet it has the same dkms error: checking global_page_state enums are sane... no NR_FILE_PAGES in either node_stat_item or zone_stat_item: NOT FOUND configure needs updating, see: config/kernel-global_page_state.m4 configure: error: in `/var/lib/dkms/zfs/0.7.12/build': configure: error: SHUT 'ER DOWN CLANCY, SHE'S PUMPIN' MUD! See `config.log' for more details -Ben McCann
Bug#888114: Blkid and Gparted report whole disk is ZFS if any partition is ZFS
This bug still exists in Arch Linux as of 9/2/2018. Gparted version is 0.31.0-1 and blkid version is 2.32.1 (as part of util-linux). FWIW, I hit this bug after creating a ZFS Intent Log (ZIL) partition on my SSD root disk for a ZFS array of HDDs. The ZIL is partition 9. This is fairly serious bug for anyone trying to optimize a ZFS array using a small piece of an SSD that is otherwise used for other non-ZFS partitions. It renders gparted useless for that device. Here's some debug output that looks similar to previous comments in the bug sudo fdisk -l /dev/sda Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 478CE577-056B-4DE2-BB0E-0D28A37F4223 Device Start End Sectors Size Type /dev/sda1 2048206847204800 100M EFI System /dev/sda2 206848468991262144 128M Microsoft reserved /dev/sda3 468992 167429602 166960611 79.6G Microsoft basic data /dev/sda4 167430144 168407039976896 477M Windows recovery environment /dev/sda5 168409088 169330687921600 450M Windows recovery environment /dev/sda6 169330688 202885119 33554432 16G Linux filesystem /dev/sda7 303548416 437766143 134217728 64G Linux filesystem /dev/sda8 571983872 959995903 388012032 185G Linux LVM /dev/sda9 959995904 976773119 167772168G Linux filesystem /dev/sda10 202885120 303548415 100663296 48G Linux filesystem Partition table entries are not in disk order. and the blkid output sudo blkid | sort /dev/mapper/vgs1-home: LABEL="HOME" UUID="274ffc71-601a-4346-92a2-b12b162047b3" TYPE="ext4" /dev/mapper/vgs1-KVM: LABEL="KVM" UUID="30786057-1854-4951-ab2c-fcbeed0ac296" TYPE="ext4" /dev/mapper/vgs1-swap: UUID="694fecbf-e63d-4f3d-b8ca-e34e28fb9dd6" TYPE="swap" /dev/sda1: UUID="AEF7-9E86" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="78db1804-fe44-49de-bc90-4c6f4d92b639" /dev/sda2: PARTLABEL="Microsoft reserved partition" PARTUUID="5d102957-ba80-4df7-94b7-e3e7fd3dc399" /dev/sda3: LABEL="WIN10" UUID="F050FDA050FD6E2A" TYPE="ntfs" PARTUUID="4580462c-87aa-4cb4-b8ae-28947d47e1e9" /dev/sda4: UUID="8208160E08160239" TYPE="ntfs" PARTUUID="a605a0fc-37a2-40b3-9036-2d203850ef46" /dev/sda5: UUID="96648D07648CEB77" TYPE="ntfs" PARTUUID="1cfe16fb-4211-4e9d-afaa-46febcf22375" /dev/sda6: LABEL="Mint 18.2" UUID="eb7c8e56-8914-4e0c-ae24-3da5ab7d7624" TYPE="ext4" PARTLABEL="Mint 18.2 Sonya" PARTUUID="2dc83abc-cfda-48e3-ac1a-aadacddeb75f" /dev/sda7: LABEL="Manjaro 17" UUID="96d61d3d-25e0-4d4e-a5b1-e35b3731c856" TYPE="ext4" PARTLABEL="Manjaro 17" PARTUUID="7ef8cc0a-7300-4934-9e55-666bebd9a80a" /dev/sda8: UUID="N31dEh-ZP4A-uxaL-aU9x-vEkl-Kw1H-7zO9g6" TYPE="LVM2_member" PARTLABEL="PVS 1" PARTUUID="fc1e4f3e-e49c-46ff-a73a-8206a47d3904" /dev/sda9: LABEL="NAS" UUID="721887637963356003" UUID_SUB="10629598274000407582" TYPE="zfs_member" PARTLABEL="ZIL" PARTUUID="3edafb8b-d13e-463a-a93b-cf961edb358b" /dev/sda10: LABEL="Man 17 Backup" UUID="bb77925d-0ce3-477b-aced-16ba3b7f4870" TYPE="ext4" PARTUUID="3789b15b-cb17-ee46-8591-859db799cb07" /dev/sdb1: LABEL="NAS" UUID="721887637963356003" UUID_SUB="2763534249674358702" TYPE="zfs_member" PARTLABEL="zfs-9b9bbb93b7b7bbcf" PARTUUID="1a20fbbd-5cf9-cc46-ab02-2084b44f1efe" /dev/sdb9: PARTUUID="8bdc2438-456c-1643-9193-05aeefa16bf8" /dev/sdc1: LABEL="NAS" UUID="721887637963356003" UUID_SUB="12980099901542533778" TYPE="zfs_member" PARTLABEL="zfs-54febf417c774651" PARTUUID="dd69e60f-78a3-8c45-be3d-ab6bbae4bbb0" /dev/sdc9: PARTUUID="6fd75129-0472-ab4f-b83c-91552d466cb7" /dev/sdd1: LABEL="NAS" UUID="721887637963356003" UUID_SUB="10649944750575006148" TYPE="zfs_member" PARTLABEL="zfs-371f350dc5f8b5ee" PARTUUID="8953ac79-2fb6-414c-b159-66cf13bb913c" /dev/sdd9: PARTUUID="a2066746-22b7-fb44-8629-9f2e2c1f75ea" and last: sudo blkid -p /dev/sda /dev/sda: VERSION="5000" LABEL="NAS" UUID="721887637963356003" UUID_SUB="10629598274000407582" TYPE="zfs_member" USAGE="filesystem" PTUUID="478ce577-056b-4de2-bb0e-0d28a37f4223" PTTYPE="gpt"
Bug#773731: lvmcache issues with missing thin-provisioning-tools
/usr/sbin/cache_check is still missing in Debian Jessie as of this morning. It would be good to fix this before Jessie goes to Stable because this bug prevented my machine from booting successfully. (System couldn't mount my lvm-cache'd /home directory). That's a pretty serious issue that took me about 30 minutes of googling to figure out. Installing thin-provisioning-tools fixed the problem. Thanks Ben McCann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681796: Hitting this without suspend
I am also hitting this bug but I don't have to suspend. It happens maybe once a week while using Xorg. The X server dies and then Kdm (?) puts up a new login screen. I can log back in and then resume work. Can't pin it on any one action although it appears to be related to using the touchpad on my Acer 1810tz laptop. I'm running Ubuntu 12.04 fully up to date. LMK how I can help track it down. I could attach gdb to the Xorg server on one the TTYs but I don't know if I could swap over to it (ctrl-alt-F1) after Xorg crashes and is sitting in gdb. -Ben McCann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
