<travier[m]>
I won't be able to discuss my ticket about the Kubernetes Community Days in the meeting today but it's more of a FYI than something really needing discussion.
<dustymabe>
travier[m] + 1
mnguyen_ has joined #fedora-coreos
mnguyen__ has quit [Ping timeout: 268 seconds]
azukku has quit [Quit: Leaving.]
c4rt0 has quit [Remote host closed the connection]
c4rt0 has joined #fedora-coreos
saschagrunert has quit [Remote host closed the connection]
c4rt0 has quit [Ping timeout: 268 seconds]
<dustymabe>
gursewak: any updates on the kdump failure in rawhide?
<gursewak>
dustymabe, I couldn't find much so far. The logs aren't really telling why we don't see the kcore file in /var/crash
<dustymabe>
what happens if you try to manually reproduce the problem outside of the test?
<dustymabe>
What do you see on the serial console of the machine?
marmijo has joined #fedora-coreos
<gursewak>
I don't really see the kdump-capture.service starting before the machine shut sdown
<dustymabe>
do you see any kernel panics?
<gursewak>
I see "Kernel panic - not syncing: sysrq triggered crash"
<dustymabe>
yeah, that's the one we triggered
<dustymabe>
ok, maybe we can put off debugging the actual failure until later
<dustymabe>
can you find the offending package and pin it for now?
<gursewak>
yep, I don't really see any other panic.
<dustymabe>
i.e. one of the new packages in rawhide is causing the test to fail presumably, so find which one it is and we'll pin on the older version of that package
<dustymabe>
and then rawhide will be unblocked at least and we can figure out what the problem is (we'll need to create a new issue for this specific problem)
<gursewak>
Sure. First guess was kexec-tools but that's not the one.
<gursewak>
+1, will create new issue for this failure
<dustymabe>
you have to look at the new packages (gives you a smaller set of packages to look at)
<dustymabe>
and it also helps to look at the first run that had the failure so the set of potential suspects is smaller
<gursewak>
copy that
<dustymabe>
so - go find the first run that failed that didn't have a new `bash` package in the list of upgraded packages (bash was the first problem) and then we'll sort through that set of packages
cyberpear has quit [Quit: Connection closed for inactivity]
aaradhak has joined #fedora-coreos
mnguyen_ has quit [Remote host closed the connection]
ravanelli has quit [Remote host closed the connection]
c4rt0 has joined #fedora-coreos
cyberpear has joined #fedora-coreos
ravanelli has joined #fedora-coreos
ravanelli has quit [Ping timeout: 260 seconds]
c4rt0 has quit [Ping timeout: 268 seconds]
ravanelli has joined #fedora-coreos
ravanelli has quit [Client Quit]
plarsen has quit [Remote host closed the connection]
plarsen has joined #fedora-coreos
<dustymabe>
jlebon: can you help me understand what the value of cosaDir in coreos-ci-lib
<dustymabe>
for example in the pipeline in most cases I just run `cosa` and assume i'm already in the cosaDir. Why is that not safe in coreos-ci-lib and we must have a variable for it
<jlebon>
dustymabe: the cosa builddir is not always the workdir
<jlebon>
in upstream CI, the workdir is normally where you build the software
<jlebon>
you usually don't have to specify the cosa dir because the default of /srv/fcos (now /srv/coreos) should be fine
wolfshappen has quit [Quit: later]
nalind has quit [Quit: until next time]
marmijo has quit [Quit: Client closed]
mheon has quit [Ping timeout: 252 seconds]
aaradhak has quit [Quit: Connection closed for inactivity]
crobinso has quit [Remote host closed the connection]