This is the cure for a lot of problems from installer hanging before it can print the SILO prompt up. In fact this is the cure for a lot of mysterious problems so I suggest you always do this! If you ask on the newsgroup this is one of the most common problems. Blame SUN for poor CDROM drives.
Aurora 2.00Beta2 prelink is broken on some machines. Cron autoruns prelink every 24 hours so we need to stop it. Firstly if you have been affected by this run prelink -ua. Then edit /etc/sysconfig/prelink and alter the line PRELINKING=yes to say PRELINKING=no.
Be aware it can take up to 15 minutes to generate the SSH keys on sun4m architectures during install. For vastly improved ssh performance install the openssl-XXXX.sparcv8.rpm (for sun4m) or openssl-XXXX.sparcv9.rpm (for sun4u) with the command: rpm -qa | grep openssl to find the version you are running and then rpm -e --allmatches openssl-OLDVERSION.sparc.rpm && rpm -Uhv openssl-NEWVERSION.sparcvX.rpm. There is a further speed increase availiable by dropping ssh version 1 instead of 2 but this has fundamental security flaws and is not a sane option - ssh 1 compatibility is the only reason this option is still available.
If installation hangs with disk problems try: boot cdrom linux ide=nodma or boot net linux ide=nodma and at the SILO prompt use linux ide=nodma. This is due to the horribly hardware bugged I/O controller in the U5 / U10. Try to get a SCSI SPARC instead or a SCSI PCI card for these sytems to get above 2MB/s disk transfer rates.
If the graphical install hangs (usually on the format after parted) use the text install instead. Text install is generally considered a much better option all round.
If your install is failing and you are lucky enough to be in this situation try the following:
Either remove RAM to below 4GB for the install, and then add it again OR you can disable it in the PROM with the following commands: asr-disable bank x command where x is 1, 2, 3, or 4. To enable it after install use asr-enable bank x.
This is an unresolved error with that keymap. A workaround exists by editing the following line in the XF86Config-4 file: Option "XkbModel?" "type5_us" to read Option "XkbModel?" "type5" Unfortunately this is the american mapping so characters such as " and @ are swapped but most should be functional.
Aurora doesn't currently support this architechture and currently there are no plans to implement this support. The reason for this is the rest of the SPARCStation 5 line use Texas Instruments CPUs which are supported in the kernel but the 170MHz version contains a Fujitsu TurboSPARC that only bears a slight similarity to the TI SPARCs. Linux has booted several times on this processor but it is unstable and had never been supported by Linux. BSDs will run on this architechture.
There is an issue with the 8MB VSIMM in the SS10 & SS20. Workaround: During initial install select 16bpp colour however during normal use the Xconfigurator won't work.
There is an issue with swapon segfaulting on boot of sun4m SMP machines. This should be resolved in the near future. The swap partitions apparently work so this isn't a major problem.
There is an issue with ROSS HyperSPARC? processors, symptoms are hanging on free kernel memory or just after the init stage of boot. They can also suffer kernel halts. Their performance also seems to be very sluggish compared to SuperSPARCs?.
During boot before the monitor is activated hit the STOP & A simultaneously. Getting to the OBP prompt via a serial cable Connect a serial cable to the serial port, ensure the keyboard isn't connected. Set the terminal settings to 9600bps, data to 8N1 and emulation to VT100. During initial boot send a BREAK to the sun. If you are using a HyperTerminal? on windows the correct command for a BREAK is CTRL + ESC then F.
Okay so you wonder why all the programs are currently built as 32bit code not 64bit while only the kernel is 64? The answer is fairly complex:
The Price of 64 bit: The cost of using 64bit operations throughout is huge. Unless a number is bigger than 4294967296, the size of a 32 bit binary number, most of the data is unused. This translates into effectively WASTING half you main memory, memory bandwidth to the CPU and the CPU cache. This is a huge performance hit.
The Payoff of 64 bit: Well there are two actually: The first is that a 64bit CPU will usually be able to perform 64bit math and logic calculations very quickly compared to a 32bit processor that will have to use software fixes. Note this is mitigated by the fact many 32bit processors can do multi register operations quickly. However as we have discussed above how many times do you actually need 64 bit maths? That said if you have to use big maths a native 64 bit arch is going to be fast.
The second is more subtle and of far more import: with a 64 bit pointer you can address more than 4GB of RAM. Note that there are hardware hacks to allow a 32 bit x86 system to use more than 4 gigs but they require operating system support and are very nasty and costly in performance terms. This HUGE address space allows extremely large applications such as databases (4GB isn't actually that large these days) to exist efficiently.
Auroras Implementation: Aurora linux currently only supports a 32 bit userland. This means the kernel exists in 64 bit space allowing it to use more than 4GB of memory. Programs however are limited to 4GB of memory per thread or program (e.g. 2 programs could use 8GB total). Work is currently being done to bring a 64 bit userland into useability. As you can imagine this is real in depth programming.
![[Home]](/wiki.gif)