Kirk Lowery <empirical.human...@gmail.com> posted e74dfca60906040548r3b0c1c89sf73c9f5e47119...@mail.gmail.com, excerpted below, on Thu, 04 Jun 2009 08:48:13 -0400:
> I have a dual Opteron box that has successfully run a "nomultilib" > 64-bit only system for years. For various reasons, the box had not been > updated for a long time. I did a major upgrade over several days, > incrementally. Somewhere along the way, some ebuild clobbered my /lib > symlink to /lib64. My profile is "nomultilib" and my global USE flags > include "-multilib". I discovered the problem when I tried to restart > one of my servers, restored the symlink,and everything works fine. Happy > ending. > > My question: I have all the portage logs from the upgrade. Is there some > way I can determine which ebuild first changed the symlink? I need to > determine whether there is a bug in that ebuild, or it was simply a > glitch because of the massive set of upgrades. In the first case, I'd > like to file a bug on that package. On the other hand, it may not be > worth the time and effort. > > But I'm willing to devote a couple of hours of research to this in the > community interest. Very interesting. FWIW, the lib-lib64 symlink has flipped a time or two over the years, depending on what stage tarball the base install came from and possibly depending on the baselayout version. Thus, I'd investigate baselayout first. (Added later:) Also see http://bugs.gentoo.org/show_bug.cgi?id=132135, and check xorg and glibc (bug 122274) as well. equery belongs (with equery being part of gentoolkit) would be helpful in this sort of situation in /most/ cases, but here I'm not so sure, since a package is said to "own" a directory if it has any files in it, and portage only removes it on uninstall if there's nothing left in it after it removes the files the uninstalled package owns, thus saving the dir if other packages own it or if there's orphaned or non-package files in the dir. Since we're talking about the major /lib and /lib64 dirs here, a larger number of packages than normal are likely to own them. At least it's not /usr/lib and /usr/lib64 we're talking about, as a HUGE number of packages will own them! Still, you /might/ find something if you look for those that use the symlink form, since those should be far fewer and the package rather out of the ordinary. At least here, nothing reports the symlink form, and baselayout doesn't own either dir but openrc owns /lib64. However, as the openrc clue will indicate to many, I'm using ~amd64 keywords and thus baselayout v2 (2.0.1 to be exact), so that's not going to be representative of a stable amd64 baselayout v1 installation (which doesn't use openrc as it's effectively both packages in one) at all. But I doubt that'll turn up anything. Something that /might/ turn up something would be grepping the portage logs for references to /lib. Of course, depending on the grep, you may get ALL /lib references including the ones in /usr, both the plain lib and the lib64 versions, and even /usr/libexec and private lib subdirs such as /usr/kde/3.5/lib or whatever, so you may have to play with the grep/search a bit to reduce the number of false positives. For various technical reasons, such system-wide changes are often specifically scripted, outside the usual portage install uninstall operations, so it's possible you can trim the search by throwing in a reference to rm, as well. Meanwhile, I read the dev list and someone happened to mention something that sounded very much like what you are saying, a bug due to a removed /lib or /lib64 symlink. My eyes perked up (ears perked up is the usual phrase, but I was reading not listening in this case) at that, but it was merely a passing reference with basically no additional information, IIRC not even a bug number I could look at, so I haven't the foggiest whether it's actually related to this or not, nor do I remember now which thread or any other context, so finding who it was to mail them and ask would be difficult. It's really rather frustrating. However, that does indicate that there's a good chance they already know about it. Thus unless you're seriously curious (as I imagine I would be, when such things happen I want to know why and how, in ordered to determine how likely they are to occur again!), you might just decide they've probably caught the bug already based on the above, and leave it at that. Finally, if you're still interested in investigating the matter and given that we now know there's likely a bug filed on it, you can try searching filed bugs. In fact, I'm already curious enough about it to do one search... On Gentoo bugzilla I used the search "ALL /lib symlink", and came up with the above listed early bugs (at the "added later" note), but nothing as recent as I recall that dev list reference being. So I don't know... But the other possible method, assuming not /too/ many packages were updated and/or that you search against the system-wide packages like baselayout, glibc, gcc, xorg-server, etc that are most likely to cause the problem, first, and leave say codecs and such unlikely candidates for later, would be to do an ALL bugzilla search against each one, checking the bugs filed in say the last three months, and see what you come up with. If you figure out what it was, please do post an update, and/or link the bug or whatever. I'm curious, and as I said, as any good admin upon seeing an unsolved mystery such as this, wonder at the possibility of it hitting here, even if it's reasonably unlikely given that on ~amd64 and updating generally a couple times a week, I'm likely long past any danger. -- 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
