AIX Open Source

I am opening this thread on behalf of an AIX client.

Some systems have broken symlinks after a dnf update.

Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
<...>
File "/opt/freeware/lib/python3.7/site-packages/dnf/yum/rpmtrans.py", line 26, in <module>
import rpm
ModuleNotFoundError: No module named 'rpm'

The user tracked this down to a broken link:
/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

I analyzed the case, from an AIX perspective, to ensure they were not encountering some issues with the KSH shell, which had some specific "cd ../.." issues. The affected levels were older service packs, and had ifixes so I wanted to rule out the issue with the KSH shell:

• IJ29779: KSH ERROR IF CD '..' (DOT DOT) IN SYMLINK DIR
• https://www.ibm.com/support/pages/apar/IJ29779

Further review and testing revealed this was not applicable to the environment.

I tested their levels, and ifixes, and could not reproduce the issue. Furthermore, the majority of their systems did not have this issue, at the same shell and oslevels.

At the time, I was not sure the issue was specific to one directory, but further discussions indicate this was, indeed specific to the rpm-python3 package symlink:

/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

The source /usr/opt/rpm/lib/python3.7/site-packages/rpm was OK, but they could not list the inode information for this symlink:

istat /usr/opt/rpm/lib/python3.7/site-packages/rpm --> OKistat /opt/freeware/lib/python3.7/site-packages/rpm  --> istat: Unable to stat /opt/freeware/lib/python3.7/site-packages/rpmls -lrt  ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm "not found"  

Relinking resolved the issue.

ln -sf /usr/opt/rpm/lib/python3.7/site-packages/rpm /opt/freeware/lib/python3.7/site-packages/rpm

It seems some underlying inode is invalid, but I cannot determine the root cause, and cannot reproduce the error, although I have attempted this for 2 days, with many tests.

I checked the delivering package:

# rpm2cpio rpm-python3-4.15.1-32_1.aix7.1.ppc.rpm | /opt/freeware/bin/cpio -idmv# find .   \( -type l -o -type d \) -name rpm -ls | grep site-packages21352    1 lrwxrwxrwx  1 root      system          59 Sep 22 20:41 ./opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm21358    1 drwxr-xr-x  2 root      system         256 Sep 22 20:41 ./usr/opt/rpm/lib/python3.7/site-packages/rpm

I am not sure what could have happened.

I have also tried to reproduce the issue, by changing inodes under symlinks:

I created a symlink directory, like the package contains:

# cd /tmp/dirB/testdir/linktest# ln -sf ../../../../..//tmp/dirB/testdir/linktest/source target

Copied this to a new directory:

# cp -hr /tmp/dirB/testdir /tmp/dirA# cd /tmp/dirA/testdir/linktest# ls -lrt targetlrwxrwxrwx 1 root system 48 Sep 24 07:06 target -> ../../../../..//tmp/dirB/testdir/linktest/source

Checked inodes:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21786 on device 10/7      Directory

Then I moved, then copied to a new directory:

mv /tmp/dirB /tmp/dirB.oldcp -hr /tmp/dirB.old /tmp/dirB

Inodes are changed for BOTH directories, so no errors:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21798 on device 10/7      Directory

They have 3 oslevels:

7200-05-02-2114 - Only 3 have this issue, and 51 do not have the issue.
7200-04-02-2028
7200-03-03-1914

I have advised that, unless they did the DNF update with debug enabled, there would not be any additional information, and I'm not even sure that debug output would show what happened, The systems were updated before the user inherited them, so he does not have any specific details about the environment at the time the update happened.

I have advised them that you might not be able to provide any additional root cause analysis, but perhaps can suggest some debug steps to apply before doing any future updates.  I will advise them to communicate with you in this forum for more advice.

I am opening this thread on behalf of an AIX client.

Some systems have broken symlinks after a dnf update.

Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
<...>
File "/opt/freeware/lib/python3.7/site-packages/dnf/yum/rpmtrans.py", line 26, in <module>
import rpm
ModuleNotFoundError: No module named 'rpm'

The user tracked this down to a broken link:
/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

I analyzed the case, from an AIX perspective, to ensure they were not encountering some issues with the KSH shell, which had some specific "cd ../.." issues. The affected levels were older service packs, and had ifixes so I wanted to rule out the issue with the KSH shell:

• IJ29779: KSH ERROR IF CD '..' (DOT DOT) IN SYMLINK DIR
• https://www.ibm.com/support/pages/apar/IJ29779

Further review and testing revealed this was not applicable to the environment.

I tested their levels, and ifixes, and could not reproduce the issue. Furthermore, the majority of their systems did not have this issue, at the same shell and oslevels.

