こんにちは。
FirepowerのバグのWorkaroundについて、どなたか、ご存じの方がいたら教えていただけますでしょうか。
Firepower 2100シリーズを使用しています。
Firepowerはアプライアンスモードで動作させASAと同じように使用しており、OSには9.16(4.19)を使っています。
9.16(4.42)で解消されたバグを踏んでしまったためVer.Upを検討し、まずは検証用Firepowerを9.16(4.55)にVer.Upしてみたところ、Ver.Up自体は成功したのですが、別のバグを踏んでしまったようです。
（2024/4/1に9.16(4.57)がリリースされています）
■事象
・Ver.Up時の再起動～作業終了後3時間経過まで
1分間隔で
「ASA-3-199015: sensord: Error updating RRD file: /var/lib/sensord.rrd～
（途中省略）
: illegal attempt update using time [2023/10/2 15:57(Unixのシリアル時刻表示)]
when last update time is [再起動した日時(Unixのシリアル時刻表示)]」
という長いメッセージが出力され続けました。
（メッセージは1回あたり約3.4KB分あるので、ACLにヒットした通信ログの確認のかなりの妨げ）
・作業終了3時間経過以降～
1分間隔でsyslog ID情報（ASA-3-199015）が出力（メッセージ本文は無し）
■原因
バグ情報：CSCwi83983(ENH: ASA-3-199015 syslog may get triggered on FP2100 with ASA in platform mode after upgrade)を踏んでしまったようです。（プラットフォームモードとの記載ですが・・・）
再起動時にFirepowerのシステムクロックが（NTPサーバがあっても）2023/10/2に戻るため、見かけ上、「未来の日時でupadate済みなので、現在の時刻（2023/10/2）でupdateできない」ということだと思います。
再起動が完了し正しい時刻になっても、updateを再試行しないため、エラーログが出続けると考えられます。
無害なバグという記載もありますが、できればエラーログの出力を止めたいと考えています。
■対処方法
Web上の他の情報も参考にすると、Workaroundとして
（通常のシェルから）expertモードに遷移
→Linuxのファイルシステムとしてアクセスできるようになるので、updateが失敗した問題のRRDファイルを削除
という特殊な方法で対応可能なようです。
しかし、expertモードへの遷移はCisco社の担当者から明確な指示があるときなど、かなり限られた条件下のものだと思います。
syslog ID = 199015を指定してロギング対象から外すこともできますが、このsyslog IDは他のEventにも対応しているため、単に外すという手段は避けたいです。
ほかに手段はあるでしょうか？
・事象が発生したFirepowerの再起動による復旧
（うまくいく可能性は低そうですが…。検証機とは言え、気軽に再起動できない環境のため、ある程度確証をもってテストしたい）
・Ver.Up時の再起動前に、NTPサーバへの接続を解除して、システムクロックを2023/10/2以前に手動設定する
（問題が発生済みのFirepowerでの対応はあきらめて、今後、Ver.UpするFirepowerで事象発生を予防できれば良しとする考え方）
ご存じ方がいたしたら、お知らせいただければと思います。
