From nobody Tue Nov 8 00:07:08 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N5pM36kXzz4gnPb for ; Tue, 8 Nov 2022 00:07:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N5pM26LxCz3GZQ for ; Tue, 8 Nov 2022 00:07:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667866044; bh=Yx0pM741GGa8zQ0Sji1lqt4gUyzZygljhgUVycW/Pnc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tPNlEz6K58P8zpJYoRaLstSztjuXd0PNg/LnXmu0qmE8++HQ3XhfrE1uyWLcCRcKtg12qwp4hIPKI5dUgvV/UHb6PE8HoOxarzCbfpxsIwrfVOyJRwYLIbYjXtM5yo8WqXLr1uqfcsrQWlxcRtuv+A/mjOPwi06Vl/XaSzhmLDDh5g5q8/wxKee1sGHoFqzGMdfPGUI/+JtrZdM4Sr4iFeCs++9S9ODyNfrQUCkEcbz1Ca7PFOFVOYl4vtqH9VEPbgQALxEFry0eCe57165j30th1Sky60kMraChCCSlmxL3etiniXo3JS1BjGDlqQTF1r1WbfGC/p1qAM7T2QhdHg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667866044; bh=waVaI2Hu02p08BZe+gDOay2nGQL5N+qfMHZx7CcKNlF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cs0QR2kEp2g5CKK4feAoelr2GtQ1/hzGbABLVvBjBzyHX+QZUAoMAfzMtXQlutgcy2O+oUyA+NU1MAlxyDJxSF8RLYYNahSXLfvaElBkIR9jCY7/0OrluggYzJkbq6AReXfQRz0uxGYxA72T9k1xj76DPnUGw5fYyVXlREO8cFdroHNX3tMIZ+VtKAslk8496CQ/0VKwtbDdJfrBmrereYYW6ZTJGgOsfkLFdE0TeE2KAClBB8tdyRXmd8VlMU2Fane8NjIR+mkkXDZDwkNv/KEsX1QNPVWePcxqFOKsVXkMGvv8FkGREDdV5abzrGQOoe85Khksy5QWpYeqCBD7eA== X-YMail-OSG: G_vEmf0VM1kflx1IvyFCrmPKQ6ZdfHJNpgtSZGQGpnpEEMwrK2FhRRJForYnfNU 5ybeoZYEow8cMSeog9DeM2WmjD2Q3lBYaTJO_uLblCfFTTbXA.tIzs0ZhsZQulsPBpKG_MvSSH6E tIkgCFHhJXiUyoHdcxs3J7seP.8YhpAB2Ik4x5zMfFAhWH_xrgrI3chCGsAw5bSEQtegP8QAjOf. r85UMmlFxLVI9Epw7ZJdmDt8JGW15FgmsdSIpJBuszrXbx9rUTQEaXKxOyBw2ceqeuZ4MQQNMhsb fM2QLSVCbJoLlx7N0tVphdllIadEKCIDteQFEhiAkffdVpkpiv50KvVgdLVesroy9TtIGYNmp.pH 1YBbaBOhjEi2ZAy.rKw.M6ikdPlKIeFRxGO64mbwKPUk2ZijexM222jpJ32SOIDMBhJ0TGI5sWuq HPHh547TFSBdfC6GVD6JjY56ExTES9zWJ8S0jHoh3FQlxvKL.d2Art2WhFHNUJ2hKKIvBeeB1xFV uooInSO_qlsPxWq28kEq_uJuLao7OJrJJydej060dC04RqzEuzsLVKx8.7t0.VfRx774a1xV6S99 SgATBWR4t054msU4JVSn7SXuQgSj5CDtAr4Uk5p3vpMe8FeQmE6w5IwDmlTPIeNvLJNTDuSK6F_O KYrx_CVAfBEiDGlkfXZl9TBRUUD4.fjk7ypwIwCo_.wQfooCIQTuNLQ9ppM6z_cvdRq5Dmli77C0 ywIEMgY9Sa4se..5yedgI6CAB4yjDLPWawnDGsjyUjqxEBif7ZdLPa.8U0l7pnQUgpNsKY2KoDpc VQtc_gJiNvU7wPSyJRrMiZ5qAtgA_0OKA7IxEJ803GLbQM65V7W4QKyEIwBuAAw.zFkFl0rPBXIR mdwYoMbEDaeeOGrmyxb_YnD_9ihra.ScnoDhnkxGk7LGQwGgsDlfRJYbG9edo4TTOKpXIP6uwWZ6 MaFqYhbG0Nzxg_SGMI_EFA90rCRkwYQMdaHnXDUMmpWR7tfiSlJHomXT2x8.p67LSEPhzja2sT6c 5YIdTUK1WNrV0fxgfMiAlqcD3JjYfO8ukvS9T.VuTTNUQPTY8NDf36kcg_rSrpazvPpXH6rFM4aS xjSIXYD3IUFlKHqPra4SHP3aNga10ifL6cQblYKH6rtOrrtsx9zY_Od5gaDveyoZOotJzh27KUap KuiHe_m.sg5uaBAWT2uIxPcdXTpzUhAHJ_w3j0ryctA69jKPpy.UyIPQAN5g4I1UknTERYOa5n__ fdA0dD6UXqrcE2SrsYsWNCE4ddvi2MhsVRObS4HD9BhlEqSAyHlvivsiaGKlk2y0Z_j40ycOXTz0 565EC3UqMl9FeUhxl0M3JZNxnE2cUffUg9mVhZNIwjyQF32wX5GquNliw9fb2qNx44h1hT9Sc7sr 9MnfNuTY.HJgAwxDQkTY8M3zKb_pxLQbklYh7s.Fk0ODLdPTy5YnFkq4cgd7TSlS8gq4SKi1GvWP s8RApmIWWnUXhHvaJZIi0vDMo320S2cFhiYmyluqz._tIqdrFRFqSM0sHQA4dEfs5fKpSvYHL.lI Yqud3y5aUKLjl.j_hzE1L2eYfoY7cLzNP4Vw4Zgd6RpJ_uNYJP1ks1g3TkxzU.9_Tr.l.lTkwkZ7 IwXn4F06ZvDoggIvlXHkxFd2AQCAxYvm2F_NzN2S4STHBM9VXzhcj.r22.vsZYTpkj6rvV7y4hit T8HZTHA.kijkgZK6Of2DItroCp2ffmzlIy4KW5DQmwYajFeKqwb55FIcebsB7lYuzedC_vC0HGnu HMKJicr8t1XCwdszmLtr4A4jrVECWXp07gUsUbALDZx1FT63jWqZym9BxFZLTwfzlD6m99es84FN .dVRqeewd8tGrFXfslpuf.qaPrBAqegNWO1P4X5pfkPCSJI81eu2Lh3gz0vLjAfxfEbXUt53Oc6i CiXATMkneqAb57hrjMa9Q9MBvFNPGX87g2.T4GGLeud2DeIkX4XJRYVY0dDiTyfTJs15oWXbXPB. PtrP7y89U5KLhoz52PeQtJuLHXptEcRdc2ct.PWkq7TR.CP7LD_fjP4b6qVuB0QdFD1bVzx2Ig1w IaEhPgrnhViW6g4P85frENqmXK8bl_GY1KwpCvynQ97maRJskRukfkgp3WWIPbBedQ4P7NKuWKck QbldeGhDY0BNcJpzDZwgpdYdC2Wx0UCEJgsjST.5HPN2G8G15fXeQJEPE5H83lkqluuBL6T34uMK D7DrGRYq4Lovy7kcBZg7UDrFvM4RRZztOVJnYJozaso9i_0sNsjg5hrwc0OyWtbJGNjBU0c0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 00:07:24 +0000 Received: by hermes--production-bf1-5878955b5f-sffnj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eb642bc4096ef7b39bf29f9c7bc2bf1f; Tue, 08 Nov 2022 00:07:20 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: adding swap when expanding root filesystem From: Mark Millard In-Reply-To: <20221107205150.GA53784@www.zefox.net> Date: Mon, 7 Nov 2022 16:07:08 -0800 Cc: Mike Karels , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com> References: <202211071610.2A7GAcHl090048@mail.karels.net> <20221107175206.GA49113@www.zefox.net> <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net> <20221107205150.GA53784@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Rspamd-Queue-Id: 4N5pM26LxCz3GZQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tPNlEz6K; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.905]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On Nov 7, 2022, at 12:51, bob prohaska 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