At the time, I was not sure the issue was specific to one directory, but further discussions indicate this was, indeed specific to the rpm-python3 package symlink:

/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

The source /usr/opt/rpm/lib/python3.7/site-packages/rpm was OK, but they could not list the inode information for this symlink:

istat /usr/opt/rpm/lib/python3.7/site-packages/rpm --> OKistat /opt/freeware/lib/python3.7/site-packages/rpm  --> istat: Unable to stat /opt/freeware/lib/python3.7/site-packages/rpmls -lrt  ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm "not found"  

Relinking resolved the issue.

ln -sf /usr/opt/rpm/lib/python3.7/site-packages/rpm /opt/freeware/lib/python3.7/site-packages/rpm

It seems some underlying inode is invalid, but I cannot determine the root cause, and cannot reproduce the error, although I have attempted this for 2 days, with many tests.

I checked the delivering package:

# rpm2cpio rpm-python3-4.15.1-32_1.aix7.1.ppc.rpm | /opt/freeware/bin/cpio -idmv# find .   \( -type l -o -type d \) -name rpm -ls | grep site-packages21352    1 lrwxrwxrwx  1 root      system          59 Sep 22 20:41 ./opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm21358    1 drwxr-xr-x  2 root      system         256 Sep 22 20:41 ./usr/opt/rpm/lib/python3.7/site-packages/rpm

I am not sure what could have happened.

I have also tried to reproduce the issue, by changing inodes under symlinks:

I created a symlink directory, like the package contains:

# cd /tmp/dirB/testdir/linktest# ln -sf ../../../../..//tmp/dirB/testdir/linktest/source target

Copied this to a new directory:

# cp -hr /tmp/dirB/testdir /tmp/dirA# cd /tmp/dirA/testdir/linktest# ls -lrt targetlrwxrwxrwx 1 root system 48 Sep 24 07:06 target -> ../../../../..//tmp/dirB/testdir/linktest/source

Checked inodes:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21786 on device 10/7      Directory

Then I moved, then copied to a new directory:

mv /tmp/dirB /tmp/dirB.oldcp -hr /tmp/dirB.old /tmp/dirB

Inodes are changed for BOTH directories, so no errors:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21798 on device 10/7      Directory

They have 3 oslevels:

7200-05-02-2114 - Only 3 have this issue, and 51 do not have the issue.
7200-04-02-2028
7200-03-03-1914

I have advised that, unless they did the DNF update with debug enabled, there would not be any additional information, and I'm not even sure that debug output would show what happened, The systems were updated before the user inherited them, so he does not have any specific details about the environment at the time the update happened.

I have advised them that you might not be able to provide any additional root cause analysis, but perhaps can suggest some debug steps to apply before doing any future updates.  I will advise them to communicate with you in this forum for more advice.

I am opening this thread on behalf of an AIX client.

Some systems have broken symlinks after a dnf update.

Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
<...>
File "/opt/freeware/lib/python3.7/site-packages/dnf/yum/rpmtrans.py", line 26, in <module>
import rpm
ModuleNotFoundError: No module named 'rpm'

The user tracked this down to a broken link:
/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

I analyzed the case, from an AIX perspective, to ensure they were not encountering some issues with the KSH shell, which had some specific "cd ../.." issues. The affected levels were older service packs, and had ifixes so I wanted to rule out the issue with the KSH shell:

• IJ29779: KSH ERROR IF CD '..' (DOT DOT) IN SYMLINK DIR
• https://www.ibm.com/support/pages/apar/IJ29779

Further review and testing revealed this was not applicable to the environment.

I tested their levels, and ifixes, and could not reproduce the issue. Furthermore, the majority of their systems did not have this issue, at the same shell and oslevels.

At the time, I was not sure the issue was specific to one directory, but further discussions indicate this was, indeed specific to the rpm-python3 package symlink:

/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

The source /usr/opt/rpm/lib/python3.7/site-packages/rpm was OK, but they could not list the inode information for this symlink:

istat /usr/opt/rpm/lib/python3.7/site-packages/rpm --> OKistat /opt/freeware/lib/python3.7/site-packages/rpm  --> istat: Unable to stat /opt/freeware/lib/python3.7/site-packages/rpmls -lrt  ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm "not found"  

Relinking resolved the issue.

ln -sf /usr/opt/rpm/lib/python3.7/site-packages/rpm /opt/freeware/lib/python3.7/site-packages/rpm

It seems some underlying inode is invalid, but I cannot determine the root cause, and cannot reproduce the error, although I have attempted this for 2 days, with many tests.

I checked the delivering package:

# rpm2cpio rpm-python3-4.15.1-32_1.aix7.1.ppc.rpm | /opt/freeware/bin/cpio -idmv# find .   \( -type l -o -type d \) -name rpm -ls | grep site-packages21352    1 lrwxrwxrwx  1 root      system          59 Sep 22 20:41 ./opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm21358    1 drwxr-xr-x  2 root      system         256 Sep 22 20:41 ./usr/opt/rpm/lib/python3.7/site-packages/rpm

I am not sure what could have happened.

I have also tried to reproduce the issue, by changing inodes under symlinks:

I created a symlink directory, like the package contains:

# cd /tmp/dirB/testdir/linktest# ln -sf ../../../../..//tmp/dirB/testdir/linktest/source target

Copied this to a new directory:

# cp -hr /tmp/dirB/testdir /tmp/dirA# cd /tmp/dirA/testdir/linktest# ls -lrt targetlrwxrwxrwx 1 root system 48 Sep 24 07:06 target -> ../../../../..//tmp/dirB/testdir/linktest/source

Checked inodes:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21786 on device 10/7      Directory

Then I moved, then copied to a new directory:

mv /tmp/dirB /tmp/dirB.oldcp -hr /tmp/dirB.old /tmp/dirB

Inodes are changed for BOTH directories, so no errors:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21798 on device 10/7      Directory

They have 3 oslevels:

7200-05-02-2114 - Only 3 have this issue, and 51 do not have the issue.
7200-04-02-2028
7200-03-03-1914

I have advised that, unless they did the DNF update with debug enabled, there would not be any additional information, and I'm not even sure that debug output would show what happened, The systems were updated before the user inherited them, so he does not have any specific details about the environment at the time the update happened.

I have advised them that you might not be able to provide any additional root cause analysis, but perhaps can suggest some debug steps to apply before doing any future updates.  I will advise them to communicate with you in this forum for more advice.

I am opening this thread on behalf of an AIX client.

Some systems have broken symlinks after a dnf update.

Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
<...>
File "/opt/freeware/lib/python3.7/site-packages/dnf/yum/rpmtrans.py", line 26, in <module>
import rpm
ModuleNotFoundError: No module named 'rpm'

The user tracked this down to a broken link:
/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

I analyzed the case, from an AIX perspective, to ensure they were not encountering some issues with the KSH shell, which had some specific "cd ../.." issues. The affected levels were older service packs, and had ifixes so I wanted to rule out the issue with the KSH shell:

• IJ29779: KSH ERROR IF CD '..' (DOT DOT) IN SYMLINK DIR
• https://www.ibm.com/support/pages/apar/IJ29779

Further review and testing revealed this was not applicable to the environment.

I tested their levels, and ifixes, and could not reproduce the issue. Furthermore, the majority of their systems did not have this issue, at the same shell and oslevels.

At the time, I was not sure the issue was specific to one directory, but further discussions indicate this was, indeed specific to the rpm-python3 package symlink:

/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

The source /usr/opt/rpm/lib/python3.7/site-packages/rpm was OK, but they could not list the inode information for this symlink:

istat /usr/opt/rpm/lib/python3.7/site-packages/rpm --> OKistat /opt/freeware/lib/python3.7/site-packages/rpm  --> istat: Unable to stat /opt/freeware/lib/python3.7/site-packages/rpmls -lrt  ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm "not found"  

Relinking resolved the issue.

ln -sf /usr/opt/rpm/lib/python3.7/site-packages/rpm /opt/freeware/lib/python3.7/site-packages/rpm

It seems some underlying inode is invalid, but I cannot determine the root cause, and cannot reproduce the error, although I have attempted this for 2 days, with many tests.

I checked the delivering package:

# rpm2cpio rpm-python3-4.15.1-32_1.aix7.1.ppc.rpm | /opt/freeware/bin/cpio -idmv# find .   \( -type l -o -type d \) -name rpm -ls | grep site-packages21352    1 lrwxrwxrwx  1 root      system          59 Sep 22 20:41 ./opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm21358    1 drwxr-xr-x  2 root      system         256 Sep 22 20:41 ./usr/opt/rpm/lib/python3.7/site-packages/rpm

I am not sure what could have happened.

I have also tried to reproduce the issue, by changing inodes under symlinks:

I created a symlink directory, like the package contains:

# cd /tmp/dirB/testdir/linktest# ln -sf ../../../../..//tmp/dirB/testdir/linktest/source target

Copied this to a new directory:

# cp -hr /tmp/dirB/testdir /tmp/dirA# cd /tmp/dirA/testdir/linktest# ls -lrt targetlrwxrwxrwx 1 root system 48 Sep 24 07:06 target -> ../../../../..//tmp/dirB/testdir/linktest/source

Checked inodes:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21786 on device 10/7      Directory

Then I moved, then copied to a new directory:

