Monday, February 08, 2010

OpenSUSE Survey

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.

Labels: ,

Tuesday, January 05, 2010

Desktop virtualization

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.

Labels: ,

Wednesday, December 02, 2009

OpenSUSE depreciates SaX2

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.

Labels: , ,

Wednesday, November 25, 2009

Upgrading woes

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.

Labels: ,

Tuesday, September 01, 2009

Pushing a feature

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:

The old YaST titlebar

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

The new YaST titlebar

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 login to vote (the site uses the same auth back end so if you have one there you have one on OpenFATE).

Thank you!

Labels: , ,

Monday, August 24, 2009

Trying KDE

In light of the announcement that openSUSE 11.2 and later will have KDE as the default desktop, I installed milestone 6 of 11.2 (barely beta quality, but much improved from earlier Milestones) and had a look at KDE for the first time since, oh, SLE9. I should further note that the Slackware servers I've run at home since college have had GNOME by preference pretty much since Gnome came available.

My first reaction? It probably matched what a lot of long-time Windows users had when they saw Vista for the first time and wanted to do something that wasn't run a web browser:
Dear God, I can't find anything, and none of my hotkeys work. THIS SUCKS!
In time I calmed down. I installed gnome, and lo it was good. I also noted certain settings that I needed on the KDE side. I switched back and explored some more. Found out where they kept the hotkeys. Found out where the sub-pixel hinting settings were hiding. This made my fingers and eyeballs happier.

Now that I've tried it for a while, in fact I'm posting from it right now, it's not that bad. Another desktop-dialect I can learn. I've gotten over that initial clueless flailing and have grasped the beginnings of the basic metaphor of KDE. I still prefer the Gnome side, but we'll see where I go in the future.

Labels: ,

Wednesday, June 24, 2009

Why ext4 is very interesting

The new ext4 file-system is one I'm very interested in, especially since the state of reiserfs in the Linux community's gestalt is so in flux. Unlike ext3, it does a lot of things nicer:
  • Large directories. It can now handle very large directories. One source says unlimited directory sizes, and another less reliable source says sizes up to 64,000 files. This is primo for, say, a mailer. GroupWise would be able to run on this, if one was doing that.
  • Extent-mapped files. More of a feature for file-systems that contain a lot of big files rather than tens of millions of 4k small files. This may be an optional feature. Even so, it replicates an XFS feature which makes ext4 a top contender for the MythTV and other linux-based PVR products. Even SD video can be 2GB/hour, HD can be a lot larger.
  • Delayed allocation. Somewhat controversial, but if you have very high faith in your power environment, it can make for some nice performance gains. It allows the system to hold off on block allocation until a process either finishes writing, or triggers a dirty-cache limit, which further allows a decrease in potential file-frag and helps optimize disk I/O to some extent. Also, for highly transient files, such as mail queue files, it may allow some files to never actually hit disk between write and erase, which further increases performance. On the down side, in case of sudden power loss, delayed writes are simply lost completely.
  • Persistent pre-allocation. This is a feature XFS has that allows a process to block out a defined size of disk without actually writing to it. For a PVR application, the app could pre-allocate a 1GB hunk of disk at the start of recording and be assured that it would be as contiguous as possible. Certain bittorrent clients 'preallocate' space for downloads, though some fake it by writing 4.4GB of zeros and overwriting the zeros with the true data as it comes down. This would allow such clients to truly pre-allocate space in a much more performant way.
  • Online defrag. On traditional rotational media, and especially when there isn't a big chunk of storage virtualization between the server and the disk such as that provided by a modern storage array, this is much nicer. This is something else that XFS had, and ext is now picking up. Going back to the PVR again, if that recording pre-allocated 1GB of space and the recording is 2 hours long, at 2GB/hour it'll need a total of 4 GB. In theory each 1GB chunk could be on a completely diffrent part of the drive. An online defrag allows that file to be made contiguous without file-system downtime.
    • SSD: A bad idea for SSD media, where you want to conserve your writes, and doesn't suffer a performance penalty for frag. Hopefully, the efstools used to make the filesystem will be smart enough to detect SSDs and set features appropriately.
    • Storage Arrays: Not a good idea for extensive disk arrays like the HP EVA line. These arrays virtualize storage I/O to such an extent that file fragmentation doesn't cause the same performance problems as would a simple 6-disk RAID5 array would experience.
  • Higher resolution time-stamps. This doesn't yet have much support anywhere, but it allows timestamps with nanosecond resolution. This may sound like a strange thing to put into a 'nifty features' list, but this does make me go "ooo!".

