Are we close to an RC release?

DefenderLLC

I noticed that this RC version did not clear my package cache. You can run this command to reclaim the disk space:

pkg clean -a

DefenderLLC

@stephenw10 said in Are we close to an RC release?:

Hmm, that's odd. Anything logged?

What should I look for specifically? Thanks!

dennypage

@DefenderLLC said in Are we close to an RC release?:

I noticed that this RC version did not clear my package cache.

I saw the same.

stephenw10

@DefenderLLC said in Are we close to an RC release?:

What should I look for specifically? Thanks!

Something that shows it verifying the boot automatically when it should have been manual for example.

DefenderLLC

@stephenw10 Can you do the boot verification from the console? I may have inadvertently pressed enter s bunch of times when I was trying to establish a session via USB cable. Things appeared to have been locked up before the terminal refreshened with new text.

stephenw10

Hmm, not sure I've ever tried!

DefenderLLC

@stephenw10 I'll to the upgrade from the console on the released version and report back! I have a feeling that's what happened because I admittedly got impatient after 10 minutes of not being able to SSH in. Normally the 24.03 upgrades were really quick (like < 2 min).

There's another 6100 MAX users that experienced the same slow upgrade. The main difference is that he is running Snort vs Suricata. He did paste some log failures in his post. Take note of the last line:

Performing automatic boot verification...done.

https://forum.netgate.com/topic/187308/24-03-rc-install-long-delays/

stephenw10

Hmm, it really is actually before the WAN is configured then....

DefenderLLC

@stephenw10 In my case, I have pfSense setup as a transparent firewall now, so there are no IP addresses on my WAN, LAN, or BRIDGE interfaces - only the MGMT interface. Not sure if that is related to my slow upgrade. I doubt it as everything is working perfectly fine pre and post upgrade.

stephenw10

As long as it has a default route via that interface it should be fine. But obviously not if that interface hasn't been configured yet when it does.

DefenderLLC

@stephenw10 said in Are we close to an RC release?:

As long as it has a default route via that interface it should be fine. But obviously not if that interface hasn't been configured yet when it does.

I can't put an IP on my BRDIGE interface because my 6100 MAX is sitting between the AT&T Fiber Gateway (which is in bridge mode itself) to my UDM-SE, so a LAN IP can't be assigned to it since the public IPs are being managed by UniFi.

stephenw10

Managed on the WAN side of the Unifi? The bridge would be in the same layer 2 as that if so so should be able to use one.

But that wouldn't matter for the update traffic. As long as pfSense has a valid default route from any interface it should be able to update.

DefenderLLC

@stephenw10 said in Are we close to an RC release?:

Managed on the WAN side of the Unifi? The bridge would be in the same layer 2 as that if so so should be able to use one.

But that wouldn't matter for the update traffic. As long as pfSense has a valid default route from any interface it should be able to update.

Here is the layout:

AT&T Gateway (mgmt IP 192.168.0.1) (IP Passover Mode) - 6100 MAX Bridge - UDM (where the WAN DHCP and additional /29 IPs are managed).

So I can't put a 192.168.0.* IP on the BRIDGE because that messes up the AT&T gateway setup with IP passover mode to the UDM. I tried it and the UniFi network lost connectivity. I also can't assign a 10.0.1.* IP from the UniFI LAN on the bridge because the bridge is in front of the UDM's WAN.

To get around all of this, I just added a MGMT interface and connected it to our 48-port switch on the UniFi LAN. My setup works, so I'm not complaining. :)

stephenw10

Can't replicate the manual verification issue. It works as expected hen upgrading to the public RC for me.

There's no way to accidentally verify it at the console. There's no easy way to do it at all.

DefenderLLC

@stephenw10 said in Are we close to an RC release?:

Can't replicate the manual verification issue. It works as expected hen upgrading to the public RC for me.

There's no way to accidentally verify it at the console. There's no easy way to do it at all.

Interesting. Since the upgrade exceeded my 300 seconds defined interval, perhaps it just skipped it since the system was still being upgraded due to the other issue you just submitted to Redmine. Thanks for checking on it though!