mv /tmp/dirB /tmp/dirB.oldcp -hr /tmp/dirB.old /tmp/dirB

Inodes are changed for BOTH directories, so no errors:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21798 on device 10/7      Directory

They have 3 oslevels:

7200-05-02-2114 - Only 3 have this issue, and 51 do not have the issue.
7200-04-02-2028
7200-03-03-1914

I have advised that, unless they did the DNF update with debug enabled, there would not be any additional information, and I'm not even sure that debug output would show what happened, The systems were updated before the user inherited them, so he does not have any specific details about the environment at the time the update happened.

I have advised them that you might not be able to provide any additional root cause analysis, but perhaps can suggest some debug steps to apply before doing any future updates.  I will advise them to communicate with you in this forum for more advice.

I am opening this thread on behalf of an AIX client.

Some systems have broken symlinks after a dnf update.

Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
<...>
File "/opt/freeware/lib/python3.7/site-packages/dnf/yum/rpmtrans.py", line 26, in <module>
import rpm
ModuleNotFoundError: No module named 'rpm'

The user tracked this down to a broken link:
/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

I analyzed the case, from an AIX perspective, to ensure they were not encountering some issues with the KSH shell, which had some specific "cd ../.." issues. The affected levels were older service packs, and had ifixes so I wanted to rule out the issue with the KSH shell:

• IJ29779: KSH ERROR IF CD '..' (DOT DOT) IN SYMLINK DIR
• https://www.ibm.com/support/pages/apar/IJ29779

Further review and testing revealed this was not applicable to the environment.

I tested their levels, and ifixes, and could not reproduce the issue. Furthermore, the majority of their systems did not have this issue, at the same shell and oslevels.

At the time, I was not sure the issue was specific to one directory, but further discussions indicate this was, indeed specific to the rpm-python3 package symlink:

/opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm

The source /usr/opt/rpm/lib/python3.7/site-packages/rpm was OK, but they could not list the inode information for this symlink:

istat /usr/opt/rpm/lib/python3.7/site-packages/rpm --> OKistat /opt/freeware/lib/python3.7/site-packages/rpm  --> istat: Unable to stat /opt/freeware/lib/python3.7/site-packages/rpmls -lrt  ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm "not found"  

Relinking resolved the issue.

ln -sf /usr/opt/rpm/lib/python3.7/site-packages/rpm /opt/freeware/lib/python3.7/site-packages/rpm

It seems some underlying inode is invalid, but I cannot determine the root cause, and cannot reproduce the error, although I have attempted this for 2 days, with many tests.

I checked the delivering package:

# rpm2cpio rpm-python3-4.15.1-32_1.aix7.1.ppc.rpm | /opt/freeware/bin/cpio -idmv# find .   \( -type l -o -type d \) -name rpm -ls | grep site-packages21352    1 lrwxrwxrwx  1 root      system          59 Sep 22 20:41 ./opt/freeware/lib/python3.7/site-packages/rpm -> ../../../../..//usr/opt/rpm/lib/python3.7/site-packages/rpm21358    1 drwxr-xr-x  2 root      system         256 Sep 22 20:41 ./usr/opt/rpm/lib/python3.7/site-packages/rpm

I am not sure what could have happened.

I have also tried to reproduce the issue, by changing inodes under symlinks:

I created a symlink directory, like the package contains:

# cd /tmp/dirB/testdir/linktest# ln -sf ../../../../..//tmp/dirB/testdir/linktest/source target

Copied this to a new directory:

# cp -hr /tmp/dirB/testdir /tmp/dirA# cd /tmp/dirA/testdir/linktest# ls -lrt targetlrwxrwxrwx 1 root system 48 Sep 24 07:06 target -> ../../../../..//tmp/dirB/testdir/linktest/source

Checked inodes:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21786 on device 10/7      Directory

Then I moved, then copied to a new directory:

mv /tmp/dirB /tmp/dirB.oldcp -hr /tmp/dirB.old /tmp/dirB

Inodes are changed for BOTH directories, so no errors:

# istat /tmp/dirB/testdir/linktest/target# istat /tmp/dirA/testdir/linktest/targetInode 21798 on device 10/7      Directory

They have 3 oslevels:

7200-05-02-2114 - Only 3 have this issue, and 51 do not have the issue.
7200-04-02-2028
7200-03-03-1914

I have advised that, unless they did the DNF update with debug enabled, there would not be any additional information, and I'm not even sure that debug output would show what happened, The systems were updated before the user inherited them, so he does not have any specific details about the environment at the time the update happened.

I have advised them that you might not be able to provide any additional root cause analysis, but perhaps can suggest some debug steps to apply before doing any future updates.  I will advise them to communicate with you in this forum for more advice.