Has anyone here installed FreeBSD on a raspberri pi before? The FreeBSD website
has a page dedicated to installing FreeBSD on a pi, but I would like to get
feedback from someone who's had first-hand experience.

.... Failure reading left brain. (A)bort (R)etry (F)rolic?

Unix Lord <nospam.Unix.Lord@f420.n105.z1.fidonet.org> wrote:
> Has anyone here installed FreeBSD on a raspberri pi before? The FreeBSD website
> has a page dedicated to installing FreeBSD on a pi, but I would like to get
> feedback from someone who's had first-hand experience.

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

On Wed, 05 Oct 2022 19:44:44 +1300
nospam.Unix.Lord@f420.n105.z1.fidonet.org (Unix Lord) wrote:

> Has anyone here installed FreeBSD on a raspberri pi before? The FreeBSD

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.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On 05/10/2022 07:44, Unix Lord wrote:
> Has anyone here installed FreeBSD on a raspberri pi before? The FreeBSD website
> has a page dedicated to installing FreeBSD on a pi, but I would like to get
> feedback from someone who's had first-hand experience.
>
> ... Failure reading left brain. (A)bort (R)etry (F)rolic?
>

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

--
Mike Scott
Harlow, England

Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>
> 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:
https://lists.freebsd.org/archives/freebsd-arm/

hth,

bob prohaska

On 07/10/2022 17:02, bob prohaska wrote:
> Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>>
>> 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.

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

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

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.(*)

>
> 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:
> https://lists.freebsd.org/archives/freebsd-arm/
>
> hth,
>
> bob prohaska
>

(*) 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.

--
Mike Scott
Harlow, England

On 2022-10-10, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
> On 07/10/2022 17:02, bob prohaska wrote:
>> Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>>>
>>> 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.
>
> 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).

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

>
>>
>> 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.
>
> 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.(*)
>
>>
>> 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:
>> https://lists.freebsd.org/archives/freebsd-arm/
>>
>> hth,
>>
>> bob prohaska
>>
>
> (*) 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.
>

Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
> On 07/10/2022 17:02, bob prohaska wrote:
>> Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>>>
>>> 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.
>
> 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).
>
>>
>> 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.
>
> 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.(*)
>
>>
>> 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:
>> https://lists.freebsd.org/archives/freebsd-arm/
>>
>> hth,
>>
>> bob prohaska
>>
>
> (*) 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.
>

Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>
> (*) 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"

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

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

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 :-{

--
Mike Scott
Harlow, England

Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
> On 11/10/2022 06:17, bob prohaska wrote:
> .....
>
>>
>> My /boot/loader.conf looks similar, but lacks hw.ftd.console="NO"
>> running 14-current. Hard to see how that would help, though.
>
> 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.
>

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

> 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 :-{
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

On 12/10/2022 16:25, bob prohaska wrote:
> Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>> On 11/10/2022 06:17, bob prohaska wrote:
>> .....
>>
>>>
>>> My /boot/loader.conf looks similar, but lacks hw.ftd.console="NO"
>>> running 14-current. Hard to see how that would help, though.
>>
>> 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.
>>
>
> Did anything bad happen? If not it's a useful thing to know.

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 for writing,

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

>
> bob prohaska
>

--
Mike Scott
Harlow, England