Bug 2225684
| Summary: | dracut creates initramfs with incorrect timestamps | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Andrew Schorr <ajschorr> | ||||
| Component: | dracut | Assignee: | dracut-maint-list | ||||
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-daemons | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | CentOS Stream | CC: | bstinson, dtardon, jwboyer, pvalena | ||||
| Target Milestone: | rc | Keywords: | Reopened | ||||
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2023-09-14 07:08:40 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Andrew Schorr
2023-07-25 16:46:49 UTC
Please note that dracut modules are not updated, but rather re-created.
I don't see how there would be any content of initrd (incl. timestamp) 'preserved'; but some files can be modified or recreated for dracut runtime (before pivot).
Most likely explanation (IMO) is that the timestamp you're seeing is date of file creatin, hence no effect on file modification (or similar issue).
Note that if you want to regenerate specific initrd, you need to add '--kver=...' arg when invoking dracut (very much recommended).
If you still think there's an issue, please run `dracut` in verbose mode ('-vvv'), attach the log here, and reopen the bug.
I thought I provided a clear example of the problem above. Did you read it? I edited sysctl.conf, then re-ran dracut, and the dracut initramfs contained the new version of sysctl.conf (based on the length change), but somehow had the timestamp of the previous reason displayed in the lsinitrd output. How can that happen? Let's try this again with dracut -vvv: [root@ti128 ~]# uname -r 5.14.0-325.el9.x86_64 [root@ti128 ~]# ls -l /etc/sysctl.conf -r--r--r-- 1 root root 1196 Sep 12 21:06 /etc/sysctl.conf [root@ti128 ~]# lsinitrd | grep sysctl.conf -r--r--r-- 1 root root 1196 May 31 10:29 etc/sysctl.conf lrwxrwxrwx 1 root root 14 May 31 10:29 etc/sysctl.d/99-sysctl.conf -> ../sysctl.conf [root@ti128 ~]# echo "# random comment" >> /etc/sysctl.conf [root@ti128 ~]# ls -l /etc/sysctl.conf -r--r--r-- 1 root root 1213 Sep 13 16:20 /etc/sysctl.conf [root@ti128 ~]# dracut -vvv -f > /tmp/dracut.log 2>&1 && echo SUCCESS SUCCESS [root@ti128 ~]# lsinitrd | grep sysctl.conf -r--r--r-- 1 root root 1213 May 31 10:29 etc/sysctl.conf lrwxrwxrwx 1 root root 14 May 31 10:29 etc/sysctl.d/99-sysctl.conf -> ../sysctl.conf How can it be that inside the initramfs, the file size of sysctl.conf has updated, but it retains the previous timestamp? This is confusing and weird. What do you mean when you say that "dracut modules are not updated, but rather re-created"? How does that relate to this issue? I will attach the dracut log. Regards, Andy Created attachment 1988728 [details]
output from dracut -f -vvv
(In reply to Andrew Schorr from comment #0) > Description of problem: > I have noticed on several occasions that the initramfs file created by > dracut does not have correct timestamps. It somehow seems to preserve the > timestamp from the previous version of the file. It can't. Initrds are always created from scratch. dracut apparently changes the timestamps at some point--probably when copying them into a temp. directory--but it has nothing to do with possible older version of the initrd. # stat /etc/sysctl.conf File: /etc/sysctl.conf Size: 451 Blocks: 8 IO Block: 4096 regular file Device: 253,2 Inode: 4720653 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:system_conf_t:s0 Access: 2023-09-14 08:34:25.094316427 +0200 Modify: 2023-09-14 08:34:17.463354615 +0200 Change: 2023-09-14 08:34:17.497354447 +0200 Birth: 2023-09-14 08:34:17.463354615 +0200 # # edit /etc/sysctl.conf # stat /etc/sysctl.conf File: /etc/sysctl.conf Size: 449 Blocks: 8 IO Block: 4096 regular file Device: 253,2 Inode: 4719020 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:system_conf_t:s0 Access: 2023-09-14 08:48:53.872152186 +0200 Modify: 2023-09-14 08:48:53.874152175 +0200 Change: 2023-09-14 08:48:53.916151951 +0200 Birth: 2023-09-14 08:48:53.872152186 +0200 # dracut /tmp/initrd # lsinitrd /tmp/initrd | grep -F etc/sysctl.conf -rw-r--r-- 1 root root 449 Apr 27 02:00 etc/sysctl.conf As can be seen, the timestamp of etc/sysctl.conf in the initrd does not match the timestamp of /etc/sysctl.conf either before or after editing. Also, many of the files in the initrd--including all kernel modules--have the same timestamp. But unless you can show this actually matters, I'm not going to spend any more time trying to figure out what's going on. (Closing as NOTABUG, because bugzilla doesn't have resolution IDONTCARE.) Ah, OK, I agree -- the timestamp seems to come from something in the dracut distribution and has nothing to do with the file's actual timestamp. I just upgraded dracut, and after remaking the initrd, I see that timestamps have jumped to 'Aug 22 14:22', which seems to be the timestamp of many of the files in the dracut rpm itself. I'm still not clear on why some files inside initrd have different timestamps, but I suppose it doesn't matter. The timestamps in there basically contain no info. |