On Sun, Jan 12, 2020 at 3:53 PM Samuel Sieb <sam...@sieb.net> wrote: > > On 1/7/20 11:16 AM, Kevin Kofler wrote: > > Chris Murphy wrote: > >> Stacked images on the same media functionality is in the kernel, it's > >> not complicated, it's well tested, doesn't require any gymnastics in > >> the initramfs - your bootloader entries can each point to different > >> root=UUIDs and image assembly is figured out entirely in kernel code, > >> no special handling in the client side deliverable. Yes the image > >> creator needs to know some things to achieve this. > >> > >> Why stacked images? Consider a single base.img that's maybe 1G, and > >> now you don't have to do separate composes for server, cloud, GNOME, > >> KDE, Cinnamon, LXQt, Astronomy that repeat a lot of the same steps, > >> including expensive steps like compressing the same things over and > >> over again. Just do a 'dnf group install' tacked onto that base.img, > >> the work being done is custom for that output, rather than repetitive. > >> Not complicated. It would be fast enough that the high level variants > >> could be composed on demand. Seconds. It'd be fast enough to queue it > >> for download within the hour. > > > > Then how do you deliver the stacked images? Either the user still needs to > > download base.img + the specific image the user actually wants, either as 2 > > downloads (but then how does the user reliably get them onto bootable media? > > Surely you don't want to require 2 media!) or as 1 combined download, or you > > ship one image with base.img and all the specific layers at once, which will > > waste a lot of download size for all the images the user does not care > > about. I do not see what use case would be served by stacked images. > > > > What would be a much more useful feature is hybrid netinstall, i.e., > > allowing liveinst to netinstall additional packages on top of the installed > > live image. See the Calamares netinstall module (e.g., on my old Kannolo 27 > > images, as long as I don't have newer ones) for how the user experience can > > look like. And that requires only installer support, no file system or > > compression support. > > At first I did think the same thing as you did, that it would have all > of them. But my understanding of what he was suggesting is similar to > your suggestion. There's a base image and then for each spin, there's > an extra stacked image that contains whatever extra is needed for that > spin. So there's a separate iso for each spin, but each one has the > base image plus (at least) one other.
The ISO contains a base.img + the diff.img that makes that particular edition/spin ISO unique. Plausibly there's more than one diff file on an ISO depending on the desired level of granularity, and whether it's useful to have more than one bootable option per ISO. A single USB stick could get imaged with a single ISO file, capable of installing all the editions. But yeah, netinstall is a much faster and easier way to get to a one off custom "spin". A portal that basically helps create a kickstart or updates.img file for Anaconda to consume. And viola. Custom installer. The gotcha there is: it's not Live demo media, and to install multiple times you either take multiple download hits, or you have to setup a local mirror. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
