[PATCH 1/1][autotest-client-tests] UBUNTU: SAUCE: ubuntu_dgx_mofed_build: create build sanity test for MOFED DKMS on DGX

[Po-Hsu Lin]

On Mon, Oct 25, 2021 at 9:40 PM dann frazier <dann.frazier at canonical.com> wrote:
>
> On Fri, Oct 22, 2021 at 04:00:00PM +0200, Taihsiang Ho (tai271828) wrote:
> > Hi Sam,
> >
> > Thanks for the verification and comments. Regarding your questions:
> >
> > 1. Any specific reason for using different shebang /bin/sh and /usr/bin/env?
> > The reason is to keep the check-mofed-modules.sh "as-is" as much as
> > possible because it has been manually used for a while. It is stable and
> > reliable.
> >
> > The script check-mofed-modules.sh was developed earlier and we have
> > manually used it for a while (several SRU cycles). When I integrated
> > check-mofed-modules.sh into autotest-client-tests, I prefer to keep it
> > "as-is" to make our automation work more stably. I chose the more portable
> > shebang "/usr/bin/env" for the test job wrapper
> > "ubuntu_dgx_mofed_build.sh", so it will be more compatible across
> > distribution.
> >
> > 2. Is the missing knem.ko expected?
> > Yes, it is expected. It's a known issue. knem.ko is expected to be present
> > if you deploy the system with "exotic-skunk". It's not present because
> > knem.ko dkms failed to build during the ephemeral maas environment. The
> > issue looks very likely raised for knem package's own buggy build script
> > to use the right headers to build itself. We have escalated the issue to
> > its upstream and we are still fixing the issue and the build script. You
> > may verify the issue by checking maas deployment log (by searching for
> > "knem") and re-install/re-build knem manually (via apt install) when the
> > system is deployed and gets ready to use.
>
> I've added a workaround for this in our preseed, so this test should
> now pass on our systems.

Cool!
Thanks for the update, Dann.

Sam

>
>   -dann