Project Talk:Toolchain/Corrupt VDB ELF files
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
~~~~), and indent successive comments with colons (:).
Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.Corner case?
I believe this to be a very specific corner case under unusual circumstances. I tested this script on at least 3 installs and all had hits that were mostly false-positives. What I mean by that is they were internally (same package) shared files outside the SOPATH like in /usr/libexec. While it was good to rebuild, it had no real changes to the rest of the system. I don't mind if I am proven incorrect but I don't believe this to be a major concern. --Grknight (talk) 12:39, 28 September 2021 (UTC)
A few points:
- It'd be really useful to have the output from runs which were false positives. It's hard to act on something I can't directly test;
- It requires more effort to determine if anything uses those libraries because other packages might be installed with a certain RPATH - my primary concern here has been making sure Portage can act consistently (and the VDB has the entries it would in normal circumstances);
- I don't think you're wrong that certain people might be fine, but it is certainly a major concern if someone is affected. And the nature of it is such that someone might be affected quite some time after the corruption occurred (when some package required finally changes SONAME, possibly months or years later).
- For quite some time, this was a regular occurrence with glibc upgrades, and the dependency resolution order is not something we can predict for every user. That is, it's not really easy to say "just these packages are affected" with a hardcoded small list.
- (The reason I suggest rebuilding everything is because I don't particularly want people to rely on the tool munging the VDB permanently.)
- Given this, I've tended towards being conservative. I've added some bold to the '-e @world' advice though.
--Sam (talk) 17:08, 28 September 2021 (UTC)
Rebuild affected packages
The output of the recover-broken-vdb-find-broken.sh command includes a comment on the first line, which results in:
root #emerge --ask --verbose --oneshot --usepkg=n $(cat broken_vdb_packages)!!! '#' is not a valid package atom.
!!! Please check ebuild(5) for full details.
To exclude the comment line, I have used:
root #emerge --ask --verbose --oneshot --usepkg=n $(grep -v '^#' broken_vdb_packages)On a few systems, I have also had to remove the version specification:
root #emerge --ask --verbose --oneshot --usepkg=n $(grep -v '^#' broken_vdb_packages | sed 's/^=//;s/-[0-9].*$/')despite having previously run
root #emerge --ask --verbose --update --deep --newuse @world(possibly due to the packages needing updates no longer being included in the dependencies of any updated packages in the @world set?) --Klightspeed (talk) 17:25, 17 December 2021 (UTC)
- Thanks! See Special:Diff/1038616 and Special:Diff/1038617.