uname -a: FreeBSD dog 11.1-STABLE FreeBSD 11.1-STABLE #0 r328208: Sun Feb 4 12:34:52 EET 2018 root@dog:/usr/obj/usr/src/sys/GENERIC amd64 After upgrade from revision r328208 to r328849 my system panics when tries to mount root fs during the boot boot process and instantaneously reboots. After rolling back to previous OS revision the problem disappears. My root zpool/zfs has the latest version: dog@dog:~ % zpool upgrade -v This system supports ZFS pool feature flags. The following features are supported: FEAT DESCRIPTION ------------------------------------------------------------- async_destroy (read-only compatible) Destroy filesystems asynchronously. empty_bpobj (read-only compatible) Snapshots use less space. lz4_compress LZ4 compression algorithm support. multi_vdev_crash_dump Crash dumps to multiple vdev pools. spacemap_histogram (read-only compatible) Spacemaps maintain space histograms. enabled_txg (read-only compatible) Record txg at which a feature is enabled hole_birth Retain hole birth txg for more precise zfs send extensible_dataset Enhanced dataset functionality, used by other features. embedded_data Blocks which compress very well use even less space. bookmarks (read-only compatible) "zfs bookmark" command filesystem_limits (read-only compatible) Filesystem and snapshot limits. large_blocks Support for blocks larger than 128KB. sha512 SHA-512/256 hash algorithm. skein Skein hash algorithm. The following legacy versions are also supported: VER DESCRIPTION --- -------------------------------------------------------- 1 Initial ZFS version 2 Ditto blocks (replicated metadata) 3 Hot spares and double parity RAID-Z 4 zpool history 5 Compression using the gzip algorithm 6 bootfs pool property 7 Separate intent log devices 8 Delegated administration 9 refquota and refreservation properties 10 Cache devices 11 Improved scrub performance 12 Snapshot properties 13 snapused property 14 passthrough-x aclinherit 15 user/group space accounting 16 stmf property support 17 Triple-parity RAID-Z 18 Snapshot user holds 19 Log device removal 20 Compression using zle (zero-length encoding) 21 Deduplication 22 Received properties 23 Slim ZIL 24 System attributes 25 Improved scrub stats 26 Improved snapshot deletion performance 27 Improved snapshot creation performance 28 Multiple vdev replacements For more information on a particular version, including supported releases, see the ZFS Administration Guide. dog@dog:~ % zfs upgrade -v The following filesystem versions are supported: VER DESCRIPTION --- -------------------------------------------------------- 1 Initial ZFS filesystem version 2 Enhanced directory entries 3 Case insensitive and filesystem user identifier (FUID) 4 userquota, groupquota properties 5 System attributes For more information on a particular version, including supported releases, see the ZFS Administration Guide.
We need some information about the panic itself to get started.
Unfortunately I cannot catch the moment of panic (or maybe it's not even a panic, but some problem with zfs that causes my root zfs pool to collapse during the root mount). My system starts booting, loads kernel and all kernel modules ( I tried to remove all of them except of zfs from loader.conf, but it didn't help) and then at the moment of mounting root zfs pool it momentarily shows some lines of error messages and PC immediately reboots. As far as my root zfs pool takes the whole disk space I have no space for non-zfs kernel dumps and therefor there's no any dumps saved. Nothing's written in logs too, because (as I understand) it happens before system can open any file to write. The reboot starts too fast and I cannot even make a photo of the screen to recognize what errors exactly happen. I tried to update the system to the most recent version from Mar 08 2018, but the problem still exists. Is there any way to make the system not reboot immediately after root zfs pool mounting error, but freeze and just show me the error until I press a key or something like that? Otherwise I'm not able to pick any additional information.
I made some investigations using the www.freshbsd.org website (http://www.freshbsd.org/search?branch=RELENG_11&project=freebsd) as a commit history source and found the last commit my system can work and the commit that breaks my system. 328463 (http://www.freshbsd.org/commit/freebsd/r328469) is the last commit my system can be successfully built and run. So now it is: dog@dog:~ % uname -a FreeBSD dog 11.1-STABLE FreeBSD 11.1-STABLE #0 r328463: Mon Mar 19 00:53:44 EET 2018 root@dog:/usr/obj/usr/src/sys/GENERIC amd64 The next commit on the site, 328469 (http://www.freshbsd.org/commit/freebsd/r328469) makes my system momentarily reboot during the boot process just after the finding the root zfs filesystem. I still cannot catch the moment to make the shot of the error screen, it runs to reboot too fast.
I can confirm I'm seeing this same issue with checkout in STABLE today r331842. Unfortunately the screen only shows the error for less than a second and then triggers a reboot. All I can see is some hex dump codes flash by in what seems to be exactly the same manner as dog@virtual.org.ua has mentioned.