Recently in opensuse Category

This weekend I put together (mostly as it turned out) a new fileserver for home. The box that's currently pulling that duty is 9 years old and still working just fine.

However, 9 years old. I'm happily surprised that 40GB hard-drive is still working. Only 58,661 power-on hours, and all of 3 reallocated sectors. But still, 9 years old. There comes a time when hardware just needs to be retired before it goes bad in spectacular ways.

The system that is replacing this stalwart performer cost under $400 with shipping, which contrasts starkly with the sticker price on the old unit which was around $1400 back in the day. This system is based on the AMD E350 CPU. Underpowered, but this is a file-server and that ancient P4 is still keeping up. I have a Drobo that I'll be moving to this unit, which is where the bulk of the data I want to serve is being kept anyway.

As for the title of the post, this E350 mobo has a UEFI firmware on it. That's when things got complicated.

I was just catching up on email when I ran into this interesting tidbit: 

Up to now, openSUSE users had the choice of using openJDK (GPL with classpath exceptions) or Sun/Oracle's Java. The Sun/Oracle Java was licensed under the "Distributor's License for Java (DLJ)", which allowed Linux distributors to package and redistribute Sun/Oracle Java. Recently, Oracle announced that openJDK 7 is the new official reference implementation for Java SE7. They no longer see the need for the DLJ licensed Java implementation and so have retired that license.

openSUSE chooses to proceed with distributing the GPL licensed official reference implementation, openJDK. We will no longer distribute newer versions or updates of the now proprietary licensed Sun/Oracle JDK. Existing installations of the Sun/Oracle JDK are still licensed under the now retired DLJ.

openSUSE users who wish to continue using the Sun/Oracle JDK (including new versions thereof and updates) should now download directly from http://www.oracle.com/java. For now we keep the current sun-java packages (under the DLJ license) in the Java:sun:Factory project and will not update them anymore.

I suggest to document in the openSUSE wiki how to install the Sun/Oracle JDK version from Oracle under openSUSE.

Which is to say, Oracle is killing the license that allows OpenSUSE to provide Sun/Oracle Java as a part of the repo.

