RESOLVED: pilot error: After upgrade to 13.0-RELEASE ipfw locks the boxes

[Valeri Galtsev]

On 5/24/21 9:54 AM, Karl Dunn wrote:
> On 5/23/21 11:36 AM CDT, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote:
> 
> Dear All,
> 
> as a lazy person, before I start rewriting all my ipfw scripts I decided 
> to ask somebody?s else wisdom. It is possible that I mi
> ssed something I have to do related to ipfw in this particular upgrade: 
> from 12.2-RELEASE to 13.0-RELEASE
> 
> I have a bunch of boxes that I have rather similar (though not 
> identical) ipfw scripts on, these were written a while back (arou
> nd 8.x-RELEASE), and were just slightly modified on some occasions. None 
> of previous upgrades 8 ?> 9; 9 ?> 10,.. 11 ?> 12 led to
>   any problems as far as ipfw is concerned. I was just rebooting the 
> machine after kernel upgrade, and after userland upgrade and
>   all pkg reinstallation, I was testing things as usually, no problem 
> with ipfw.
> 
> After this upgrade: to 13.0-RELEASE, ipfw effectively locks any remote 
> access to the box (except for ping). My first guess was I
>   just missed relevant part in release notes (which I must confess I 
> rarely read carefully), but I don?t find anything special re
> lated to ipfw.
> 
> I hope, someone points me too obvious ?pilot error? I made. Before I 
> start re-creating ipfw scripts, and testing every line in t
> hem as did when I was learning it when first started playing with ipfw.
> 
> Thanks in advance for all your answers.
> 
> Valeri
> 
> ++++++++++++++++++++++++++++++++++++++++
> Valeri Galtsev
> Sr System Administrator
> Department of Astronomy and Astrophysics
> Kavli Institute for Cosmological Physics
> University of Chicago
> Phone: 773-702-4247
> ++++++++++++++++++++++++++++++++++++++++
> 
> Valeri:
> 
> A wild and unlikely guess (because ping works and nothing else does):
> 
> Interfaces name(s) have changed, e.g. what was em0 is now em1.
> 
> It might help to post relevant parts (or all) of dmesg, rc.conf and 
> loader.conf, and the (sanitized) ipfw rules.
> 
> I am on the digest for freebsd-auestions, so I will get your response 
> quicker if you copy me at kdunn at acm.org.
> 

Thank you, Karl!

Once I started collecting information Karl offered to look into, I had 
to reboot machine(s) with ipfw enabled, and I discovered that all works 
and ipfw does not lock the machine(s) off.

So, I figure my pilot error was: I did not disable ipfw for the duration 
of all upgrade steps, namely:

freebsd-update upgrade -r 13.0-RELEASE

freebsd-update install

reboot

freebsd-update install

pkg update

pkg upgrade -y -f

freebsd-update install


and I discovered I'm locked off somewhere before last step (removing 
unnecessary leftovers of previous system release on new system).


All is well on a bunch of systems, - on all systems I upgraded so far.


Bottom line: disable ipfw before starting upgrade; enable ipfw after ALL 
STEPS of upgrade are accomplished.

Thanks a lot Karl!

Valeri

> -- Karl Dunn kdunn at acm.org
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe at freebsd.org"

-- 
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++