We're still waiting to have the shim officially signed, but we want to start
using our signed release process now.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The R535 driver branch, which is LTS, does not compile on arm64 with GCC
14/kernel 6.6. Keep amd64 on R535 and switch arm64 to R570 by default.
R570 is the first driver version that I found that is currently
supported and works for arm64.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
So that we can pick-up kmods contained in sysexts (like zfs) and generate
complete module dependency information. I thought we could skip running depmod
for nvidia drivers because we manually insmod them, but nvidia's GPU operator
driver validation expects to be able to run modprobe - so we have to generate
them.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
The nspawn container runs in it's own scope, which journal output is then
associated with. By passing `--keep-unit` we can guarantee that all log output
will stay associated with the nvidia.service and can be viewed by running
`journalctl -u nvidia.service`.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Installers for 570 sometimes default to Open drivers, which we can't support
properly at this time. Force proprietary drivers. There are also additional
options that suppress certain worrisome error strings - enable those if
supported too.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Users have reported that in some cases the nvidia.service fails because
/opt/nvidia/current is a directory and the symbolic link gets created inside
it. I have no idea how we get there, but to make the service robust in the face
of this kind of issue:
- remove the directory if it exists
- use `-T` with ln to ensure that symbolic link creation fails if `current` is a directory
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
This change moves CONFIG_MICROSOFT_MANA=m from amd64_defconfig-6.6 to
commonconfig-6.6 to support the MANA network driver on ARM64 instances,
too.
Signed-off-by: Thilo Fromm <thilofromm@microsoft.com>
These dependencies are pulled into SDK at some point during the
multi-stage SDK build, but our package automation is not smart enough
to catch this. Help it by listing some packages explicitly.
