Well, do not assume anyone is actually looking at the log files.
If the end result is the rpm installs without errors I don't look too closely at the details, and likely others also do not look too closely, especially if I am doing a big upgrade on my home system that has a lot of output. If the package/upgrade reports it worked I don't look closely at the raw details. At best in my experience of debugging linux systems in my day job, the odds are the important looking error messages coming of the scriptlets/kernel is *NORMAL* and not actually important nor useful unless you are the one creating the spec file for the rpm.
And 2 of my dnf log files on the one home system I checked appear to have 11,000 of the errors in each file.
On Thu, Jun 2, 2022 at 6:09 PM home user <mattisonw@xxxxxxxxxxx> wrote:
On 6/2/22 3:24 PM, Roger Heflin wrote:
> From reading the errors it would seem that the install scriptlet the
> rpm(s) that deliver those files believe they need to create all of the
> hardlinks under those directories. It would appear to be a poorly
> written install scriptlet that passed testing because they installed and
> then uninstalled the one package and never had more than one installed
> to get the errors.
>
> It is a meaningless error, and it indicates that it tried to create a
> link but the link was already there (almost certainly created by the
> exact same scriptlet correctly at some earlier point in time). The code
> would seem to need to check if a hardlink was already done and then
> assume the link is correct, and not re-do it and get an error, or verify
> that the file is a hardlink and then remove it and recreate it to make
> sure it is right, or simply check the inode of the 2 files they are
> hardlinking and if they are the same then there is nothing to see.
>
> It probably means the command they are using to create the link should
> simply return success if there is already a hardlink in place pointing
> to the correct place (inode is the same), maybe under option control
> similar to mkdir -p that does not report an error when the directories
> it is being asked to create already exist.
So why am I the only person experiencing this problem?
Or are other people experiencing it, but just not saying anything?
> On Thu, Jun 2, 2022 at 3:05 PM home user <mattisonw@xxxxxxxxxxx
> <mailto:mattisonw@xxxxxxxxxxx>> wrote: > Before proceeding, please note that I have no sys.admin. training or
> experience. I'm a home user trying to maintain my home f35 workstation.
>
> When doing my weekly patches (dnf upgrade), I get swamped with
> "hardlink" error messages. There are a huge number of them, and they
> fly past far too fast to see what dnf was doing when the messages
> started. I found the messages in two log files. I put them on the
> google drive. The file names with links to them on the google drive
> are
> as follows:
>
> dnf.rpm.log.1
> "https://drive.google.com/file/d/17VBjtSM_6YNSRcsvjmYRvuSRbnGkbMzp/view?usp=sharing
> <https://drive.google.com/file/d/17VBjtSM_6YNSRcsvjmYRvuSRbnGkbMzp/view?usp=sharing>"
>
> dnf.rpm.log.3
> "https://drive.google.com/file/d/14GJdhNN0Kcr2_m3sXa7FMU-vHWY1WBpz/view?usp=sharing
> <https://drive.google.com/file/d/14GJdhNN0Kcr2_m3sXa7FMU-vHWY1WBpz/view?usp=sharing>"
>
> The 10 terminal display log lines after the last "hardlink" message are:
> ----------
> Upgrading :
> xorg-x11-drv-nvidia-470xx-libs-3:470.129.06-2.fc35.i686 88/159
> Upgrading :
> xorg-x11-drv-nvidia-470xx-libs-3:470.129.06-2.fc35.x86_64 89/159
> Running scriptlet:
> xorg-x11-drv-nvidia-470xx-3:470.129.06-2.fc35.x86_64 90/159
> Upgrading :
> xorg-x11-drv-nvidia-470xx-3:470.129.06-2.fc35.x86_64 90/159
> Running scriptlet:
> xorg-x11-drv-nvidia-470xx-3:470.129.06-2.fc35.x86_64 90/159
> Cleanup : urw-base35-fonts-20200910-9.fc35.noarch 91/159
> Erasing : kernel-5.17.6-200.fc35.x86_64 92/159
> Running scriptlet: kernel-5.17.6-200.fc35.x86_64 92/159
> Cleanup : system-config-printer-1.5.15-5.fc35.x86_64 93/159
> Erasing : kernel-modules-5.17.6-200.fc35.x86_64 94/159
> ----------
> The log files generated by today's "dnf upgrade" are these:
> ----------
> -rw-r--r--. 1 root root 1024681 Jun 2 12:46 dnf.librepo.log
> -rw-r--r--. 1 root root 779081 Jun 2 13:08 dnf.log
> -rw-r--r--. 1 root root 6254 Jun 2 13:07 dnf.rpm.log
> -rw-r--r--. 1 root root 14186202 Jun 2 12:43 dnf.rpm.log.1
> -rw-r--r--. 1 root root 88 Jun 2 12:42 dnf.rpm.log.2
> -rw-r--r--. 1 root root 12846472 Jun 2 12:42 dnf.rpm.log.3
> -rw-r--r--. 1 root root 19131 Jun 2 12:38 dnf.rpm.log.4
> ----------
> If you need/want to see any of those, let me know and I'll put it on
> the
> google drive.
>
> H-E-E-E-L-P !!!
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure