Date: Mon, 7 Nov 2022 16:07:08 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Mike Karels <mike@karels.net>, freebsd-arm@freebsd.org Subject: Re: adding swap when expanding root filesystem Message-ID: <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com> In-Reply-To: <20221107205150.GA53784@www.zefox.net> References: <202211071610.2A7GAcHl090048@mail.karels.net> <20221107175206.GA49113@www.zefox.net> <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net> <20221107205150.GA53784@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09E80B35-0325-44E6-8191-55DCC79A51F1>