<guesswhat[m]>
Hey, question, is there any doc how to setup butane for systemd service with User= directive instead of user systemd service? The problem is, its not possible to create dependency between system and user systemd services
bgilbert has joined #fedora-coreos
ravanelli has joined #fedora-coreos
<dustymabe>
guesswhat[m]: just add it to the unit file?
<guesswhat[m]>
it still require lingering
<dustymabe>
it shouldn't IIUC - it runs from the system context, just as the user you specify
<dustymabe>
ravanelli: yes - let's schedule something - at this point I'd say let's try for maybe tomorrow morning and then target the test day for next Monday or Tuesday
<dustymabe>
jlebon: bgilbert: what does bootupctl do if someone rolls back their system? i.e. will our new service roll back the bootloader update too? Is that what we want?
<guesswhat[m]>
dustymabe: thanks, seems its still somehow buggy
<jlebon>
dustymabe: as long as the service only exists in the barrier release, it'll only ever try to update from that deployment
<ravanelli>
dustymabe: 👍 sgtm
<dustymabe>
jlebon: good point - we have to be diligent about removing it then
<dustymabe>
ravanelli: can you update the tickets with the new target date? and work with SumantroMukherje to get it confirmed
<ravanelli>
sure
<b100s>
guesswhat[m], yeah, seems like DNS issue. But strange. Actually node is healthy and serving prod traffic. Seems it is old toolbox issue. I found easier way to check cpu power settings using cat /sys/.. : )
<b100s>
guesswhat[m], nope; check 17th March, around 11:00 UTC : )
<dustymabe>
jlebon: bgilbert: i'm going to do another round of testing on aarch64 RPi4 and then work on getting my upgrade test cleaned up a bit for review (and then a corresponding fcos-pipeline job for running the test)
<dustymabe>
oh actually - something interesting I found
<guesswhat[m]>
b100s: oh, i see :)
<dustymabe>
when I run the upgrade test on x86_64 it doesn't make it all the way to success. I think we've had this problem before and never noticed it
<dustymabe>
i.e. the f31 bootloader won't boot an f37 payload
* dustymabe
wonders when the blscfg stuff made it into the bootloader and also Fedora
<jlebon>
dustymabe: huh, that's interesting. what's the error?
<dustymabe>
honestly I can't really tell. The system just doesn't boot and the logs/console are kind of opaque.
<dustymabe>
I don't have a real console on the machine because I'm running it through kola, but may try at some point to figure it out
<jlebon>
ahh ok. i guess we'll have to hack around that in the new upgrade test on x86_64?
<dustymabe>
indeed. won't be hard
<dustymabe>
just need to understand the real problem first
<bgilbert>
we should figure this out. my impression was that we have a direct-boot mechanism that doesn't go through UEFI
<bgilbert>
the unit is written to only run on UEFI systems. if we still need a bootloader update on those, then the unit is buggy and we'll need to fix it
<dustymabe>
yeah I understand, the problem is we don't have documented how to even install that way
<dustymabe>
I misremembered the other day that via Uboot didn't include UEFI
<dustymabe>
sorry - EFI
<bgilbert>
ahh
<dustymabe>
so here is what I did the other day
<dustymabe>
I had a system already installed that was installed using the EDK2 install method
<dustymabe>
I confirmed it observed the problem
<dustymabe>
and also that doing a rollback+bootloader update + reboot backinto f38 worked
<dustymabe>
then I used a separate SD card to do the uboot install steps
<dustymabe>
and verified that starting from f35 (after getting around my coreos-installer sig issue) hit the same problem and was fixed by a bootctl update
<dustymabe>
so at that point I was sufficiently satisfied that both install methods we have documented use the EFI binaries and wiould be fixed by this update
<bgilbert>
okay, so you haven't actually tested the unit there. would you mind pasting the unit into the uboot system and confirming that systemd starts it?
<bgilbert>
want to make sure the ConditionFirmware does what we think
<dustymabe>
yeah I can try that
<dustymabe>
I know at least bootctl status reports EFI