* [gentoo-amd64] Re: lib32 flush with no emul-linux-*
2007-01-30 2:21 [gentoo-amd64] lib32 flush with no emul-linux-* Daiajo Tibdixious
2007-01-30 9:19 ` Bo Ørsted Andresen
@ 2007-01-30 10:06 ` Duncan
1 sibling, 0 replies; 5+ messages in thread
From: Duncan @ 2007-01-30 10:06 UTC (permalink / raw
To: gentoo-amd64
"Daiajo Tibdixious" <daiajo@gmail.com> posted
a4a9bfcb0701291821l47ea160pa76a94f1f52da661@mail.gmail.com, excerpted
below, on Tue, 30 Jan 2007 13:21:57 +1100:
> [This sort of continues from "unmerging slotted group packages" which
> drifted into general gentoo maintenance, and hence my first --depclean
> since inception.]
> revdep-rebuild is pulling up hundreds of broken links since the depclean.
> A large group of them are in /usr/lib32.
> A while ago I got rid of all emulation programs (firefox-bin,
> mplayer-bin) and all of the emul-linux-* packages.
> I've been putting back via --usepkg everything revdep-rebuild comes up
> with but it doesn't help at all, so I've switched to looking at the
> raw "broken /usr/lib32/blah_calls (requires blah_so)";
> doing an 'equery belongs blah_calls' which usually brings up nothing,
> or a 64 bit application, then I manually delete the
> /usr/lib32/blah_calls.so file.
> This will get the job done (I believe), however is incredibly tedious.
>
> So, can I simply rm /usr/lib32/* ?
You probably want to run equery b /usr/lib32, and see what's still using
it. I have no 32-bit only packages here, but on a multilib profile
system (including mine), you will almost certainly find at least a couple
packages using it, including glibc and sandbox (from portage). This is
because they include both 64-bit and 32-bit components, to support 32-bit
stuff if you want to run it.
Having found the packages that use the dir, you can run equery f <pkg>, to
get a listing of files for the package, and see what each one uses in that
dir. Anything /not/ listed as being used by those packages /may/ be safe
to remove. However, my usual routine is rather more cautious. I move
stuff I'm not sure about to something like (in this case)
/usr/lib32.remove, and carry on using the system for awhile. If a month
or so later nothing has complained, then I go ahead and remove it.
Another alternative to running equery f and seeing what belongs to
each package, is to do something like this:
for file in /usr/lib32/*; do equery b $file; done
That takes a somewhat longer to process but is a bit more automated. Any
searching for... entry that doesn't have a corresponding package is a file
portage doesn't directly anyway know anything about.
Note that either way, some of those files might still be used by eselect
(generally symlinks in its case), or be otherwise useful files that weren't
installed by portage, but with a bit of sysadmin sense, you can figure out
if they are orphaned or useful, and delete the orphaned ones, keeping
anything useful, and *.remove-ing everything you're not sure about to see
if it's actually still used or not. In the context of revdep-rebuild,
however, particularly for 32-bit stuff which except for the multilib
toolchain isn't going to be critical for operation of a 64-bit system,
it's generally safe to say that any real *.so* files portage doesn't know
about are likely to be orphaned and therefore safe to remove, while any
symlinks to such files need further investigation. Native executable
binaries likewise. Watch out for config files and anything scripted,
altho normally those shouldn't be in lib32 anyway, but there may be
certain abnormal exceptions.
At one point I had a hard drive go bad, or rather, parts of it go bad,
due to overheating. At the time, I had /var and /usr on separate
partitions, with older backup versions of each. When part of the drive
went bad, however, it took only some of the partitions, and I ended up
running a system with a new /var (and thus portage database) and /, but
an old /usr. Thus the files on /usr didn't agree with what was in the
portage database. While I was able to remerge all the packages the
portage database in /var said were merged, thus getting all the right
files on /usr, that didn't take off all the old ones, and I had a LOT of
orphaned files. I used for loops like the one above to help me track
down what was supposed to be there and what wasn't, so I could remove it.
Thus, it's fair to say I have rather more experience dealing with this
than I'd like. =8^(
After that, I updated to a four-drive kernel md-RAID arrangement, with
all my critical stuff on RAID-6, so I can lose two drives at once without
loss of critical or system data. I also have a bit better cooling for
the drives, altho I'm not sure that would have helped in the situation
that took down the old one, an AC failure here in Phoenix, in the middle
of the summer, where the room itself was likely 50 C possibly hotter, so
who knows /how/ hot the drives got in the computer. Anyway, when I redid
the filesystems on the RAID layout, I kept everything that portage
normally installs stuff to on the same partition as its database (so /,
/var, and /usr are all on the same partition, and I split off /usr/local,
/var/log and the like instead), so when I image that partition for backup,
everything portage knows about stays in sync and I shouldn't have to worry
about at least /that/ sort of orphaning again. Lesson learned from
experience, I guess.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
gentoo-amd64@gentoo.org mailing list
^ permalink raw reply [flat|nested] 5+ messages in thread