<guesswhat[m]>
Any idea what is happening ? (chronyd)[2016]: chronyd.service: Failed to set up mount namespacing: /run/systemd/unit-root/var/lib/chrony: No such file or directory ?
<guesswhat[m]>
(chronyd)[2016]: chronyd.service: Failed at step NAMESPACE spawning /usr/sbin/chronyd: No such file or directory
<guesswhat[m]>
also console-login-helper-messages-gensnippet-os-release.service and onsole-login-helper-messages-gensnippet-ssh-keys.service are failing
<guesswhat[m]>
nvm, its probably related to create-swapfile.service: Job tmp.mount/start deleted to break ordering cycle starting with create-swapfile.service/start
<dustymabe>
jlebon: thoughts on the best way to remove the qcom dtb ?
<dustymabe>
postprocess?
<jlebon>
dustymabe: or ideally remove-from-packages
<jlebon>
i don't know if it's a pure deletion we need or if we need to also update some map/database file with a command. we can ask pbrobinson probably :)
<dustymabe>
jlebon: pop over into #fedora-iot
<dustymabe>
I had been chatting with him over there
<jlebon>
ahh missed that
<baude>
dustymabe, could you spare a minute or two and take some pity on me? I need some systemd help again
<baude>
i have been using systmed-analize to try and get the order of a service i want to start automatically. the service appears to be running, but i dont see it in -analize ... making this debug much more difficult
<dustymabe>
baude: it's running but you don't know when it started? doesn't the journal print a message for that?
<baude>
i dunno, i would have thought systemd-analize would
<dustymabe>
what command are you running?
<baude>
i tried critical-chain
<jlebon>
bgilbert: it turns out i had disabled systemd-oomd on my workstation too at some point :)
<baude>
dustymabe, what shoul di use
<jlebon>
bgilbert: was expecting to see systemd-oomd have some kind of config where it just acts as a handler for oom events from the kernel, kinda like coredumps, but that doesn't seem to be a thing
<bgilbert>
jlebon: I imagine that would be hard to make deadlock-free
<jlebon>
i guess so? not sure if the oom-killer is invoked in an immediate "need to allocate memory now" or if there's a margin of safety
<bgilbert>
there's a reentrancy problem
<bgilbert>
even if oomd were wired entirely into RAM, any incidental kernel-side memory allocations for syscalls would still use GFP_KERNEL and could put oomd to sleep
<dustymabe>
baude: to see the deps you can do something like: `systemctl list-dependencies NetworkManager`
<dustymabe>
and `systemctl list-dependencies --reverse NetworkManager`
<dustymabe>
there's --reverse --after --before
<bgilbert>
i.e. userspace processes don't have the allocation knobs to disable reentrancy that kernel code does, so I'd expect oomd has to be significantly more conservative
<jlebon>
right, gotcha. anyway, agreed we probably don't want to e.g. manage knobs in various systemd units related to systemd-oomd, but possibly we could tweak the base oomd.conf file to satisfy us
* jlebon
goes for food
smitterl has quit [Remote host closed the connection]
<baude>
dustymabe, what would i need in a systemd file that would get it to fire AFTER NM
<dustymabe>
`After=NetworkManager.service` ?
<baude>
Wants=NM.service ?
<baude>
and anything in the install section ?
<dustymabe>
though note that NM is a daemon, so just because the daemon is up doesn't mean networking is fully configured yet
<baude>
nod, umderstood
<dustymabe>
baude: for the install section you'd just want to make sure your unit gets pulled in (i.e. it gets enabled)
<baude>
what doies that mean ? [Install] with nothing else?
<dustymabe>
add WantedBy=multi-user.target to just have it be enabled by default on a system
<dustymabe>
under [Install]
<dustymabe>
for your ordering from earlier - maybe `After=network-online.target` would be what you want?
<dustymabe>
depends on your requirements
<baude>
shit
<baude>
still not correct
<baude>
dustymabe, if i do systemctl list-dependencies --before NetworkManager and my service is in there, that means it runs before NM correct ?
<dustymabe>
baude: `man systemctl` and read the `--before` entry
<dustymabe>
--before With list-dependencies, show the units that are ordered after the specified unit.
<dustymabe>
I admit, in my mind it would be the opposite.
<baude>
got it, well, the evidence i am seeing is it ran before
Betal has quit [Ping timeout: 255 seconds]
<dustymabe>
jlebon: help me figure out what's wrong with this remove-from-packages entry: [kernel-core, /usr/lib/modules/.*aarch64/dtb/qcom/.*]
<baude>
dustymabe, tyvm, you got me over the hurdle finally
Betal has joined #fedora-coreos
<jlebon>
dustymabe: let me boot a system again
<jlebon>
dustymabe: try dropping the `/usr`
<jlebon>
looks like the hardcoded paths in the rpm header is /lib/modules/... and i'm not sure if remove-from-files knows they're the same or just works directly off of what librpm has
jpn has quit [Ping timeout: 255 seconds]
baude has quit [Quit: Leaving]
<dustymabe>
jlebon: I think I started without the `/usr/` and it still wasn't working
<jlebon>
dustymabe: ack ok, weird. let's use a postprocess then. i'm intrigued so might take a look at some point at why that doesn't work
baude has joined #fedora-coreos
baude has quit [Quit: Leaving]
<jlebon>
ravanelli: feel free to ping me here if you need reviews for the GCP udev rules thing (just reviewed the f-c-c one)
<ravanelli>
jlebon: Checking
jpn has joined #fedora-coreos
baude has joined #fedora-coreos
jpn has quit [Ping timeout: 265 seconds]
ravanelli has quit [Remote host closed the connection]
<baude>
if i have a dev version of ignition, and i mount that into the cosa container like COREOS_ASSEMBLER_GIT=/home/baude/go/src/github.com/coreos/coreos-assembler/ cosa shell
jpn has joined #fedora-coreos
<baude>
and i use the correct cmd-buildextend-hyperv command from my dev mount but the ignition binary in the initrd is not correct, but is correct in the overlay ... any ideas where to poke around ?
misuto has quit [Remote host closed the connection]
misuto has joined #fedora-coreos
sentenza has joined #fedora-coreos
<dustymabe>
baude: you need to put the ignition binary in the overrides/rootfs/ folder