<dustymabe>
yes.. we have options. we could open an issue directly upstream (as you linked there) or we could open a BZ in Fedora against rawhide. Since we're working in rawhide which is really close to upstream I tend to go straight to the source sometimes
<jlebon>
i think we should probably do a bit more digging first. it's totally possible what we're doing isn't correct
<dustymabe>
jlebon: that's fair. Can you and saqali work together on that?
<saqali>
+1, not sure if we have enough info to give
<dustymabe>
or if you'd prefer.. I've got a race condition I'll trade you :)
<jlebon>
sure. saqali: do you have enough context to investigate, or do you want to chat a bit first?
<saqali>
I need more info about the hunch you mentioned in the tracker
<dustymabe>
bgilbert: am I right there ^^ that overrides.py doesn't support fast-tracking a build that isn't in bodhi?
jpn has quit [Ping timeout: 276 seconds]
<bgilbert>
dustymabe: yup
<dustymabe>
just checking.. are you opposed to supporting that OR are you "PR's welcome"?
<bgilbert>
dustymabe: I'm not opposed, but what would that mean exactly? when would we hit that case, and what would we put in the Bodhi link (which we've defined as mandatory for fast-tracks)?
<dustymabe>
I think it just means that there is a build that we know we want and the maintainer is probably going to make an update for it but we want to get it $now
<dustymabe>
for example.. systemd maintainer does a new build of systemd for us (which takes time to run and build) and then leaves for the day
<dustymabe>
tomorrow they will create a bodhi update (or at least they said they would)
<dustymabe>
but we want to use it today
<dustymabe>
it's totally fine for this special case to require manual updating
<dustymabe>
i'm just illustrating the case
<bgilbert>
I'm a bit hesitant because we're essentially shipping an off-the-record build
<bgilbert>
in that case
<dustymabe>
indeed
<bgilbert>
the other thing about a fast-track is that it automatically goes away when the build goes stable
<bgilbert>
which isn't directly defined without a Bodhi update
<dustymabe>
correct, we'd still want that
<bgilbert>
(yes, we can work backward to find a Bodhi update once that exists, but it may never exist)
<dustymabe>
my understanding from the code is that the graduated overrides flow doesn't require bodhi
<bgilbert>
yeah, I'm making a semantic argument rather than a code one
jpn has joined #fedora-coreos
<dustymabe>
it just checks the repos to see if there is a higher or equal NVRA
<dustymabe>
ahh. yeah
<bgilbert>
I don't feel super-strongly about it, just pointing it out
<dustymabe>
fair
<dustymabe>
cool. I think we'll leave it like it is. Just wanted to go through that thought exercise with you
<saqali>
jlebon: hmm commenting out symlink removal in coreos-teardown-initramfs.sh still created a failing build
<saqali>
Perhaps the issue is not that after all? Should we open an upstream issue?
<dustymabe>
ravanelli: +1
<dustymabe>
let's catch up in a bit
<dustymabe>
I need to finish the review on your other PR too
paragan has quit [Quit: Leaving]
<bgilbert>
saqali: while chatting with jlebon about serial console args, we realized there's a small missing piece in the GRUB password work
<bgilbert>
saqali: s390x doesn't use the grub.cfg at all. ppc64le does use the grub.cfg but doesn't use grub: petitboot parses the grub.cfg and supports a subset of the commands, not including the password ones
<bgilbert>
saqali: since this is a security feature, we shouldn't just quietly ignore the GRUB directives on platforms that don't support them
<bgilbert>
saqali: so we should probably add code in fedora-coreos-config that fails the boot if there are password directives in user.cfg on an arch that doesn't support them
<jlebon>
saqali: nice find. does the symlink still exist in the real root?
dwalsh has joined #fedora-coreos
jpn has quit [Ping timeout: 246 seconds]
tormath1 has quit [Quit: leaving]
jpn has joined #fedora-coreos
<saqali>
bgilbert: that sounds like a good idea, where in the boot process should we add this logic?
<bgilbert>
saqali: I think probably after Ignition files stage, before Ignition umount, because:
<bgilbert>
1) we should retain the semantics of failing in the initrd if an invalid config is provided, and
<bgilbert>
2) it's not worth the extra trouble of parsing the Ignition config to catch the problem before provisioning starts. if the config is invalid, the user will need to tear down the machine and start over anyway.
<saqali>
Are there any other checks relating to the config that we perform at this point?
azukku has joined #fedora-coreos
Betal has joined #fedora-coreos
jpn has quit [Ping timeout: 260 seconds]
<dustymabe>
jlebon: ravanelli: I did a round of review on https://github.com/coreos/coreos-assembler/pull/2887 - mostly minor comments. I think we can get this in soon and then fix anything else that shakes out when we integrate it.
<ravanelli>
dustymabe: Thanks, I'm fixiing the comments now
b10s_ has joined #fedora-coreos
dwalsh_ has joined #fedora-coreos
enilflah has joined #fedora-coreos
HappyHappyMan has joined #fedora-coreos
dustymab1 has joined #fedora-coreos
<bgilbert>
saqali: not afaik
<bgilbert>
I think it'd probably be a new service in 35coreos-ignition
dwalsh has quit [*.net *.split]
misuto has quit [*.net *.split]
djinni` has quit [*.net *.split]
b100s has quit [*.net *.split]
dustymabe has quit [*.net *.split]
HappyMan has quit [*.net *.split]
enilflah_ has quit [*.net *.split]
djinni` has joined #fedora-coreos
nemric has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn_ has joined #fedora-coreos
jpn has quit [Ping timeout: 276 seconds]
azukku has quit [Remote host closed the connection]
bagasse_ has joined #fedora-coreos
tempus_fol has joined #fedora-coreos
llamma` has joined #fedora-coreos
<jlebon>
walters: were you planning to backport the base-oscontainer schema change to cosa 4.11?