XPost: comp.unix.bsd.freebsd.misc

Hi all.

I'd got a freebsd 13.0 system up and running booting from a usb3 disk on
a pi4. Before completing the final touches, I thought I'd stress test it
and simply pulled the mains plug out to see how well it would recover.

It didn't.

It gets part way up, but hangs "waiting for /dev/ufs/rootfs". Networking
seems to be up, as the pi can be pinged. But that's as far as it goes.

I've checked the disk on a separate machine, and fsck'd it. All looks
well. I've also cranked up kern.cam.boot_delay to 20000, but no change.

I guess I'll have to reinstall, but it would be good to know what the
issue is. And I'm disappointed in the failure mode: OK, pulling the plug
is nasty, but power companies do it from time to time; I don't mind if I
have to boot single user and fsck disks, but this.... Not Good.

Any thoughts? (Or recommendations for a UPS to run 2 pi's??)
Thanks.


--
Mike Scott
Harlow, England

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

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

Hi all.

I'd got a freebsd 13.0 system up and running booting from a usb3 disk on
a pi4. Before completing the final touches, I thought I'd stress test it
and simply pulled the mains plug out to see how well it would recover.

It didn't.

It gets part way up, but hangs "waiting for /dev/ufs/rootfs". Networking >seems to be up, as the pi can be pinged. But that's as far as it goes.

I've checked the disk on a separate machine, and fsck'd it. All looks
well. I've also cranked up kern.cam.boot_delay to 20000, but no change.

I guess I'll have to reinstall, but it would be good to know what the
issue is. And I'm disappointed in the failure mode: OK, pulling the plug
is nasty, but power companies do it from time to time; I don't mind if I
have to boot single user and fsck disks, but this.... Not Good.

Any thoughts? (Or recommendations for a UPS to run 2 pi's??)
Thanks.

I am using this:
https://www.apc.com/shop/nl/en/products/APC-Power-Saving-Back-UPS-ES-700VA-230V-8-Outlets-CEE-7-7/P-BE700G-GR
but it is noisy and now discontinued
works OK though.

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):
https://uk.pi-supply.com/products/pijuice-standard
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

Hi all.

I'd got a freebsd 13.0 system up and running booting from a usb3 disk on
a pi4. Before completing the final touches, I thought I'd stress test it
and simply pulled the mains plug out to see how well it would recover.

It didn't.

It gets part way up, but hangs "waiting for /dev/ufs/rootfs". Networking seems to be up, as the pi can be pinged. But that's as far as it goes.

I've checked the disk on a separate machine, and fsck'd it. All looks
well. I've also cranked up kern.cam.boot_delay to 20000, but no change.

I guess I'll have to reinstall, but it would be good to know what the
issue is. And I'm disappointed in the failure mode: OK, pulling the plug
is nasty, but power companies do it from time to time; I don't mind if I
have to boot single user and fsck disks, but this.... Not Good.

Any thoughts? (Or recommendations for a UPS to run 2 pi's??)

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
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

On 24/01/2022 23:59, bob prohaska wrote:

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

Hi all.

I'd got a freebsd 13.0 system up and running booting from a usb3 disk on
a pi4. Before completing the final touches, I thought I'd stress test it
and simply pulled the mains plug out to see how well it would recover.

It didn't.

It gets part way up, but hangs "waiting for /dev/ufs/rootfs". Networking
seems to be up, as the pi can be pinged. But that's as far as it goes.

I've checked the disk on a separate machine, and fsck'd it. All looks
well. I've also cranked up kern.cam.boot_delay to 20000, but no change.

I guess I'll have to reinstall, but it would be good to know what the
issue is. And I'm disappointed in the failure mode: OK, pulling the plug
is nasty, but power companies do it from time to time; I don't mind if I
have to boot single user and fsck disks, but this.... Not Good.

Any thoughts? (Or recommendations for a UPS to run 2 pi's??)

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.

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.

hth,

bob prohaska

--
Mike Scott
Harlow, England
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

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

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.

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 ;-)
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

On 25/01/2022 10:41, Jan Panteltje wrote:

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

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.

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

.....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.




--
Mike Scott
Harlow, England
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

On 24/01/2022 23:59, bob prohaska wrote:

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

Hi all.

I'd got a freebsd 13.0 system up and running booting from a usb3 disk on
a pi4. Before completing the final touches, I thought I'd stress test it
and simply pulled the mains plug out to see how well it would recover.

It didn't.

It gets part way up, but hangs "waiting for /dev/ufs/rootfs". Networking
seems to be up, as the pi can be pinged. But that's as far as it goes.

I've checked the disk on a separate machine, and fsck'd it. All looks
well. I've also cranked up kern.cam.boot_delay to 20000, but no change.

I guess I'll have to reinstall, but it would be good to know what the
issue is. And I'm disappointed in the failure mode: OK, pulling the plug
is nasty, but power companies do it from time to time; I don't mind if I
have to boot single user and fsck disks, but this.... Not Good.

Any thoughts? (Or recommendations for a UPS to run 2 pi's??)

It's hard to diagnose what's wrong without a serial console. AFAIK that's

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.

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

Many thanks.




--
Mike Scott
Harlow, England
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

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.

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.

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.

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-)

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.

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

Good luck,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

On 2022-01-25, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

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

To block an IP address:
To test if firewall active type
<snip>
Simple ;-)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

On 25/01/2022 18:46, bob prohaska wrote:

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

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.

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.

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

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.

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-)

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


--
Mike Scott
Harlow, England
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

On 25.1.2022 16:20 PM, Mike Scott wrote:

On 25/01/2022 10:41, Jan Panteltje wrote:

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

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.

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

.....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.

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 <https://wiki.nftables.org/wiki-nftables/index.php/Main_Page>.

--

-TV

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

On 25/01/2022 18:46, bob prohaska wrote:

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

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.

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.

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

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

On 26/01/2022 16:59, bob prohaska wrote:

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

On 25/01/2022 18:46, bob prohaska wrote:

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

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.

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.

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

Just to be clear, you're using single-user on FreeBSD with a
_wireless_ keyboard?

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


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

FreeBSD was anywhere near supporting native Pi wireless features,
whether bluetooth or wifi.

It doesnt need to be,

Thanks for writing!

bob prohaska

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

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

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

Just to be clear, you're using single-user on FreeBSD with a
_wireless_ keyboard?

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

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

FreeBSD was anywhere near supporting native Pi wireless features,
whether bluetooth or wifi.

It doesnt need to be,

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.


--
Mike Scott
Harlow, England

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)