As a user of java apps in the line of my work, this deeply annoys me. What few management java apps work well on Linux (it's always a surprise when something does), seem to work best with Oracle Java not OpenJDK..

It probably won't be just OpenSUSE affected by this.

The Linux boot process, a branching chart. For the most part, the levels do not depend on column. LILO does not require EFI, nor does GRUB require BIOS. EFI and BIOS support are now included in both bootloaders. Yes, there is some simplification here. EFI is very featured, but hasn't been commonly exercised to its full extent. Eventually EFI could possibly replace GRUB/LILO, but that day hasn't come yet.

Pre-Boot Enviroinment
BIOS		EFI
POST Read bootable media Load Master Boot Record Execute MBR		POST Read bootable media Load the GPT table Mount the EFI system-partition Load EFI-drivers for the system Execute MBR
Bootstrap Environment
GRUB(v1)	GRUB(v2)		(E)LILO
Stage 1 loaded into MBR/EFI and gets executed by BIOS/EFI Stage 1.5 loaded by Stage 1, including critical drivers Stage 2, in the boot filesystem, executes Stage 2 loads the kernel	Stage 1 loaded into MBR/EFI and gets executed by BIOS/EFI Load first sector of core.img Continues loading core.img Loads GRUB config Loads the kernel		Stage1 loaded into MBR (or EFI by ELILO) and executed by BIOS/EFI Stage 1 loads the first cluster of Stage 2, and executes. Loads LILO information. Loads the kernel
Kernel Load
The kernel uncompresses into memory If configured, the kernel mounts the Initial Ramdisk, which contains needed modules to load the rest of the OS Mounts the root filesystem, loading any needed modules from initrd Swaps / from initrd to the actual root filesystem Executes the specified init process
UID 1 process
Initd	Systemd	Upstart	Launchd
Checks /etc/inittab for loading procedures Runs scripts specified by inittab Mounts needed filesystems Loads needed modules Starts needed services based on runlevel Finishes setting up userspace	Reads /etc/system.conf Mounts needed filesystems Loads needed modules Starts services as needed	Runs startup events listed in /etc/events.d based on runlevel. Loads needed modules Mounts needed filesystems Starts needed services	Reads /etc/launchd.conf for config details Reads /etc/launchd.plist for per-driver/service details

I did this because Things have Changed from the last time I really studied this. Back when I started it was BIOS, LILO, and Initd. I never did bother to wrap my head around Grub, mostly because the automatic tools have gotten a lot better so knowing it just to install isn't needed, and I haven't had the right kind of boot problems where I'd learn it through troubleshooting. I've also yet to run into EFI in the wild (I think...). Now that OpenSUSE is actively considering moving over to SystemD and Ubuntu having thrown initd over the side some time ago in favor of Upstart, it's time to revisit.

I'm still fuzzy on SystemD so that's probably wrong.

I somehow missed this when it first came out, but there is a move a-foot to create a rolling-update version of OpenSUSE. The announcement is here:

http://lists.opensuse.org/opensuse-project/2010-11/msg00206.html

In the last couple of days the repo has been created and opensuse-factory has been awash in requests to add packages to it.

What IS this thing, anyway?

It's like Factory, but with the stable branches of the packages in use. For instance if OpenSUSE 11.4 releases and a month later Gnome 3.0 drops, 11.4 will still be on whatever version it shipped with but OpenSUSE Tumbelweed (the name of this new rolling-updates version) will get it. The same applies to kernel versions. 11.4 will likely have 2.6.37 in it, but 2.6.38 will drop pretty soon after 11.4 releases.

Is this suitable for production?

Depends on how much testing you want in your packages. The order of tested-stable of SUSE versions from least to most is:

1. Factory (breaks regularly!)
   
2. Factory-Tested
3. Tumbleweed
4. OpenSUSE releases
5. SLES releases (long term support contracts available)
   

Factory-Tested is also pretty new. It's a version of Factory that passes certain very specific tests, so you're much less likely to brick your system by using it over Factory itself. It will have bugs though, just not as many blockers.

There are some usages where I'd be leery of OpenSUSE releases just from code quality and support considerations, and Tumbleweed would be nearly certain to be rejected. And yet, if your use-case needs cutting edge (not bleeding edge) packages, Tumbleweed is the version for you.

Right now it looks like determining which packages get updated in Tumbleweed will be determined by the project maintainers. For the Gnome example, they have a Devel and Stable branch in their repo and it will be the Stable repo that gets included in Tumbleweed. Find a bug? It'll get reported to the repo-maintainer for that package. It may get fixed quicker there, or not. Tumbleweed users will help the OpenSUSE releases be more stable by providing testing.

Personally, I'll be sticking with the Releases version on my work desktop, since I need to maintain some stability there. I just might go Tumbleweed on my home laptop, though. 

I've been looking for a new laptop. I finally found one, Dell had a sale on their Studio 15 line. This is a Core i5 laptop with all the niftyness I wanted. I also purchased a new 320GB hard-drive for it. Why? So I could put the Dell supplied one, with its pre-built Win7 install, into a baggie for later use if I so chose, and so I could get openSUSE onto it without mucking about with resizing partitions and all that crapola.

I did what I could to make sure the components were Linux compatible (Intel wireless not Dell, that kind of thing), but some things just don't work out. This is a brand new laptop with a brand new processor/chipset/GPU architecture, so I planned on having at least one thing require several hours of hacking to get working. This is the price you pay for desktop-linux on brand spanking new hardware. I, at least, am willing to pay it.

And pay I am. I installed OpenSUSE pretty simply, or at least it started there. It got to the first reboot and got a black screen of nothingness. Watching post it was pretty clearly a kernel video handling problem. Some quick googling identified the problem:

OpenSUSE 11.2 uses the 2.6.31 kernel. This laptop uses an intel 4500MHD GPU. Support for which was introduced in 2.6.32, and greatly refined in 2.6.33. What's more, it uses Kernel Mode Setting Direct Rendering Management, support for which was introduced in 2.6.32. All this means is that 2.6.31 simply can't support this video GPU at anything like reasonable speeds.

OpenSUSE 11.3 (currently in a very buggy Milestone 3 release, soon to be M4) has a 2.6.33 series kernel. But I don't want to be buggy. So...

Time to compile a kernel!

Because I've done it before (a LOT), kernel compiles do not scare me. They take time, and generally require multiple runs to get right, so you just have to plan for time to get it right. So I booted to the OpenSUSE 11.2 Rescue System, followed these instructions, and got into my (still half installed) file-system. I plugged it into wired ethernet because that's hella easier to set up from command-line, and used yast to grab the kernel-dev environment. Then downloaded 2.6.33 from kernel.org. I had to grab the /proc/config.gz from a working x86_64 system, so I pulled the one from my 11.2 install here at work, threw it into the kernel-source directory, ran 'make oldconfig', answered a bajillion questions, and tada. make bzImage; make modules; make modules_install ; make install ; mkinitrd -k vmlinuz-2.6.33 -i initrd-2.6.33, and a bit of Yast GRUB work to make certain Grub was set up right, and reboot.

Most of the way there. I had to add this line to /etc/modprobe.d/99-local:

options i915 modeset=1

Which got me enough graphics to finish the openSUSE install, and get me to a desktop. I don't yet know how stable it is, haven't had time to battletest it. I probably need updated x.org software for full stability. I did get it up long enough this morning to find out that the wireless driver needs attention; dmesg suggested it had trouble loading firmware. So that's tonight's task.

Update: Getting the wireless to work involved downloading firmware for the 6000 from here, dropping the files into /lib/firmware, and rebooting. Dead easy. Now, Suspend doesn't work for some reason. That might be intractable, though.

It's time for another openSUSE survey! If you're an openSUSE user (or even a user of SLES/SLED) it's a good idea to take this thing. They set development priorities based on these surveys, so if you have an area that needs buffing up this is the place to tell them. Or if you want to tell them 'works great!' this is where you do it too.

http://www.surveymonkey.com/s/6MJYV7T

Virtualizing the desktop is something of a rage lately. Last year when we were still wondering how the Stimulus Fairy would bless us, we worked up a few proposals to do just that. Specifically, what would it take to convert all of our labs to a VM-based environment?

The executive summary of our findings: It costs about the same amount of money as the normal regular PC and imaging cycle, but saves some labor compared to the existing environment.

Verdict: No cost savings, so not worth it. Labor savings not sufficient to commit.

Every dollar we saved in hardware in the labs was spent in the VM environment. Replacing $900 PCs with $400 thin clients (not their real prices) looks cheap, but when you're spending $500/seat on ESX licensing/Storage/Servers, it isn't actually cheaper. The price realities may have changed from 12 months ago, but the simple fact remains that the stimulus fairy bequeathed her bounty upon the salary budget to prevent layoffs rather than spending on swank new IT infrastructure.

The labor savings came in the form of a unified hardware environment minimizing the number of 'images' needing to be worked up. This minimized the amount of time spent changing all the images in order to install a new version of SPSS for instance. Or, in our case, integrating the needed changes to cut over from Novell printing to Microsoft printing.

This is fairly standard for us. WWU finds it far easier to commit people resources to a project than financial ones. I've joked in the past that $5 in salary is equivalent to $1 cash outlay when doing cost comparisons. Our time management practices generally don't allow hour by hour level accounting for changed business practices.

There is an ongoing thread on opensuse-factory right now about the announcement to ditch SaX2 from the distro. The reason for this is pretty well laid out in the mail message. Xorg now has vastly better auto-detection capabilities, so a tool that generates a static config isn't nearly as useful as it once was. Especially if its on a laptop that can encounter any number of conference room projectors.

This is something of the ultimate fate of Xwindows on Linux. Windows has been display-plug-n-play (and working plug-n-play at that) for many, many years now. The fact that XWindows still needed a text file to work right was an anachronism. So long as it works, I'm glad to see it. As it happens, it doesn't work for me right now, but that's beside the point. Display properties, and especially display properties in an LCD world, should be plug-n-play. 

As one list-member mentioned, the old way of doing it was a lot worse. What is the old way? Well... when I first started with Linux, in order to get my Xwindows working, which was the XFree86 version of Xwin by the way, I needed my monitor manual, the manual for my graphics card, a ruler, and a calculator. I kid you not. This was the only way to get truly accurate ModeLines, and it is the ModeLines that tell Xwindows what resolution, refresh rate, and bit-depth combinations it can get away with.

Early tools had databases of graphics cards and monitors that you could sort through to pick defaults. But fine tuning, or getting a resolution that the defaults didn't think was achievable, required hand hacking. In large part this was due to the analog nature of CRTs. Now that displays have all gone digital, the sheer breadth of display options is now greatly reduced (in the CRT days you really could program an 800x800x32bit display into Xwin on a regular old 4:3 monitor, and it might even have looked good. You can't do that on an LCD.).

