Project Talk:Toolchain/Corrupt VDB ELF files

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 16:48, 9 December 2024 (UTC)
:: Your reply ~~~~

Corner case?

Talk status
This discussion is still ongoing.

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

Talk status
This discussion is done.

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.
--Sam (talk) 05:29, 18 December 2021 (UTC)