Re: Installing 13.1 ARM on SSD

On 2022-Jul-8, at 13:30, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Jul-8, at 13:10, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On 2022-Jul-8, at 12:15, John Kennedy <warlock@phouka.net> wrote:
>> 
>>> On Fri, Jul 08, 2022 at 06:26:59PM +0000, Wall, Stephen wrote:
>>>> I tried something like this - I used rsync to replicate the SD card's (mounted) msdos partition onto the SSD's (also mounted) efi partition.  That got past the firmware message, but then it stopped in the boot loader asking for a partition to boot from.  'zfs:zroot/ROOT/default' resulted in an unknown partition.
>>>> 
>>>> At the moment, I'm running with the SSD imaged from the FreeBSD RPI .img file, and that is working, but it's UFS, not ZFS.  I'll give your steps a try, and if I get nowhere, I might wind up creating a UFS partition for root and boot, and make the rest of the disk zfs with my desired filesystems.
>>> 
>>> So, bsdinstall should have set that up (zroot/ROOT/default).  From the
>>> UFS disk, I think (off the top of my head) you can just do a "zfs import
>>> zroot" and then you should be able to see it (and everything else) with
>>> a:  "zfs list -tall -r zroot"  If you picked something other than zroot
>>> for the pool name, you might need to do some more tweaking.
>>> 
>>> In my case, my USB disk is only ~256G.
>> 
>> "The Design and Implementation of the FreeBSD Operating System"
>> says about ZFS (page 548):
>> 
>> "Like all non-overwritingfile systems, ZFS operates best
>> when at least a quarter of its disk pool is free. Write
>> throughout becomes poor when the pool gets too full. By
>> contrast, UFS can run well to 95 percent full and acceptably
>> to 99 percent full."
>> 
>> So, for a 256 GiByte USB disk used basically just as space for
>> one ZFS area (so nearly all the 256 GiBytes is available),
>> That would mean being careful to avoid having much less than
>> 64 GiBytes free on the media: hopefully using less than 192
>> 192 GiBytes of space at all times.
> 
> Corrections: "that" not "That". Only one "192".
> 
>>> I don't know if uboot has any
>>> BIOS limitations like old x86 did.  I've never had to be too wary, but
>>> then I've never had BIOS-breaking SSDs laying around to attach to RPI.
>>> 
>>> I think uboot has some commands that might let you do some zfs
>>> exploration,
> 
> I'm not aware of the RPi* firmware or the U-Boot that it
> loads and starts being able to deal with ZFS of themselves.
> 
> The first stage that deals with ZFS, to my knowledge, is the
> FreeBSD EFI loader (that was loaded and started by U-Boot).
> 
> The RPi4B sequencing for the normal FreeBSD way of
> setting things up is:
> 
> RPi* firmware (I'll  not give substages in this)
> -> armstub8-gic and U-Boot

Sorry:

armstub8-gic is RPi4B (and related) specific.
The other/older aarch64 RPi*'s use armstub8 .

> -> FreeBSD loader
> -> FreeBSD kernel
> -> FreeBSD world
> 
> The FreeBSD loader goes on the msdosfs file system,
> under efi/ . . . but that msdosfs file system also
> has the RPi* firmware, armstub8-gic, and U-Boot
> files at its top level.
> 
> (Most other SBC boards seem to have U-Boot [and,
> sometimes more] outside any file system, needing to
> be dd'd to the right place that the partitioning
> and file systems need to avoid overlapping.)
> 
>>> but hate to point you at web resources because there seems
>>> to be a huge variations in what we end up with on FreeBSD/RPI.  My RPI
>>> is a few hours into a firefox rebuild so I can't give you some real
>>> guidance from what I'm using at the moment.
> 


===
Mark Millard
marklmi at yahoo.com