I'd like to fix: https://pagure.io/atomic-wg/issue/226
Right now for Atomic Host, we embed the ostree content inside the squashfs, with the goal that users of the ISO don't have to hit the network. We hook bits into interactive-defaults.ks; see this change for how it works:
https://pagure.io/fedora-lorax-templates/c/e34c371501d6eac75925aae86bd737c8a...
However, if one wants to then extract the ISO to do a kickstart install, the user must repeat the `ostreesetup` bits:
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/...
Specifically from his attachment: ostreesetup --osname="fedora-atomic" --remote="fedora-atomic" --url="file:////run/install/repo/content/repo" --ref="fedora-atomic/25/x86_64/docker-host" --nogpg
which is really internal implementation details that I'd like the ability to change without breaking people's kickstarts, and conversely not require them to specify by default.
Are there any facilities today for a "default kickstart" like /usr/share/anaconda/interactive-defaults.ks, except not just interactive?
Related to this, I was trying to do an "installer ISO sanity check" and ended up extracting the ISO like the docs suggest. However... this triggers a different mode where we don't end up mounting the squashfs (DRACUT_ISODIR in packaging/__init__.py terms), $repodir in dracut/anaconda-lib.sh terms AFAICS.
Which means the installation can't find the ostree content.
I guess maybe the right fix here is to plow forward on https://pagure.io/fedora-lorax-templates/c/e34c371501d6eac75925aae86bd737c8a... but if anyone knows the code here and can offer a quick anaconda-side change for the existing code that'd be handy.
I am assuming we want the ostreesetup command (and other stuff added to interactive-defaults.ks [2]) to be configured during the compose/build of the atomic installer iso, so trying to put it in installclass or common anaconda would not fit here, and we should look for a mechanism for adding kickstart snippet from installer image to regular kickstart (and maybe interactive-defaults.ks as well).
For example using something like /usr/share/anaconda/kickstart/ config file drop directory [1]. File /usr/share/anaconda/kickstart/10-atomic.cfg generated during installer iso build would be concatenated with regular kickstart. It would be actually prepended, but we may want to add option (or have in mind doing it in the future) to add it at the beginning or at the end (/pre /post sub directory, or assume regular kickstart being 50-ks.cfgi ?).
Now for atomic we would need the same snippet to be added to interactive-defaults.ks (non-kickstart installation) so: - either lorax (atomic installer compose) would put the same snippet also into interactive-defaults.ks during compose as it does now, but that would make for example things like placing the 10-atomic.cfg file via product.img impossible - or anaconda would add 10-atomic.cfg to both regular kicstart (for kickstart installation) and interactive-defaults.ks (for non-kickstart installation), but that may be too inflexible for other possible usages of the mechanism - or we would have separate drop subdirs for kickstart and interactive-defaults.ks
And as Martin Kolman reminded me, we could use the mechanism also to unify defaults for anaconda password policy (kickstart vs non-kickstart installations)
[1] We already have /usr/share/anaconda/kickstart/post-scripts containing eg post scripts for copying screenshots and logs to target system post install.
[2] /usr/shara/anaconda/interactive-defaults.ks
# Kickstart defaults file for an interative install. # This is not loaded if a kickstart file is provided on the command line. auth --enableshadow --passalgo=sha512 firstboot --enable
%anaconda # Default password policies pwpolicy root --notstrict --minlen=6 --minquality=50 --nochanges --notempty pwpolicy user --notstrict --minlen=6 --minquality=50 --nochanges --notempty pwpolicy luks --notstrict --minlen=6 --minquality=50 --nochanges --notempty # NOTE: This applies only to *fully* interactive installations, partial kickstart # installations use defaults specified in pyanaconda/pwpolicy.py. # Automated kickstart installs simply ignore the password policy as the policy # only applies to the UI, not for passwords specified in kickstart. %end ostreesetup --nogpg --osname=rhel-atomic-host --remote=rhel-atomic-host --url=file:///install/ostree --ref=rhel-atomic-host/7/x86_64/standard
services --disabled cloud-init,cloud-config,cloud-final,cloud-init-local
%post --erroronfail fn=/etc/ostree/remotes.d/rhel-atomic-host.conf; if test -f ${fn} && grep -q -e '^url=file:///install/ostree' ${fn}$; then rm ${fn}; fi %end
%post --erroronfail rm -f /etc/ostree/remotes.d/*.conf echo 'unconfigured-state=This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.'
$(ostree admin --print-current-dir).origin
%end
Radek
On 15.2.2017 16:03, Colin Walters wrote:
I'd like to fix: https://pagure.io/atomic-wg/issue/226
Right now for Atomic Host, we embed the ostree content inside the squashfs, with the goal that users of the ISO don't have to hit the network. We hook bits into interactive-defaults.ks; see this change for how it works:
https://pagure.io/fedora-lorax-templates/c/e34c371501d6eac75925aae86bd737c8a...
However, if one wants to then extract the ISO to do a kickstart install, the user must repeat the `ostreesetup` bits:
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/...
Specifically from his attachment: ostreesetup --osname="fedora-atomic" --remote="fedora-atomic" --url="file:////run/install/repo/content/repo" --ref="fedora-atomic/25/x86_64/docker-host" --nogpg
which is really internal implementation details that I'd like the ability to change without breaking people's kickstarts, and conversely not require them to specify by default.
Are there any facilities today for a "default kickstart" like /usr/share/anaconda/interactive-defaults.ks, except not just interactive?
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Hello,
I finally got to work on this and came up with this PR for master: https://github.com/rhinstaller/anaconda/pull/1076 We could consider it for f26 if it is useful for Atomic.
Radek
On 15.2.2017 16:03, Colin Walters wrote:
I'd like to fix: https://pagure.io/atomic-wg/issue/226
Right now for Atomic Host, we embed the ostree content inside the squashfs, with the goal that users of the ISO don't have to hit the network. We hook bits into interactive-defaults.ks; see this change for how it works:
https://pagure.io/fedora-lorax-templates/c/e34c371501d6eac75925aae86bd737c8a...
However, if one wants to then extract the ISO to do a kickstart install, the user must repeat the `ostreesetup` bits:
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/...
Specifically from his attachment: ostreesetup --osname="fedora-atomic" --remote="fedora-atomic" --url="file:////run/install/repo/content/repo" --ref="fedora-atomic/25/x86_64/docker-host" --nogpg
which is really internal implementation details that I'd like the ability to change without breaking people's kickstarts, and conversely not require them to specify by default.
Are there any facilities today for a "default kickstart" like /usr/share/anaconda/interactive-defaults.ks, except not just interactive?
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On 05/23/2017 01:45 PM, Radek Vykydal wrote:
Hello,
I finally got to work on this and came up with this PR for master: https://github.com/rhinstaller/anaconda/pull/1076 We could consider it for f26 if it is useful for Atomic.
Radek
I closed the PR and I am moving the discussion back to the list.
From the PR:
I'm thinking that it's probably best for now to find a place to hack
in the logic
to say "if there's no payload specified, and we find ostree data in
/ostree/repo,
pick that up automatically".
- Are we able to pick all needed values specified by ostreerepo command from the data/repo we find? - How about other configuration (%post) from atomic interactive-defaults.ks - could it be moved into anaconda logic as well? So the interactive-defaults.ks mechanism is not needed...
Radek
On 15.2.2017 16:03, Colin Walters wrote:
I'd like to fix: https://pagure.io/atomic-wg/issue/226
Right now for Atomic Host, we embed the ostree content inside the squashfs, with the goal that users of the ISO don't have to hit the network. We hook bits into interactive-defaults.ks; see this change for how it works:
https://pagure.io/fedora-lorax-templates/c/e34c371501d6eac75925aae86bd737c8a...
However, if one wants to then extract the ISO to do a kickstart install, the user must repeat the `ostreesetup` bits:
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/...
Specifically from his attachment: ostreesetup --osname="fedora-atomic" --remote="fedora-atomic" --url="file:////run/install/repo/content/repo" --ref="fedora-atomic/25/x86_64/docker-host" --nogpg
which is really internal implementation details that I'd like the ability to change without breaking people's kickstarts, and conversely not require them to specify by default.
Are there any facilities today for a "default kickstart" like /usr/share/anaconda/interactive-defaults.ks, except not just interactive?
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.stg.fedoraproject.org