@robi: Nut package does not exist on 2.3. Yet….  :)

Hello! Thanks - switching to always R/W helped a lot  :)

The "Live CD" it mentions is an older platform that was removed. It literally ran the entire time from CD. If you installed to a disk in the firewall, it's not a Live CD after it's been installed, it's a Full Install.

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

No VMs, this is an Alix 2D13 box. I don't think it's a problem with my connection (residential cable 60/10) or Google getting slammed. This is a ping and trace route from a Windows 10 PC on my LAN: C:\Users\Max>ping /n 10 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=17ms TTL=57 Reply from 8.8.8.8: bytes=32 time=17ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Reply from 8.8.8.8: bytes=32 time=18ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Reply from 8.8.8.8: bytes=32 time=16ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Reply from 8.8.8.8: bytes=32 time=17ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Ping statistics for 8.8.8.8:     Packets: Sent = 10, Received = 10, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 15ms, Maximum = 18ms, Average = 16ms C:\Users\Max>tracert 8.8.8.8 Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops: 1    15 ms    8 ms    <1 ms  alix.xxxxxxx.ca [192.168.1.1]   2    13 ms    15 ms    9 ms  10.106.198.129   3    48 ms    19 ms    16 ms  67.231.220.33   4    20 ms    62 ms    22 ms  van58-9-231-73.dynamic.rogerstelecom.net [209.148.231.73]   5    71 ms    54 ms    46 ms  van58-9-229-225.dynamic.rogerstelecom.net [209.148.229.225]   6    57 ms    17 ms    34 ms  209.85.255.197   7    80 ms    36 ms    65 ms  209.85.244.81   8    16 ms    16 ms    39 ms  google-public-dns-a.google.com [8.8.8.8] Trace complete. This is from the Alix box (used the diag tools) just few seconds apart from previous test: PING 8.8.8.8 (8.8.8.8 ) from 24.xx.xx.xx: 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=58 time=417.078 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=15.511 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=15.816 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=730.556 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=15.938 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=58 time=16.812 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=58 time=734.701 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=58 time=731.509 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=58 time=730.188 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=58 time=725.335 ms –- 8.8.8.8 ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 15.511/413.344/734.701/336.799 ms Traceroute (using ICMP): 1  10.106.198.129  847.450 ms  814.365 ms  195.907 ms 2  67.231.220.33  1021.659 ms  19.124 ms  244.071 ms 3  209.148.231.73  749.957 ms  184.235 ms  823.869 ms 4  209.148.229.225  24.710 ms  576.026 ms  191.700 ms 5  209.85.255.197  210.232 ms  999.869 ms  227.566 ms 6  209.85.244.81  450.445 ms  17.743 ms  319.402 ms 7  8.8.8.8  14.587 ms  161.061 ms  823.111 ms There is no noticeable latency from any of the clients on the LAN. Speed test, ping tests are all normal, even playing online games is smooth. The problem seems to be when testing from the Alix box. In 2.2.6 apinger was reporting reporting the correct values.

Thanks, we've updated the sticky thread.

Phil, what'd you do to replicate? And on what kind of system? I'm testing on relatively fast hardware or VMs on fast systems, maybe something replicable on an ALIX or something? It was in a VirtualBox VM on my Windows10 laptop. I just tried rebooting it twice again and can't get the error to happen again. But for some reason the VM is booting much faster than usual at the moment, so maybe it is a timing thing.

the post was delete. This is a user to user forum and it is moderated and watched by admins and mods. So it is more common or usual that something will be corrected, deleted, pushed, baned, or lead to the right area by admins or mods.

Take a look at the possible fixes in: https://forum.pfsense.org/index.php?topic=109690.0

That's why I got no answers, the answer was here: https://forum.pfsense.org/index.php?topic=109690.0 Sorry for wasting hard drive space on the forums.

https://forum.pfsense.org/index.php?topic=105399.msg588219#msg588219 https://forum.pfsense.org/index.php?topic=105399.msg588787#msg588787

If something hooked into the same startup/shutdown scripts that handle the RRD and DHCP lease backups, perhaps, but that code does not exist currently.

I could resolve one issue. The problem with deleted snapshots was because of my backup process (xsibackup) was running wild. I was able to correct this. But the main issue is still on the table.

For info: I upgraded my v2.2.6(amd64 full) to v2.3.1 dev(didn´t see that 2.3 -rel was out…) After the upgrade I had -27Mb free diskspace of my 8Gb root. No package could do the upgrade due to no diskspace. Made a fresh install of 2.2.6 with old config and upgraded to 2.3 and this time it worked. /illern

That's weird.  Unchecking the box for the host on the master should disable it from being a sync target.  However, there were some fixes to the XMLRPC sync code by another forum member last year.  Those fixes corrected some longstanding things, but they may have inadvertently broken the "disable sync" for individual targets. The XMLRPC sync page is up for the some major rework soon, and I will be sure all this is addressed then. Bill

Hi Jimp, thanks for looking at my issue(s). I verified that box, and I have 3 rows in the /boot/loader.conf.local: ahci_load="YES" kern.cam.boot_delay=10000 kern.ipc.nmbclusters="1000000" I checked it against the "master" (still on 2.2.6), and see no difference, even the file TS is the same.