This is a few months old, but worth watching if you’re interested in IllumOS at all:
We ran Solaris 2.0 at the Visualization Lab just to become familiar with it. It would crash just sitting there with nobody logged in, running nothing but system daemons. I don’t think I really liked Solaris at all until 2.3, as I started to get more familiar with it.
I’ve been having some problems with the OpenIndiana oi_148 to oi_151a update, but only on one virtual machine in particular. Until today i’ve been stuck, until I thought to:
After that, the image-update went fine. I need to learn more of the options for pkg, apparently. I had skipped that before because my other OI machines did not have that non-sticky option set, and the upgrade worked there.
Today, I had to enable python and perl USE flags globally in /etc/make.conf. I guess Gentoo changed the default setting for these flags. Personally I like having the kind of built-in tools and scripts that these provide, so I turned them on. Plus, enabling these flags avoided having to rebuild dozens of ebuilds (I have a lot of stuff installed).
I can understand why the Gentoo devs did it (most people don’t need perl/python/ruby support embedded in Vim, for example), but I’m beginning to think there’s no way for me to keep up with changes, or if there is, I totally missed it, so everytime this changes I’ll be looking at Bugzilla and the Forums. Maybe there’s a way I can track these kind of USE flag changes on my own system, in a more obvious way then the output from eix-sync. I’ll have to look into it.
This is a gentoo problem I hadn’t seen before:
Turns out, I needed to build with “-introspection” in order to build it again with “introspection”. Or maybe I could just globally disable introspection, but not sure what that would change, it looks like a Gnome thing. As usual I ended up with lots of Gnome and KDE installed, and really I still just use Enlightenment everywhere. If it wasn’t Enlightenment, it would be Windowmaker or something similar.
I sometimes have a need to take down a Linux host “hard”, that is, without the normal shutdown scripts. Among other methods, I accomplish this with:
This is suboptimal (risks corruption), but it does the job. The hosts in this case have kernel modules that the normal “rmmod” would hang on forever, and since they have no console/ILO or IPMI or other power control I am forced to use this or some other trick to take down (reboot -f or sending a NOC person out on the floor are the other common methods, the latter being our last resort).
Because this immediately forces the kernel to reboot (assuming you have the “Magic SysRq” option in your kernel), using ssh becomes a problem, as the TCP connection dies without you getting a RST packet, so normal ssh and TCP timeout mechanisms apply, and it’ll take a few minutes for the host to come back up and issue a TCP RST in response to a keep alive message for that connection.
Now, every once in awhile I do something without giving it enough thought. That’s a kind way of saying I do something really dumb. Imagine, if you will trying to reboot a lot of machines via an “at” job. Further imagine that you decided to change your normal reboot/shutdown -r to the aforementioned sysrq-trigger trick.
Also interesting is that using sysrq-trigger doesn’t allow the at job to be removed from the queue before the machine is restarted, and will just say there until the job is allowed to exit normally.
I think you see what I did. Dumb. Thankfully there are a few seconds available between boot and when the job runs to remove the job from the queue.
Whenever I create a zone on Solaris, I have a couple of things I always seem to have to fix beyond the usual configuration. Since I don’t do it that often, I have to look them up repeatedly, so I thought I’d just put them in this post and maybe that’ll help me remember and I can just look them up in one place.
First, I always need to change the permissions on /dev/ptmx. Before you change the permissions to 666 on this STREAMs master clone device, the shell won’t have any terminal control, so:
Second, install SUNWuiu8 to get rid of an annoying message when you log in via ssh:
I think this is a missing dependency for SunSSH.
So,
I’ll add more as I think about it.
EDIT:
Sure enough, even with OpenIndiana 151a, I still need to change permissions on the /dev/ptmx device file.
The SUNWuiu8 problem is gone, though. It appears to already be installed now.
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:
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. 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 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:
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.
Note: the next part could help, but it’s far easier to use lafilefixer these days.
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 a command at a time 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.
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.