View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007624 | Rocky-Linux-9 | basesystem | public | 2024-08-15 10:15 | 2024-08-15 11:02 |
Reporter | Borislav Andric | Assigned To | Louis Abel | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | not fixable | ||
Summary | 0007624: basesystem package should never be updated | ||||
Description | Rocky Linux 9 updated package "basesystem" which according to Red Hat should never be done. As i can check RHEL didn't update its package This Rocky's change broke at least recommended way to check installation time of operating system and diverges Rocky's behavior compared do RHEL. Changelogs for basesystem in up2date Rocky 9: > * Thu Feb 29 12:00:00 AM 2024 Louis Abel <label@resf.org> - 11-13.0.1 > - Rebuild to address build system issue Install date of this package is recommended way to check date and time of installation since RHEL 3. From Red Hat's knowledge base article "How can I find the installation date of my Red Hat Enterprise Linux system ?" on https://access.redhat.com/solutions/16525 > finding the installation date can be best accomplished using the "basesystem" rpm. > Basesystem should be the first package installed on a system and it should never be removed. > Since this package is never removed or updated, the install date of this package indicates the install date of the system. | ||||
Steps To Reproduce | Install Rocky 9 without updated baseimage. Check install time with: rpm --queryformat "%{name} install time is %{INSTALLTIME:date}\n" -q basesystem Do DNF update. Check install time again with same command. Time is changed to time of update and it should not be changed ever. | ||||
Tags | No tags attached. | ||||
Thank you for the report! You are correct that basesystem is the starting point of an installed system. I understand that it may be a problem that we updated it, which is justified. Unfortunately, as our change log suggests, it was done to address a build system issue at the time, an issue we were unable to get around. There are a few other ways to verify when the system was installed via normal means (e.g. not a preinstalled cloud image) that the article doesn't point out, such as /root/anaconda-ks.cfg and /var/log/anaconda/*.log. The article mentions /var/log/anaconda.*, but those have not existed for a long time. While those are not foolproof methods and "basesystem" would be as the red hat article suggests, they are at least options. I can see for example when I rolled out one of my systems by looking at anaconda: [label@xmpp01 ~]$ ll /var/log/anaconda/ total 4644 -rw-------. 1 root root 41902 Jul 14 2022 anaconda.log -rw-------. 1 root root 3330 Jul 14 2022 dbus.log -rw-------. 1 root root 52565 Jul 14 2022 dnf.librepo.log -rw-------. 1 root root 120 Jul 14 2022 hawkey.log -rw-------. 1 root root 2680813 Jul 14 2022 journal.log -rw-------. 1 root root 40 Jul 14 2022 ks-script-5usye6mw.log -rw-------. 1 root root 0 Jul 14 2022 ks-script-7s2m3rjh.log -rw-------. 1 root root 63 Jul 14 2022 ks-script-ab4_yum8.log -rw-------. 1 root root 529 Jul 14 2022 ks-script-dg_adxr5.log -rw-r--r--. 1 root root 25782 Jul 14 2022 lorax-packages.log -rw-------. 1 root root 702295 Jul 14 2022 lvm.log -rw-------. 1 root root 235716 Jul 14 2022 packaging.log -rw-------. 1 root root 9044 Jul 14 2022 program.log -rw-------. 1 root root 208799 Jul 14 2022 storage.log -rw-------. 1 root root 761339 Jul 14 2022 syslog >This Rocky's change broke at least recommended way to check installation time of operating system and diverges Rocky's behavior compared do RHEL Unfortunately, we have other differences in comparison to RHEL. These come in the form of branding patches or simply patches to add support for our distribution. We have a close to accurate page of what we patch here: https://sig-core.rocky.page/documentation/patching/changes/ There are other packages we've had to rebuild, too, as unfortunate (and annoying for us) as it is. All of these can be seen as issues to some, and we do understand that as it also bothers the rest of my team. And unfortunately for this package, there's nothing we can really do, as you may have guessed. For those who have installed mid-cycle 9.3 or on 9.4's release, they will not have this discrepancy on their system. Thank you again for the report and thank you for supporting Rocky Linux. Closing as not fixable. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2024-08-15 10:15 | Borislav Andric | New Issue | |
2024-08-15 11:02 | Louis Abel | Assigned To | => Louis Abel |
2024-08-15 11:02 | Louis Abel | Status | new => closed |
2024-08-15 11:02 | Louis Abel | Resolution | open => not fixable |
2024-08-15 11:02 | Louis Abel | Note Added: 0008185 |