resolve handling of RootFsInfo() error on kubelet start

[liggitt]

follow-up from #19137

b61c00c made the RootFsInfo() lookup failure on kubelet startup non-fatal because it was blocking CI (it fails when run on tmpfs/bindmounts I think)

need to determine the impact of continuing the kubelet even without the EphemeralStorageCapacityFromFsInfo results

[sjenning]

kubernetes/kubernetes#65595

[sjenning]

@liggitt since b61c00c is already in 3.11 and the upstream PR kubernetes/kubernetes#65595 does roughly the same thing do we want to

1. revert the drop comment and pick the upstream one for 3.11 or
2. stay for 3.11 and get the upstream fix in the 3.12 rebase

[liggitt]

if we don't plan to enable the feature in 3.11, it's largely moot. if we do, then we should revert/pick that PR, right?

[sjenning]

agreed. I'll keep this in mind if we decide to go forward with LSI in 3.11 (which would be a stretch, I think)

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-merge-robot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale