Older blog entries for spot (starting at number 92)

Aurora:

We're close. I promise. I'm pushing as hard as i can to get these last errata packages to build. Stupid mozilla.

And now, for your viewing amusement:

Rule #1 of online behavior: When drunk, don't get online.
Rule #2 of online behavior: If you choose to ignore rule #1, don't get on IRC or any other chat medium.
Rule #3 of online behavior: If you ignore both rule #1 & #2, be prepared to be publicly heckled.

log starts @ ~04:59:33

<ottorongo> HEYT PPARTY PEOPLE
<ottorongo> WHAT'S UP
<tarzeau> do you have a sparc?
<ottorongo> yes
<ottorongo> I have a few
<ottorongo> but honestly I'm not here to talk about sparc
<ottorongo> I am gears
<ottorongo> of fame from lilofree.net
<ottorongo> not sure why the fame
<ottorongo> but I am drunk
<ottorongo> and I just wanted tos ay
<ottorongo> say
<ottorongo> fuck lilo
<ottorongo> fuck that fucker
<ottorongo> right in the ass
<ottorongo> what a fucker eh?
<ottorongo> don't you agree?
<ottorongo> come on I'll talk about sparc if you agree
--> sonic (sonic@psycho.slavetothe.net) has joined #sparc
<ottorongo> come on
<ottorongo> c'monnnn!!!
<tarzeau> lilo is kaput, that's all
<tarzeau> someone should fix it
<ottorongo> awesome
<tarzeau> we use silo here
<ottorongo> so anyway I have 2 sparc 5's and a sparc 20
<tarzeau> capitalist!
<ottorongo> ah
<ottorongo> I use netbsd
<ottorongo> on sparc
<ottorongo> anyway
<ottorongo> I like how linux has that uhhjh
<tarzeau> i use debian gnu/linux (sid) on my sparc classic
<ottorongo> framebuffer penguin
<ottorongo> later
<sonic> i heard lilo was the leader of the "candyman" child pedophile porno ring
<-- ottorongo (gears@linuxos.org) has left #sparc
<-- sonic (sonic@psycho.slavetothe.net) has left #sparc

log ends

Yes, ladies and gentlemen, lilofree.net. Take a bow.

Lord knows, we could all do without the wallops, but at least opn's admins are mostly sober.

Aurora:

Build 0.3 isn't happening today. I'll try to work on it some more tonight, but I really want to get a gcc3 package in there, even though Jakub is going to build a much better one in July. I also still have some errata packages to build.

Please have patience with me. :)

Aurora:

Damn. gcc3 takes forever to build & test on an Ultra 10. ;)

Looks like the Build 0.3 release won't be until tomorrow at the earliest. All apologies to people waiting with baited breath.

Aurora:

I saw the installer go into the X based GUI for the first time today. It was beautiful. Still got bugs, but hey, that was pretty.

Either the RAM on fry (my AXi at work) or its CPU is going bad. I booted it with diag-switch? true, and the ram claims to pass, in addition to the cpu, but I was getting compile time errors that I don't get on the Ultra 10. Specifically, on glibc and gcc, with it stopping on "Internal bus errors" in a different place each time. Good thing I've got a spare AXi at home. I'm going to swap out the CPU and see if it becomes happier. Building things on the U10 takes too long, even with a gb of ram. In case you were wondering, thats whats delaying Build 0.3 now. I'm going to kick off a gcc3.1 build attempt to see if it builds on the U10. I hope it does.

Laptops back. Means I can actually do work from home again. In theory.

Aurora:

Auroraconda gets to stage 2! There are still some quirks in stage 1, but man, it was pretty to see it roll into Stage 2 today. Mind you, it didn't get too far, but in the words of Jeremy Katz, "Stage 2 is a lot easier to fix".

Doing a lot of work on the rescuecd code. I know know a lot more about mkisofs on sparc and silo now. For the time being, I'm going to be content to have it boot into a bash shell with all the utilities and kernel modules present.

Kernel is pretty much frozen at 0.96. I know as soon as I say this, it will need fixing in some other area.

Dave Miller confirmed my assumptions about the SunFire 280R, the UltraSPARC III+ CPUs aren't supported by Linux yet.

The loss of my laptop is limiting the amount of work I can do from home. And when I say limiting, I mean, I'm not doing ANY work from home. I already can't wait for its return from Dell. Of course, Tadpole could offer to send me a SPARCbook to fill the void. Yeah. Thats not gonna happen.

Today was rough. Velociraptor, my Dell Inspiron 4000, refused to boot beyond its BIOS today. I called Dell to have it RMAd, to be informed that TODAY was the last day on my warranty. They decided that I was still covered today, but that to be safe, I really should purchase an extended warranty, which i did, for a little over $200. That was a quite unexpected expense. :/

Aurora:

I bought two Sparcstation LXs over the weekend, and yesterday I managed to coax a very minimal install of Red Hat Linux 6.2 onto the first one... and today, when I booted it, I discovered that its ethernet port is dead. Hopefully the other one will have a working ethernet port.

My manager convinced Red Hat to purchase (on loan) a Sunfire 280R, for some sort of traveling demo. He's letting me play with it for a week or so, before he needs to blank it and install Slowlaris. Red Hat Linux 6.2 doesn't boot on it, and auroraconda isn't quite ready yet, so I'm probably going to install SuSE and manually bootstrap Aurora over top of it.

SPARCs currently on my alternate desk at work:

(1) Ultra 2 SMP (1) Ultra 10 (2) Sparcstation LX (1) Sparcstation 2 (1) AXi

That SunFire makes more noise than an s/390.

Poked at the rescue cd code, I'm thinking that would be a nifty LinuxWorld giveaway. It will probably need the further auroraconda fixes as well. Anaconda needs to be reminded that, no, sparc doesn't want to use pcmcia. :) If tadpole sends me a SPARCbook, i'll reconsider.

Aurora:

Looked at the kernel spec file for a long time last night at work, trying to think of a sane way to apply a few patches to an "enterprise" kernel, and ONLY to an enterprise kernel. Unfortunately, the only way of doing so would also required those patches to apply to the kernel-source bundle, which will make dealing with all the other kernels unpleasant with in some situations. I don't think I'll be able to do that, short of doing one of the following: 1) have the spec generate a kernel-enterprise-source package in addition to kernel-enterprise 2) write a new spec just for kernel-enterprise & kernel-enterprise-source packages.

And since neither of those ideas is anything that I'd really prefer to do, I think this is what I'm going to do. The src.rpm will grab the patches, they just aren't going to be applied. I'll test the kernel with these patches after Build 0.3 releases, and if it holds up, I'll put them into the mainstream kernel RPM for the next Build.

Which patches are these? The RML realtime & Ingo's O1 for sparc64.

I think this is a ok decision anyways, since cache_decay_ticks isn't calculating sane values with the current algorithm + patchset, and I'd have to force it to 1 (which isn't end of the world bad, but its not optimal) to keep SMP actions from getting slowed down.

But lemme tell you, cleaning up patches so that they merge against Aurora is fun. Fun fun fun. First thing I'm going to do after Build 0.3 is start working on a 2.4.19 based kernel (not 2.4.18pre6, or any of the pres for that matter). Then again, it will probably be as bad as it is now, since most of my patches will appear in 2.4.19 anyways. Ah well, I can dream can't I?

In unrelated news, I'm going to the beach for a week, starting Saturday. This means, no Aurora, no emails, no nothing for a whole week. I'm going to try to enjoy it.

and now, the brief Aurora update:

I'm still waiting for Tom Duffy to send me his o(1) patches, so that I can go ahead and build 0.96 (it would just be 0.95-enterprise, but I'm going to put the sun4c forkbomb patch into the main kernel at the same time). if they dont come in by the end of the day today, i'm just going to disable the enterprise build in the spec and build 0.96...because...

Jeremy seems to have resolved one of the major auroraconda issues last night, everywhere i turn, theres a note from him saying "i think i fixed auroraconda". thats a good sign. ;)

I still need to respin the 6.2 ISO after inflating the initrd such that it takes up 2.88M of boot image total, and see if it will boot. If it does, isos are much much easier, if it doesn't, we're going to have to do some serious serious black magic to get the installer in 1.44M. Which in and of itself isn't necessarily so bad. We'd need that to happen anyways if we want boot floppies. Right now, I'd settle for bootable isos.

And if I can have something for a few people to test before I go to the beach on Saturday (i'll be gone for a week), that would be excellent. But, one thing at a time.

Some of the Toshibas (usually the Satellites, but also, occasionally the Tecras) refuse to boot off cdrom media with bootimages larger than 1.44M (7.0 had a 1.44M boot image, 7.1+ has 2.88M boot images).

Reference: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=47288

Aurora:

The original bug poster for the sun4c problem submitted a patch that seems to resolve it. I'm still confused about using a sun4c as a high traffic mailserver, but hey, whatever floats your boat. I'll add the patch and respin the kernel on Monday.

Sun is now offering a SunBlade 100 for the show instead of the Ultra 10. They offered me a whole list of stuff, and I picked the SunBlade (so did the Debian team). It will give me a chance to try to fix some of the X issues, and hopefully, we'll have a working installer by August. *cough*

We're in the middle of the migration, and the mailing lists are down. Just be patient, they'll come back up, I promise.

Aurora:

Thank you to all the people who offered up hosting space and servers. Aurora is completely covered at this point, its just a race against the clock to move all the files off linuxpower.org. Shouldn't be a problem.

Spent all my time today working on my prtdiag script. About all I can do for Aurora now is sit and wait for the installer work to be done. Well, that and poke the people who are working on it with sticks.

I know Xconfigurator needs some significant rewrites to deal with the Blades, but I really need one of them in a functional state (and sitting, attached to a monitor, in front of me) to do the work. Thus, this won't happen anytime soon.

I'm not terribly concerned with sun4c being vulnerable to forkbombs. The fact that it boots without eating you alive is miracle enough. If you're seriously trying to use it as a high yield mailserver, then you're sick enough to fix the code yourself.

I'm going to add mdadm to Aurora, even though Red Hat hasn't done so yet. Its proved its worth in migrating sparc 2.2 RAID to sparc 2.4 RAID.

Oh, and the Carolina Hurricanes are in the Stanley Cup Finals. How bout them apples? :)