Bug 225663 - FreeBSD 11.1-STABLE on root zfs panics on boot
Summary: FreeBSD 11.1-STABLE on root zfs panics on boot
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.1-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
Keywords: regression
Depends on:
Reported: 2018-02-04 15:18 UTC by dog
Modified: 2018-03-31 18:40 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description dog 2018-02-04 15:18:27 UTC
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:

async_destroy                         (read-only compatible)
     Destroy filesystems asynchronously.
empty_bpobj                           (read-only compatible)
     Snapshots use less space.
     LZ4 compression algorithm support.
     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
     Retain hole birth txg for more precise zfs send
     Enhanced dataset functionality, used by other features.
     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.
     Support for blocks larger than 128KB.
     SHA-512/256 hash algorithm.
     Skein hash algorithm.

The following legacy versions are also supported:

---  --------------------------------------------------------
 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:

---  --------------------------------------------------------
 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.
Comment 1 Andriy Gapon freebsd_committer 2018-02-04 17:00:58 UTC
We need some information about the panic itself to get started.
Comment 2 dog 2018-03-08 09:27:42 UTC
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.
Comment 3 dog 2018-03-20 18:26:59 UTC
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.
Comment 4 Roger 2018-03-31 18:40:38 UTC
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.