Hi,

On Tue, Oct 04, 2005 at 06:42:50AM -0400, Chris Mauritz wrote:

Just curious...why would you want to run CentOS on a sparc system instead of Slowlaris? Or have I just answered my own question? 8-)

For me, as who is crunching this together, it's matter of challenging myself to see if i can pull yet another arch from my sleeve. Solaris would work better and propably even faster on hardware i do have, but for me, and some others too, it might be just a set of features available which is driving towards Linux/sparc. Unified set of packages (at least mostly) among working, familiar, package management.

I've been past 'i do have time for peeking/poking other OS too' a long time now, so Solaris is bit blurry area for me now. I do easily remember things like being able to install screen easily just to see it's not working and not even complaining during installation for missing ncurses. With correctly packaged RPMS one could not do such things by accident.

Another matter might be hardware support for some people. Most of the targetted hardware being PCI, Linux might provide wider support of hardware than Solaris - at least it does for me :)

So there might be numerous reason why people would like to run Linux instead of Solarsis on sparc hardware.

Then there is Aurora Project. w/o some of the patches made there, o'd be not even able to to hack CentOS-4 codebase to work on sparc at all. Aurora being targeted a little different now as they are re-building Fedora Core and i'd say CentOS-4 target would be long term maintainability and not so much all the cool bleeding edge. Both can co-exists and benefit from each other tho.

Hi,

On Tue, Oct 04, 2005 at 09:34:26AM -0500, Aleksandar Milivojevic wrote:

I'm really curious about the sparc64 version of CentOS. Currently there are only Debian and Aurora, with Debian being something completely different, and Aurora not even having working installer for current version (only for RH7.3 equivalent version). Mandrake or Suse (not sure which one) also has sparc64 version, but not for free.

