• freebsd: bad stress test result on pi4/hdd

    From Mike Scott@3:770/3 to All on Sun Jan 23 08:16:39 2022
    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)
  • From Jan Panteltje@3:770/3 to usenet.16@scottsonline.org.uk.inval on Sun Jan 23 09:06:00 2022
    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)
  • From bob prohaska@3:770/3 to Mike Scott on Mon Jan 24 23:59:49 2022
    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)
  • From Mike Scott@3:770/3 to bob prohaska on Tue Jan 25 08:48:54 2022
    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)
  • From Jan Panteltje@3:770/3 to usenet.16@scottsonline.org.uk.inval on Tue Jan 25 10:41:58 2022
    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)
  • From Mike Scott@3:770/3 to Jan Panteltje on Tue Jan 25 14:20:34 2022
    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)
  • From Mike Scott@3:770/3 to bob prohaska on Tue Jan 25 14:42:35 2022
    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)
  • From bob prohaska@3:770/3 to Mike Scott on Tue Jan 25 18:46:35 2022
    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)
  • From meff@3:770/3 to Jan Panteltje on Wed Jan 26 02:11:19 2022
    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)
  • From Mike Scott@3:770/3 to bob prohaska on Wed Jan 26 08:01:28 2022
    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)
  • From Tauno Voipio@3:770/3 to Mike Scott on Wed Jan 26 12:36:18 2022
    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)
  • From bob prohaska@3:770/3 to Mike Scott on Wed Jan 26 16:59:42 2022
    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)
  • From The Natural Philosopher@3:770/3 to bob prohaska on Wed Jan 26 17:57:29 2022
    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)
  • From Mike Scott@3:770/3 to The Natural Philosopher on Thu Jan 27 08:47:39 2022
    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)