On Fri, Dec 09, 2022 at 08:09:42AM +0000, Daniel P. Berrangé wrote: > On Thu, Dec 08, 2022 at 12:54:16PM -0800, Adam Williamson wrote: > > On Thu, 2022-12-08 at 20:43 +0100, drago01 wrote: > > > On Thursday, December 8, 2022, Chris Adams <linux@xxxxxxxxxxx> wrote: > > > > > > > Once upon a time, Daniel P. Berrangé <berrange@xxxxxxxxxx> said: > > > > > On Thu, Dec 08, 2022 at 07:59:20PM +0100, drago01 wrote: > > > > > > That would be very crazy, as you will have a degraded user experience > > > > > > (laggy UI, wrong resolution, ...) to save a couple of megabytes that > > > > are a > > > > > > non issue for today's hardware. > > > > > > > > > > Please bear in mind the difference between bare metal and virtual > > > > > machines. The bare metal machine may have 32 GB of RAM, making a > > > > > 800 MB install image a non-issue. For a public cloud virtual machine > > > > > though, this could bump your VM sizing up 1 level from 2 GB quota > > > > > to a 4 GB RAM quota, with correspondingly higher price point. > > > > > > > > Also "today's hardware" increasingly includes small devices like > > > > Raspberry Pi. ARM devices don't typically use anaconda, but there are > > > > also small x86 based devices competing with the small ARM devices. > > > > > > > > I think the answer is "no", but I'll ask anyway: is there a way to evict > > > > all the firmware once the system is started? I'm guessing that as long > > > > as it's all in one disk image, that's not possible. Can we tack on a > > > > second disk image with use-once (at most) stuff and then drop the whole > > > > image after startup? > > > > > > > > > > Again there is no reason why everything on the disk image had to be loaded > > > into memory in the first place. Same way when you boot your installed > > > system, not everything on disk is loaded into memory. If you don't need the > > > firmware, it should stay on the install media and never be loaded into > > > memory. > > > > The problem is, what is "the install media"? We don't *only* support > > installs from USB sticks and DVDs - things the installer could > > potentially access as local storage after starting up. We also do > > installs where everything is retrieved over the network - PXE installs, > > for instance. > > > > There are possible ways to finesse things even in those cases - as I > > said, Daniel started thinking them through a bit - but it's not as > > simple as just "put this stuff on the ISO and read it off that". > > It could potentially be almost that simple actually > > qemu-nbd -c https:///some.server/path/to/second.iso > mount /dev/nbd0 /mnt/second-iso > > This uses QEMU's curl driver, which will fetch blocks of the ISO > content only as they are accessed, so you're not pulling down the > whole ISO if you only read 2 files from it. > > The 'nbdkit' program can be used instead of qemu-nbd, and probably > a better choice since it can layer into all sorts of interesting > functionality that QEMU's curl layer can't offer. This, but using kernel nbd root instead of a qemu nbd file: https://rwmj.wordpress.com/2019/02/19/nbdkit-linuxdisk-plugin/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
