ZFS ISSUES!!! built on Wed Jul 11 16:46:22 EDT 2018

Hugovsky

I do have zfs_load="YES" on loader.conf and it failed to upgrade from:

2.4.4-DEVELOPMENT (amd64)
built on Fri Jul 13 19:58:06 EDT 2018
FreeBSD 11.2-RELEASE

to:

Can't be sure snapshot version. It was arround 14:00 GMT+1.

w0w

0_1531844987826_VirtualBox_pfSense-244 testing bug_17_07_2018_19_25_49.png

Clean install and upgrade, both versions are on the screenshot. No problem after boot and reboot.

Hugovsky

Well.... it didn't work for me.

EDIT: sorry. Adding pics.

EDIT2: Now it should be here.

maverick_slo

For me either... Same error

Updating repositories metadata...
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
Setting vital flag on pkg... done.
Downloading upgrade packages...
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
Checking for upgrades (9 candidates): ......... done
Processing candidates (9 candidates): ......... done
The following 10 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
openvpn-auth-script: 1.0.0.3 [pfSense]

Installed packages to be UPGRADED:
snort: 2.9.11.1_1 -> 2.9.11.1_2 [pfSense]
php72-pfSense-module: 0.62_1 -> 0.62_5 [pfSense]
pfSense-rc: 2.4.4.a.20180713.1056 -> 2.4.4.a.20180717.0756 [pfSense-core]
pfSense-kernel-pfSense: 2.4.4.a.20180713.1056 -> 2.4.4.a.20180717.0756 [pfSense-core]
pfSense-default-config: 2.4.4.a.20180713.1056 -> 2.4.4.a.20180717.0756 [pfSense-core]
pfSense-base: 2.4.4.a.20180713.1056 -> 2.4.4.a.20180717.0756 [pfSense-core]
pfSense: 2.4.4.a.20180713.0955 -> 2.4.4.a.20180717.0730 [pfSense]
git: 2.18.0 -> 2.18.0_1 [pfSense]
e2fsprogs-libuuid: 1.44.2_1 -> 1.44.3 [pfSense]

Number of packages to be installed: 1
Number of packages to be upgraded: 9

57 MiB to be downloaded.
[1/10] Fetching snort-2.9.11.1_2.txz: .......... done
[2/10] Fetching php72-pfSense-module-0.62_5.txz: ...... done
[3/10] Fetching pfSense-rc-2.4.4.a.20180717.0756.txz: .. done
[4/10] Fetching pfSense-kernel-pfSense-2.4.4.a.20180717.0756.txz: .......... done
[5/10] Fetching pfSense-default-config-2.4.4.a.20180717.0756.txz: . done
[6/10] Fetching pfSense-base-2.4.4.a.20180717.0756.txz: .......... done
[7/10] Fetching pfSense-2.4.4.a.20180717.0730.txz: . done
[8/10] Fetching git-2.18.0_1.txz: .......... done
[9/10] Fetching e2fsprogs-libuuid-1.44.3.txz: ..... done
[10/10] Fetching openvpn-auth-script-1.0.0.3.txz: . done
Checking integrity... done (0 conflicting)

Upgrading pfSense kernel...
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
pfSense-kernel-pfSense: 2.4.4.a.20180713.1056 -> 2.4.4.a.20180717.0756 [pfSense-core]

Number of packages to be upgraded: 1
[1/1] Upgrading pfSense-kernel-pfSense from 2.4.4.a.20180713.1056 to 2.4.4.a.20180717.0756...
[1/1] Extracting pfSense-kernel-pfSense-2.4.4.a.20180717.0756: .......... done
===> Keeping a copy of current kernel in /boot/kernel.old
Upgrade is complete. Rebooting in 10 seconds.
Success

w0w

Will try exactly 2.4.4.a.20180713.1056 to see what happens.

w0w

@maverick_slo
yes, it refuses to boot with the same error after upgrade.
I don't understand how it's happening... Ask on redmine, please.

Raul Ramos

ZFS needs opensolaris.ko.

/boot/loader.conf should have this line.

opensolaris_load="YES"
zfs_load="YES"

w0w

I've real hardware installation and it never have had this first line.

kern.cam.boot_delay=10000
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
vfs.zfs.min_auto_ashift=12
zfs_load="YES"
autoboot_delay="3"
hw.usb.no_pf="1"

All I have, I think, years since zfs introduced.

w0w

Just now fixed broken installation by booting it manually loading all kernels needed and edited loader.conf adding one line

zfs_load="YES"

Works like a charm.

Raul Ramos

I have a 2.4.3 that don't have the "opensolaris_load="YES"" and an earlier version of 2.4.4 with untouched loader.conf that have the line.
When this problem begin i solve the boot loading zfs manually on start and i had to load kernel, opensolaris.ko and zfs.ko. Loading zfs.ko without opensolaris.ko i get zfs needs opensolaris.ko error message.
So i don't know...

Edit:
@w0w said in ZFS ISSUES!!! built on Wed Jul 11 16:46:22 EDT 2018:

Works like a charm.

Nice

w0w

I've downloaded pfSense-CE-memstick-2.4.4-DEVELOPMENT-amd64-20180710-0609, I think this version was compiled before bug was introduced. Installed and upgraded it to the latest. Boots just fine. So I expect only versions containing this static config file are affected and you should clean install the latest version to fix everything. May be there is some other way to fix this... don't know.

jimp

You don't need opensolaris_load="YES", only zfs_load="YES". When loading the .ko files at the loader prompt you need to load them both manually but not when using the loader.conf entry.

The problem is that the kernel package was including its own copy of /boot/loader.conf which clobbered the copy made by the installer which included the zfs line.

There was another fix put in this morning that has not made it into a snapshot yet that should take care of any remaining issues. Before you upgrade, make sure your /boot/loader.conf or /boot/loader.conf.local contains zfs_load="YES".

jimp

For me, the latest snapshot upgrades OK from a VM that previously failed. Everything should be OK now, but additional feedback for upgrades/fresh installs would help.

w0w

Previously failed 2.4.4.a.20180713.1056 now upgraded successfully.

maverick_slo

Yup all fine.

Thanks!

Hugovsky

Me too. I've upgraded from 2.4.4.a.20180713 without a problem.

motific

Just updating hasn't cured it for me - I'm still having issues on 2.4.4.a.20180723.2155

I'm adding the zfs_load line to loader.conf now and will see how that goes next time I need to reboot.

motific

Looks like editing the config manually sorted it (just in case anyone else is in the same boat.)

w0w

If you have had already broken installation, where config entry was missing, it is expected that you will fail to boot, until you fix it manually. Upgrade does not "fix" this. Because it should not do it. Globally it's not broken and it got broken once or twice before only on development releases. There is no need to add some code to fix this if it never going to broke itself on stable releases.

motific

You can say that, but it wasn't the behaviour I was expecting - I expected if an update broke it then an update will fix it and included the info for others who may have had the same expectation.