Messages

Oh and it's 23.7.8_1 (already happened with 23.7.8 as well)

I'm assuming this is 23.7.8... is your WAN DHCP or PPPoE or static setup? If resolving fails for a long time during boot eventually the system has no way to come up gracefully. What sort of DNS resolution are you using? Root servers, forwarding or something fancy like DNS over TLS?


Cheers,
Franco

Hi Franco,

the WAN interface is a static setup (double NAT / behind another FW actually for the time being) but the DNS server is local & that very same FW/Router and is accessible whenever the opnsense reboots... and nothing fancy at all.

Good morning,

I just installed OPNsense again after a while on a test system, installed the os-wireguard plugin, configured and connected to the endpoint (Cloudflare warp in this case) just fine, but after a reboot the connection is always down.

Checked the System > Log Files > Audit logs and saw this entry:

Code Select Expand

/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/usr/bin/wg syncconf 'wg1' '/usr/local/etc/wireguard/wg1.conf'' returned exit code '1', the output was 'Name does not resolve: `engage.cloudflareclient.com:2408' Configuration parsing error'

Checked the mentioned '/usr/local/etc/wireguard/wg1.conf' file and its endpoint looks correct (as per wg.conf notation):

Code Select Expand

####################################################
# Interface settings, not used by `wg`             #
# Only used for reference and detection of changes #
# in the configuration                             #
####################################################
# Address =  172.16.0.2/32
# DNS =
# MTU =
# disableroutes = 1
# gateway = 172.16.0.1

[Interface]
PrivateKey = NopeNopeNope
ListenPort = 56351

[Peer]
# friendly_name = Cloudflare
PublicKey = ShouldBeFineToPasteButMaybeRatherNope
Endpoint = engage.cloudflareclient.com:2408
AllowedIPs = 0.0.0.0/0,::/0

When restarting the wireguard service for this connection it works as expected so I was wondering if the one has anything to do with the other / how to make sure the connection IS up after reboot?

... or why does the 'Default deny / state violation rule' strike if I have a custom rule(s) allowing everything in and out for a particular interface?

Basically my issue is that I want to pass traffic in/out on one particular interface entirely unfiltered. Hence I went ahead and added on 'IN' and one 'OUT' rule allowing everything quasi, see screenshot below.

However, for that interface I still keep seeing firewall log entries blocking traffic based on the 'Default deny / state violation' rule regularly.

Given that this particular interface is physically connected to a second router/firewall, I really, really do not want any filtering happening on the OPNsense box and was wondering HOW I can disable filtering (illegal state or not) completely and for good?


See screenshots at: https://imgur.com/a/PdBGxTG

Hi Maurice,

thanks for the quick reply & yeah, seems like it.. even though I didn't configure either of those (explicitly). Anyway, audit output is the following:

***GOT REQUEST TO AUDIT CONNECTIVITY***
Currently running OPNsense 23.7.4 at Fri Sep 15 11:19:32 PDT 2023
Checking connectivity for host: mirror.sfo12.us.leaseweb.net -> 209.58.135.187
PING 209.58.135.187 (209.58.135.187): 1500 data bytes

--- 209.58.135.187 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
Checking connectivity for repository (IPv4): http://mirror.sfo12.us.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 854 packages processed.
All repositories are up to date.
Checking connectivity for host: mirror.sfo12.us.leaseweb.net -> 2605:fe80:2100:b001::5187
PING6(1548=40+8+1500 bytes) 2600:1700:50e7:XYZZ:XYZZ:XYZZ:XYZZ:XYZZ --> 2605:fe80:2100:b001::5187
1508 bytes from 2600:1700:50e7:XYZZ:XYZZ:XYZZ:XYZZ:XYZZ, icmp_seq=0 hlim=64 time=0.091 ms
1508 bytes from 2600:1700:50e7:XYZZ:XYZZ:XYZZ:XYZZ:XYZZ, icmp_seq=1 hlim=64 time=0.204 ms
1508 bytes from 2600:1700:50e7:XYZZ:XYZZ:XYZZ:XYZZ:XYZZ, icmp_seq=2 hlim=64 time=0.271 ms
1508 bytes from 2600:1700:50e7:XYZZ:XYZZ:XYZZ:XYZZ:XYZZ, icmp_seq=3 hlim=64 time=0.200 ms

--- 2605:fe80:2100:b001::5187 ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.091/0.191/0.271/0.064 ms
Checking connectivity for repository (IPv6): http://mirror.sfo12.us.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7
Updating OPNsense repository catalogue...
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
pkg: http://mirror.sfo12.us.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/meta.txz: Authentication error
repository OPNsense has no meta file, using default settings
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
pkg: http://mirror.sfo12.us.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.pkg: Authentication error
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
SSL certificate subject doesn't match host mirror.sfo12.us.leaseweb.net
pkg: http://mirror.sfo12.us.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.txz: Authentication error
Unable to update repository OPNsense
Error updating repositories!
***DONE***

Good morning,

I have some odd behavior going on and I have no clue where it's coming from, so maybe someone has an idea. I installed OPNsense yesterday on a system and after some basic interface assignments, updates etc.. it appears to be oddly broken insofar as every https request from the system itself fails stating something like this, i.e. when just trying to retrieve a file from a remote webserver via https:

"[...]
root@jBFirewall:~ # curl https://pkg.opnsense.org/FreeBSD:13:amd64/23.7/sets/changelog.txz
curl: (60) SSL: certificate subject name 'jbfirewall.home.local' does not match target host name 'pkg.opnsense.org'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
[..]"

Mind you, that certificate subject name is my OPNsense's hostname and I assume my OPNsense's web gui / self signed cert.


Something similar happens when I try to check for updates:

'[...]
***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 23.7.4 at Fri Sep 15 10:42:13 PDT 2023
Fetching changelog information, please wait... SSL certificate subject doesn't match host pkg.opnsense.org
fetch: https://pkg.opnsense.org/FreeBSD:13:amd64/23.7/sets/changelog.txz: Authentication error
Updating OPNsense repository catalogue...
SSL certificate subject doesn't match host mirrors.nycbug.org
SSL certificate subject doesn't match host mirrors.nycbug.org
SSL certificate subject doesn't match host mirrors.nycbug.org
SSL certificate subject doesn't match host mirrors.nycbug.org
SSL certificate subject doesn't match host mirrors.nycbug.org
SSL certificate subject doesn't match host mirrors.nycbug.org
pkg: http://mirrors.nycbug.org/pub/opnsense/FreeBSD:13:amd64/23.7/latest/meta.txz: Authentication error
repository OPNsense has no meta file, using default settings
SSL certificate subject doesn't match host mirrors.nycbug.org
SSL certificate subject doesn't match host mirrors.nycbug.org
SSL certificate subject doesn't match host mirrors.nycbug.org
pkg: http://mirrors.nycbug.org/pub/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.pkg: Authentication error
SSL certificate subject doesn't match host mirrors.nycbug.org
SSL certificate subject doesn't match host mirrors.nycbug.org
SSL certificate subject doesn't match host mirrors.nycbug.org
pkg: http://mirrors.nycbug.org/pub/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.txz: Authentication error
Unable to update repository OPNsense
Error updating repositories!
pkg: Repository OPNsense cannot be opened. 'pkg update' required
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***
[..]"


It appears my local, self-signed web gui interface is calling remote https retrievals to fail.. but.. why? I have no captive portal active, no proxy or anything (as far as I can tell), so why is there a mismatch of certs / how does the local one get tangled up there?


Does anyone have any idea where something / I went wrong?

Thanks!

I have no answer unfortunately, but, given that I -do- have PBR issues with IPv6... I got a bit curious and was wondering what you're doing / if it works. I try to do PBR for a very select few destination IPv6 networks over VPN and while IPv4 works perfectly, IPv6 does not. Did you by any chance specify a specific destination network and it DOES work for you, and if so, would you mind posting screenshots for the typical places to configure?

Thanks!
-Joerg

Good evening,

I have a very odd problem / behavior with OPNsense which I haven't seen before but maybe someone knows where this may come from:

I have a LAN rule (before the default one) to route certain destination networks over a (wireguard) VPN interface. Thing is, when I try to access a destination webserver in said destination network, I get a CA error and when I look at the cert, it's for OPNsense.localdomain.

Sooo why does a policy based firewall rule "redirect" browsers to the OPNsense box? I have no captive portal active and the DNS still resolves the real (destination webserver) IPs.. but how is it possible OPNsense re-routes to itself? What might be causing this?


Thanks for any hints/ideas,
-J

You will have to use one firewall rule for each of the uplinks with the appropriate source prefix and then configure the right gateway in the firewall rule.

If those prefixes are dynamic, right now you're out of luck.

I have tried that @bimbar but that alone did not work, unfortunately. Clients still always picked the default gateway (which is WAN1, not the policy-routing target, WAN2/GW_WAN2 one) - which I assume makes sense.. how would they know, based on firewall rules, which route (wanting) to go out... RA wise they get IPs assigned out of both IPv6 subnets but what I am missing is how can clients know that for XYZ target networks, please use the non-default / WAN2 gateway?

Once that's clear/known to clients, I guess further FW rules make total sense (allowing the two lan clients' /64 subnets to access to/through the FW and also use the corresponding WAN gateway for that outwards) but my logical disconnect is, how would clients ever know which route to go? Setting up IPv6 FW rules has no effect on any routing 'announcements' or knowledge , at least not by default as far as I understand...

Since you can not reasonably use NAT on IPv6, you must make sure that not only the firewall routes over the correct uplink, but also that the client devices use the right source address.

So I'm afraid the best you can do is policy route on the firewall so the right source address is routed over the right uplink, you will not be able to determine which uplink to use beyond that, since the client makes that decision.

Yes, I think we're thinking the same here.. the missing link / information for me is though how to tell OPNsense which of the two /64 IPv6 subnet belongs to which of the two WAN interface/gateway?

How and where can I configure that the one /64 is routed via WAN1 and the other /64 via WAN2? How does OPNsense choose (and let LAN clients know) that for a certain target IPv6 network, it has to go over WAN2 vs the default WAN1?

Take a search through the forums for the implications of how this works.  This may fix your problem.

5SF

Just to double check I look for the right thing.. you mean the '(Disable) reply-to' functionality, right?

Good evening!

Under your Firewall -> Rules -> [Interface] are you choosing a gateway on the rule?

Yes I do - I have two rules there, one for IPv4, one for IPv6 and each have the corresponding IPv4 and IPv6 GW for WAN2 set. 'reply-to' per rule is set to 'default' (I tried setting the GW there explicitly as well, but made no change)... and

Also under Firewall -> Settings -> Advanced, did you "Disable reply-to" ?

... nope, the 'Disable reply-to' checkbox is not checked. Should I?

Good evening,

I have some problems with setting up two static wan interfaces in combination with policy based routing and maybe someone sees / reads what's wrong and could push me in the right direction.

I have two physical WAN connections coming in, each with one static IPv4 (/30) and one static IPv6 address (/126). In addition to that one static IPv6 address per link, I got a /48 block assigned.. again.. per link and the two are not overlapping. One's WAN1, one's WAN2. WAN1's IPv4 and IPv6 gateways have highest priority and are the default route(s).

To my LAN interface I have assigned a static 192.168.x.x/24 IPv4 address and a static fd6e:XXXX:YYYY:ZZZZ::1/64 IPv6 address.


I do not have any plans for multi wan in the sense of failover or load balancing (at least for now), I simply want to route certain target networks over WAN2. I've therefore added two Firewall > Settings > LAN rules, one for the IPv4 and one for IPv6 target networks I want to route to using WAN2 to utilize the corresponding WAN2 gateways.

Now this seems to work, albeit something is.. wrong. I can e.g. traceroute to the target IPv4 networks and can see the WAN2 IPv4 GW is used, but for IPv6... all trace hops time out. And there are some other effects.. which I assume are related to IPv6 not working.


I can reproduce the issue i.e. when I take all Google ASNs and get their IPv4 and IPv6 ip ranges, put them in an alias group and setup a firewall rule the same way.. to route to these target networks over WAN2.. and everything works, but slow (google.com takes initially long to load, but then appears in an instant.. same with youtube and videos etc.) - which I think (and I obviously might be very wrong here), that whenever IPv6 doesn't work for google services and / or browsers, they fall "back" to IPv4, which seems to work just fine..


So long story short.. my question basically is - what pieces of the puzzle might I be missing here to perform IPv6 policy based routing over a non-default WAN interface?


Thanks,
-J

Did you get QAT running? I got a 8970 card and just updated to 22.1 today, so I am very curious if anyone did manage to get it going.

Good afternoon,

my 21.7(.6 atm) OPNsense system has this re-occurring issue that for some reboots it 'falls' into an endless reboot cycle with panics shortly into the boot sequence.

The system itself is stable while up for weeks and weeks, but once I or an update performs a reboot, it sometimes (not always?) ends up in a neverending boot > crash > reboot > crash etc loop and all that seems to help is to turn the system physically off and back on again.

I have a hard time pinpointing what might be the cause here (and I know, without configs etc it might be difficult for others as well), but can maybe someone interpret the System > Firmware > Reporter logs and sees what might be going on?

dmesg.boot:

Code Select Expand

---<>---
Copyright (c) 2013-2019 The HardenedBSD Project.
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.1-RELEASE-p21-HBSD #0  1c99b63a2ba(stable/21.7)-dirty: Wed Nov 10 11:17:14 CET 2021
    root@sensey:/usr/obj/usr/src/amd64.amd64/sys/SMP amd64
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1)
VT(efifb): resolution 800x600
HardenedBSD: initialize and check features (__HardenedBSD_version 1200059 __FreeBSD_version 1201000).
CPU: Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz (3600.21-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x906ea  Family=0x6  Model=0x9e  Stepping=10
  Features=0xbfebfbff
  Features2=0x7ffafbff
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended Features=0x29c6fbb
  Structured Extended Features3=0x9c002600
  XSAVE Features=0xf
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 66566623232 (63482 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs
FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 hardware threads
FreeBSD/SMP Online: 1 package(s) x 6 core(s)
random: unblocking device.
ioapic0  irqs 0-119 on motherboard
Launching APs: 1 2 3 5 4
Timecounter "TSC-low" frequency 1800104924 Hz quality 1000
wlan: mac acl policy registered
random: entropy device external interface
kbd1 at kbdmux0
module_register_init: MOD_LOAD (vesa, 0xffffffff812947f0, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
000.000056 [4344] netmap_init               netmap: loaded module
[ath_hal] loaded
nexus0
efirtc0:  on motherboard
efirtc0: registered as a time-of-day clock, resolution 1.000000s
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
hpet0:  iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 24000000 Hz quality 950
Event timer "HPET" frequency 24000000 Hz quality 550
Event timer "HPET1" frequency 24000000 Hz quality 440
Event timer "HPET2" frequency 24000000 Hz quality 440
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  irq 16 at device 1.0 on pci0
pci1:  on pcib1
pcib2:  mem 0x81500000-0x8151ffff irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pci3:  at device 0.0 (no driver attached)
pcib4:  irq 17 at device 1.0 on pci2
pci4:  on pcib4
pci4:  at device 0.0 (no driver attached)
pcib5:  irq 18 at device 2.0 on pci2
pci5:  on pcib5
pci5:  at device 0.0 (no driver attached)
pcib6:  irq 16 at device 1.1 on pci0
pci6:  on pcib6
ixl0:  mem 0x4010800000-0x4010ffffff,0x4011008000-0x401100ffff irq 17 at device 0.0 on pci6
ixl0: fw 8.4.66032 api 1.14 nvm 8.40 etid 8000aba4 oem 1.267.0
ixl0: The driver for the device detected a newer version of the NVM image than expected.
ixl0: Please install the most recent version of the network driver.
ixl0: PF-ID[0]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C
ixl0: Using 1024 TX descriptors and 1024 RX descriptors
ixl0: Using 6 RX queues 6 TX queues
ixl0: Using MSI-X interrupts with 7 vectors
ixl0: Ethernet address: 3c:fd:fe:9f:62:4c
ixl0: Allocating 8 queues for PF LAN VSI; 6 queues active
ixl0: PCI Express Bus: Speed 8.0GT/s Width x8
ixl0: SR-IOV ready
ixl0: netmap queues/slots: TX 6/1024, RX 6/1024
ixl1:  mem 0x4010000000-0x40107fffff,0x4011000000-0x4011007fff irq 17 at device 0.1 on pci6
ixl1: fw 8.4.66032 api 1.14 nvm 8.40 etid 8000aba4 oem 1.267.0
ixl1: The driver for the device detected a newer version of the NVM image than expected.
ixl1: Please install the most recent version of the network driver.
ixl1: PF-ID[1]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C
ixl1: Using 1024 TX descriptors and 1024 RX descriptors
ixl1: Using 6 RX queues 6 TX queues
ixl1: Using MSI-X interrupts with 7 vectors
ixl1: Ethernet address: 3c:fd:fe:9f:62:4d
ixl1: Allocating 8 queues for PF LAN VSI; 6 queues active
ixl1: PCI Express Bus: Speed 8.0GT/s Width x8
ixl1: SR-IOV ready
ixl1: netmap queues/slots: TX 6/1024, RX 6/1024
vgapci0:  port 0x4000-0x403f mem 0x4012000000-0x4012ffffff,0x4000000000-0x400fffffff irq 16 at device 2.0 on pci0
vgapci0: Boot video device
xhci0:  mem 0x4013000000-0x401300ffff irq 16 at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
pci0:  at device 20.2 (no driver attached)
sdhci_pci0:  mem 0x4013019000-0x4013019fff irq 19 at device 20.5 on pci0
sdhci_pci0: 1 slot(s) allocated
pci0:  at device 21.0 (no driver attached)
pci0:  at device 21.1 (no driver attached)
pci0:  at device 22.0 (no driver attached)
pci0:  at device 22.1 (no driver attached)
pci0:  at device 22.4 (no driver attached)
ahci0:  port 0x4090-0x4097,0x4080-0x4083,0x4060-0x407f mem 0x81900000-0x81901fff,0x81903000-0x819030ff,0x81902000-0x819027ff irq 16 at device 23.0 on pci0
ahci0: AHCI v1.31 with 8 6Gbps ports, Port Multiplier not supported
ahcich0:  at channel 0 on ahci0
ahcich1:  at channel 1 on ahci0
ahcich2:  at channel 2 on ahci0
ahcich3:  at channel 3 on ahci0
ahcich4:  at channel 4 on ahci0
ahcich5:  at channel 5 on ahci0
ahcich6:  at channel 6 on ahci0
ahcich7:  at channel 7 on ahci0
ahciem0:  at channel 2147483647 on ahci0
device_attach: ahciem0 attach returned 6
pcib7:  irq 16 at device 27.0 on pci0
pci7:  on pcib7
pcib8:  irq 16 at device 27.4 on pci0
pci8:  on pcib8
ix0:  mem 0x4011800000-0x4011bfffff,0x4011c04000-0x4011c07fff irq 16 at device 0.0 on pci8
ix0: Using 2048 TX descriptors and 2048 RX descriptors
ix0: Using 6 RX queues 6 TX queues
ix0: Using MSI-X interrupts with 7 vectors
ix0: allocated for 6 queues
ix0: allocated for 6 rx queues
ix0: Ethernet address: d0:50:99:d9:f0:97
ix0: PCI Express Bus: Speed 8.0GT/s Width x4
ix0: netmap queues/slots: TX 6/2048, RX 6/2048
ix1:  mem 0x4011400000-0x40117fffff,0x4011c00000-0x4011c03fff irq 17 at device 0.1 on pci8
ixl1: Link is up, 10 Gbps Full Duplex, Requested FEC: None, Negotiated FEC: None, Autoneg: False, Flow Control: None
ixl1: link state changed to UP
ix1: Using 2048 TX descriptors and 2048 RX descriptors
ix1: Using 6 RX queues 6 TX queues
ix1: Using MSI-X interrupts with 7 vectors
ix1: allocated for 6 queues
ix1: allocated for 6 rx queues
ix1: Ethernet address: d0:50:99:d9:f0:96
ix1: PCI Express Bus: Speed 8.0GT/s Width x4
ix1: netmap queues/slots: TX 6/2048, RX 6/2048
pcib9:  irq 16 at device 28.0 on pci0
pci9:  on pcib9
pcib10:  irq 16 at device 0.0 on pci9
pci10:  on pcib10
vgapci1:  port 0x3000-0x307f mem 0x80000000-0x80ffffff,0x81000000-0x8101ffff irq 16 at device 0.0 on pci10
pcib11:  irq 16 at device 29.0 on pci0
pci11:  on pcib11
nvme0:  mem 0x81600000-0x81603fff irq 16 at device 0.0 on pci11
ixl0: Link is up, 10 Gbps Full Duplex, Requested FEC: None, Negotiated FEC: None, Autoneg: False, Flow Control: None
ixl0: link state changed to UP
pci0:  at device 30.0 (no driver attached)
isab0:  at device 31.0 on pci0
isa0:  on isab0
pci0:  at device 31.5 (no driver attached)
acpi_button0:  on acpi0
acpi_tz0:  on acpi0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
acpi_syscontainer0:  on acpi0
orm0:  at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0
atrtc0:  at port 0x70 irq 8 on isa0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
est0:  on cpu0
Timecounters tick every 1.000 msec
ugen0.1: <0x8086 XHCI root HUB> at usbus0
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
nvd0:  NVMe namespace
nvd0: 244198MB (500118192 512 byte sectors)
Trying to mount root from ufs:/dev/gpt/rootfs [rw]...
WARNING: /mnt was not properly dismounted
WARNING: /mnt: mount pending error: blocks 0 files 1
WARNING: /mnt: reload pending error: blocks 0 files 1

/var/crash/info.0:

Code Select Expand

Dump header from device: /dev/gpt/swapfs
  Architecture: amd64
  Architecture Version: 4
  Dump Length: 74752
  Blocksize: 512
  Compression: none
  Dumptime: Sat Dec  4 11:47:41 2021
  Hostname:
  Magic: FreeBSD Text Dump
  Version String: FreeBSD 12.1-RELEASE-p21-HBSD #0  1c99b63a2ba(stable/21.7)-dirty: Wed Nov 10 11:17:14 CET 2021
    root@sensey:/usr/obj/usr/src/amd64.amd64/sys/SMP
  Panic String: page fault
  Dump Parity: 3066618741
  Bounds: 0
  Dump Status: good

/var/crash/textdump.tar.0: See https://pastebin.com/407qeQMu