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. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
