Update kernel version reported by uname -r

[thundergolfer]

Description

Currently gVisor reports the kernel version as 4.4.0 and this version hasn't been updated in 5+ years: ebe8001

I'm wondering about a couple things:

1. Could this version number be bumped higher?
2. Is it possible to comment on this value why the version is set at this version and what the policy is around updating it?

Is this feature related to a specific bug?

No specific bug, but a user thought we were running a very old (2016) Linux kernel and that prompted me to look into this 🙂.

Do you have a specific solution in mind?

No response

[ayushr2]

The last bump (3.11.10 -> 4.4.0) happened 6 years back: 5a0be6f.

I don't think we have any explicit policy around it yet. I agree we should probably bump it to some 6.x version now.

[thundergolfer]

Thanks, sounds good to me!

[EtiennePerot]

Bumping this version isn't just a matter of increasing the version counter; as per the last time this was done (5a0be6f), this requires also adding stub handlers for the system call numbers that were added since 4.4. This is so that error messages are more descriptive, the auto-generated syscall table remains up-to-date with the syscalls that match the kernel version number gVisor reports, and so that the telemetry for unimplemented syscalls (the counter metric that tracks the calls to unimplemented syscalls) works for those system calls. Patches welcome :)

[Ammar-Alnagar]

i am having an issue where my training script hangs due to this bug ,
WARNING:accelerate.utils.other:Detected kernel version 4.4.0, which is below the recommended minimum of 5.5.0; this can cause the process to hang. It is recommended to upgrade the kernel to the minimum version or higher

is there a way to upgrade the kernel for myself ? or a way to bypass it ?

[EtiennePerot]

@Ammar-Alnagar, it is unlikely that the application is hanging specifically because of the reported kernel version.

My guess from reading this message is that it's warning the user about some specific Linux bug that got fixed in version 5.5.0. But gVisor isn't Linux. Changing gVisor's reported version to 5.5.0 will not change the behavior of the gVisor kernel. So I suggest filing a separate bug with more details about what application you are running and gVisor logs in order to investigate why the script is hanging.

[Ammar-Alnagar]

@EtiennePerot Oh ok , thanks for the response

[Ammar-Alnagar]

@EtiennePerot , I just checked and my issue is directly related to the gVisor Kernel version , as it detects the gVisor kernel and just hangs there.
I dont really know why but that what the "accelerate" library team said when i emailed them.
is there perhaps a workaround for me ?

[EtiennePerot]

This warning appears to be coming from a Python library:
https://github.com/huggingface/accelerate/blob/f0b030554cbcd01c5541c449e92066715f21a99e/src/accelerate/utils/other.py#L320-L335

So you could always just monkeypatch it out.

import accelerate.utils
accelerate.utils.check_os_kernel = lambda: None

If the program still hangs, then you can now be certain that the problem isn't a matter of checking the kernel version, and therefore this is not the same bug as this one.

[Ammar-Alnagar]

I will be sure to try it , Thanks alot for the help