dustymabe changed the topic of #fedora-coreos to: Fedora CoreOS :: Find out more at https://getfedora.org/coreos/ :: Logs at https://libera.irclog.whitequark.org/fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Client Quit]
jpn has joined #fedora-coreos
jpn has quit [Client Quit]
mnguyen has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
saqali has quit [Quit: Leaving]
lvrabec_ has joined #fedora-coreos
gursewak has quit [Ping timeout: 258 seconds]
lvrabec has quit [Read error: Connection reset by peer]
gursewak has joined #fedora-coreos
HappyMan has quit [Ping timeout: 260 seconds]
gursewak has quit [Ping timeout: 256 seconds]
gursewak has joined #fedora-coreos
gursewak has quit [Ping timeout: 248 seconds]
tempus_fol is now known as tempora
Anders[m] has joined #fedora-coreos
bgilbert has quit [Ping timeout: 256 seconds]
heldwin has joined #fedora-coreos
Betal has quit [Quit: WeeChat 3.5]
QuentinTheJerky has joined #fedora-coreos
<QuentinTheJerky> do you have to do anything special in coreos for docker containers to forward ports to allow outside access?
<travier[m]> QuentinTheJerky: Nothing special. Have you published the ports used by the container?
<QuentinTheJerky> only like: sudo podman run -it --name samba -p 139:139 -p 445:445
<QuentinTheJerky> can see its listening in netstat -tulpn
<QuentinTheJerky> but cant connect it seems
<QuentinTheJerky> anyone have experience with container dperson/samba in coreos ?
QuentinTheJerky has quit [Quit: QuentinTheJerky]
QuentinTheJerky has joined #fedora-coreos
QuentinTheJerky has quit [Client Quit]
<travier[m]> QuentinTheJerky: You'll probably get an answer faster in a docker support channel
QuentinTheJerky has joined #fedora-coreos
QuentinTheJerky has quit [Quit: QuentinTheJerky]
QuentinTheJerky has joined #fedora-coreos
QuentinTheJerky has quit [Client Quit]
jakfrost has joined #fedora-coreos
ravanelli has joined #fedora-coreos
jpn has joined #fedora-coreos
ravanelli has quit [Read error: Connection reset by peer]
ravanelli has joined #fedora-coreos
jpn has quit [Ping timeout: 240 seconds]
mnguyen_ has joined #fedora-coreos
<dustymabe> though it did look like he was using podman?
mnguyen has quit [Ping timeout: 246 seconds]
<dustymabe> LakshmiRavichand: mind a review on https://github.com/coreos/fedora-coreos-config/pull/1796
mnguyen has joined #fedora-coreos
mnguyen_ has quit [Ping timeout: 276 seconds]
jakfrost has quit [Quit: Leaving]
crobinso has joined #fedora-coreos
<travier[m]> dustymabe: my bad, I read docker container and assumed docker
<travier[m]> QuentinTheJerky: podman support channel should be good too :)
<dustymabe> travier[m]: jlebon: I'm trying to chase down https://github.com/coreos/coreos-assembler/pull/2921#issuecomment-1155517794
<dustymabe> I'm guessing that coreos-diskful-generator runs in both the initrd and the real root which is causing the file to already exist?
<dustymabe> does anyone know here off the top of their head if /run/ is preserved from the initrd in the real root?
<dustymabe> i'm looking at a booted system and I don't see /run/udev/rules.d/80-coreos-boot-disk.rules at all
<dustymabe> but according to the error (which is present on every boot) it does exist.
<dustymabe> I have a local patch to update COSA/mantle/kola to detect if a generator failed
<dustymabe> hmm - maybe I'm wrong that it's executing in the real root.. Maybe there is a process in the initrd that is executing a daemon-reload (which re-executes all generators)
<dustymabe> some contenders: https://paste.centos.org/view/fea3a319
<dustymabe> yeah OK.. I guess we should just make that generator more idempotent
<dustymabe> we should probably re-evaluate all of our generators for idempotency considering daemon-reload will re-execute them
mheon has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
nalind has joined #fedora-coreos
mnguyen_ has joined #fedora-coreos
jpn has joined #fedora-coreos
heldwin has quit [Ping timeout: 240 seconds]
<sgallagh> Colin Walters: Have you seen an issue with rpm-ostree getting stuck in a loop trying to prep an upgrade? I'm looking at my journal and it keeps hitting:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/54760a2fda1651eb6a4103ed38a56c624854dbfd)
mnguyen has quit [Ping timeout: 256 seconds]
<sgallagh> (FTR, this is on Silverblue, if that matters. I figured this was a better channel for discussing ostree stuff though)
heldwin has joined #fedora-coreos
jpn has quit [Ping timeout: 248 seconds]
<dustymabe> sgallagh: FWIW I haven't seen that
<sgallagh> Actually, I take it back. It's not forever. After a long enough time, it ends up crashing. Getting a coredump now.
saqali has joined #fedora-coreos
plarsen has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 276 seconds]
<jlebon> for now, you can temporarily manually use the CLI to upgrade until it makes it in the compose
ravanelli has joined #fedora-coreos
<sgallagh> jlebon: That's it exactly. Thanks!
<jlebon> just submitted it to stable :)
<dustymabe> jlebon++
<zodbot> dustymabe: Karma for jlebon changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any
<lucab> that shouldn't block an upgrade though, it's just some warnings in the logs
<lucab> (unless it coredumps on something directly related to those gvariants)
<sgallagh> lucab: I have a core file (235MiB compressed) so if you want to have a look...
<jlebon> sgallagh: can you pastebin just the stack trace for now?
<jlebon> hmm yeah, that looks like a different issue
plarsen has quit [Quit: NullPointerException!]
<jlebon> can you upload the coredump somewhere?
<sgallagh> Sure, I'll throw it on my fpeople space. Give me a minute...
<jlebon> thanks!
<dustymabe> lucab++
<dustymabe> jlebon++
<sgallagh> jlebon++
<zodbot> sgallagh: Karma for jlebon changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any
<sgallagh> lucab++
<zodbot> sgallagh: Karma for lucab changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any
<jlebon> sgallagh: can you give the ostree commit on which that coredump was generated?
<sgallagh> jlebon: How do I get that information?
<sgallagh> BaseCommit: 6bf98c134e27c6fd21f78c700d6caea052f78789f240ef2f80de25bb09f0cab3
<sgallagh> Is that it?
<jlebon> yup, that's it!
<jlebon> thanks
heldwin has quit [Ping timeout: 240 seconds]
mnguyen has joined #fedora-coreos
mnguyen_ has quit [Ping timeout: 272 seconds]
heldwin has joined #fedora-coreos
gursewak has joined #fedora-coreos
Guest36 has joined #fedora-coreos
saqali_ has joined #fedora-coreos
saqali has quit [Ping timeout: 240 seconds]
guesswhat has joined #fedora-coreos
saqali__ has joined #fedora-coreos
<walters> Stephen Gallagher: thanks for bringing this up, reliabilty of OS updates is important to me so I want to be sure we've root caused and fixed this. I'm not sure that the warning is actually related, but maybe
<dustymabe> walters++
<zodbot> dustymabe: Karma for walters changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any
saqali_ has quit [Ping timeout: 240 seconds]
<sgallagh> Colin Walters: I have suspicions that the issue is related to some RPM repositories being behind the firewall.
<sgallagh> Since the retry looping seems to happen most often when I boot up and don't log onto the VPN right away.
<sgallagh> (The repo providing my VPN configutation being one of them)
<sgallagh> s/configutation/configuration/
ravanelli has quit [Remote host closed the connection]
bgilbert has joined #fedora-coreos
<jlebon> sgallagh: at least re. the crash, the repo involved seems to be google-chrome
cyberpear has quit [Quit: Connection closed for inactivity]
saqali_ has joined #fedora-coreos
<jlebon> is it reproducible btw? (the crash, not the gvariant printing)
saqali__ has quit [Ping timeout: 248 seconds]
Betal has joined #fedora-coreos
<jlebon> have to context switch, but filed https://github.com/rpm-software-management/libdnf/issues/1544
saqali_ has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
<sgallagh> Interesting
<sgallagh> I have dozens of coredumpctl entries for rpm-ostree
ravanelli has joined #fedora-coreos
<sgallagh> Looking through them, they all seem to be happening at the same location in libdnf
<sgallagh> So I'd say "yes, it's repeatable"
<sgallagh> Thanks
<jlebon> ack, thanks for checking!
nb has quit [Quit: The Lounge - https://thelounge.chat]
nb has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
Guest36 has quit [Ping timeout: 252 seconds]
cyberpear has joined #fedora-coreos
jpn has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
<dustymabe> jlebon: in an effort to make a few optimizations to the `build` job before we start to convert the build-arch job to be more like it I created https://github.com/coreos/fedora-coreos-pipeline/pull/545 that parallelizes more steps.
<dustymabe> currently untested, i'm debating whether setting up a dev pipeline for testing it would be worth it vs just YOLO and submitting fixups.
jpn has quit [Ping timeout: 256 seconds]
<jlebon> dustymabe: ack, will review before eod
<dustymabe> take your time. I'm now going through and setting up an "ideal" build-arch.Jenkinsfile and will work backwards from that to implement the `cosa remote-session create` UI
<jlebon> +1 nice
saqali has joined #fedora-coreos
gursewak_ has joined #fedora-coreos
gursewak has quit [Remote host closed the connection]
gursewak_ has quit [Ping timeout: 256 seconds]
crobinso has quit [Ping timeout: 240 seconds]
bgilbert has quit [Quit: Leaving]
bgilbert has joined #fedora-coreos
<bgilbert> any opinions on https://github.com/coreos/coreos-installer/pull/888? would be good to apply it to the upcoming release if there's consensus (cc jlebon)
<jlebon> stamped
<bgilbert> +1
guesswhat has quit [Quit: Client closed]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 248 seconds]
nalind has quit [Quit: bye]
<dustymabe> jlebon: still around? got one more for you
<dustymabe> this should help us (cc gursewak) do debug runs without pushing results to s3
<jlebon> dustymabe: hmm, not sure. i think an OFFLINE parameter instead would be cleaner
<jlebon> this change is slightly increasing complexity in a non-obvious way
<dustymabe> and/or DONTARCHIVE?
<dustymabe> or UPLOAD_RESULTS = False ?
<jlebon> an OFFLINE parameter which skips over anything which pushes data outside jenkins
<dustymabe> right.. i'm just thinking OFFLINE is overloaded (i.e. you could be thinking kola tests with no net)
<dustymabe> we could also have KOLA_RUN_SLEEP imply UPLOAD_RESULTS=False
<jlebon> ahhh gotcha
<jlebon> NO_UPLOAD?
<dustymabe> WFM
<jlebon> +1
gursewak has joined #fedora-coreos
<dustymabe> i'll update it tomorrow
<dustymabe> have a good night all
<jlebon> good evening!
saqali has quit [Quit: Leaving]
dwalsh has quit [Ping timeout: 260 seconds]
jpn has joined #fedora-coreos
heldwin has quit [Quit: Teleporting ...]
jpn has quit [Ping timeout: 244 seconds]
mheon has quit [Ping timeout: 272 seconds]