この問題は2021年10月28日現在の情報です。該当のIssueはUbuntu 5.4.0-81 stops bnx2x loading hardware、BCM57800 SRIOV bug causes interfaces to disappear、Kernel 5.11.22-3 Breaks Dell Broadcom 1/10 Gigabit Quad Cardsです。近日中に解決される見通しです。
2021年10月29日追記
MAAS利用時においては、すでにMAASに登録済みのサーバーについてはデプロイ可能のようです。MAASに登録する際に処理であるEnlistやコミッショニングではNICを正常に認識できずに処理できないことを手元の環境で確認しています。 ISOブートの場合は、Ubuntu Kernel 5.4.0-80以前で起動すればNICは正常に動作する（およびUbuntu Kernel 5.4.0-89ではNICが正常に動作しない）ことを手元の環境で確認しています。いずれも現在focal-proposedで提供されているUbuntu Kernel 5.4.0-90が正式にリリースされれば解決すると思われます。本記事は少々修正をいれています。
修正内容はこちらです。
普段、技術検証をする時はMAASを使ってOSをセットアップしています。数年そんな感じで便利に運用していた訳ですが、最近UbuntuのデプロイEnlist,コミッショニング、ISOメディアを使ったインストールに100%失敗するようになりました。しかし、同じMAASで使っているBL460c Gen8という古いサーバーや、Supermicroのサーバー、タワー型のGen9世代のサーバーや仮想マシンへのデプロイした場合は問題なく動くようです。
というわけで､非常に面倒なのですが調査することにしました。
特別なハードウェア（NICやGPU、SmartNIC）などを使わないで良い検証をする時は普段、BL460c Gen9ブレードサーバーを使っています（ほぼ私が独占利用）。何台かあるブレードで試して同じ症状だったので、Gen9も古いサーバーですしサーバーの経年劣化かなと思ったのですが、検索したら気になるIssueを見つけました。
まずはこれです。Ubuntu Kernel 5.4.0-81以降のバージョンでbnx2xドライバーを使うNICが読み込まれないという問題です。該当のドライバーを使うNICは認識すらしなくなると言う問題です。致命的すぎます。
以下は（MAASで）Enlist、コミッショニング、デプロイを試したときの状況です。NICを認識できずにBusyboxシェルが動いた状況になります。
ではUbuntu 20.04ではなくUbuntu 18.04を使おうかと思った訳ですが、Ubuntu 18.04を利用しても同様の問題が発生します。Ubuntu 18.04の標準カーネルは4.15なのですが、これもバックポートの影響なのでしょうか。
Enlist、コミッショニングについては現在のMAASの都合上、Ubuntu 18.04かUbuntu 20.04が必要になります。しかもこの処理にカスタムイメージは使えないので、オフィシャルの対応がされるまで該当のNICを実装したサーバーは使えない可能性があります（NICを追加、変更しない限り）。
そして最近（と言うか昨日）、その報告のコメントに次のリンクが投稿されました。
BCM57800 based 1/10 Gigabit Integrated NetworkでSR-IOVが有効だと一部のインターフェイスが認識されなくなるという問題です。Ubuntu Kernel 5.4.0-80では問題ありませんが、5.4.0-88だとNICのインターフェイスが一部迷子になるという報告です。問題はすでに修正され、そのうち5.4.0-90がリリースされると思います（ただし現時点の最新版は5.4.0-89であり、報告の問題は最新版でも再現します）。
ではSR-IOVを無効にすれば良いのではないかと思うのですが、ハードウェア側でSR-IOVを無効にしても、設定しているインターフェイスがKernelに認識されないため問題が発生しました。該当の環境はMAASでデプロイしているため、グローバルパラメータで「intel_iommu=off」を設定してみたのですが、この設定でも回避できませんでした。
今回採り上げた問題はLinux Kernel 5.4だけに起こる問題では無く、Linux Kernel 5.11にも存在するようです（というよりは、Linux Kernel 5.11にあった問題を他の機能の実装のためにUbuntu Kernel 5.4にバックポートした影響なのかもしれません）。
さらにUbuntuの場合、機能をそれぞれのUbuntu Kernelにバックポートしているため、5.8、5.11、5.13等でも同じ問題が発生する可能性があり、アップデートが提供される見通しになりました（ただし、該当のアップデートは2021年10月29日10時時点ではリリースされていません）。
問題に該当しない環境について
仮想マシンで動かす場合やコンテナーでUbuntuを動かす場合は、特にこの問題が該当することはありませんのでご安心ください。この問題はベアメタルでUbuntuを動かす場合に起きる問題です。
とりあえず今対応できる方法
（問題に該当しない）他のNICを増設する方法ももちろんあるのですが、ISOブートの場合はオフラインインストールすれば回避できそうです。該当の問題はUbuntuの場合Ubuntu Kernel 5.4.0-81から5.4.0-89で問題が再現するため、使うインストーラにも注意する必要があります（同時期にリリースされたHWEカーネルも問題が再現する可能性があります）。
Ubuntu 20.04.2 ISOイメージでインストールした場合
- 5.4.0-65
Ubuntu 20.04.3 ISOイメージでインストールした場合(問題に該当する場合がある)
- 5.4.0-81
しかも新しいインストーラーは基本、インストールプロセスの中でアップデート処理が行われます。そのため、この問題を回避するには「オフラインインストール」をする必要があります（完全にオフラインにするとリモートアクセスできませんので、ゲートウェイアドレスやDNS IPアドレス、社内プロキシーを設定しないなどの方法で回避するなど）。
他にリモートアクセスする手段（iDracとかiLoみたいなもの）があれば、インストール中にメインのインターフェイスを無効化すれば簡単に対応できます。
また回避したのにセットアップ後の習慣で「sudo apt upgrade && sudo reboot」とかやると、再起動後にがっかりすることになります。一時的にカーネルパッケージの更新をブロックできるように設定すべきでしょう（当然、問題が修正されたカーネルが更新されたら除外設定を取り除くのをお忘れ無く）。
sudo apt-mark hold linux-generic linux-image-generic linux-headers-generic
MAASで管理されているサーバーの場合
問題はMAASで現在ベアメタルプロビジョニングしている場合です。
MAASはEnlist、Commition、Deployと言う処理でイメージを使います。このうちDeployのプロセスではMAASが対応しているイメージ（カスタムイメージも含む）を利用できますが、EnlistとCommitionではUbuntu 18.04か20.04のオフィシャルのイメージを利用するしか手段がありません。該当の問題はUbuntu 18.04とUbuntu 20.04で報告されていますので、現状は新しいサーバーの追加もデプロイもできないことになります。
MAASはイメージをまずメモリに読み込んだ後、そのイメージで起動してストレージに書き込むという処理をします。このイメージはデフォルトの設定だと定期的に新しいイメージをチェックして、自動更新されます。 たとえイメージが最新で無かったとしても、最近のUbuntuインストーラーは脆弱性をできる限りは委譲した状態にするため、インストールプロセスの中で自動更新が行われます。つまり、「たまにMAAS公式のUbuntuイメージはたまに壊れるから自動更新を切っとけ」みたいな運用をしていても普通にセットアップすると再起動後はリモートアクセスできなくなります。
ソフトウェア的には回避する方法はないので、イメージの最新化と修正したカーネルがミラーに反映されるのを待つしかありません（別のNICを実装するという方法はありますが）。
この対応と調査をするために3日かかってしまいました。最終的にはUbuntuのKernelの問題でしたが...そういえば何をするためにUbuntuをベアメタルプロビジョニングしたんでしたっけ？私。
最後に一言
bnx2xは度々問題を起こすNICドライバーだそうです。他のNICを使った方が良さそうです。
