rpm -V 什麼時候不驗證 md5sums？
我有一個舊系統（Fedora Core 6，它是一個用於為舊設備建構的獨立系統）。我正在嘗試建構一個匹配的虛擬機，但我注意到了一個我無法解釋的差異。
兩個系統上都有包 glibc-2.5-3，其中包括文件 /lib/libc-2.5.so。
輸出在兩個系統上
rpm -qi glibc完全匹配。在這兩個系統上，
rpm -Vv都說一切都很好（........ /lib/libc-2.5.so）。兩個系統上的
md5sum文件不匹配。(當我
objdump -x在兩個系統上執行文件時，我得到不同的起始地址值，確認實際上兩個 SO 文件是不同的。那麼，為什麼
rpm -V告訴我 md5sum 匹配，而它顯然不匹配？這些庫是如何變得不同的？
這些庫很可能是預先連結的。RPM 知道預連結。
這篇文章談到了它。
“問題”（如果你可以這麼說的話）是 rpm 知道預連結，並且知道如何處理它。正如此郵件列表電子郵件中簡潔解釋的那樣，“rpm when –verify 將預連結 –verify，本質上是 –undo，然後再次進行預連結並進行比較。” 所以 rpm 沒有通過驗證的原因是它基本上關閉了要檢查的文件的預連結，執行驗證，然後重新打開預連結。這就是為什麼 rpm 不會報告 MD5SUM 更改，但 AIDE 會報告的原因。
連結的電子郵件在哪裡：
在 2003 年 4 月 4 日星期五下午 4:24:39 -0500，詹姆斯·拉爾斯頓寫道：
> > 在 2003-04-04 11:34: 35-0500 Jakub Jelinek 寫道： > > > > > > > 人預連結 > > > > > > 我最終會寫更多的文件。 > > > > > > > > > 一個問題… > > > 如果 prelink 就地修改了實際的二進製文件和庫（從我閱讀手冊頁來看似乎就是這種情況），這不是本質上使“rpm –verify”無用嗎？prelink 修改的每個二進製文件和庫都將無法通過 size/md5sum/mtime 測試。 > > >
它不會失敗。rpm 當–verify 將預連結–verify，本質上是–undo，然後再次預連結和比較。
> > 即使 –undo 用於恢復預連結，“rpm –verify”仍然會失敗（除非預連結恢復了文件開始之前的確切 mtime，也就是說）…… > > >
prelink 不會修改預連結庫/二進製文件的 mtimes。
雅各布
通常，另一種可能性是可以在規範文件本身的每個文件或每個目錄級別上禁用單獨的驗證檢查。因此，雖然在這種情況下並非如此，但打包程序完全有可能禁用 MD5 總和檢查已知因某種原因而更改的文件。