Date: Fri, 18 Mar 2022 23:07:57 -0500 From: Kyle Evans <kevans@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, Eugene Grosbein <eugen@grosbein.net>, FreeBSD stable <freebsd-stable@freebsd.org>, FreeBSD Release Engineering Team <re@freebsd.org> Subject: Re: 13.1 mini-memstick installation image size Message-ID: <CACNAnaH7AoigLZ0uCu9tcmwM1_F=u9A0mg=dTk0QvoQMMrY3wg@mail.gmail.com> In-Reply-To: <CANCZdfr4fBqkuq4hiksGc_quJJRuAfMSRzfinY%2BJAnsMjL%2Bu%2Bw@mail.gmail.com> References: <72d30fc3-0ce4-51f8-ac7f-1b8eff63f3a9@grosbein.net> <CANCZdfokU7zi=D1TMdb0r4smy1fYgj-b_AvVY-HCzBTJ8q6v9g@mail.gmail.com> <373722bf-8f1d-7400-f639-83abdcd9fa10@grosbein.net> <20220319120900.3bca186fab063731706cbd65@dec.sakura.ne.jp> <CANCZdfr4fBqkuq4hiksGc_quJJRuAfMSRzfinY%2BJAnsMjL%2Bu%2Bw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 18, 2022 at 10:11 PM Warner Losh <imp@bsdimp.com> wrote: > > On Fri, Mar 18, 2022, 9:09 PM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote: >> >> On Sat, 19 Mar 2022 08:54:45 +0700 >> Eugene Grosbein <eugen@grosbein.net> wrote: >> >> > 19.03.2022 3:58, Warner Losh wrote: >> > >> > > On Fri, Mar 18, 2022 at 8:12 AM Eugene Grosbein <eugen@grosbein.net <mailto:eugen@grosbein.net>> wrote: >> > > >> > > Hi! >> > > >> > > I wonder if we really need /usr/share to be over 106MB in FreeBSD-13.1-BETA1-amd64-mini-memstick.img >> > > increasing its uncompressed size upto 434MB ? Same for bootonly image that is somewhat less >> > > but it's still pretty large to be used for network booting some hoster's virtual machine, for example. >> > > >> > > Isn't it time to use GEOM_UZIP, move kernel modules to /boot/modules out of /boot/kernel >> > > and compress /boot/modules (141MB) and /usr (165MB) to reduce size of "mini" installatiom media drastically? >> > > >> > > >> > > Or we could just compress the modules. We've supported loading compressed modules for a long time.... >> > >> > AFAIK, kldload cannot load compressed modules, only loader can. >> >> If so, kldload should support it as loader does. > > > I thought I'd added it years ago by uncomptessing to /tmp and loading it from there.. > The kldload(2) interface feels kind of ugly for this... I find myself often referencing `kldstat- v` to quickly figure out exactly which module I've loaded by path, but we don't really have a way of aliasing these back to the compressed source.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaH7AoigLZ0uCu9tcmwM1_F=u9A0mg=dTk0QvoQMMrY3wg>