XPost: comp.unix.bsd.freebsd.misc

(This follows from the wireshark thread, but I've tried to move on)

I have a sparkling new rpi4B 4Gb. It booted raspbian (off the net)
happily, so I know that (a) the hardware works, and (b) I know how to
write the relevant sd card.

I've written the system
FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img
onto the sdcard, but all I get is the multicoloured screen that
indicates a problem. The green LED flickered irregularly on the way -
but hard to know which flickers are significant.

(I've used the same system in a pi3 - boots correctly)

I've also tried putting the same card in a USB reader (I gather from the
web that that ought to boot) - that gives a screenload of text moaning
about MSD command timeout plus other stuff. then seems to crash the pi
and goes back to the coloured screen.

In desperation I've tried writing the image to an HDD and connecting to
USB. That just goes to the coloured screen.


Can anyone help me get this going please? I really want to boot from HD ultimately. 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:

(This follows from the wireshark thread, but I've tried to move on)

I have a sparkling new rpi4B 4Gb. It booted raspbian (off the net)
happily, so I know that (a) the hardware works, and (b) I know how to
write the relevant sd card.

[snip]

Can anyone help me get this going please? I really want to boot from HD ultimately. Thanks.

Best to take a look at the freebsd-arm mailing list archives at https://lists.freebsd.org/archives/freebsd-arm/
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
https://lists.freebsd.org/archives/freebsd-arm/
but there are better resources by now.

Hope this helps,

bob prohaska
--- 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 bob prohaska <bp@www.zefox.net> wrote:

I've put some random notes at
https://lists.freebsd.org/archives/freebsd-arm/
but there are better resources by now.

Sorry, didn't refresh the clipboard. My notes are at http://www.zefox.net/~fbsd/
Alas, the disclaimer really does still apply.

Apologies for the confusion!

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 25/09/2021 03:17, bob prohaska wrote:

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

(This follows from the wireshark thread, but I've tried to move on)

I have a sparkling new rpi4B 4Gb. It booted raspbian (off the net)
happily, so I know that (a) the hardware works, and (b) I know how to
write the relevant sd card.

[snip]

Can anyone help me get this going please? I really want to boot from HD
ultimately. Thanks.

Best to take a look at the freebsd-arm mailing list archives at https://lists.freebsd.org/archives/freebsd-arm/
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
https://lists.freebsd.org/archives/freebsd-arm/
but there are better resources by now.

Hope this helps,

bob prohaska

Thanks for the advice. After posting, I kept digging around, and came
up with a long thread at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080

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

Thanks for the advice. After posting, I kept digging around, and came
up with a long thread at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080

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.

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

XPost: comp.unix.bsd.freebsd.misc

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

Glad you got it working thus far!

bob prohaska

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

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?

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

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

XPost: comp.unix.bsd.freebsd.misc

In message <sis1fu$htm$1@dont-email.me>
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

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?

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

XPost: comp.unix.bsd.freebsd.misc

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

Anyone had two HD's working in at once?

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

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

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

XPost: comp.unix.bsd.freebsd.misc

On Mon, 27 Sep 2021 16:29:50 +0100, Mike Scott wrote:

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.

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

XPost: comp.unix.bsd.freebsd.misc

On 27/09/2021 17:09, Martin Gregorie wrote:

On Mon, 27 Sep 2021 16:29:50 +0100, Mike Scott wrote:

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.

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.

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

XPost: comp.unix.bsd.freebsd.misc

On 27/09/2021 17:52, The Natural Philosopher wrote:

On 27/09/2021 17:09, Martin Gregorie wrote:

On Mon, 27 Sep 2021 16:29:50 +0100, Mike Scott wrote:

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.

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.

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

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

XPost: comp.unix.bsd.freebsd.misc

On Mon, 27 Sep 2021 20:12:27 +0100, Mike Scott wrote:

On 27/09/2021 17:52, The Natural Philosopher wrote:

On 27/09/2021 17:09, Martin Gregorie wrote:

On Mon, 27 Sep 2021 16:29:50 +0100, Mike Scott wrote:

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.

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.

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

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.

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

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

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

Here are some notes that might help: http://www.zefox.net/~fbsd/freebsd_on_raspberrypi
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
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

XPost: comp.unix.bsd.freebsd.misc

On Mon, 27 Sep 2021 10:37:49 +0000, crn wrote:

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

...or a USB drive which has it's own power skt and PSU.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)