アダプターの交換は完了しましたが、can0 はもう存在しませんか? OpenArm 構成を変更する前に、インターフェイス マッピングと udev の名前を確認してください。
USB CAN アダプタを変更した後に、非常に一般的な OpenArm ホスト側エラーが表示されます。古いセットアップ コマンドは依然として can0 を参照していますが、新しいアダプタはバインド方法が異なるか、予期したインターフェイスをまったく作成しません。
USB CAN アダプターの交換後にシステムが can0 で「そのようなデバイスはありません」と報告する OpenArm ケースをどのように診断していますか?
アダプターの検出、インターフェイスの作成、および命名仮定を検証する方法と、ホスト構成の間違いと実際の CAN ハードウェア障害を区別するのに役立つチェックを共有してください。
返信する場合は、正確なエラー症状を 1 つと、原因を明らかにしたインターフェイスまたはアダプターの正確なチェックを 1 つ含めてください。
初心者向けのコンテキスト: アダプターを交換した後、毎回「candump can0: No such device」が表示されましたが、「lsusb」では依然としてドングルが表示されました。 したがって、ハードウェアが表示されましたが、予想されるインターフェイス名にバインドされていませんでした。
初心者向けのコンテキスト: 決定的なチェックは `dmesg | rg -i can` に加えて ip -details link` を追加します。 最初に別の仮想 CAN が作成されたため、新しいアダプターは can1 として作成されました。 古いスクリプトは can0 をハードコードしていたため、起動に失敗しました。
初心者向けのコンテキスト: アダプターのシリアルに固定された udev ルールで問題を修正し、ルール名でインターフェイスを解決するようにスタートアップを更新しました。 それ以来、スワップは起動スクリプトを書き直すことなくプラグアンドプレイで実行できるようになりました。
初心者向けのコンテキストフォローアップ: 初心者向けのフォローアップの質問: アダプタの交換後、起動前に物理アダプタのシリアルをインターフェイス名にマッピングするために最初に実行するコマンドはどれですか?
最も近い症状を選択して、適切なトラブルシューティング パスに従ってください。
ほとんどの場合、ハードウェア障害ではなく、インターフェイスの名前変更またはバインディングの違いが原因です。
lsusb
dmesg | rg -i "can|usb"
ip -details link | rg -n "can"udev でアダプター ID を固定し、起動スクリプト内の安定した名前でインターフェースを解決します。
まずはチェックリストのテンプレートとして使用してください。 実行前に自分のセルでインターフェイス名、フィクスチャ ID、安全条件を確認してください。