Router dead.. mountroot>

micropone

seems like something happened with latest dev. snapshot

its stuck in mountroot>

I tried trying the file system name but no luck…

TechyTech

Just finished migrating from bare metal to virtualbox and ran into this myself, thought it was something amiss in the migration.

After finished the migration, everything was working, then updated to the latest pfsense build; update apears to go fine, then after reboot, the zfs root will not mount.

Ended up backing up configuration, reloading with latest build image installed as ufs, and restoring configuration to get going again.

Update: Dug up some info.

After the first update new error appears on console:

Warning: file_get_contents(): Filename cannot be empty in/etc/inc/pfsense-utils.inc on line 1120

Then once rebooted, the mount failure happens.

On the rebuild using UFS, after each reboot, I’'m getting crash dump errors similar to the first error after upgrade.

PHP Errors:
[16-Feb-2018 <scrub>America/Los_Angeles] PHP Warning: file_get_contents(): Filename cannot be empty in /etc/inc/pfsense-utils.inc on line 1120

The “America/Los_Angels” part is the timezone. I’ve tried changing the timezone, but still get the same error, just different time zone.</scrub>

MorpheusRO

Same thing happened to me…

You can use this workaround (https://redmine.pfsense.org/issues/6929) for the moment, to be able to boot, until the issue is solved.

w0w

@TechyTech:

Just finished migrating from bare metal to virtualbox and ran into this myself, thought it was something amiss in the migration.

After finished the migration, everything was working, then updated to the latest pfsense build; update apears to go fine, then after reboot, the zfs root will not mount.

Ended up backing up configuration, reloading with latest build image installed as ufs, and restoring configuration to get going again.

Update: Dug up some info.

After the first update new error appears on console:

Warning: file_get_contents(): Filename cannot be empty in/etc/inc/pfsense-utils.inc on line 1120

Then once rebooted, the mount failure happens.

On the rebuild using UFS, after each reboot, I’'m getting crash dump errors similar to the first error after upgrade.

PHP Errors:
[16-Feb-2018 <scrub>America/Los_Angeles] PHP Warning: file_get_contents(): Filename cannot be empty in /etc/inc/pfsense-utils.inc on line 1120

The “America/Los_Angels” part is the timezone. I’ve tried changing the timezone, but still get the same error, just different time zone.</scrub>

Same for me, first error was PHP and today’s snap went to unknown filesystem

w0w

@MorpheusRO:

Same thing happened to me…

You can use this workaround (https://redmine.pfsense.org/issues/6929) for the moment, to be able to boot, until the issue is solved.

No. It’s fails with
load /boot/kernel/opensolaris.ko can’t find ‘opensolaris’

Use load /boot/kernel**.old**/opensolaris.ko instead!

occamsrazor

I had the same on the latest development snapshot. Had to re-install and restore backup config….

w0w

I think it’s https://github.com/pfsense/pfsense/commit/d0af08f591396ce66ee3936c43d9d8e3049a5be7

LostInIgnorance

For anyone else that is having this issue, I am not as good as some of the people in the forum, but this helped me as a reference for this issue.

at the mountroot> prompt, hit enter, then type reboot when you get to the db> prompt
Once the menu appears for the pfSense boot screen hit 3
Use the provided lines at the prompt

load /boot/kernel/kernel
load /boot/kernel/opensolaris.ko
load /boot/kernel/zfs.ko

Now type boot and pfSense should now boot

Unfortunately, the part about editing the loader.conf does not stick, so it will be cleared out on every reboot.

LostInIgnorance

So whatever was changed with the purging of duplicate entries will purge any changes made to loader.conf on reboot. I even created a loader.conf.local and it purged that file too.

w0w

Sad that it was not properly tested before merging, but anyway the positive thing is that I’ve learned a bit how to restore snapshot on ZFS
And yes, thanks to MorpheusRO for pointing.

loos

@LostInIgnorance:

So whatever was changed with the purging of duplicate entries will purge any changes made to loader.conf on reboot. I even created a loader.conf.local and it purged that file too.

Yes, there was a missing assignment in the new function, I committed the code from the wrong branch here.

I’m very sorry for the breakage.

shinzo

I have a zfs partition and after the latest snapshot still not booting correctly. (2.4.3.a.20180221.0835)

Had to put this in the loader.conf to make it boot up
opensolaris_load="YES"
zfs_load=“YES”

And Dummynet doesnt seem to be loading up automatically as well.
Feb 21 11:02:29 php-fpm 10134 /rc.filter_configure_sync: The command ‘/sbin/ipfw /tmp/rules.limiter’ returned exit code ‘1’, the output was 'Line 2: setsockopt(IP_DUMMYNET_CONFIGURE): Protocol not available’
Feb 21 11:02:29 php-fpm 10134 /rc.filter_configure_sync: The command ‘/sbin/kldload dummynet’ returned exit code ‘1’, the output was ‘kldload: can’t load dummynet: No such file or directory’

“kldload dummynet” manually does fix it ^^

maverick_slo

Yeah it`s still botched…

w0w

~~What a mess… does anybody tests those snaps on ZFS at all before making it available for download?~~

Hmm… I’ve updated another one system from 2.4.1 to 2.4.3

2.4.3-DEVELOPMENT (amd64)
built on Wed Feb 21 08:35:06 CST 2018
FreeBSD 11.1-RELEASE-p6

And it’s booted just fine, even second time and yes it’s ZFS.
Is it possible that you have updated your firewalls only twice in-between 14 and 21 February? Because this wrongly committed pfsense-utils.inc erases .conf files but you will know it only on second reboot or next upgrade, getting this well known mountroot>

Anyway I don’t know how it’s related to dummynet, but i was getting the same error when mountroot> came to me on 16 February.
On this 2.4.1 to 2.4.3 version I do not have it.

robvanhooren

filed bug 8344

jimp

There is no problem with the current snapshot. You might have bad code on the snapshot you were running before the update, or from a previous upgrade, but the current code is fine and current snapshots are fine.

If you are on a snapshot from a couple days ago when the problem started, check your loader.conf and loader.conf.local files before you upgrade. You could also gitsync to current master code before doing the upgrade to make sure the existing bad code didn’t remove your loader config before doing an upgrade as well.

But now that you’re on a good snap with a proper loader.conf then it should be OK from here on.

shinzo

I will reload the system with the latest snapshot and report back.

shinzo

So the latest snapshot is working better. It looks like loader.conf.local is not pulled during boot anymore?

w0w

Both loader.conf anf loader.conf.local are in place and in my case are not changed at all.