Also, as I mentioned before, it looks like openSUSE 11.2 will make ext4 the default filesystem.

Labels: , ,

Monday, June 15, 2009

openSUSE 11.2 milestone 2

I'm doing some testing of openSUSE. Pitching in, getting my open-source groove on. One of the new things is decidedly minor, but it makes good eye-candy. They have a new title font!

New title font


Also, as of milestone 2, ext4 is the default file-system.

Labels: ,

Tuesday, October 28, 2008

The gift of security

Last Christmas my parents bought me a 4GB IronKey. This is a nifty little device! And really, the gift of data security is rather thoughtful. And yesterday, it finally got the new firmware that enables Linux support!

Between then and now I haven't really been able to use it at work. And since transporting files between work and home is one of the nicer features of it, it has largely sat unused. But right this moment it is mounted to my openSUSE 10.3 workstation. This beats a floppy disk for transporting pgp/gpg keys.

Labels: , , ,

Monday, August 18, 2008

My favorite compiz plugin


I love that plugin. Ad-hoc screen captures. I use it all the freaking time. It has managed to engrain itself into my expectations about how computers should work to the extent that I started swearing at XP the other day since I couldn't do that. Such a simple thing, but my how effective it is at capturing a quick snippet of what I want. No more do I have to...
  1. PrtScrn the application I want
  2. Open Paint
  3. Paste the screencap
  4. Copy the section I need
  5. Create new canvas
  6. Paste the copied section
  7. Save to file
That's a lot of work. This widget? Much faster and easier.

Labels: ,

Monday, June 30, 2008

Novell Client for Linux, packaged for OpenSUSE

It has been mentioned many places, and I've done some of the mentioning, that since openSUSE is the foundation for SLED, it makes sense for Novell to distribute an NCL for openSUSE. It turns out they're working on just that. And here is the Novell beta page. I'm soooo going to try this out, since I'm running openSUSE 10.3 on my work desktop and won't be moving to openSUSE 11 until I can run the client on it (oh, wait, I can).

It should also be mentioned that Ubuntu is a very frequently requested target for another NCL, but I have reason to believe that'll never happen. First of all, any Novell Client involves closed source 3rd party licensed code, which makes it hard to port to Linux in the first place (a relic of being based on code from the days when open-source was just an ethical standpoint rather than a tangible market force). Second, Novell has proven to be rather light in developer resources in certain areas, and linux integration with non-SUSE linux distros is very minimal.

Labels: , , , , ,

Wednesday, March 05, 2008

Flash on openSUSE 10.3

For the past few months the flash plugin hasn't been working for me. I didn't miss it much since I have a WinXP VM up all the time and it can play them, just not sound. I hadn't been using it much since the nspluginwrapper processes had a tendency to hang once in a while and consume 100% single-thread CPU. Annoying that. As I use the 'flashblock' plugin, it didn't bite me hard I just didn't click on flash unless I really wanted to view it. Since like 80% of non-text ads are now delivered as flash, this has greatly reduced the advertising I have to sit through and fly-ins like CNN is now doing are transparent.

But. No sound for my YouTube! So, I had to fix that.

Right now I'm running openSUSE 10.3, and using Seamonkey as my primary browser (though Firefox was broken for flash too). It took me close to two hours to figure out what the heck went wrong and how to fix it.

Everything I found said I should run the following command to just make it work:

nspluginwrapper -v -i /usr/lib/browser-plugins/

Except I kept getting this error:

nspluginwrapper: no appropriate viewer found for ./

What ultimately ended up fixing it is the following series of commands:

As root:
  1. zypper rm nspluginwrapper nspluginwrapper-i386. This removed the existing nspluginwrapper install, which I suspect was borked.
  2. zypper in nspluginwrapper nspluginwrapper-i386. This installed both packages. Both packages ARE required for this to work on x86-64 machines. Remember, nspluginwrapper allows you to run 32-bit plugins in a 64-bit browser, so it has to cross the boundaries.
As my primary user:
  1. nspluginwrapper -v -i /usr/lib/browser-plugins/ This gave the following output:
    1. Install plugin /usr/lib/browser-plugins/
      into /home/[user]/.mozilla/plugins/
Also of note, the resulting binary,, is about 90% larger than the old binary it replaced. I know that nspluginwrapper has had some updates since openSUSE 10.3 came out, and I suspect that a lot has changed. So I have high hopes that perhaps the hanging-plugin problem will go away. We shall see.

Also of note, I believe that running the nspluginwrapper -v -i process may have to be done every time nspluginwrapper gets updated. But, it would seem I have to explicitly upgrade it so remembering to do it shouldn't be an issue.


Friday, October 05, 2007

openSUSE 10.3 is in

No problems, but one. The "nvidia in Xen" problem is back. The prior solution isn't working yet. Unresolved symbols. This could be a work-stopper, or the thing that makes me move all the way to VMWare.

Labels: , ,

Friday, September 28, 2007

Novell client for Linux, part 2

I'm doing a test with the vanilla openSUSE kernel and the results are VASTLY BETTER. A snippet:
    KB  reclen   write rewrite    read    reread
51200 256 9178 9189 9130 8898
Compare that with the earlier numbers for that record size and you can see the problem.
    KB  reclen   write rewrite    read    reread
51200 256 595 587 8551 8491
See? It has to be something in the Xen Dom0 environment.

This would be a lot easier if Wireshark would stop freezing hard when I try to save a capture.

Labels: , ,

Novell Client for Linux

I'm running the beta of it, but keep in mind I'm also running it on openSUSE, which is not what it has been specifically designed for. That said, I do have some performance numbers. Yesterday I ran a very simple IOZONE test on a 50MB file. This isn't a great test since it fits entirely inside the server's cache. But I'm not worried about that, I just want to see how fast this code can peddle.

Performance was... not good. Unfortunately, right now I can't tell if that is a side effect of running it on openSUSE 10.2, inside a Dom0 Xen domain. I want to re-run it running the standard kernel and see if the performance also doth suck.
                                   random  random
KB reclen write rewrite read reread
51200 4 3259 3218 3875 4026
51200 8 5144 4925 5404 5215
51200 16 193 196 6980 6788
51200 32 593 599 8371 8309
51200 64 609 594 8213 8437
51200 128 589 590 8399 8432
51200 256 595 587 8551 8491
51200 512 598 595 8528 8439
51200 1024 596 588 8580 8295
51200 2048 594 596 8595 8542
51200 4096 597 609 8258 8548
51200 8192 595 599 8683 8683
51200 16384 608 599 8673 8585
As you can see, performance at record sizes over 8 is not great for writes. Reads, on the other hand, are quite zippy. Still not as zippy as the Windows client, which I've seen get up to 11000 on those tests. But still, zippy. I don't know where the problem is. I did some sniffing to try and figure it out, but nothing really stuck out as a cause. I'm seeing some 160ms delays in ACKs, but they're coming from the server. I can't tell what condition of the client-side write is causing the delayed ACK. Need more testing.

Labels: , ,

Friday, August 24, 2007

openSUSE news

They have a new news-portal site, which is nifty:

They had a nice article today about the results of a recent desktop linux survey. Bucky had a nice bit of analysis about it too.

This is nice to see. As I've mentioned before, I'm using openSUSE 10.2 at work (and right now). I can't use SLED because we're not entitled to it, nor will my boss pay for it. That said, I probably could do what a co-worker is doing and run SLES10sp1 instead ;). OpenSUSE now has 10.3 beta 2 out, which I'm not going to test quite yet as I don't have a test system for it; I wish I did have one.

One of the nice things that'll be in 10.3 (or rather, not in) is they're doing away with zmd for updates, and using a libzypp based process instead. This cheers me, as I've had a lot of trouble with the zmd one. It's better than it was in 10.0/1, but still not good.

Also, of course, openSUSE code forms the basis for what'll eventually become SLED.

Labels: ,

Wednesday, July 11, 2007

Novell Client for Linux beta 2.0 release on openSUSE

I have managed to get the new beta of the NCL 2.0 working on my openSUSE 10.2 workstation. This is very nice. Some nice details can be found here in the Novell support groups. My steps were rather similar.
  1. Install the referenced RPM. I did it with an "rpm -i [rpm-name]". Use the RPM for your processor type. I'm using 64-bit and it worked just fine for me.
  2. Run the "ncl-install" from the beta download.