I do belive Aurora Project is making new installer on that FC3 based thing soon enought too. There seems to be some issues still left (and as i haven't even tried to generate installation media still, there might be somne major issues on that area).

My aim being making something that could be mainatained with minumun pain for next 5-6 years, but rebuilding the bleeding edge.

My guess is that you'll do only sparc64? There's probably not many people that still have sparc32 machines around (well, I have one, an SS5 box, currently running OpenBSD, mostly because there's no decent current Linux distro for the thing, primary use to burn some electricity and as monitor stand). Not even sure if 2.6 kernels would run on the thing at all...

I do have sparc32/UP version of some CentOS-4.1 level kernel running on dual-CPU SS20. It's so damn slow that it's not primary target. Userspace is 32bit and everything needed is provided as 32bit, but the initial goal is not including something that is crawling with 100Mhz range of CPU-speed - it's just too damn slow :)

My initial merge for semi-working SMP-patch for sparc32 was faling miserably. First generating kernel just too large not to even boot and after some fine tuning, it did not boot anyway.

I'd say personally that it is time to drop anything below ultra-sparc now and not trying to drag legacy behind. I was even considering making gcc use -mcpu=v8 as default, as noone really does have those sun4c sparcs anywehere doing anything reasonable. Then again, gcc might not been having too much testing for such target, so i dropped it.

I did do build all the stuff and even installed it to be built against itself with this -mcpu=v8, but later on i did revert back to thise default -mcpu=v7 as one needs -mcpu=ultrasparc anyway for things starting to fly where it's needed (like glibc + openssl).

My kernel isn't still stable on SMP, but neither is Aurora's. My only SMP-capable target is Netra T1405 tho, so it might work much better on some other hardware. The kernel being most crucial piece on this puzzle and frankly i a, no kernel hacking guru and propably never will be. I try and fail, test and fail, but sometimes i just can't figure out all of those kernel internals like this one where kernel was not swapping. I finally managed to isolate it to some non-working atomic operrations and merged some stuff from 2.6.12.x to fix it up. David S. Miller would have solved this propably in 15mins, but i am no guru on that area :)

My plan is to start looking for real installation image generation today.

So my fear is that the kernel area is the most headaches even after release. Userspace seems to be pretty consistent even now.

Hi,

On Tue, Oct 04, 2005 at 12:14:13PM -0500, Aleksandar Milivojevic wrote:

Quoting Pasi Pirhonen upi@iki.fi:

Speaking of Aurora, last time I was playing with it, RAID on boot was not supported. So you couldn't have /boot on RAID1, and also attempting to do so would trash either partition table or file system superblock (!?), depending which order you attempt to do things. I don't know if it was problem with Aurora or with kernel. Have you attempted doing anything like that in your testing?

I don't know about that. I know that for ia64 the RHEL2.1 dfid let to mirror this VFAT /boot/efi, but RHEL3 didn't. I do believe that RHEL3-level stuff lets to mirror /boot on x86-64, but RHEL4 doesn't. The point being that this is working quite varying way even on mode mainstream stuff.

At least i can say that this is not first priority problem at all. As long as there isn't reasonably well installable version at all, the secondary problems aren't on the list :)

Definitely. If it takes more than 5 minuts of work to get sparc32 kernel working, it is not worth it. And even than it would be waste of disc space on mirrors to store sparc32 distribution. Its like having i386 (as in boots on an Intel 80386 or 80386SX processor) distribution. Simply way too slow.

I'd say that sparc32 would be there eventually, but not for initial release.

Is entire userland going to be 32-bit only, or there will be option to install 32bit or 64bit version of particular package (like on x86_64)?

There is 64bit glibc + lot of stuff to make 64bit gcc to build (like xorg-x11-libs etc.). So it's ready for 64bit compilation/packages.

It's not like x86-64. It's like ppc64. on sparc the userspace has been 32bit and still is. For x86-64 the userspace is 64bit with 32bit support, so it's really other way around.

For ppc64 i've made myself 'all way 64bit version' to be able to maintain those 64bit parts. For sparc64 is was too much of hasle now as most of the stuff won't easily go 64bit.

I am quite conservative on what i do risk now when i do have my buildsystems up and working (32bit and other box for 64bit parts). When i do have working installer, i'll be more wreckless once again as it would be much easier to get back. Now it's installing Aurora 1.0, updateing it to 1.92 and then updating to my own tree (initially it's kernel 2.4, so you have to go thru that 1.92/2.6 w/o udev to get there).

I do actually have one test compilation ongoing and should start about now the building the installation images (have to make box w/ framebuffer a recent enought to be able to generate the installer. Yes, it need keyboard/fb to make images :)

Quoting Paul Heinlein heinlein@madboa.com:

My recollection is that the trouble lies with silo, but I can't find the document that led me to that conclusion.

Whatever it was, it was nicely destroying partition table and first file system on the disk way before you would get anywhere close to silo. It was a really weird stuff.

And there was nothing warning you not to attempt something like that. So you would go from bootable system to unbootable system in about 2 minutes. Well, unbootable but fixable if you'r good in rescue mode stuff (and I had to use Debian boot CD for that).

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Quoting Chris Mauritz chrism@imntv.com:

Just curious...why would you want to run CentOS on a sparc system instead of Slowlaris? Or have I just answered my own question? 8-)

Probably for exactly the same reason one would run CentOS on an Intel box instead of Solaris. Now that Intel is becomming mainstream architecture for Solaris (Sparc is slowly going away), and taken that Solaris is now absolutely free (exacty the same price as CentOS) and it was announced they'd go open source with it. Anyhow, in Solaris 10 they fixed bunch of performance isues, and there's some really cool new stuff too (dtrace and you get machine virtualization by default).

I've been at Solaris 10 presentation held by Bryan Cantrill (senior staff engineer in the Solaris kernel development group), and some of the stuff was awesome. Interesting thing about presentation was that it was done on an AMD64 laptop running x86_64 version of Solaris (well, actually, there's no separate x86_64 version, if it finds 64-bit processor it'll use it). Not a single Sparc in sight.

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Hi,

On Thu, Oct 06, 2005 at 05:57:57PM -0400, Lamar Owen wrote:

Oh, the other reason I might want to run CentOS/SPARC is to help build CentOS/SPARC to give back to the CentOS community. That 14 CPU E6500 should make a nice buildbox.

This seems to be as good as any insertion point for this.

I've actually (it didn't work perfectly still) installed CentOS-4/sparc now.

I am just now getting out of the server to NFS a next generation of tree which i am about to test install in few minutes.

Didn't even look about CD-image generation still and the tftp-images i try to generate are b0rked, but i just toss the vmlinux + initrd on running install and lauch the installer from there now.

So there is definetly some progress ongoing all the time ......