eldergods.org

Yesterday, via the excellent Gentoo Bugzilla, I came across a reference to a tool for Gentoo I hadn’t seen before, one that would have come in handy before. It came up because I was trying to emerge a new amarok, and the build was unable to find libpcreposix.la… the new libpcre doesn’t include that file, but there was still a reference to it in something amarok needed.

The ebuild is called dev-util/lafilefixer, and to run it:

lafilefixer --justfixit

Whoever put this together has now helped me a great deal… I had literally hundreds of .la files that it updated. Plus it fixed amarok and let me complete my emerge update.

The thing I like most about Gentoo is the extraordinary flexibility that portage allows to make a system the way you want.   Every once in awhile, I find something annoying however (this happens on every operating system, you’re hearing about this one because it was just the most recent).   Today’s case in point:  I found that several things depending on libselinux.so.1 despite my having “-selinux” in my global USE flags, and selinux disabled in the kernel.   Because one of the packages that depends on that library is coreutils (which includes mv, cp, ln, and many other things you can’t afford to be without.)

How did this happen?  Because my /var/lib/portage/world file has a lot of packages in it that don’t really need to be there (they should be pulled in as dependancies of packages I do want, not in the way I have them.)   When I was migrating to the this box, instead of just looking at the few hundred packages in world, I grabbed a list of everything I’d compiled, and used that to build my new box.   One result of that is that sys-libs/libselinux got compiled.  (At least, I think that’s how it happened.)   I noticed but didn’t think it was going to be a problem.  However, for some ebuilds (coreutils being the most important to me), if the selinux header files are installed on the box, the configure script detects files like /usr/include/selinux/flask.h and proceeds to include selinux support.   Then you will find that /bin/cp and many other critical utilities are linked against libselinux.so.1, so you can’t remove the sys-libs/libselinux, and since the USE flag has no effect other than changing RDEPEND in the ebuild, you’re stuck.   Catch-22, almost.

Today I finally resolved to fix this, because I got annoyed, and because sys-libs/libselinux is hard-masked after my latest sync (as a result of the sync and having to update my profile with eselect).

The first part, fixing coreutils is pretty easy:

euse -D selinux
mv /usr/include/selinux /usr/include/selinux-save
emerge -av coreutils
emerge -C libselinux
rm -r /usr/include/selinux-save

Unfortunately, after that… you are still stuck.   The coreutils will work, but I was left with a number of packages that revdep-rebuild reports as missing libselinux.so.1… furthermore they all die when trying to link against libselinux:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lselinux

Ah, portage, why are you so cruel to me?    The above example is from gnome-terminal.  Good thing I still use xterm.

So, what to do?   I’m not kidding, this is basically it, in one line form:

find /usr/lib64 -name '*.la' -print | xargs grep selinux | cut -f1 -d: | sed -e 's#^./##g' | xargs equery b | awk '{print "="$1}' | sort -u | xargs emerge

Built that up once I realized that the *.la files still contained references to the libselinux (-lselinux).  Basically, it searches for all the .la files that contain references to selinux.   .la files are just text files that control the linking process, either as part of libtool or the compile-time linker. My command above just uses some rather lame shell tricks to run emerge against all the packages those files belong too.

Even after that was complete, I still had libnss3.so.12 breakage to contend with, but at least revdep-rebuild was working at that point (not breaking on every ebuild it found missing libselinux.so.1).    Frustrating.

I hope this saves someone some damn time, somewhere.

Update: you may want to look at lafilefixer, which is a simpler way to fix this problem.

The Case of the 500 mile email limit

This actually seems legit to me, in all the particulars.  I want it to be true, anyway.

So awhile ago, I got greedy and tried to install a 400GB IDE drive in a Sunblade 150 I’d got for cheap. Those of you who are more familiar with that hardware than I was (or am, really), will already be laughing at what a stupid idea that was. For those of you who don’t know, it can only address about 138GB per drive. The math is out there, but basically it’s a limitation of the IDE controller… and doesn’t apply to SCSI and FC drives in any of the Sun boxes, which is probably why this never occurred to me.

So… I backed off that plan and installed a pair of 120GB drives.  Now the system won’t boot.  And the console is, shall we say, unresponsive. I live a charmed life, I tell ya.

As a result, I have since collected a couple of other old Sun workstations via Ebay and the employee purchase program at work (which are basically “worthless”, like $65), and even an old Pentium 4 for Solaris x86.   So I’ve got the gear, but I haven’t had time to continue with any but the most cursory examinations of OpenSolaris.   I got 2 of them booted up with ZFS root on fairly recent versions of Nevada.   Waiting for the SPARC release of Indiana to be readily available.

In the meantime, I thought I might work on some of my other Solaris related projects.

Sometimes I wake up to find that the cursor on my workstation has disappeared.   And it doesn’t seem to be simply invisible, it’s actually not interacting with the desktop in any way.   I can still see the mouse in the list of enumerated USB devices.   Generally the keyboard is still working.

One suggestion I keep running across in my normal google searches is to disable HWCursor in xorg.conf.   Messed around with that for a few days.

After a lot of tests, it turns out that killing xscreensaver fixes the problem…. no need to restart X.

Lately, the problem has stopped happening, so I am considering that an update to x11-misc/xscreensaver may have fixed the problem.

