ditto with xma111's comments….from there you can add geo blocking, malware IP blocking, ad blocking, open source with transparent code demanding updates when needed, IPS.

Pretty rich...

If you're getting a 169.254 IP address then the client is failing to contact a dhcp server.

You should see link LEDs even if pfSense is not booting fully.

That video is of an older ALIX device so it may not behave the same as an APU.

Did you install pfSense on this yourself?

Try connecting to the serial console to see what's happening at boot:
https://www.netgate.com/docs/pfsense/vk-t40e/connect-to-console.html

Steve

@Derelict:

Wrong image. Select VGA console in the downloader or connect terminal software to the correct serial port if that's what you really want.

You probably want this one:

pfSense-CE-memstick-2.4.2-RELEASE-amd64.img.gz

Ahhhh. I totally overlooked that. Thanks for pointing that out. I will re-download and try again. Thanks!

the routing seems to be o.k. Strange. Are you sure, that tcp packets did come to port 80 of the firewall and the firewall answered (you can see the answers e.g. in wireshark)?

Normally it would use the hostname assigned to it, but I did see once where a host was receiving a hostname via WAN DHCP and it used that instead. Though the exact circumstances escape me at the moment, I don't recall it happening recently though.

Usually the most you'd need to do would be a reboot.

Where is it exactly that you're seeing the old hostname? In the logs on the firewall itself? Or on a remote log server? If it's the latter, it could be a (reverse) DNS or host file issue on the log server.

@Arnaud.D:

Thank you for your answer.

I think we will have to do so, but I hoped that I could have do this on a easier way.

what i've suggested is the easiest way

lol I guess its been a while since I have made a liveCD myself. I didn't even realize they discontinued it. My overall goal was to run from "read-only" media. I might be better off using a linux distro to achieve my goal.

@haleakalas:

Try to add the following line in /boot/loader.conf.local as well as /boot/device.hints
hint.hpet.0.clock=0

(Having it in one of the files should suffice but I can't remember which, as I did this once some time ago.
In any event it won't harm your system if you have it in both places)

Alternatively you might want to go into your NUC's BIOS and check the ACPI section.
If there is something called CSM or Compatibility Support Mode or Legacy Compatibility mode which is ON try to turn it off and reboot.

Sorry to bring up a relatively old post but I just wanted to thank you for this.  I've never had this issue until I tried to upgrade to 2.4 this morning.  Adding this line to /boot/loader.conf.local got me back up and running.  Thanks again!

@kyualex:

I'm so sorry!
I took the password from config export of the previous firewall.
I should have noticed the "=" sign at the end of pawwsord to notice it has been encrypted  :-[ :-[
[/quote]

Not encrypted, base64 encoded. You can use a base64 decoder to get the real password.

Hi,

Use the GUI (Diagnostics menu) and the console access to check if your pfSense has an Internet connection.

Btw : I voted "1" - or should I vote for the other "1" ? Your vote proposal and question are not clear at all.

Yes you can.

The issue with most USB connected GPS devices though is that they don't provide the PPS signal. And yes USB connected GPS as a time source is bad….very bad! But also fun.  ;)

Steve

It is possible to override parts of the ACPI tables to by-pass things like this.
https://www.freebsd.org/cgi/man.cgi?query=acpi&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html

But that should not be required. You might enable acpi debugging info, that might give you more idea what's happening.

hw.acpi.verbose=1

The fact you are hitting this and even others running the same hardware are not implies either you have a faulty board or you have added something faulty to it or you have a different BIOS version.

Steve

The haproxy config won't be removed when you uninstall. That all stays in place. Once you reinstall haproxy the settings will all still be there.

The config upgrade code steps nicely through each upgrade step 1 at a time, and each step deals separately, in time order, with config format/data changes required for a particular new feature/fix. I reviewed it all "some time ago" for any bits that might go wrong, and it is all good as far is I could see. You can restore an old config from any old pfSense version (and even an old m0n0wall config) and the system will reboot and apply all the needed upgrade steps.

So choose whichever path you like -

upgrade the existing 32-bit system to 2.3.5 then save the config, install a 64-bit system and restore the config; or save the existing "old" config, install a 64-bit system and restore that old config

either will work equally well.

Thanks bfeitell!

I recently updated my pfsense install to a UEFI install to take advantage of the real estate of my 3840x2160 resolution monitor via the console and I had some screen tearing at the bottom which obfuscated the active command prompt. I've been searching for a solution for close to a week and had tried everything from attempting to load vesa.ko and i915kms.ko (for my Intel HD graphics), to trying to get the vidcontrol command to work, to trying to edit /boot/loader.conf with kern.vty=vt,  kern.vt.fb.default_mode="<x>x<y>", etc.

This is the only solution that actually worked for me!

Edit: I stand corrected. I was able to change the resolution by interrupting the boot process, but I can't get the setting to load automatically with the /boot/loader.rc.local file.</y></x>

Thank you!  I have the same problem.  Somebody please fix this.  Who manages the package?