Pasi Pirhonen wrote:

This comes from me (one of centos core. ia64, s390, s390x maintainer and CentOS-4/alpha(axp) maintainer).

amazing!

This has been 'under construction' long time. I started working with this really after finnishing the 4.1beta for alpha/axp late Jun this year.

CentOS-4/alpha and CentOS-4/sparc as just trying to follow CentOS-4 official arches as closely as possible. Making mods to only to packages that really needs it, so maintenance burden for these are minimized. The goal having other supported arches beoynd official ones.

My goal is to start working on finalizing this soonish and being able to say 'it's release' as of CentOS-4.3 time. It worked quite good on alpaha for 4.1beta -> 4.2rel, but dunno about sparc yet (ie. this is not promise to cruch it as release for 4.3 timeline).

I start making the security updates to this 4.2beta too tho immetiatedly even tho there will be no security announcements for it before it really is release.

The yum should be configured to take care of this pretty much automatically (updates). There are updated openssl as i didn't spot quite all that needed to be changed while making the SRPM for sparc. Todays security updates are there too.

I'll push the sparcv9 glibc there soonish as i've now pretty confident it won't break the db4/rpm as oen could see happening on 1.92 or Aurora. Sparc (as is ppc too tho) is funny that way that you can't have your normal running/distributed distro as build host. There are a lot of things that has to be differently on build host.

I just wanted to get this out for testers and maybe get some feedback to be able to make it release some distant day.

I am pretty confident that this will evolve a good robust distro.

did you include aurora's patch into this packages? or try to incorporate their changes into this distro? can we upgrade from aurora 1.92 to this or we have to reinstall the whole system? yours.

On 10/17/05, Pasi Pirhonen upi@iki.fi wrote:

If someone does have IDE/CD sparc and want't to put in IDE/DVD, that most propably just work with DVD-image.

I have tested the DVD-installation on Netra/X1 and U10 with IDE/DVD.

I downloaded and burned the dvd last night. I tried booting from the dvd this morning on an Enterprise 450, and it said the disk was not bootable. I guess I'll try the cd version and see if there is any difference. Any thoughts? Yes, I have a dvd rom in it.

Grant

Hi,

On Tue, Oct 18, 2005 at 03:10:36PM -0500, Aleksandar Milivojevic wrote:

Quoting Aleksandar Milivojevic alex@milivojevic.org:

PCI: Address space collision on region 6 [000001ff00080000:000001ff000bffff] of device 0000:00:05.0

However, machine seems to work stable so far (well, at least last couple of hours since it was installed).

netra/x1

PCI: Address space collision on region 6 [000001ff00080000:000001ff000bffff] of device 0000:00:05.0

So it's there. That is actually some kind of conflict between ethernets (PCI 00:05.0 is another of itegrated ethernets).

I haven't had any problems with this either.

Hi,

On Wed, Oct 19, 2005 at 10:31:47AM -0500, Aleksandar Milivojevic wrote:

...

So it's there. That is actually some kind of conflict between ethernets (PCI 00:05.0 is another of itegrated ethernets).

I googled around, and the problem is not Sparc specific. Lot of pointers to PPC, and some articles on Debian and Aurora mailing lists for Sparc (mostly small boxes such as Netra X1 and SunFire v100). Not common on i386, but I found couple of folks having same problems there (usually BIOS update resolved problem on i386). Some articles go back couple of years to kernel 2.4. So it is old thing. Seems that thing either doesn't affect the system, or it makes it unbootable. Depending how lucky you are. Guess we were lucky ;-)

I really don't know. I do remember noticing this too, but when wverything seemed to be working -> i forgot it totally.

There is yet another thing about Netra/X1, and V100 too i guess, the dmfe.ko didn't work on Netra/X1, so i fixed the hwdata pointing to tulip for these PCI-ids. This was a must for hardware _i_ did have available for testing, but for some cases the dmfe might even work (don't really know :)

