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.