freebsd on pi4b won't boot

[snip]

Best to take a look at the freebsd-arm mailing list archives at

While at it, subscribe to at least freebsd-arm. I've gotten vast amounts of help there.

There are a few (many?) details to be worked through. I did it after getting my RPI4, which is now working happily, proof positive that it's a doable proposition with limited knowhow. As a first try, just pick a different snapshot and try that. Older, newer, doesn't matter. Start with SD card boot, then move to USB when you've got a good image.

I've put some random notes at

but there are better resources by now.

Hope this helps,

bob prohaska

Sorry, didn't refresh the clipboard. My notes are at

Alas, the disclaimer really does still apply.

Apologies for the confusion!

bob prohaska

Thanks for the advice. After posting, I kept digging around, and came up with a long thread at

of which comment #15 gives a download link (sourceforge) for an updated u-boot.bin which works fine for the sdcard boot.

However, booting from HD, it stalled after complaining 'mountroot: waiting for device /dev/ufs/rootfs'.

Cranking up kern.cam.boot_delay to 10 sec, necessary for the pi3, has mixed success here. Sometimes boots, sometimes not; sometimes tries the network instead. I'll free up a spare disk, and see if that makes a difference.

>

--
Mike Scott 
Harlow, England

FWIW, here's the /boot/loader.conf for my Pi4: # 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"

In particular, I don't recall where the line hw.usb.template=3 came from. If you don't have it that might be worth a try. My HDD is a 1 TB Seagate in a $10 USB-SATA case, both from Amazon, about as cheap as it gets.

If you don't have a serial console set up it might pay to acquire the usb-serial adapter needed. FreeBSD still won't listen to the USB keyboard in single-user mode. That makes it very difficult to debug (and report) problems.

Glad you got it working thus far!

bob prohaska

On 26/09/2021 01:58, bob prohaska wrote: ....

Thanks for the info.

I've now had it running happily off either sdcard or booting from HD. But I've hit another annoyance.

Basically, it won't run with two USB HDs attached. If I boot off sdcard, then plug in the disks, the first is fine: the second produces a stack of errors then crashes.

Messages start with da0: .... destroyed then it detaches the keyboard and mouse, then I get usbd_req_re_enumerate: .... USB_ERR_IOERROR, ignored

and it's power cycle time. Ouch!

Anyone had two HD's working in at once?

The PSU is the rpi 15W standard issue, btw. Could that be an issue though?

--
Mike Scott 
Harlow, England

The pi internals cannot supply 2 HDs with power. Use an external USB C hub with its own power.

--
http://www.netunix.com/

It's pretty much certain.

I do have a RasPi with two HDDs attached, but to make that work I had to get a very powerful PSU (mine's rated at 8 amps, which is more than enough, but it was not expensive), and, crucially, I had to jumper the main 5V line to the USB power pins so as to avoid the current limiting circuitry asspciated with USB within the Pi. This has my setup relying on the PSU's current limiting.

Don't do this unless you know what you're doing.

The other advice, getting a powered USB hub, is wise.

This may be jumping ahead a bit; but, if you get a hub and want to run both the Pi and the hub off the same PSU, beware of cheap power splitters that don't have enough copper in them and thus drop too much voltage.

David

On 27/09/2021 14:10, David Higton wrote: ....

OK, thanks - I get the picture. NCD, as my old maths teacher used to say.

The immediate reason for doing this is that the root partition resizes to fill the disk. I can't work out a way of making it resize to what I want -- hence a desire to copy between disks. But my knowledge of partitions is ATM clearly too limited :-{

Longer term is that this would prevent my current offline backup scheme (plug in backup disk, rsync, unplug disk) from working. I'll have to think a bit before proceeding.

Thanks again (to all, for your answers and patience).

--
Mike Scott 
Harlow, England

Don't forget that rsync can backup to a disk attached to a different machine on your LAN - when this is running there's a copy of rsync running on each machine: they talk to each other to transfer the data being backed up so, if the disk receiving backed up files is attached to a host other than the RPi, you don't need to attach more than one HDD to it.

I've been using this backup system for several years now. I'm backing up one RPi and three other Linux systems onto the same USB-connected HDD which, like you're planning to do, is kept offline in a firesafe when not receiving backups. Actually I have two backup disks, which are used in rotation, so there is always one in the firesafe with the door closed.

--
--   
Martin    | martin at 
Gregorie  | gregorie dot org

Yes. The tradeoffs between a usb connected drive and a usb connected gigabit ethernet are worth exploring, if you have, or feel like building, a NAS type solution

--
WOKE is an acronym... Without Originality, Knowledge or Education.

Thanks to both for the comments.

FWIW my main backup strategy is dump running daily, networking the output to my desktop machine. So if the server dies nastily and kills its disks, the data is safe elsewhere (although restore is /very/ messy!). That's kept for a couple of weeks. The 'rsync' backup is done occasionally, mainly to have a hot standby that's "not too out-of-date".

I'll review matters when the pi is running to my satisfaction.

--
Mike Scott 
Harlow, England

Backup frequency: I do the backups I described on a weekly basis, immediately before running software updates on all systems. That's a dnf update on the Fedora-based systems and apt update on RPis.

One of the Fedora machines is also my 'house server', which means it holds much more data, (mail archive, git repositories for locally developed software, etc.) so it additionally gets backed up overnight using rsnapshot, with the backups held on a USB drive that sits alongside the machine it backs up.

As this is primarily a sort of 'finger-trouble' protection I accept that its not proof against power spikes, fire, etc. Using a USB drive is a deliberate choice: each night a cron job mounts it, runs the rsnapshot backup and unmounts it, so it should should be fairly safe against malicious software because its invisible when unmounted. The backup run normally takes just under 10 minutes.

--
--   
Martin    | martin at 
Gregorie  | gregorie dot org

Not trivial, but doable if you can afford a few do-overs 8-)

Here are some notes that might help:

My procedure supposes single-user mode. You can suppress the filesystem resize by mouting the unbooted image media elsewhere and renaming or deleting an empty file in the FreeBSD root directory named firstboot.

HTH,

bob prohaska

...or a USB drive which has it's own power skt and PSU.