One thing I noticed is that the region it complains about is not reported in "cat /proc/iomem". The "LED on unused ehternet port flashes like crazy" thing could also be related to this.

No idea.

Hm, one interesting thing. Building packages with rpmbuild, they are compiled for sparc (32-bit userland), but tagged as sparc64. I've checked the binaries with the file command (and ldd too), and they are really 32-bit binaries. I also attempted to do --target=sparc, but got the same thing (32-bit binaries in package marked as sparc64).

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

Quoting Pasi Pirhonen upi@iki.fi:

that would be the part, i said about 'running machine can't be configured as build machine'.

For starters there are command 'sparc32bash', which will partly hide the fact machine running 64bit kernel. Same thing applies for ppc64 where the userspace is 32bit.

Secondly it's much more easy to compile stuff as sparc32 when one alters the /etc/rpm/platform from sparc64-redhat-linux to sparc-redhat-linux. I really don't yet know how to handla all this _properly_. This is something to be resolved before actual release time.

The sparc32/sparc32bash is basic stuff under sparc/sparc64 compilation.

Oh well... I guess I'll be hacking those files by hand if/when building my custom RPMs on 4.2beta. The sparc32/sparc32bash alone wasn't sufficient. I tought it was as simple as choosing the default (like i386 is default arch on IA-32). Guess I was wrong ;-). I was kinda surprised when --target=sparc hasn't worked like I expected it to work.

Anothet thing is that i intentionally left out all the other bits and pieces of 64bit userspace than glibc/glibc-devel. I have to do some work on this area and sort out what bits and pieces i am actually inclusing on installation media and what is pushed to extras or something. Some of those are runtime and some ofg those are just parts that are really needed to be able to build 64bit parts. Even then i have to play tricks for some parts of 64bit to make it build.

I guess most of libraries, at least. Vast majority of applications don't benefit from huge addresss space, but from time to time there's something user might want to compile in 64bit mode (and than he'll cry if there's no 64bit version of library xyz).

BTW, just out of curiousity I attempted to compile "hello world" program with -m64, just to find out it can't be linked. Would it be possible to include libgcc_s_64.so in next update (I guess it would be libgcc.sparc64 package)? Not really possible to compile much in 64-bit mode without it (well, you can compile, but not link) ;-)

Ah, I always hated mixed 32/64bit systems. I perfectly understand reasoning why they exist, and probably would do the things the same if I were decision maker, but I hate them anyhow. From time to time I'm getting into the mood "ok, let it give more disk and memory, and let it run a bit slower, but give me pure 64bit system, so I don't have to tweak things constantly" ;-). Actually that was the thing I always loved about Alpha and OSF/1 (or Tru64 as it is called these days). It was clean, pure 64-bit system from day one, with no 32-bit past dragging around. There was no "this part is 32-bit, that part is 64 bit, oh no I don't have nn-bit version of that library" mambo jumbo. Just couple of buggy applications that assumed sizeof(int) == sizeof(void *), but that was easy to fix most of the time. Maybe it would be even a bit faster if they made it mixed 32/64-bit, but it was fast enough that nobody really cared ;-)

Most of those are needs for 64bit gcc to build. These days the damn thing needs about half of the universe to even build.

Yeah I know. I don't look forward to recompiling gcc even on relatively recent Intel hardware. Guess on old(er) Sparcs it is ten times worse (at least).

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

Hi,

On Tue, Oct 18, 2005 at 02:51:01PM -0500, Aleksandar Milivojevic wrote:

I just did an install on SunFire v100 (similar machine to Netra X1). Works nicely. Created /boot as normal partition, and than created software RAID-1 and used it as physical volume and put the rest of the system under LVM. Since it was text install, I had to do LVM stuff manually from command line before using "disk druid" (LVM dosn't have GUI in text installs, and I didn't want to use autopartitioning). The "workstation" install took about an hour to complete from the CDs.

