freebsd: bad stress test result on pi4/hdd

On a sunny day (Sun, 23 Jan 2022 08:16:39 +0000) it happened Mike Scott snipped-for-privacy@scottsonline.org.uk.invalid> wrote in <ssj2t7$pm7$ snipped-for-privacy@dont-email.me:

I am using this:

But maybe it is better to power the Pis via some HAT with battery, like this for example (have not tried it would design my own, but descriptio nmakes sense, and the thing is cheaper too):

It's hard to diagnose what's wrong without a serial console. AFAIK that's the only way to use single-user mode, which is how one normally recovers from an ungraceful shutdown. It's also useful for tinkering with u-boot if that becomes necessary. FreeBSD is still a little undercooked around the edges on the RPi series, but I've crashed mine more than a few times without serious problems.

hth,

bob prohaska

Then you're luckier than I am.

I put the system back together and tried the same thing - pulled the plug. Exactly the same problem - hangs waiting for the root device, disk light flashing away.

OTOH, I tried raspbian on the exact same h/w. Not a problem - had the full gui running, power cycled and it came straight back up every time.

I've been with freebsd for a long time (v4 if I recall), and it's been pretty robust against all manner if ills including power outages. But this one's a show stopper, and I've taken a very reluctant decision (but still reversible!) to move everything to raspbian. The hardest part seems to be the firewall - I understand pf imperfectly but well enough; iptables/firewalld seems to me a bit of a conceptual morass ATM.

On a sunny day (Tue, 25 Jan 2022 08:48:54 +0000) it happened Mike Scott snipped-for-privacy@scottsonline.org.uk.invalid> wrote in <ssodho$2jk$ snipped-for-privacy@dont-email.me:

For me to make using it simple I wrote 2 scripts:

To block an IP address:

/usr/local/sbin/ireject

# this is called to add an input deny for an IP addres to ipchains, # and save the configuration. if [ "$1" = "" ] then echo "Usage: ireject IP_address" exit 1 fi iptables -A INPUT -s $1 -p all -j DROP iptables -A OUTPUT -s $1 -p all -j REJECT /usr/sbin/iptables-save > /root/firewall exit 0

This is called at boot time:

/usr/local/sbin/load-firewall # flush old config iptables -F # load new config /usr/sbin/iptables-restore < /root/firewall exit 0

To test if firewall active type iptables -L

So to reject an IP_address I simply type ireject IP_ADDRESS

Since I am always root this works, but others may need sudo perhaps. Now have 4438 lines in /root/firewall ;-)

You can also reject IP ranges and specific ports

-A INPUT -p tcp -m tcp -m iprange --src-range XX.YY.ZZ.0-XX.YY.ZZ.255 -j DROP

-A INPUT -p tcp -m tcp -m iprange --dst-range XX.YY.ZZ.0-XX.YY.ZZ.255 -j DROP

-A INPUT -p tcp -m tcp --dport 20:21 -m iprange --src-range XX.YY.ZZ.0-XX.YY.ZZ.255 -j DROP

When using raspi as router things look a bit different echo "setting IP forwarding" iptables -F route add -net 192.168.0.0/16 dev eth0 echo 1 >/proc/sys/net/ipv4/ip_forward # This line finds the PI_address associated with interface ppp0 ip_address= `ifconfig | awk '/P-t-P/{print $2}' | cut -d':' -f2` iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -o ppp0 -j SNAT --to-source $ip_address

Using ppp0 becasue I use usb_modeswitch and an older 4G USB stick, the new ones show up as ethX

Simple ;-)

.....snip...

Thanks for the info.

My major issue is that I make extensive use of pf's "table" feature. I've recently found out that maps into "IP sets" with firewalld [I think!], but the interactions between various rule sets I find confusing ATM. But for reasons noted in my next posting following up BP's comments, I'll put this on hold.

Ah, bingo. There's the solution. I've put 'hw.fdt.console="NO"' into loader.conf. Now I see errors on the screen - and after fixing them up, it boots. Also, 'boot -s' now works, which I'd assumed was intentionally disabled.

Mind you, I also see at the top of loader.conf a 'boot_multicons="yes"', and maybe switching that to 'no' would have the same effect.

Who on earth thought switching errors mid-startup just to a serial console was a good idea?!

'autoboot_delay="2"' also seems a useful idea for the pi4, which seems to have a much slower countdown than the pi3.

But it looks as though I can stay with freebsd, which is a big win for me; I've learned a lot about linux's firewall which is also a win.

And while typing this, I've pulled the plug on the rpi several times: usual complaints about improper dismounts, but starts every time.

Many thanks.

Is this on HDMI/USB console? If so it's a considerable step forward. I've always used serial consoles and never thought to try it.

I've noticed the slow countdown, not sure if it's intentional or a bug. As bugs come and go it's not a big itch 8-)

That's encouraging, though I don't understand what it might be attributed to.

Good luck,

bob prohaska

Good call on these scripts! Nice way to make iptables a bit more managable.

Yes, sorry; I should have said. HDMI video and a wireless USB keyboard/mouse.

Indeed no; but I'm impatient! I'm more irritated by vncserver, but that'll have to be another thread.

The tool for Raspbian (Raspi OS) firewalls is nftables. It combines the old iptables and ebtables to give firewalling on layers 2 (Ethernet) and layer 3 (IP).

A good start site is

Just to be clear, you're using single-user on FreeBSD with a _wireless_ keyboard? That's a double surprise, I didn't think FreeBSD was anywhere near supporting native Pi wireless features, whether bluetooth or wifi.

Thanks for writing!

bob prohaska

USB keyboard that uses wireless to get to the USB...

That's a double surprise, I didn't think

It doesnt need to be,

On 26/01/2022 17:57, The Natural Philosopher wrote: ....

Indeed. USB dongle to a rather ancient mouse and keyboard. Saves wires cluttering an already untidy desk. Didn't occur to me about wireless direct to the pi.

It's amazing how many localised bits and bobs get onto a system over the years then left to do their job and forgotten about -- moving everything from the old i386 to the pi is proving quite a chore.