3:03 p.m.
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"
dnf.rpm.log.3
"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 !!!
3:50 p.m.
On 6/2/22 13:03, home user 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"
For some reason you have debug kernels installed. Try "dnf remove
kernel-debug*" and see if that solves your problem.
4:43 p.m.
(sorry. I accidentally hit "Reply" rather than "Reply List")
On 6/2/22 2:50 PM, Samuel Sieb wrote:
On 6/2/22 13:03, home user 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"
For some reason you have debug kernels installed. Try "dnf remove
kernel-debug*" and see if that solves your problem.
Trying to think a step ahead,
how long will I have to wait before "dnf upgrade" (to see if the dnf
remove solves my problem) gives me something more than "nothing to do"?
4:45 p.m.
On 6/2/22 14:43, home user wrote:
On 6/2/22 2:50 PM, Samuel Sieb wrote:
> On 6/2/22 13:03, home user 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"
>
>
>
> For some reason you have debug kernels installed. Try "dnf remove
> kernel-debug*" and see if that solves your problem.
Trying to think a step ahead,
how long will I have to wait before "dnf upgrade" (to see if the dnf
remove solves my problem) gives me something more than "nothing to do"?
It's hard to say how long. It depends on what packages you have
installed. I think there's an updates push every day or so. But if it
is related to a kernel upgrade, then that could be a while longer. You
could try temporarily enabling updates-testing if you don't have it
enabled. That should give you some updates and maybe even a kernel one.
4:45 p.m.
On 6/2/22 2:50 PM, Samuel Sieb wrote:
On 6/2/22 13:03, home user 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"
For some reason you have debug kernels installed. Try "dnf remove
kernel-debug*" and see if that solves your problem.
bash.1[~]: dnf remove kernel-debug*
Dependencies resolved.
======================================================================================================================================================
Package Architecture
Version Repository
Size
======================================================================================================================================================
Removing:
kernel-debug-devel x86_64
5.17.7-200.fc35 @updates
63 M
kernel-debug-devel x86_64
5.17.9-200.fc35 @updates
63 M
kernel-debug-devel x86_64
5.17.11-200.fc35 @updates
63 M
Transaction Summary
======================================================================================================================================================
Remove 3 Packages
Freed space: 188 M
Is this ok [y/N]: y
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing :
1/1
Erasing : kernel-debug-devel-5.17.11-200.fc35.x86_64
1/3
Erasing : kernel-debug-devel-5.17.9-200.fc35.x86_64
2/3
Erasing : kernel-debug-devel-5.17.7-200.fc35.x86_64
3/3
Verifying : kernel-debug-devel-5.17.7-200.fc35.x86_64
1/3
Verifying : kernel-debug-devel-5.17.9-200.fc35.x86_64
2/3
Verifying : kernel-debug-devel-5.17.11-200.fc35.x86_64
3/3
Removed:
kernel-debug-devel-5.17.7-200.fc35.x86_64
kernel-debug-devel-5.17.9-200.fc35.x86_64
kernel-debug-devel-5.17.11-200.fc35.x86_64
Complete!
bash.2[~]: dnf upgrade
Last metadata expiration check: 3:04:38 ago on Thu 02 Jun 2022 12:31:30
PM MDT.
Dependencies resolved.
Nothing to do.
Complete!
4:53 p.m.
On 6/2/22 14:45, home user wrote:
On 6/2/22 2:50 PM, Samuel Sieb wrote:
> For some reason you have debug kernels installed. Try "dnf remove
> kernel-debug*" and see if that solves your problem.
Removing:
kernel-debug-devel x86_64
5.17.7-200.fc35 @updates 63 M
kernel-debug-devel x86_64
5.17.9-200.fc35 @updates 63 M
kernel-debug-devel x86_64
5.17.11-200.fc35 @updates 63 M
Right, now I remember. This was a rpm/packaging issue a while back. A
requirement of "kernel-devel" would pick up the debug one instead of the
regular one and there was some (I think networking-related) package that
brought it in.
11:46 a.m.
New subject: "hardlink" errors during weekly "dnf upgrade". [SOLVED]
On 6/2/22 2:50 PM, Samuel Sieb wrote:
On 6/2/22 13:03, home user wrote:
> 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"
For some reason you have debug kernels installed. Try "dnf remove
kernel-debug*" and see if that solves your problem.
I finally tested the fix this morning with the weekly run of "dnf
upgrade". I saw none of them "hardlink" errors. So Samuel's diagnosis
and cure is the solution.
This seems to have also fixed another problem. For the past few weeks,
the weekly "dnf upgrade" would take some 15-20 minutes doing some
"invisible" work, I think it was at the end of the cleanup phase. The
system monitor graph would show lots of CPU activity during that 15-20
minutes, but the system monitor process table and "top" would show very
few or no processes using more than 1% CPU. This workstation is a 3+
GHz, quad-core, 8 CPU machine. This did not occur during today's "dnf
upgrade". It does bother me that CPU-intensive processes seems to be
able to hide from "top" and the system monitor process table.
I do agree with Roger also. Some part of the patching process was not
being done properly.
I've marked this thread "SOLVED". Thank-you Samuel and Roger.
Bill.
12:08 p.m.
New subject: "hardlink" errors during weekly "dnf upgrade". [SOLVED]
How did you determine the cpu activity?
Processes doing a lot of disk io operations will cause a lot of "D" states
and will show in the load average but are generally using little or no
actual cpu and won't show up on top.
And potentially creating (or attempting) to create links would be doing a
lot of trivial disk iops that spend a lot of time waiting on the disk.
What kind of disk is the OS on? Even with a ssd the iop takes some small
amount of real time (typically about 10-50us) but is a huge amount of time
compared to the few cpu cycles it takes to create the iop.
On Thu, Jun 9, 2022 at 11:48 AM home user <mattisonw(a)comcast.net> wrote:
On 6/2/22 2:50 PM, Samuel Sieb wrote:
> On 6/2/22 13:03, home user wrote:
>> 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?us...
>
> For some reason you have debug kernels installed. Try "dnf remove
> kernel-debug*" and see if that solves your problem.
I finally tested the fix this morning with the weekly run of "dnf
upgrade". I saw none of them "hardlink" errors. So Samuel's
diagnosis
and cure is the solution.
This seems to have also fixed another problem. For the past few weeks,
the weekly "dnf upgrade" would take some 15-20 minutes doing some
"invisible" work, I think it was at the end of the cleanup phase. The
system monitor graph would show lots of CPU activity during that 15-20
minutes, but the system monitor process table and "top" would show very
few or no processes using more than 1% CPU. This workstation is a 3+
GHz, quad-core, 8 CPU machine. This did not occur during today's "dnf
upgrade". It does bother me that CPU-intensive processes seems to be
able to hide from "top" and the system monitor process table.
I do agree with Roger also. Some part of the patching process was not
being done properly.
I've marked this thread "SOLVED". Thank-you Samuel and Roger.
Bill.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
2:15 p.m.
New subject: "hardlink" errors during weekly "dnf upgrade". [SOLVED]
On 6/9/22 11:08 AM, Roger Heflin wrote:
How did you determine the cpu activity?
a. "% CPU% column in the "Processes" tab of gnome's "System
Monitor".
b. the "CPU" (top) plot in the "Resources" tab of gnome's
"System Monitor".
c. the "CPU %" column in the "Process Table" tab of kde's
"ksysguard".
d. the "CPU History" (top) plot in the "System Load" tab of kde's
"ksysguard".
e. the "%CPU" column in the output generated by the "top" command
running in a terminal.
a, c, and e seem to approximately agree with each other.
b and d seem to approximately agree with each other.
But a, c, and e seem to disagree by a large amount with b and d.
Processes doing a lot of disk io operations will cause a lot of
"D"
states and will show in the load average but are generally using little
or no actual cpu and won't show up on top.
And potentially creating (or attempting) to create links would be doing
a lot of trivial disk iops that spend a lot of time waiting on the disk.
What kind of disk is the OS on? Even with a ssd the iop takes some
small amount of real time (typically about 10-50us) but is a huge amount
of time compared to the few cpu cycles it takes to create the iop.
Seagate BarraCuda 3.5 (CMR) ST2000DM006-2DM164, 2.00 TB.
The 15-20 minute problem was occurring either
- at the end of the clean-up phase of the "dnf upgrade"; or
- between the clean-up phase and the verifying phase of the "dnf
upgrade"; or
- at the start of the verifying phase of the "dnf upgrade".
On Thu, Jun 9, 2022 at 11:48 AM home user <mattisonw(a)comcast.net
<mailto:mattisonw@comcast.net>> wrote:
> This seems to have also fixed another problem. For the past few weeks,
> the weekly "dnf upgrade" would take some 15-20 minutes doing some
> "invisible" work, I think it was at the end of the cleanup phase. The
> system monitor graph would show lots of CPU activity during that 15-20
> minutes, but the system monitor process table and "top" would show
very
> few or no processes using more than 1% CPU. This workstation is a 3+
> GHz, quad-core, 8 CPU machine. This did not occur during today's "dnf
> upgrade". It does bother me that CPU-intensive processes seems to be
> able to hide from "top" and the system monitor process table.
>
> I do agree with Roger also. Some part of the patching process was not
> being done properly.
>
> I've marked this thread "SOLVED". Thank-you Samuel and Roger.
>
> Bill.
4:24 p.m.
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.
On Thu, Jun 2, 2022 at 3:05 PM home user <mattisonw(a)comcast.net> 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?us...
"
dnf.rpm.log.3
"
https://drive.google.com/file/d/14GJdhNN0Kcr2_m3sXa7FMU-vHWY1WBpz/view?us...
"
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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
6:07 p.m.
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(a)comcast.net
<mailto:mattisonw@comcast.net>> 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?us...
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?us...
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 !!!
6:41 p.m.
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(a)comcast.net> 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(a)comcast.net
> <mailto:mattisonw@comcast.net>> 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?us...
> <
https://drive.google.com/file/d/17VBjtSM_6YNSRcsvjmYRvuSRbnGkbMzp/view?us...
>"
>
> dnf.rpm.log.3
> "
https://drive.google.com/file/d/14GJdhNN0Kcr2_m3sXa7FMU-vHWY1WBpz/view?us...
> <
https://drive.google.com/file/d/14GJdhNN0Kcr2_m3sXa7FMU-vHWY1WBpz/view?us...
>"
>
> 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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
7:03 p.m.
On 6/2/22 16:41, Roger Heflin wrote:
Well, do not assume anyone is actually looking at the log files.
Yes, unless you're watching the updates happen, you won't see it. And
if you're using something like Gnome Software, it's all in the
background anyway. I didn't even know about those 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.
Do you also have kernel-debug-devel packages installed? Has this system
been upgraded for many versions?
I don't have any errors like that, but this install is newer than the
issue that caused it and on any older systems, I've already cleared
those packages.
7:39 p.m.
I have 2 of those kernel-debug-devel packages installed. I also have rpm
fusion nvidia drivers.
And this system started with fc25.
On Thu, Jun 2, 2022 at 7:04 PM Samuel Sieb <samuel(a)sieb.net> wrote:
On 6/2/22 16:41, Roger Heflin wrote:
> Well, do not assume anyone is actually looking at the log files.
Yes, unless you're watching the updates happen, you won't see it. And
if you're using something like Gnome Software, it's all in the
background anyway. I didn't even know about those 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.
Do you also have kernel-debug-devel packages installed? Has this system
been upgraded for many versions?
I don't have any errors like that, but this install is newer than the
issue that caused it and on any older systems, I've already cleared
those packages.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
12:12 a.m.
On 6/2/22 17:39, Roger Heflin wrote:
I have 2 of those kernel-debug-devel packages installed. I also have
rpm fusion nvidia drivers.
And this system started with fc25.
That explains it then. You should probably remove those packages and
put the regular devel package if you even need it. I think the headers
package is all you need.
10:15 a.m.
(replying to a few posts)
(Roger)
> Well, do not assume anyone is actually looking at the log files.
(Samuel)
Yes, unless you're watching the updates happen, you won't see
it.
I do watch the "dnf upgrade" output live.
I upgraded from f34 to f35 on April 07. I think (I'm not sure) I
started seeing all them "hardlink" errors 3 weekly patches after that
(end of April or early May), but I've been too behind and swamped to try
to deal with it.
(Roger)
I also have rpm fusion nvidia drivers.
So do I. Your mentioning that has me wondering if that is related.
(Roger)
And this system started with fc25.
I started with whatever version of Fedora was current in spring 2013.
684
days inactive
691
days old
15 comments
3 participants
participants (3)
-
home user -
Roger Heflin -
Samuel Sieb