FreeBSD

Yes, a few times. Earlier I needed to use a special image as the release ones weren't quite up to date with whatever Pi it was (Pi3?). More recently I think I just flashed the release image and it worked.

Theo

Not for some years, but back when my internet feed ran at 3Mb/s I used an original Rpi B (256Mb) as a router (using a USB ethernet adaptor for the second interface)and VOIP gateway (using yate) under FreeBSD. It all worked fine. I expect things have only become better.

FreeBSD 13 offers full tier 1 support for the PI. I have a Pi4 running as our family this-that-and-the-other server; not bad, but don't expect to run any heavy computations on it!

No biggy about installation if you're not fussy about partitioning - dd the image onto your drive, and boot (Pi4; slightly messier on earlier Pi's).

The OP doesn't indicate what Pi will be used. Like Mike, I've had good luck with a Pi4. I've also had good luck with Pi2 using the special USB bootcode.bin boot mode for USB disks. Pi3 is more tricky, working well with microSD boot but having some trouble booting from USB.

Having a serial console connection is _very_ useful. Single-user mode can't use a USB keyboard. That makes troubleshooting difficult without a serial console.

It's a good idea to subscribe to the FreeBSD-ARM mailing list. I've received a great deal of essential help there, evidenced by the archives:

bob prohaska

There's a work-around for early pi's: it's entirely possible to boot from SD card, but have the fstab on that point all partitions to a usb drive. I confess a weird hybrid, and I'm not clear on where the root partition is finally mounted from, but even so I think the worst that happens is that / is left as "rw but not much of either" (but mind /tmp).

Are you sure about that? I have a distinct memory of running into that a while back, and fixing it with loader.conf enabling dual consoles. IMBW.

If I can remember, and think through covid head-fuzz, I'll try to take a look later.(*)

(*) My pi4 loader.conf (13.1; boots from usb3 hd) is

# Configure USB OTG; see usb_template(4). hw.usb.template=3 umodem_load="YES" # Multiple console (serial+efi gop) enabled. boot_multicons="YES" boot_serial="YES" # Disable the beastie menu and color beastie_disable="YES" loader_color="NO"

hw.fdt.console="NO" autoboot_delay="2"

But I'm not at all sure offhand what all the incantations actually do.

The root partition is specified as a parameter/argument given to the kernel when it is loaded. In PiOS on a "standard" pi (no firmeware alterations) this is specified in cmdline.txt file in the FAT boot partition. So in pios on any pi, you can leave the pi to boot from the boot partition on the SD card, but specify a USB connected disk partition as the root partition. The booted OS can mount the SDScard boot partition readonly, or leave it unmounted. That way the sdcard is normally not written to and you don't get corruption.

I never mess with the firmware and have used this method for years and have not had sdcard corruption problems.

I'm not sure how freebsd arranges the boot process, but it must use the standard firmware to load the first stage of the boot process so should be able to do something similar.

Jim

My /boot/loader.conf looks similar, but lacks hw.ftd.console="NO" running 14-current. Hard to see how that would help, though.

root@nemesis:~ # more /boot/loader.conf # Configure USB OTG; see usb_template(4). hw.usb.template=3 umodem_load="YES" # Multiple console (serial+efi gop) enabled. boot_multicons="YES" boot_serial="YES" # Disable the beastie menu and color beastie_disable="YES" loader_color="NO" filemon_load="YES" net.inet.tcp.tolerate_missing_ts="1" #hw.usb.debug=1 vm.pageout_oom_seq="4096" vm.pfault_oom_attempts="120" vm.pfault_oom_wait="20" root@nemesis:~ # init 1 root@nemesis:~ # Stopping apache24. Waiting for PIDS: 1201. Stopping cron. Waiting for PIDS: 1154. Stopping sshd. Waiting for PIDS: 1144. Stopping powerd. Waiting for PIDS: 1101. Stopping devd. Waiting for PIDS: 851. Writing entropy file: . Writing early boot entropy file: . . Terminated Oct 10 14:18:42 nemesis syslogd: exiting on signal 15 Enter full pathname of shell or RETURN for /bin/sh:

but the HDMI console is unresponsive to typing on the USB keyboard.

When I exit from the single user shell on the serial console all returns to normal.

That isn't to say it's impossible to communicate with single-user mode via HDMI/USB, but it certainly isn't a default.

U-boot _is_ able to use an HDMI console in parallel with serial, but HDMI/USB became unresponsive after issuing usb reset. After that only the serial console worked. Typing boot at the loader prompt seemed to work. It's unclear what would happen in case of, for example, a mountroot failure.

Somewhat curious, at the very least....

Thanks for writing,

bob prohaska

On 11/10/2022 06:17, bob prohaska wrote: .....

Just done a check on my spare PI4/13.1

setting hw.ftd.console="NO" allows single-user, although the 'pick a shell' prompt gets a bit lost in other screen clutter. It does work though.

I've not a clue why though.

But, methinks, we had this very same conversation back in January ("bad stress test result", in cubfm and here). Must be age or covid; my memory's not what it was :-{

Did anything bad happen? If not it's a useful thing to know.

I've been carping about lack of single-user support on hdmi and usb for ages. I don't specifically remember either 8-(

Thanks for writing,

bob prohaska

Seems fine. Main machine's been running for months and has been upgraded from 13 to 13.1 in that time without issue. The spare Pi4 has been in and out of single user while checking this out, and that seems solid too.

Thanks rather to yourself - it was your earlier comments that enabled me to set the Pi up properly.