On 11/28/2012 12:56 PM, Amy Tran wrote:> Hello there,
>
> I'd like to have iso image version for ultra sparc 64bit.
> Recently, I downloaded centos version 4.2 beta iso image and installed on
SunUltra sparc 64 bit machine.
> It was hang when it went to the screen " the CentOS 4.2 beta
screen,<Tab>/<Alt tab> |<Space> selects |<F12> next
screen ".
>
> Any idea?
>
Amy,
I have several UltraSPARC machines. There is a Fedora 12 beta for
SPARC, and a somewhat Fedora 15 (IIRC) for SPARC, which is also beta or
maybe even pre-beta. There is little to no active development, but
there is a Fedora-SPARC mailing list that gets a little traffic. The
only fairly well supported Linux currently for SPARC is Debian, and it
can be a pain on older hardware (like our SBUS E6500 machine (18 CPU's,
16GB of RAM, three IO cards on the centerplane with three SBUS slots in
each)).
The biggest problem with a CentOS 6 on SPARC (which would be the easiest
one to roll right now) is that SBUS autodetection in the
dracut-generated initrd is horribly broken; I've written up how to
manually boot an SBUS based UltraSPARC system on F12 with dracut, and
it's archived in the Fedora-SPARC list's archives from a couple of years
back. But, while rolling C6 from F12 is not going to be easy; it is
still very likely to be easier than C5.
See https://fedoraproject.org/wiki/Architectures/SPARC for the fedora
secondary page, but be sure to read recent messages in the fedora-sparc
list archives about Dennis Gilmore's withdrawal from the project (as he
was the only active developer, and while there was some talk, there
hasn't been much activity on the list since).
See also, for historical information and possible starting points for a
C5 on SPARC:
http://wiki.auroralinux.net/wiki/
Now, rumor has it that Oracle is interested in OEL on SPARC (I think I
remember hearing that Larry E mentioned it publicly at a press
conference a while back), and it might be possible to use an Oracle
EL/SPARC as a starting point for a CentOS rebuild from the same upstream
sources, should such a beast ever actually materialize. That's actually
the path I would personally take, if I wanted to put our E6500 back into
production. I do have a Fedora 12 beta box in production as a console
server, and it works fine (it's a Blade 1000 with two CPU's), but any
usage that would be Internet-facing would be foolhardy at this point.
Years ago I posted on the centos-devel list a message offering a
possible build box using our E6500, but the interest level just wasn't
there at that time, much like the interest level in the IA64 port is
just not there right now, either. Now, I've successfully gotten up to
CentOS 5.8 on IA64, rebuilding from source, but I started with
ScientificLinux CERN 5.4 as a base, which made the job much easier, and
I rebuilt on a much much faster box than the E6500, even with 18 CPU's,
is going to be.
Even given a CentOS 5.0 on SPARC, it would take, I estimate, three to
four months of solid rebuilding to get from 5.0 up to current, with no
time out for errors or correcting of errors, due to the speed of the
CPU's and disk. I say that having done just exactly that (with the IA64
port) on a 30CPU SGI Altix with 54GB of RAM available for the 1.5GHz
Itanium CPU's, and the time the machine spent rebuilding alone, from a
5.4 level to a 5.8 level, was a good solid three weeks, and that was
with a ramdisk for the buildroot and fast EMC Clariion iSCSI storage,
and not Sun Storedge D1000's loaded with 36GB 10K RPM SCSI drives on
SBUS DiffSCSI ISP's hooked to 400HMz CPU's on a 66MHz centerplane like
with the E6500. I haven't at this point rebuilt the updates; that's on
my list for January....
Anyway, at least with the IA64 port there is source support in the
upstream packages (and there are IA64-specific things in some
packages). There is no upstream SPARC support, and hasn't been in the
Enterprise Linux lifetime (last officially supported-by-Red Hat build on
SPARC was Red Hat Linux 6.2 back in 2000, if I remember correctly).
That's where the Aurora SPARC Linux project started; I ran Aurora for
quite a long time on several SPARC boxen, beginning with an Ultra 5 and
Aurora 0.32 (or was it 0.42...?), and progressing through some Ultra
30's, and finally the E6500, which started with a built-up Aurora 2.99
and then a scratch reinstall at Fedora 12, which was a project in and of
itself.
There are issues on SPARC; one is the 32bit/64bit split-brain system
with a 64-bit kernel and 32-bit userland. There are more, and I don't
have a current list, since I've been out of that particular circle since
Fedora 12 beta for SPARC: around, oh, June of 2010 is when I did the F12
on the E6500 bit. It's in the archives; see:
https://lists.fedoraproject.org/pipermail/sparc/2010-June/thread.html
under the threads with my name on them.....
Now, if Oracle does do official support, it might be worthwhile to power
up the E6500 again.... but for now it's just sitting there unplugged.
It does make a pretty resilient Pound/Varnish reverse proxy, and very
few shellcode injectors know how to deal with SPARC..... so it would
have its uses.
And the Blade 1000? Well:
[root at sb1k-1 ~]# dmesg|grep 2010
Linux version 2.6.32.21-166.fc12.sparc64 (mockbuild at korolev.ausil.us)
(gcc version 4.4.4 20100726 (Red Hat 4.4.4-14) (GCC) ) #1 SMP Fri Sep 10
13:32:10 UTC 2010
On node 0 totalpages: 262010
rtc_cmos rtc_cmos: setting system clock to 2010-10-14 19:27:41 UTC
(1287084461)
[root at sb1k-1 ~]# uptime
11:50:48 up 776 days, 21:23, 1 user, load average: 0.00, 0.00, 0.00
[root at sb1k-1 ~]#
Still running, and it's as up to date as F12 on SPARC ever will be.
Last reboot was when I moved it to the co-lo, where it is a console
server on an out-of-band management network for a backup server.