So now i know the software RAID1 works too. I don't use RAID on my build machines. I do have all the important information on my NFS-server, so i can just toss a machine, install it again, vonfig few things and i am good to continue from where i left on updates build or anything.

The kernel is "kernel-2.6.9-22.EC"? Shouldn't it be "kernel-2.6.9-22.EL"? Typo? On purpuse?

That is not a typo. It's intentional and the abrevation would be 'Enterprise Compatible'. I've used it long time for my 'heavily patched versions of same codebase' just to make it clearly different from .EL. line which are mostly unmodified.

If Solaris kernel was up and running before booting CentOS install CD, the machine might need to be powered off first. This is something specific to 2.6 kernel (2.4 kernels do not have that problem). I'm not sure if this is needed when booting 2.6 kernel for the very first time, or every time after Solaris kernel was loaded. At least this is true on Sun Enterprise 150 and SunFire v100.

I have no info on this area. generally it's one machine - one OS for me anyway. Someone might find this info interesting tho.

If you talk about Aurora 1.0 as 2.4-kernel -> it has different version os SILO too. SILO is the loader which is booted from disk, so that might be more like SILO related than kernel related.

When creating partitions, leave third partition to be "entire disk". This is not really needed under Linux, but it is customary on Sun boxes (and if you dual-boot, you probably want to have it that way to keep Solaris happy).

I am aware of this. The util-linux (mount command) is patched spcially for not complaining about duplicate LABELs found if for example partion 1 is /boot, so partition 3 would have /boot label too visible.

Anaconda still installs sun disk label IMO on disks, so the '3 - whole disk' is there. And what i've tested (/boot, / and swap which make three paritions) anaconda nicely skips the 3rd parition and leaves it as 'whole disk'.

Supposedly /boot can't be on software RAID-1. I remember this back from Aurora days. Don't remember if it was SILO limitation or something else. Haven't attempted to put /boot on software RAID-1 on CentOS, so who knows, maybe it works now after all...

It must be SILO. But i remember yaboot just recently getting the 'boot from mirrored disk support', so sparc has not been alone on this. On ia64 one can't mirror the /boot VFAT partition either, so it's no like unique for sparc.

There are no virtual consoles on headless systems (aka console over serial port). At least not as far as I know. However, you can get command line by pressing ctrl-z on any Anaconda screen. Type "exit" to get back to Anaconda.

That is general trick, but good to know. One could boot to rescue mode too and use the shell there to make what even needed (ctrl-z would be quiker tho).

On SunFire v100 network interfaces are detected in reverse order. What Solaris sees as dmfe0 is eth1 under Linux, and what Solaris sees as dmfe1 is eth0 under Linux. Needless to say, labels on the back of the box correspond to how Solaris sees them. Also, the LED for first ethernet port (dmfe0 under Solaris, eth1 under Linux) flashes like crazy, although there's no cable connected to it and the interface is not configured.

same on Netra/X1. I don't know if tweaking the probe-order on PROM would fix this for PROM. Tweaking Linux PCI-probes for something so simple would be overkill IMO.

The text version of firstboot is ugly, at least in minicom. You'll have trouble navigating it. But be brave, I've seen worse ;-)

Fortunately you can just leave it there and it'll timeout dooner or later :)

I've attempted connecting USB DVD-burner. No luck. Bunch of error messages logged by the kernel, and udev creates /dev/uba (!?) device for it. USB stick worked and I got /dev/uba* devices created for all partitions found on USB stick. However, /etc/fstab and /media directory were not updated (as on i386). While I'm at it, there's also no entries for IDE CD-ROM in /etc/fstab file and /media directory.

USB might be something wort invertigating. That was quite out of scope for making the damn thing installable for wider public. As i've been saying, it's a start and i do hope getting feed back to make it release as of time of CentOS-4.3 time. There is lot of fixing and so little time :)

Primary goal is to get it installed. When it's OK, it's much easier to provide just updates to installed system and get new working features in.

For above, it's nice to hear that even something IS working under USB too....