08:52 <guesswhat[m]> Any idea how to debug kill() signals on FCOS? Ive tried to install bcc-tools to explore it wit killsnoop, but I have hard times installing it. Thanks

15:40 <millerthegorilla> hi, trying to pull in remote files during ignition, but getting certificate error due to time being set wrong.  How to set time so it is correct?  I have set the correct timezone, but no go.  Do I have to manually configure chronyd?'

15:47 <millerthegorilla> time sync is not happening on first boot, so external https sources are failing with x509 wrong time error. I see there is a github issue, but I guess it isn't solved for raspberry pi which has no battery rtc. https://github.com/coreos/ignition/issues/870

17:22 <millerthegorilla> coreos image has no python!? so impossible to use ansible? seems a bit strange, and there is no ignition config to allow installation of files. I guess I will have to set up a oneshot systemd service?

17:31 <apollo13[m]> Using ansible to configure coreos seems to be a bit against it's point. The idea is that the image is basically configured as you need it and for changes you deploy a new image

17:40 <millerthegorilla> apollo13 so how do I configure an image? Currently I am following the instructions at https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-raspberry-pi4/ and coreos-installer downloads the aarch64 image. I looked at coreos-installer iso customize, but it doesn't look like you can configure which packages are ultimately in the iso.

17:41 <millerthegorilla> and I am using ansible to install a bunch of packages and configure them, and also to configure a podman container setup. I don't think ignition can do that by itself.

17:47 <millerthegorilla> apollo13[m], I guess I could chroot into the provisioned disk's system... seems a lot of hassle though.

18:01 <apollo13[m]> Well my look on things might not 100% align with the coreos team but those are my thoughts: you can use rpm-ostree to install packages but that should basically be a last resort. You can use ignition to fetch binaries (not packages) and put them into the correct location. Or (and that is imo the way that follows the concept the most) build your own images. Either via cosa or by using docker images (yes you can use special docker

18:01 <apollo13[m]> images as upgrade targets for coreos).

18:02 <uny[m]> CoreOS's /var/log/README is a broken link. Is this worth a bug report?

18:10 <millerthegorilla> apollo13 - not good enough. There is no way I am going to shove binaries onto an image. I will only ever use the appropriate package manager as this does config, auditing, and guarantees correctly installed secure package.

18:12 <millerthegorilla> the butane specification should have a 'packages' section, to allow the specification of packages to be installed on first boot. Problem being that rpm-ostree then needs to reboot after install for new package tree to be current.

18:12 <apollo13[m]> millerthegorilla: do whatever you like, I am not trying to convince you. That said you should forget the idea that coreos has a "package manager". I would see it more like a stripped disk image and for an update you just boot another image

18:12 <millerthegorilla> An alternative would be to allow the customization of an image in the way that one can customize a podman image.

18:13 <apollo13[m]> You can customize coreos like you can with a podman image

18:14 <apollo13[m]> This is what I have written as option above

18:14 <millerthegorilla> coreos certainly has a package manager. rpm-ostree and its management of packages via an immutable os is the priniciple reason that I am using coreos. Immutability is a highly secure feature.

18:14 <apollo13[m]> But if you are using rpm-ostree inside the system that kinda goes against the idea of immutability for me. Ymmv

18:14 <millerthegorilla> apollo13 do you mind letting me know how? And I mean not by hacking it?

18:15 <millerthegorilla> ok fella. whatever you say.

18:15 <apollo13[m]> https://coreos.github.io/rpm-ostree/container/

18:28 <uny[m]> <apollo13[m]> "But if you are using rpm-..." <- Absolutely true in my experience. Tracking down issues on a stock CoreOS system is relatively easy since everyone's running it. Tracking down issues on a system with a bunch of layers and overrides, however, is not easy. And the first thing you're asked to do is to get rid of them and see if the bug still exists.

18:30 <uny[m]> Life's easier when the customization goes inside the containers.

18:30 <uny[m]> That said, it's pretty tough to keep to zero layered packages.

18:36 <apollo13[m]> Depends imo, building custom images with cosa directly is not impossible. And in general I think the container approach brings the best of the two worlds: you can add your own packages but you also get it in image form from the start which is useful if you run more than one machine

19:31 <millerthegorilla> hmm, it occurs that I can pull a podman container and then alias it to obtain python.

19:42 <apollo13[m]> yeah you can do that, though I don't think that will help you with ansible

21:10 <walters> You can also run Ansible as part of a container build, deriving from FCOS: https://github.com/coreos/layering-examples/tree/main/ansible-firewalld