In addition, user-space display tools in both KDE and Gnome have advanced to the point that that's what most users will ever need. While I have done the gonzo-computing of a hand-edited xwindows config file, I do not miss it. I am glad that Xwindows has gotten to this point.

Unfortunately, it seems that auto-detect on Xwindows is about as reliable as Windows ME was about that. Which is to say, most of the time. But there are enough edge cases out there where it doesn't work right to make it feel iffy. It doesn't help that people tend to run Linux on their crappiest box in the house, boxes with old CRTs that don't report their information right. So I believe SaX2 still has some life in it, until the 8 year old crap dies off in sufficient numbers that this tool that dates from that era won't be needed any more.

Yesterday I upgraded my work desktop to openSUSE 11.2 from 11.0. I'd skipped 11.1 because upgrading (rather than reformat/reinstall) is always a lot of work. This proved to be no exception. Even though I was involved with the milestone builds for openSUSE, I didn't have the ability to test my guaranteed-to-have-problems desktop.

I had two problems:

1. The XWindows hot-plug support for input devices just plain doesn't work on my system. This was introduced in 11.1, so that would have bit me then.
2. VMWare Workstation just wouldn't compile the modules. The 11.2 kernel is too new.

I've managed to solve both problems. The first was solved by putting my old (backups are your friend!!) xorg.conf file into play and adding one line in the ServerFlags section to tell it to not bother auto-adding input devices. The second involved installing 6.5.3 instead of 6.5.2, and using a bit of crowbar-fu to make it fit. 6.5.2 just wouldn't work, where 6.5.3 required some special handling.

