-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
rhel-9.7
-
None
-
None
-
Low
-
rhel-bootloader
-
None
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
-
x86_64
-
None
What were you trying to do that didn't work?
After installing shim-x64-16.1-5.el9.x86_64 package, I checked the installation with rpm -V shim-x64 and the latter reports some Timestamp issue:
# rpm -V shim-x64-16.1-5.el9.x86_64 .......T. /boot/efi/EFI/BOOT/BOOTX64.EFI .......T. /boot/efi/EFI/BOOT/fbx64.efi .......T. /boot/efi/EFI/redhat/BOOTX64.CSV .......T. /boot/efi/EFI/redhat/mmx64.efi .......T. /boot/efi/EFI/redhat/shim.efi .......T. /boot/efi/EFI/redhat/shimx64-redhat.efi .......T. /boot/efi/EFI/redhat/shimx64.efi
The RPM dump states that timestamp for shimx64.efi is 1760985451:
# rpm -q --dump shim-x64-16.1-5.el9.x86_64 [...] /boot/efi/EFI/redhat/shimx64.efi 1035680 1760985451 c4c6aecfa15c16bb7b1644cffd8c3f835f67139b3427d595da167447febff5b6 0100700 root root 0 0 0 X
Stracing the installation of the package shows the proper timestamp is applied to the temporary inode (which is later renamed into shimx64.efi):
1896 15:50:18.566440 utimensat(37</boot/efi/EFI/redhat/shimx64.efi;6915fe3a>, NULL, [{tv_sec=1760985451, tv_nsec=0} /* 2025-10-20T18:37:31+0000 */, {tv_sec=1760985451, tv_nsec=0} /* 2025-10-20T18:37:31+0000 */], 0) = 0 <0.000009>
But the file system stat shows it differs by 1 second:
# strace -fttTvyy -s 256 -o stat.strace -- stat /boot/efi/EFI/redhat/shimx64.efi [...] Modify: 2025-10-20 18:37:30.000000000 +0000 [...] 1965 16:08:40.332374 statx(AT_FDCWD</root>, "/boot/efi/EFI/redhat/shimx64.efi", ..., stx_mtime={tv_sec=1760985450, tv_nsec=0} /* 2025-10-20T18:37:30+0000 */, ...) = 0 <0.000035>
esandeen@redhat.com commented that this was expected because FAT timestamps have a 2 seconds granularity:
/* * truncate mtime to 2 second granularity */ struct timespec64 fat_truncate_mtime(const struct msdos_sb_info *sbi, const struct timespec64 *ts) { return fat_timespec64_trunc_2secs(*ts); }
Please update the RPM build code to make sure that file timestamps have that granularity to avoid reporting a discrepancy.
What is the impact of this issue to you?
False-positives reported by rpm
Please provide the package NVR for which the bug is seen:
kernel-5.14.0-611.7.1.el9_7.x86_64
shim-x64-16.1-5.el9.x86_64
- relates to
-
-
- New
-
