Nothing in syslog or resolver.log, and no unbound running.

It was the hostname.  <facepalm>.  Strange that it didn't throw an error anywhere, though.</facepalm>

I have confirmed this issue.

Select "Password protect the console menu" from System->Advanced, Admin and press Save. The console now prompts for login in real time. Reboot to confirm the setting is preserved - yep, all good - the console prompts for login at the end of the boot output. Upgrade to latest snapshot. Console is no longer password protected. (but config.xml has <disableconsolemenu>correctly in it) Reboot (any number of times) - console is never password protected. Go to System->Advanced, Admin and press Save. Now the password protect is implemented.

The underlying cause seems to be that pfsense-utils.inc/setup_serial_port() is only called by config.lib.inc/reset_factory_defaults() and directly from system_advanced_admin.php

setup_serial_port() modifies /etc/ttys to implement the required settings on the appropriate tty entry/s.

On a nanoBSD upgrade, that needs to be done to the new /etc/ttys on the new slice. But there does not seem to be any code that does it during or after the upgrade. I looked on 2.1.5 also, and it looks like there is nothing there either and that an upgrade from an earlier version to 2.1.5 might have this same issue.

I do not know about a full upgrade - perhaps /etc/ttys will be overwritten by the upgrade file, or perhaps it will be left in place and thus will work.

Bug ref: https://redmine.pfsense.org/issues/4140</disableconsolemenu>

that's now covered by https://redmine.pfsense.org/issues/4139 as it regressed further today.

This thread is for 2.2, not 2.1.5. Different binaries. If you have that error on 2.1.5, start a new thread in the packages forum rather than using this unrelated thread.

https://redmine.pfsense.org/issues/4059

Could someone please give me a hint where the download actually happens? I can't find the place where

pkg_fetch_recursive

is called. It looks like the base_url is not set properly…

Black diamonds are missing from RSS feed's NTP story.  Hooray!

Thank you for reporting, fixed.

I see this problem constantly. With 2.1.5, I saw apinger problems every few days or weeks, usually triggered by packet loss. With 2.2, I see apinger problems start after a hour or two, and it's unclear what triggers it.

FYI, the first 64bits of an IPv6 address identifies your network, you should really black out the values after the first 3 colons. You have the first 80 bits, while not enough to ping your network, it's enough to send packets to your network.

You'll notice it starts with 2601:8:, which is shorthand for 2601:0008:. What you want to block out is Keep:Keep:Keep:block:block:block:block:block. This will be the first 48bits, which is probably just your ISP. If you asked your ISP for a larger block, and gave you a /48, then this could be your network, but most ISPs are probably going to only hand out /64, /60, /56, but I've heard of some handing out /48s on request, no questions asked.

/sbin/tunefs -t enable /

and

from: https://forum.pfsense.org/index.php?topic=66622.msg430150#msg430150

I'm fairly sure I tried that as well as this was one of the many threads I'd read yesterday but I'll give it another go tomorrow, just to be sure.

Edit.
Got it to work, where I believe I went wrong before was using /bin/sh instead of /sbin/.

Thanks for your help.

sorry, mentioned here and never seen… we have the year 1984 ;-)

will be back if necessary.

Not to go too far off-topic, but since you mentioned it…

GRC actually has a free DNS benchmark utility. It'll pit your server against up to 72 DNS servers operated by major ISPs around the US (some will likely be unreachable as they're for customers of that ISP, but you can remove the unreachable ones by right-clicking in the list).

You'll likely find that cached resolution time is unbeatable by having your own local recursive DNS server, but other lookups may be just a little slower than a few of the servers. However, keep in mind we're talking milliseconds here. Also, if you commonly visit the same sites over and over, cached lookup might be what you're really interested in anyway. As an example, my system…

topped the list in cached performance (0 ms)

came out 28th out of 44 in uncached performance (85 ms avg across 50 lookups)

placed 17th out of 44 in resolution of uncached .com domains only (72 ms avg across 50 lookups)

After testing, the right-click menu allows exporting results to a CSV file, which provides a bit more data (min/avg/max) and you can obviously then sort and filter it as you see fit.

Obviously performance will depend on your ISP's performance and the internet as a whole, since Unbound will be talking to DNS servers all over the world instead of just your ISP or a reliable third-party. I'm plenty happy having Unbound do all the work though.

Here is an example screenshot showing both firewall widget and snort widget.

widgets.JPG_thumb
widgets.JPG

Wow, changing media to CD helped. I was trying to avoid writing a CD. Do it "Go Green" style.
Thank you!

Hm, I am having the same messages on my ALIX. though a bit differently formatted:

Creating symlinks......ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib                                  a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout                                                                done.

I just interprete them as informational only - I feel no reason to be worried.

Regards,
Peter

well the original issue mentioned in the thread seems fixed, regarding that config error i think it would be better to start a new thread or create a bug report

seems a lot better now

well for me it worked once only and the next 5 times i tried it never worked

Dec 20 09:28:35 kernel: vr1: link state changed to DOWN Dec 20 09:29:41 php: rc.kill_states: rc.kill_states: Removing states for IP 92.99.177.145/32 Dec 20 09:29:41 check_reload_status: Rewriting resolv.conf Dec 20 09:29:46 kernel: ovpnc1: link state changed to DOWN Dec 20 09:29:46 check_reload_status: Reloading filter Dec 20 09:29:47 check_reload_status: updating dyndns WAN Dec 20 09:29:47 check_reload_status: Restarting ipsec tunnels Dec 20 09:29:47 check_reload_status: Restarting OpenVPN tunnels/interfaces Dec 20 09:29:47 check_reload_status: Reloading filter Dec 20 09:29:50 kernel: vr1: link state changed to UP Dec 20 09:29:50 check_reload_status: Linkup starting vr1 Dec 20 09:29:51 php-fpm[32866]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN. Dec 20 09:29:51 php-fpm[32866]: /rc.openvpn: OpenVPN: Resync client1 ExpressVPN Dec 20 09:29:51 check_reload_status: Reloading filter Dec 20 09:29:57 php-fpm[23733]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:29:57 php-fpm[23733]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:29:57 php-fpm[23733]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:29:57 php-fpm[23733]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:29:57 php-fpm[23733]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:29:57 php-fpm[23733]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:29:58 php-fpm[23733]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:29:58 php-fpm[23733]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:29:58 php-fpm[23733]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:05 php-fpm[32866]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:05 php-fpm[32866]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:05 php-fpm[32866]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:05 php-fpm[32866]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:05 php-fpm[32866]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:05 php-fpm[32866]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:05 php-fpm[32866]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:05 php-fpm[32866]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:05 php-fpm[32866]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:11 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:11 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:11 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:11 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:11 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:11 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:11 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:11 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:11 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Dec 20 09:30:18 login: login on ttyu0 as root Dec 20 09:30:18 sshlockout[47575]: sshlockout/webConfigurator v3.0 starting up