I don't know why the 'evdev' stuff in xorg is failing on me. It's on my list to figure out, but as I have a working config at the moment that's kind of low priority. But that needs fixing, since 11.3 will most assuredly reintroduce that fault.

VMWare.... reportedly version 7 works without a hitch. But I can't have that yet, so I had to get 6.5 in somehow. The crowbar I mentioned was killing certain processes the vmware installer spawns to compile the kernel modules it requires. Once those were ruthelessly murdered, the installer completed and it would work. Clearly, I have to be leery of kernel updates until I can use 7.

Other than some theme tweaks that I needed to redo, this was the cleanest upgrade I've had. All the Gnome stuff worked right out of the gate, which is a first. In the past I've had to blow away most of my Gnome configs and restart from scratch. I'm glad those bugs have been ironed out.

One of the things I have missed when Novell went from SLE9 to SLE10 was the lack of a machine name in the title-bar for YaST. It used to look like this:



With that handy "@[machinename]" in it. These days it is much less informative.



If you're using SSH X-forwarding to manage remote servers, it is entirely possible you'll have multiple YaST windows open. How can you tell them apart? Back in the 9 days it was simple, the window told you. Since 10, the marker has gone away. This hasn't changed in 11.2 either. I would like this changed so I put in a FATE request!

If you'd also like this changed, feel free to vote up feature 306852! You'll need a novell.com login to vote (the opensuse.org site uses the same auth back end so if you have one there you have one on OpenFATE).

Thank you!