In reply to@_slack_taloscommunity_U01Q4R344CU:matrix.org
Yea...I wish I had looked at those devices on older instances to see what permissions it had. Could a kernel version bump have changed what permissions are set on it?

In reply to@_slack_taloscommunity_U01Q4R344CU:matrix.org
I should be able to just boot on B slot (assuming I'm currently on A) to go back to 0.11.0 (where I was at before upgrading), right?

In reply to@_slack_taloscommunity_UGL0YU56H:matrix.org
yes, it should work

In reply to@_slack_taloscommunity_U01Q4R344CU:matrix.org
👍🏻 thanks...I try that in a bit to see what I can figure out.

In reply to@_slack_taloscommunity_U01KV18KND9:matrix.org
Maybe just Ready: false?

In reply to@_slack_taloscommunity_U017CK35MFA:matrix.org
yeah, error means Ready: false right now

In reply toundefined

In reply toundefined

In reply to@_slack_taloscommunity_U017CK35MFA:matrix.org
you can see the other flags if you expand the server item. Theila can help you if server is not accepted. You can accept the server in the context menu under ... button. And if that's not the case, then any deeper investigation may require using kubectl and looking at sidero container's logs

In reply to@_slack_taloscommunity_U01KV18KND9:matrix.org
ah i think i need to look at the logs...

In reply to@_slack_taloscommunity_U01KV18KND9:matrix.org
not much useful stuff in the kubectl describe server output

In reply to@_slack_taloscommunity_U017CK35MFA:matrix.org
Makes me feel that we need to add a way to view pods logs in Theila next.

In reply to@_slack_taloscommunity_U01KV18KND9:matrix.org
that would be cool. im mostly CLI guy, but its nice to have a ui to run to in a pinch

In reply to@_slack_taloscommunity_U01KV18KND9:matrix.org
also being able to view a pie chart or something if available hw based on serverclass would be nice

In reply to@_slack_taloscommunity_U01KV18KND9:matrix.org
we have a bunch of different types of hw

In reply to@_slack_taloscommunity_UEGUHLTR9:matrix.org
what makes a server "ready"?

In reply to@_slack_taloscommunity_UEGUHLTR9:matrix.org
clean and accepted

In reply to@_slack_taloscommunity_U01Q4R344CU:matrix.org
same thing on 0.11.0. i’ll have to keep digging. just wish i could remember the last time i had checked for hardware transcoding. for most of the stuff we watch it isn’t an issue to do software transcoding on the cpu. but the 4k stuff needs it to prevent buffering and nearly maxing out the cpu

In reply to@_slack_taloscommunity_U01Q4R344CU:matrix.org
FYI andrey i’ve put up a feature request issue for this. I’ve got a workaround I can use for now until we we can get something more proper figured out. https://github.com/talos-systems/talos/issues/4001

---
apiVersion: batch/v1
kind: Job
metadata:
  name: udev-rules
  namespace: default
spec:
  template:
    spec:
      restartPolicy: Never
      volumes:
        - name: rulesd
          hostPath:
            path: /usr/etc/udev/rules.d
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                  - talos-192-168-32-4
      containers:
        - name: write-udev-rules
          image: alpine:3.14.0
          resources:
            requests:
              memory: 30Mi
              cpu: 20m
            limits:
              memory: 30Mi
              cpu: 20m
          volumeMounts:
            - mountPath: /usr/etc/udev/rules.d
              name: rulesd
          command:
            - sh
            - -c
            - ,-
              set -eux
              echo 'SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="44", MODE="0660"' > /usr/etc/udev/rules.d/99-intel-gpu.rules
              echo 'SUBSYSTEM=="drm", KERNEL=="card*", GROUP="44", MODE="0660"' >> /usr/etc/udev/rules.d/99-intel-gpu.rules
  backoffLimit: 0

In reply toundefined

In reply toundefined

files:
    - path: /var/../usr/etc/udev/rules.d/99-intel-gpu.rules
        permissions: 0o644
        op: create
        content: ,-
        SUBSYSTEM=="drm", KERNEL=="card*", GROUP="44", MODE="0660"
        SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="44", MODE="0660"

In reply toundefined

In reply to@_slack_taloscommunity_U01Q4R344CU:matrix.org
after finding the relevant code, i realized I can actually still use the files machine config by making the path relative to /var. obviously quite hacky and potential for breakage in the future. The downside here is that the file gets written after udev has already started its thing. So for already present devices (like the intel gpu), it won’t get picked up until you reboot again after having the boot process write the file. ~Although maybe restarting the udev service would allow it to pick it up without having to reboot. I’ll try that next time…for now it’s late and I need to sleep.~ Nope: looks like udevd doesn’t support restart via API

files:
    - path: /var/../usr/etc/udev/rules.d/99-intel-gpu.rules
        permissions: 0o644
        op: create
        content: ,-
        SUBSYSTEM=="drm", KERNEL=="card*", GROUP="44", MODE="0660"
        SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="44", MODE="0660"

In reply to@_slack_taloscommunity_UGL0YU56H:matrix.org
That was a cool hack btw, yes, I feel we should expose udev rules as the first class citizens in the machine configuration. Thanks for digging into that!