That was pretty much it. It isn't perfect, but it is w-a-y better than using NetStorage and WebDav for this stuff. One area of inperfection is the tray icon gets smooshed.
NWTRAY getting smooshed
See that little sliver of an icon between the magnifying glass and the vertical bar? That's the nwtray icon. It's about 2 pixels wide. If I can click on it I get the full NWTRAY menu just fine, but it's hard to hit.

The other problem is the "Novell Services" button in nautilus. When I click that button, it looks like gnome crashes. I haven't been able to find out where the dump traces are going so I don't know what's up with that. If I access the services from the 2-pixel wide NWTRAY things work just fine, though.

Throughput still sucks, though. The Windows client is still better for that. But... throughput is w-a-y better than using a WebDav connection! Progress!

Labels: , , ,

Friday, May 18, 2007

Acessing NetWare from openSUSE

I've been asked how I've been managing a NetWare network if my primary workstation is OpenSUSE. That's a good question. Right now I'm doing it through two methods:
  1. I have WinXP running in a Xen VM that I use for 90% of it. Network throughput blows chunks, though.
  2. NetStorage (MyFiles for you WWU people) supports WebDav, and so does Nautilus.
Screen-cap of nautilus using webdav on netstorage
As you can see. In fact, I used the above screen to drop the screen-cap I made into my myweb folder for publication.

That said, there IS a way to get the Novell Client for Linux 1.2 installed to openSUSE, I just haven't done it yet. You can find instructions in the Novell newsgroups, which google handilly archives. I must mention that NCL1.2 will be getting service-packed when SLES10 SP1 comes up within the next month. These instructions may not be valid once SP1 is being published from

Labels: , ,

Thursday, May 17, 2007

A peeve

I've ranted previously about why I don't like Firefox. I use Seamonkey.

I'm also using openSUSE 10.2 for my work desktop.

OpenSUSE has compiled Seamonkey as a 64-bit package, rather than 32-bit. This made flash a rather dodgy thing until Adobe released v9 for Linux. Unfortunately, Adobe has yet to release a 64-bit version of flash so I'm stuck using NSPluginwrapper to get flash. And since flash is on about, oh, 80% of commercial web pages it gets loaded a lot.

Something, somewhere causes nspluginwrapper to hang in such a way as to consume 100% CPU. I have a dual core, so this is livable. It also happens often enough that I've modified my seamonkey launcher to "nice" the seamonkey process to as low priority as I can get it. I don't know what causes it to spike like that, but seems to trigger it, and YouTube vids are very likely to trigger it too. I've taken to using Firefox, 32-bit on 10.2, to view that sort of thing if I have to.

Once adobe gets off their butts and released a 64-bit flash plugin for Linux I'll be a very happy camper.

Labels: ,

Friday, February 09, 2007

NetStorage and gnome davs::

I just figured out how to get NetStorage to work with openSUSE 10.2! You have to set NetStorage to 'cookieless mode'. Now I have access to my NetWare hosted volumes from openSUSE! It'd be better if I could direct mount them, much more efficient transfer protocols, but this will do until Novell releases the next Client for Linux with SLED10 sp1.

Labels: , ,

Monday, January 29, 2007

An incompatibility

I've been working on Zen Asset Management 7.5 the past few days. In the process I discovered a rather significant incompatibility with the client. Well, significant for me since it'll make client testing harder.

When run on a Windows XP virtual machine running on Xen 3.0.3 that comes with openSUSE 10.2, it causes the clock in the VM to slow w-a-y down. On the order of 1 tick per 30 ticks on the host machine slow. This makes it unusable in a rather significant way.

It also is completely unfixable! Running Windows in a full VM in Xen on openSUSE 10.2 is an unsupported operation. I have the CPU for it, and it runs pretty well in every other way. But something the inventory process does causes some Xen emulation to go 'poink' in a bad way. It is so bad that even after the VM is powered off and the BIOS is putting the virtual machine to rest, it STILL takes a very long time for the VM to unload. No idea where to report this one.

In general, the product looks interesting. Getting it rolled out everywhere will take a lot of work. Plus, for some reason it isn't accepting my license code. But that's something that can be fixed with a call in to Novell.

Labels: , ,

Thursday, December 14, 2006

