> I'd like to create a fedora feature for this, but I, um, don't intend to
> actually do any of the coding. I can talk about what's needed until I turn
> blue, though, and test things and so on. Would anyone like to raise their
> hand to help?
I don't think you're going to find anyone here that has the patience to
do an official feature. That's not to say we're not interested in doing
the coding work, just that we can do without the administrative
aggravation that comes with it.
> Basically, we need something that:
>
> - takes a kickstart in
> - outputs a tarball of /
It feels like you might need some sort of wrapper around anaconda that
does the argument passing for --dirinstall --kickstart= etc. and then
bundles the results up into a tarball.
> Requirements:
>
> * install without swap or any other partitioning (easy, I think)
> * install without any bootloader (should be done)
> * install with no docs (ditto)
A directory install should handle not needing any partitions, and the
rest should all be in git now.
> * don't add any packages not in the explictly-given package set + rpm reqs
I think at this point you're talking about this line:
packages = storage.packages + ["authconfig", "firewalld"] + ksdata.realm.packages
You're not going to have ksdata.realm.packages unless you specifically
ask for support. storage.packages is likely only going to be e2fsprogs
unless you specify partitioning with lvm or btrfs or multipath. So that
just leaves authconfig and firewalld, both of which are listed as
default in core.
The reason those two are required by anaconda right now is that we need
to be able to run them on the target system. authconfig, at least, we
always pass some arguments to. I guess firewalld will always do
something even if we're telling it to disable the firewall.
So if we're going to allow you to not install those packages, we still
need a way to run them. If they've got a chroot option, we can just do
that and run the versions on the installation media.
> Nice to Have:
>
> We do a number of things in the image kickstart `%post` that could be
> handled by the tool directly. This would make it easier for end users
> to make their own images without complicated kickstarts.
>
> * Create /dev/tty1 and /dev/loop# devices statically
> * soft-link /dev/tty1 to /dev/console
> * anonymize images with no /var/lib/random-seed or other supposed-to-be-
> unique elements (/etc/hosts?)
> * disable /tmp on tmpfs
These are all awfully specific things that I would prefer to keep out of
anaconda. Remember that kickstart files can %include stuff. You can
distribute a base one that does all the fancy stuff and then tell people
to %include it in their own.
> Bonus:
>
> * anaconda run in its non-vm mode to reduce build time and resources.
> In fact, it'd be ideal to be able to run this _inside a docker
> container_.
I guess you would have to try anaconda --dirinstall like this and see
what happens. I've not, so I don't know if it would work or not.
- Chris
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
