PF16W6Y2 ~ # merge-usr --dryrun INFO: Migrating files from '/bin' to '/usr/bin' INFO: Skipping symlink '/bin/mail'; '/usr/bin/mail' already exists INFO: Skipping symlink '/bin/awk'; '/usr/bin/awk' already exists INFO: No problems found for '/bin' INFO: Migrating files from '/sbin' to '/usr/bin' INFO: No problems found for '/sbin' INFO: Migrating files from '/usr/sbin' to '/usr/bin' INFO: Skipping symlink '/usr/sbin/apxs'; '/usr/bin/apxs' already exists INFO: No problems found for '/usr/sbin' INFO: Migrating files from '/lib' to '/usr/lib' INFO: Already a symlink: '/lib32' INFO: Migrating files from '/lib64' to '/usr/lib64' ERROR: Conflict for symlink '/lib64/libpam.so': [Errno 17] File exists: '/usr/lib64/libpam.so' ERROR: Conflict for symlink '/lib64/libpamc.so': [Errno 17] File exists: '/usr/lib64/libpamc.so' ERROR: Conflict for symlink '/lib64/libpam_misc.so': [Errno 17] File exists: '/usr/lib64/libpam_misc.so' ERROR: Leaving '/lib64' as a directory due to prior errors I checked the md5sum of the conflicting files - they differ.
It's unclear why you have a /lib64/libpam.so at all. Is it orphaned (use qfile -o)?
it seems so anton@PF16W6Y2 ~ $ qfile -o /lib64/libpam.so /lib64/libpam.so anton@PF16W6Y2 ~ $ qfile -o /lib64/libpamc.so /lib64/libpamc.so anton@PF16W6Y2 ~ $ qfile -o /lib64/libpam_misc.so /lib64/libpam_misc.so anton@PF16W6Y2 ~ $
are they safe to remove?
I think it should be okay if you're in a root shell and then run merge-usr immediately.
something went wrong with merge-usr and I ended up with a broken pam. Fortunately I left one more text console open with root logged in. Emerging pam got me back on track. I think extra precaution should be excersized when handling pam libraries in merge-usr
(In reply to Anton Gubarkov from comment #5) > something went wrong with merge-usr and I ended up with a broken pam. > > Fortunately I left one more text console open with root logged in. Emerging > pam got me back on track. > > I think extra precaution should be excersized when handling pam libraries in > merge-usr It's hard to say what happened given you had orphaned files, there easily could've been more. I've not seen any issues like this. I assume you don't have the output from merge-usr and details of what went wrong?
No, I don't Although I have inspected the journal and found the trace of the problem that initially manifested after I merged-usr internal error: Failed to start QEMU binary /usr/bin/qemu-system-x86_64 for probing: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libpam.so.0: cannot open shared object file: No such file or directory the link to libpam.so.0 was one of the files I removed from /lib64 after removing the orphaned files. the links pointed to them and became invalid irritating merge-usr, so I removed them too. apparently, there were no similar links in /usr/lib64 causing the above error. When I emerged pam package, the links were re-created.
Removing the SONAME symlink (libpam.so.0) was an error. I don't think we told you to do that. Removing the .so symlinks *only* would have sufficed. Those are the only files flagged with ERROR in the merge-usr output. I don't think there is any way the merge-usr script could handle this better: it alerted you of the exact problem, but you took it a bit too far. :) This isn't an issue caused by merge-usr or the current pam ebuilds. My best guess for how the orphaned .so symlinks got created: you probably ran "ldconfig" without options at some point. This will create symlinks to the latest version of each library installed in all system libdirs. Generally, you should run "ldconfig -X" instead to avoid this behavior.