Recently, a friend contacted me about recovery of a Solaris box he had made a bit of a mistake on. The problem was, he had moved everything from / into a subdirectory of /, let’s call it /cores for our purposes here. Commands wouldn’t work. He had a running /sbin/sh shell but that was it…. so shell built-ins were all he could do e.g. “echo *”. We fixed it pretty quick, with only minor residual problems, but I thought I’d put down the method here in case it helps someone sometime.

The first problem is that libraries are no longer found along their proper paths…. libc.so is the first problem. That’s easily fixed, however.

# export LD_LIBRARY_PATH=/cores/usr/lib:/cores/lib

That’s the simple part, I’m sure most people know the LD_LIBRARY_PATH tricks to force searching for libraries in other directories. The part that I don’t think people get is… once you’ve done that “ld.so.1″ (the runtime linker) is still in the wrong place. ld.so.1 is responsible for using the LD_* variables in the first place, among the many other wonderful things it does. So running commands from, for example, /cores/usr/bin is still impossible, at least in the standard way.

The second and final trick you need to fix this is to use ld.so.1 to “run” the executable. So, this fails:

# /cores/usr/bin/mv /cores/* /
mv: Cannot find /usr/lib/ld.so.1
Killed

But this allows you to run a command like you’d expect:

/cores/usr/lib/ld.so.1 /cores/usr/bin/mv /cores/* /

Turns out, you can use “ld.so.1″ as an “interpreter” of sorts for executables on some flavors of Unix. At least Solaris and Linux, but I would not be surprised if this works elsewhere, I simply haven’t tested it. On Linux, for example, you would use something like:

/lib/ld-linux.so.2 /bin/ls

To run “ls” in this fashion.

The lesson, boys and girls, is to know your runtime linker, it may save you one day.

One of the tools I build on new unix boxes after I get a toolchain of some kind (vendor or GNU) is invariably emacs.

I’ve been working on Solaris 10 more lately, and found that emacs wouldn’t build, and I found that odd… clearly other people had got it to build.

The interesting bit is that it’ll build if you use the right options, but it’ll crash when it exits. I was puzzled by this for awhile, but eventually found the answer on the tubes of the interweb. Unfortunately, I’ve had to recompile it now several times, both at work and home, and I keep having to rediscover this little platform-specific tidbit. Hopefully now that it’s posted here I’ll remember.

I gather than GCC 3.3.x puts some zero-initialized variables in the .bss segment, and that’s a problem with Solaris (at least on SPARC), so the answer is to add “-fno-zero-initialized-in-bss” to $CFLAGS before configure.

I’m still working out how to compile this with Studio 11 from Sun, I’ll update this when I remember the changes necessary.

Just got back from Linux World in San Francisco (actually, show ended on Thursday but I hung out until the 19th to visit friends.) Good show, but 6 days is a recent record for me being away from home, and it’s good to be back.

I focused on the HPC and kernel development tracks while I was there. In particular, I have several new things to experiment on that I saw there.

For starters, it became clear that I should probably get an AMD-based system for my OpenSolaris experiments. The demo machine I saw there with OpenSolaris with a Brandz CentOS lx zone on it seemed like a really decent machine, and while I’ve always liked SPARC, maybe it would be good to have both.

For the meantime, I will actually be playing with opensolaris on VMWare. Virtualization has been a pretty big topic lately, and at the conference I talked to SuSE (who’s distributing Xen), XenSource, VMWare (which I’ve been using since it was first available, and am currently using at work and at home), SWSoft (makers of OpenVZ/Virtuozzo) (which I’d managed to never hear about before somehow.)

I’ll have more to say about what I saw there. Next time I may even take pictures.

With a full make clobber that it has to do on the source tree before it can start to compile, the OpenSolaris nightly build takes a long time:

(5) mcclung@dogstar: time nightly ./opensolaris.sh
40724.25u 7185.90s 15:02:27.12 88.4%

This is 5.11 svn_38. It’s faster in an untouched OpenSolaris tree, I think, I will have to test that as well. Even with all the other stuff I compiled for /usr/local during the first build, it only took 11-12 hours.

I’m assuming we’re still somewhat limited by the 650MHz CPU. I don’t think it’s using that much RAM, and I don’t see that we’re swapping (machine has 1GB of RAM.) The real limit is probably disk I/O, but I’ll have to verify that.

Recently, I bought a Sunblade 150 off of Ebay to experiment with OpenSolaris. I considered getting another PC specifically for this project, but eventually my nostalgia for Sun SPARC gear won out and I got it… it wasn’t even that expensive. I did end up replacing the RAM and adding a second IDE drive to it, which all seems to be working fine. I had earlier tried to get OpenSolaris working on a Sun Ultra 10 someone has on semi-permenent loan to me. With only 128MB of RAM it didn’t seem to want to boot SunOS 5.10 or 5.11 svn_16 (although it runs Gentoo just fine, if slowly). Between that and having a couple of 9GB drives in it, that wasn’t an ideal platform.

I’m hoping, as time goes on, to become more familiar with the internals of OpenSolaris. I had some exposure in a couple of classes, mostly the SunOS 5.5.1 device drivers class I took way back in 1996. If nothing else, this will give me more practice on Solaris features that became available in SunOS 5.10, such as Dtrace

My first project is to time the compile of the complete system using the nightly command. I timed it before, but it wasn’t a fair test because I was compiling several things at the same time, as sort of a stress test of the system after I replaced all the memory. I’ll post the results here.