SXDE 9/07 Installfest and the Work Around
By PotstickerGuru on Sep 21, 2007
Last week, I wrote about all the gory details about my recent salmon fishing trip up north in BC. I think I mentioned that I had also managed to bring along the latest Solaris Developer Express Release (SXDE 9/07) to upgrade a few machines while I was up there. In this edition of my blog, I thought it might be instructive to note some things I had to do with some platforms to get it working - not only for public consumption, but so that I'd remember what to check for in the next few revs of Nevada to see if those things changed.
Background on SXDE 9/07
For those of you who download and get Nevada regularly, this section is old stuff. But I find it instructive to give a broad picture, As I've seen it from the inside - on where SXDE came from. As far as I can recall, the existing SXDE release evolved from the original Solaris Express program. It's still basically the same thing, just re-branded Nevada (aka Solaris 11, aka Solaris Next, aka Open Solaris -sorta). The older Solaris Express was a roughly monthly or bi-monthly snapshot of stable bits for Solaris Nevada which is the next version of Solaris that is in development. Because of a typical 2-week build cycle for Nevada, the older Solaris Express was basically the most stable of each group of 3 - 4 builds that our volume developer program folks would push out for public download.
The SXDE rebranding did two things. First, it stretched out the interval to every 3 - 4 months for a developer release, which was more reasonable than every 6 - 8 weeks, since that's hardly enough time to evaluate the release itself and test compile a bunch of apps. The second thing SXDE did was to bundle developer tools installation into a new installation script that saves the end user from yet registering and downloading another wad of stuff with the compilers, NetBeans and all the other Sun Studio Tools.
Recently, some folks may have heard about Project Indiana - aka the new "Open Solaris." I'm stealing the "OpenSolaris" moniker in this blog just for the time being and I interchange it with Nevada - Solaris 11. But I should qualify for readers that the official "Open Solaris" will change and evolve as a new distribution under Project Indiana. The program is being run by in the Community and headed up by new Sun employee, and Former Debian Linux Guy, Ian Murdock. It's great to have Ian as the new project Team for "Open Solaris." His leadership in the Linux community in the early days gives him a perspective on the needs and wants of Linux users that many Enterprise Solaris Management folks don't have. I'm sure there are other blogs and message boards that Ian can personally respond about Project Indiana. But expect him to change and shape what is OpenSolaris now and take it to a more desirable place for endusers and developers alike. Also expect to have avenues of participation that can change the way Solaris gets distributed. This may be an opportunity to take a look-see at OpenSolaris.ORG.
Getting back to this next release of SXDE 9/07, we will find that it adds a few more features, fixes more bugs, and comes with a nice looking new GUI installer. It is based on Solaris Nevada build 70, but has undergone two more interations (build 70a and then finally build 70b) before getting the full product team endorsement to release.
Internally, before we release any version of Solaris, upper management likes to encourage all software engineers to download the pre-release bits and test it on presumably our own hardware. As part of our jobs, we already do quite a bit of sanity testing before the bits go out for every build. But being the engineers we are, most of us don't actually do the normal install that the regular users out there would use. Nope. We do the Big-Friggin' Update (aka BFU, aka Bonwick-Faulkner Update, aka Blindingly Fast Update). BFU is a process that basically flashes and clobbers the bits onto your running system (with some other cool technical details omitted) in just a few minutes.
Usually, BFUs are fast and friendly and before we know it, we've upgraded a system, making it ready for more Solaris development. And because we use BFU's, we probably don't do as much work on testing the actual installer our customers use and we avoid a lot of the idiosyncracies that exist only in the installer. So why not make this a standard? Well, BFUs aren't pretty when they don't complete safely or cleanly. Any good Solaris sysadmin worth his/her salt should be able to figure out how to recover. But for most users, this is probably an unexceptable risk/burden and so we do recommend using the actual installer, even though we don't use it ourselves. Just suffice it to say to, "Do as we say, not as we [Solaris engineering] do."
Upper Management aren't blind to this irony. Appropriately, they've tried to put their feet down and insisted that all internal engineers actually do an installation from optical media and file any bugs on the upcoming SXDE versions and fill out a feedback form. But this is high-tech corporate America. Management putting its foot down doesn't mean much in terms of threats; the stick simply doesn't work. Instead, they dangled a carrot of possible raffle for prizes to internal employees who complete an install and then fill out a survey. The carrot has been neither a sure-catch carrot (i.e. not everyone wins in a raffle), nor was it a fat carrot (i.e. the prizes weren't very expensive either). While I would have appreciated a new Sony TX-series ultra-portable notebook as a grand prize, the product team was giving away old junk, like an old Java tote-bag, or a whimpy 1XL tshirt from last year's trade show or maybe a baseball cap was all. Unbelievably, despite the dearth of good prizes, I found myself caught up in the Jackpot-Fever of the raffle even though I only fit 3XLT Tshirts!
For the first SXDE, I was announced the internal winner of the Most-Installfest-Submissions award. No gifts even got distributed (at least I never received any), except maybe I got a laser printable certificate in my emailbox, which I had to print out myself. Yeah, it's sort of hokey - but times are tough, and I'd rather keep the stock up from the days when it was just $3/share. But it shouldn't have been much of a surprise to folks that I would have the most. I have the most cheap x86 boxes of any engineer I know, except maybe for Brian Dowdy (i.e. think of us as "Hardware-Hos"). so, for this second\* SXDE Installfest, I again came out on top with Most-submissions. (\* We did have plans to do a second SXDE around the Nevada b64 timeframe, but decided to wait until b70.)
This time around, I did get some prizes. Like two XL Tshirts. I don't fit, but maybe in 10 years, my son will grow big enough, unless his younger sister out-eats and outgrows him. I also received a rich, corinthian leather notepad/portfolio thingy (say that with Ricardo Montalban's accent) which holds some paper and pens. I'm not sure what I would do with this since most everything I write these days goes through a keyboard. I didn't even use it to take notes on the installation issues I discovered. But if they gave me that tiny/mini Sony TX-series 2.7 lbs subnotebook w/ 2GB memory and 32GB of boot flash... maybe I'd double my efforts!
With any new version of Solaris, there's a debate as to whether to upgrade or do a fresh install. My testing philosophy is simply. I have spare disks around. For testing, I yank out the mission critical data, set that aside, stick a new disk inside probably with Solaris already on there, and then a) upgrade when I can, then b) after successful or unsuccessful upgrade, I reinstall from scratch.
Upgrade or Fresh Install?
For those folks that have done upgrades before, we know there are two major problems with upgrades. A) Not all things get upgraded. Some packages aren't removed and some files aren't replaced. Some new stuff doesn't get installed. There are ways to find out internally what the upgrade will clobber and add, but in essence, it gets complicated to find out what should have been upgraded but didn't. The only way to be safe is to do a fresh install. The other big problem is that B) the Upgrade is very slow. The installation console claims it may take 2 hrs or longer, but in reality, unless you have a honkingly-fast-storage and processor, the upgrade install takes as much as 6 hours or more to complete. Especially if you're trying to upgrade an older system. Typically, I can do a fresh install in just 40 minutes or less.
The solution I've come up with is to simply put all my data on partition slices which I'll preserve. Then do a fresh install on the root (/) slices. This helps save quite a bit of configuration and reinstallation of apps. In other words, I put most stuff on the /export and /opt slices and only clobber the root (/). The only problem though is that SXDE needs to clobber the devtools in /opt, and it clobbers the package tracking for all the extra value freeware I've added, so we can't really use the packaging mechanism to remove a package any longer. To re-install and configure all that stuff takes time again. I live with this solution since I don't usually remove freeware packages, and many I compile from scratch and don't install by pkgadd(1M). But this might be a dilemma for some. In which case, the upgrade path might be better. Regardless, I recommend keeping home-directory data on a separate slice and to preserve it.
This new SXDE presents some issues with upgrade or fresh install that folks should be aware of. A) the new GUI makes it easy to install from scratch, but before you realize you've clicked all the buttons, you may have skipped the steps needed to preserve partitions on your disk. If you'd like to take more time, and not use the new Dwarf Caiman installer, you may want to simply use the older installer (i.e. option 2: Solaris Express). B) The new SXDE installation has issues with older disk slicing and number and may not be able to upgrade you. This was supposedly fixed in build 70b, but you may still encounter this issue that the disk partitioning can't be upgraded and the GUI may only allow you to do a fresh install with fresh partitioning that will wipe your disk. The unsavoury solution is to rsync your data to another disk somewhere, do a fresh install, then rsync back. I have about 25 GB of data for myself and my wife at home. It takes about 1 episode of Stargate SG-1 to move that data off the install disk. This is still faster than doing an upgrade, and I've got scripts that restore my data and some server and network configuration too. Another option is to stick 2 disks in the box and mount it later. But I don't like the extra cost of 7Watts to power another drive. A single drive, and better yet, a single notebook drive, is what I prefer on my home system for improved acoustics and thermal power dissipation. Not to mention, I pay less for electricity with my systems always on.
Graphics Not Working for VIA Unichrome/CastleRock
SXDE and Solaris in general use Xorg. We're following the distro fairly closely these days and that's added support for more and more graphics adapters. But it's also dropped support. One area of support is for the older VIA CastleRock/Unichrome (CLE266 chipset and prior generations) onboard graphics. When I tell people internally that I actually use the onboard graphics, some scoff at me. They suggest I actually blow another 20+ Watts and get a cheap ATI Radeon S7000 or nVidia card (some which suck another 50+Watts by themselves). And maybe that would work. But there is a bug filed against this problem internally for VIA embedded graphics. I used to have a workaround for the VIA unichrome issue, which was to take the buggy S10u1 SUNWgraphics-ddx package and unbundle it, and just extract out the via_drv.so file and copy it into /usr/X11/lib/modules/drives/ and clobber the existing module. This worked through Nevada build60-something. But since build 63 or 65, that no longer has ABI compatibility. I now get core dumps. This is true even with S10 8/07. Luckily, there are cheap VIA c7/cn700 chipset boards these days that have Unichrome Pro graphics which are supported extremely well. I can't say that about the SiS Mirage graphics. I have an older SiS 741 chipset with Mirage graphics which worked okay with Xorg, around Nevada build 55 time frame (SXDE 1), but with the latest Xorg, the pixel quality at native resolution is really blurry, and on my Intel D201GLY mini-ITX board, the graphics are unusable beyond 800x600 pixels. However, with Fedora Core Linux and Windows, they've seemed to have solved both the VIA and SiS graphics issue in their version of X distro. My solution for now, is that these are relegated for headless/server use and not for home use. But for SXDE2, the GUI installer requires the graphics. Otherwise, you're back to booting option 2 - the old Solaris Express installer, which will fail or be unacceptable, at which time, I'd recommend just installing using the text console.
Many of us have been trying the new NWAM (NetWork Auto-Magic) feature. It's controlled through the SMF. You svcadm disable network/physical:default and enable the network/physical:nwam. This works well, I hear, from a number of folks. They all pretty much have a single primary ethernet wired interface and it's on a laptop that uses DHCP. This is where NWAM works now. But it seems like since build 60-something of Nevada, the folks support the standard DHCP for ethernet interfaces have fixed some long standing bugs. For years now, many of us inside guys have been complaining and filing RFEs against the ifconfig(1M) command in Solaris. Simply, it was moronic to ignore the standard DHCP fields for DNS under most conditions. Instead, we focused on getting DHCP to work inside our Sun-centric NIS environment. DHCP would work most of the time and plumb /etc/resolv.conf file and alter the /etc/nsswitch.conf files under the right NIS network conditions. But for some reason, it would rarely work when doing DHCP over a standard connection. Well, since b60-something, this appears to have been fixed. I'm not sure if the NWAM guys had a hand in this, but thanks to whomever. There are some outstanding issues still when it's a WiFi interface. For some reason, it may be a GUI interaction with the free inetmenu application folks are using and download from OpenSolaris.ORG. Not sure. But it used to work and plumb the routes on WiFi connections, but it may not with SXDE. If it isn't working, I've usually helped many folks get up and running for a session by a) check the routing using netstat -rn and seeing if there is a defaultroute. Next, I check to see if the /etc/nsswitch.conf file has hosts: and ipnodes: using the DNS nameserver. There should be a "dns" following "files" in the nsswitch.conf file. If not, you should be able to append to those lines and get it working. Please file a bug at the SXDE community site.
VIA c3 Panic on Shmem pagesize and re-init()
Okay, for those of you who love VIA c3 and enjoy running servers at 13 Watts total power with Solaris, well, better stick to S10 update 4 (8/07) or Nevada b65 and prior. We put something in around the b68 or b69 timeframe that I think, does some kind of dynamic shared memory page size and inquires with the system to set this. If I recall the bug report, the VIA c3 doesn't support this, so it panics. This was supposedly fixed and putback into build 72 of Nevada, but it seems to only work for newer Nehemiah based systems. If I run the latest SXDE on Samuel or Ezra cores, the panic is now fixed, but the init() crashes on fatal signal 9 and restarts a gazillion times for my epia 800 system. I've added comments to the internal bug about this where they claim b72 had the fix and I tried it and it was still no go. But hopefully, it won't be long before we have that available. But for your SXDE users with older Epia systems with VIA c3/non Nehemiah, please refrain from upgrading.
Older Intel 815 graphics - Newer ICH9 945 Graphics
I've tested SXDE on both an older Compaq box with 1GHz P3 and embedded 815 graphics. I used to have to stick an nVidia Riva TNT graphics board in there. (I got a half dozen of these older 16 and 32 MB AGP 2X cards, some low-pro for some AMD Geode bookpc systems I have) for just $5 from Compuvest.com. But they do add to the power profile of the box. So I try to remove the card and see if it works. Amazingly, it appears to now work with Intel 815 graphics, and I can save another 6 -10 watts steady state. I haven't tested the 815 graphics support on the older Intel OEM D815EEA and D815EEA2 boards, which I have a small stash of from other boxes, although, I did try around b69 time frame at it was still broken.
I have some older Intel Bearlake test systems for the ICH9 chipsets that have onboard 945 graphics as well, and SXDE works flawlessly. I have some older Dell 2001FP LCD monitors that can't handle true 60Hz refresh at 1600x1200 24-bit. I've either had to lower the bit depth to 16-bit or lower the resolution to non-native. The latest SXDE is pretty good and syncs up to 50Hz refresh at 24-bit native. This collaboration with Intel is going great as we're seeing more and more support for native Intel chipsets on our platforms.
Network Settings/IPfilters/IPSEC Upgrade from S10 and early Nevada
If you run SXDE1 (build 55b) or Solaris 10 update 4 (August/07) and you upgrade to SXDE 9/07, there is a pretty high change, if you were running IPSEC security, like Punchin, or you were using IPFilters, that the upgrade will hose your settings. Two things have changed. The IKE (internet Key Encryption) service as set by SMF requires a few configuration changes. If you were using IPSEC Punchin, which we use internally at Sun for tele-commuting access into Sun's internel networks, like I'm doing now, then this requires a bunch of changes. Most of the installation handles it for you, but the PunchIn packages we use must be upgraded to v 2.x and the certs need some upgrading to the latest. I had to pkgrm the old SUNWpunchin and affiliate certificate pkgs and reinstall the new ones. Before uninstalling, it's useful to run a /usr/local/bin/client_backup to back up the local certs. Luckily, the new service supports the older legacy backup, so a client_restore against the older certificate backup, will re-install and sync the keys up correctly. I usually test the punchin again, and if everything is kosher, I run client_backup again and save the new format of the cert-wad-of-stuff.
One issue folks may have with upgrading from S10 u4 or early is that for some reason, the /etc/ipf/pfil.ap file gets blown away sometimes. And without the presence of this file, the new SXDE gives all sorts of SMF start-up errors. They're basically harmless, but if you're like me and run your machines both for local access and for tunneled access, I run IPFilters and TCP Wrappers on all systems, even my laptop. The SMF warnings are disconcerting and even more worrisome if your filters aren't active. It's like streaking around in public inviting any evil spirit to give you an STD. Anyway, the simply solution is to login to some other Solaris box and copy over the /etc/ipf/pfil.ap file and reconfigure for your interface and reboot. The nasty messages go away, and hopefully, your ipfilters will report they are up and enabled, and your log file (if you log attempts at incursion) should show you that packets are being denied access.
Oh, and one more cool utility in SXDE 9/07 is the latest Network setting GUI in the administration tools for the Gnome Desktop. The only problem is that it doesn't properly set the /etc/nsswitch.conf file either. So no DNS, even though the GUI has a DNS server tab. Solution is the hand-edit the /etc/nsswitch.conf file again and put in dns for hosts: and ipnodes: then it should work.
Post Install - Post Login Setup
If rev'ving from an old version of Nevada or S10 and the home directory hasn't changed, the first time a user logs in, SXDE will actually spend a good minute perusing all the gnome files and what not and try to re-instate the old Gnome config you had, with the latest SXDE version of Gnome. Clearly, if you were using S10 Mozilla, and now you've got stuff in Firefox, that won't carry over quite correctly. Thurderbird will try to import settings over. But overall, the process can take upwards of 2 minutes while the screen sits there black and there's a small progress bar thingy that swings back and forth and doesn't actually tell you what the progress is. But I have yet to have the process fail. It can just take a hell of a long time - long enough to maybe go take a coffee or bathroom break, head into the garage to get a sledge-hammer, comeback, think about taking a sledge hammer to the machine. But don't do it. It will complete and hopefully, you'll be a more patient person for it. The next login isn't too bad. Of course, if you're on a QUAD core box with two sockets, this probably will never be a problem, since either, it'll happen very quickly, or you'll be running headless as a server anyways. But if you're like me and run older, slower, low-power boxes, then it can be a test of patience.
Brother HL-2040 Printer Installation
In SXDE 1, I had to do all sorts of tricks and installed CUPS freeware to finally getting printing to work. This was really disappointing because I saw that killer sale for the Brother HL-2040 again for $59 after rebate and couldn't help myself. I had my buddy buy one also for a grand total of 3 laser printers. 22 ppm monochrome, with a 1500 page cartidge is, well, dirt cheap.
Not with SXDE 9/07. I have finally retired the last Linux print server/internal backup server box in my house. I have one last box to retire and Linux will no longer run anything internally. That;s because I took the USB cable out of my laser printer, plugged it in, and while logged into Gnome, I got a pop-up notifying me that the printer was up and available and enabled. I opened the browser, went to a home page, and sent out a print job. Seconds later, the printer just works. This is now working with the USB subsystems for VIA, Intel, SiS and nVidia MCP chipsets on all my systems. Only issue is that I heard there's a Parallel port bug that prevents the OS from seeing any ECP/EPP ports. That's being addressed, maybe in b74 timeframe. But that's one old printer if you're still using Parallel. Even my old Epson 880 has USB. But it just ran out of ink, so I haven't tested it on Solaris. I'm just stoked that my Brother Laser printer is finally working and it does so transparently. So props to the Solaris printing folks upstairs for all their hard work. I still need to test my battery of Epson printers, but that will come in due spare time.
I sure there are lots more things open to improvement. I'll continue to re-install the next versions and keep testing. I'm still not quite over trauma of the 700+MB requirement for Solaris graphical install. But with memory and motherboards so cheap, I'm having a good retail therapy shopping for more hardware. Only what do I do with the old stuff? Everytime I look at my pile of old stuff, it's hard to say goodbye to some good friends that have served me well, and could still handle lots of tasks. I'd like to donate the stuff maybe, or perhaps try to work on a custom distro with small footprint and installer that uses less than 250MBs and uses XFCE or something like that. Or maybe in the future, that might be a goal of the new OpenSolaris distribution.