openSUSE 10.2 on the ASUS P5B Deluxe

This board in general is not a good Linux board. It was purchased with Windows in mind. Which in the end turned out to be something of a negative, as three of the five people who got them wanted a Linux-something installed. Two of us have gotten it working, and the third may come around once I'm done dorking with my setup.

There are two big areas that cause problems with this board:
  1. The chipset, Intel 965G, has no native PATA support so ASUS attached a JMicron PATA controller. The JMicron PATA controllers are broken in all but the newest kernels (2.6.18 or newer). There is a limp-mode for 2.6.16 and older that can work (google all-generic-ide). This is a b-i-g problem when you consider almost all Optical drives are still PATA.
  2. The kernel included with the Goldmaster media ( locks up the install hard. The cause of which is, as of this writing, unknown [Update: the kernel falsly detects AGP, which is the source of the lock, using the boot option "agp=off" may bypass this detection]. This will probably change when they remaster the install media later on.
There are some BIOS settings that need to be set in order to make the system usable on Linux. Because there are functionally two separate IDE controllers on the board, there are two separate places in BIOS you need to go to in order to configure your IDE environment. This board has the option of RAID, but it is actually a software RAID and is not well supported in Linux yet. I didn't use it.

On the MAIN page in BIOS there is a sub-menu for IDE Configuration. You want to set 'Configure SATA as' to IDE. Don't use ACHI, so far only Vista can use ACHI right there. Linux will eventually support it. (and if you're reading this article two years from now, Linux probably has figured it out. Google harder.)

The second setting is on the ADVANCED menu, in the OnBoard Devices Configuration sub-menu. Set 'JMicron Controller Mode' to ACHI. That's right, ACHI. Not IDE. This allows the PATA optical devices to be detectable. This looks counter intuitive, but this is what seems to work.

Now that you've done that, you have put the shiny DVD into the optical drive and booted from it. You hit 'install from DVD' on the front screen, and.... it bombs, unable to detect the media.

That's because 10.2 isn't quite smart enough yet to detect it. You can force the issue by putting the following line on the "Boot Options" line on the front screen:


This tells the kernel to force-load the JMICRON driver. This allows the kernel to locate the DVD drive with which it'll continue the installation process.

Now comes the harder problem, the kernel shipped with 10.2 Goldmaster will hard lock the P5B. There is a work-around which you can find in Bug 229365.
  1. When the install gets to the 'now we will reboot your machine', click SKIP.
  2. [Control]+[Alt]+[F5] to get to a shell
  3. cd to /mnt/etc/
  4. vi modprobe.conf.local
  5. Append this text to the file "blacklist intel_agp"
  6. Save the file
  7. Reboot
That SHOULD get you in.

[revised 12/21/2006]
Update 4/2/2007:

Turns out there have been some key problems in the Linux kernel relating to this particular P965 chipset. From a bug I reported a few weeks ago:
Looking at the lspci output I get the understanding that
intel-agp shouldn't initialize at all - there's not Intel Integrated Graphics
controller. The code in intel-agp, however, blindly assumes an 845 if there's a
host bridge with no matching IG (in agp_intel_probe()).
Which is a long way of saying that if Intel AGP is loaded, either compiled in or falsely loaded due to a bad detection by the kernel, it'll have problems. The kernel falsely detects an integrated graphics controller and attempts to load agp_gart, which if loaded does Bad Things. It looks like the openSUSE guys are now aware of this problem, so we may have a new kernel in the not too distant future to fix this. Or perhaps this is just on the list for 10.3 when it comes out. Don't know yet.


Monday, December 11, 2006

More on openSUSE 10.2

Reinstalling with LILO as a boot-loader this time caused me to actually have a working boot loader. Unfortunately, Linux still won't boot. It'll load the kernel and boot gets to the line that reads:

agpgart: Detected an Intel 965G Chipset.

Then locks the computer hard. Kinda useless.

On the up side I now can boot the Windows partition so I have access to big hard drives again. Yay. I'm currently re-downloading RC1, since I KNOW that worked. I'll then selectively bootstrap packages from 10.2-Final after I get it in. I'll avoid the kernels since I know those don't work. I'll wait for new kernels to get checked in that hopefully fix my problems.

I have a bug report in on it, but it's ranked 'normal' so won't get special attention.


This page is powered by Blogger. Isn't yours?