Re: adding swap when expanding root filesystem

On Nov 7, 2022, at 12:51, bob prohaska <fbsd@www.zefox.net> wrote:

> On Mon, Nov 07, 2022 at 12:47:29PM -0600, Mike Karels wrote:
>> On 7 Nov 2022, at 11:52, bob prohaska wrote:
>> 
>>> On Mon, Nov 07, 2022 at 10:10:38AM -0600, Mike Karels wrote:
> [snip]
> 
>>>> I have a prototype,
>>>> and wondered if this is a good thing to do.  Granted, this will often
>>>> create swap on microSD, which is not optimal, but probably better than
>>>> nothing.
>>>> 
> [snip]
> 
> Definitely better than nothing. I think it's a good thing to do.
> 
>>>> The current prototype creates a swap partition which is 1/10 of the disk
>>>> if the disk is at least 15 GB and the initial root partition is no more
>>>> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
>>>> probably enable this by default, but provide a way to disable it via a
>>>> kenv variable and/or a variable in /etc/rc.conf.
>>>> 
>>>> Thoughts?
>>> 
> 
> "Yes, please!". I'd suggest 2-4x physical RAM rather than 1.5x,
> simply because extra swap is harmless and microSD cards are 
> amply large; 64GB was about the smallest readily available 
> last time I looked. Now it's probably 128GB. 
> 
> It might be wise to add a warning about flash wearing out,
> but it took a year of near-continuous buildworlds to kill
> a 128GB microSD holding -current on a Pi3 with ~3 GB swap.
> 
> Anything done to make FreeBSD work better on Raspberry Pi
> and competitors is worth a try. Running from microSD isn't
> ideal but does work if used gently. It worked much better
> under armv7. Between aarch64 and growth in compilers
> working swap seems essential now, the more the better. 
> 
>>> For starters, is there any hope of making bsdinstall run from the
>>> microSD and installing FreeBSD via the traditional process on USB?
> [snip]
>> 
>> I think that???s a completely different problem.  I suspect that this
>> is already possible, fetching packages over the net, but I don???t
>> know the incantation.  Ideally the packages would be local, but then
>> the image would be more like a CD-ROM.  It would be nice to have
>> a procedure documented though.
>> 
> Since there's a complete system on the microSD can't that be used
> as the initial repository?
> 
> I agree it is a different problem in terms of implementation. 
> If bsdinstall can format a boot device for Raspberry Pi I should 
> give it a try.

Remember that bsdinstall does not deal with U-Boot
installation in general. Also the amount of space
U-Boot and the like takes varies. The Rock64 images
use a 16 MiByte space for its U-Boot and the like,
which are stored outside any file system. Most
do not require that much but I do not know if 16
MiBytes is the largest example around.

(Always reserving a large space may make layouts
more uniform --at the cost of not using part of
that space in many cases.)

Nor does bsdinstall deal with the likes of RPi*
firmware installation. (RPi*'s are not the only
examples of some material going in the msdosfs.
But some of those may also require U-Boot or
some such outside any file system.) RPi*'s also
have armstub8-gic.bin and armstub8.bin to deal
with (beyond what is strictly RPi* firmware).

As I remember there are systems with U-Boot/WhatEver
placement requirements that conflict with use of GPT:
MBR is used instead. There are also issues like some
RPi*'s not being able to boot from GPT unless
bootcode.bin is used. Even RPi4B's might have such
issues with an old enough EEPROM content (unsure).

As I remember, bsdinstall uses no installation target
specific information and requires user controlled
adjustments to make settings that would work for
the specific target environment. There would also be
separate steps outside bsdinstall. The dd and growfs
handling style is, in part, a way to avoid such
extra manual involvement and extra-knowledge
requirements.


===
Mark Millard
marklmi at yahoo.com