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
anton@PF16W6Y2 ~ $ qfile -o /lib64/libpamc.so
anton@PF16W6Y2 ~ $ qfile -o /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
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.