Summary: | sys-libs/pam-1.5.2-r3 has different versions of libpam.so libpamc.so libpam_misc.so in /lib64 and /usr/lib64 - breaks merge-usr | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Anton Gubarkov <anton.gubarkov> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | sam, zlogene |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 690294 |
Description
Anton Gubarkov
2022-12-16 05:26:14 UTC
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. |