tek@cs.ucla.edu (Ted Kim (ATW)) (09/19/89)
In article <1232@brazos.Rice.edu> adoyle@bbn.com (Allan Doyle) writes: >X-Sun-Spots-Digest: Volume 8, Issue 109, message 8 of 12 > ... >Obviously, I'm getting bitten by boot code that was configured for a 68030 >with native MMU, or am I? What is going wrong here? How do I fix it? Once >I get the sucker to boot, what else is going to bite me. I noticed a bunch >of symbolic links in /usr/shar/mdec that are CPU specific. You will also have to change /boot and your boot block that is installed with the installboot(8) program. Also you will want to run with a different set of /usr/kvm stuff. >The real question is: How do I put the 280 CPU into the system with the >shortest turnaround? The path of doing a new installation of 4.0.3 each >time I swap CPUs will probably work but takes too long. (The client after >all, likes short repair times...). We have a similar problem switching between 3/60s and 3/80s. I don't have a general solution, but here is what I do to cut down the work. Get a sun3 /usr/kvm and a sun3x /usr/kvm and put them somewhere convenient. Then make /usr/kvm a symbolic link to the appropriate directory. When you want to switch put a new kernel in, a new boot, switch the symbolic link and you are ready. Note that all the other processor specific stuff like /usr/mdec and /usr/stand all are really symbolic links to /usr/kvm anyway, so those are all handled automatically. Some things to watch out for: 1. I put the relocated /usr/kvm in the root under /export/exec/kvm/{sun3,sun3x}. Make sure you remove the normal symbolic links there and that you have enough space in your root before trying it. 2. In addition, the symbolic links (for processor types) in your relocated /usr/kvm have to be adjusted to point properly to "true" and "false". 3. You should be aware that the dynamically version of libkvm is in your relocated /usr/kvm. Therefore, your relocated kvm should be in a partition that is mounted early in booting like / or /usr. Otherwise you have to modify the /etc/rc* files. Good luck! As in all experiments of this nature, you should very careful and have a way to backout/recover. Otherwise, you may find yourself with an unbootable system. -ted #include <disclaimer.h> Ted Kim ARPAnet: tek@penzance.cs.ucla.edu UCLA Computer Science Department UUCP: ...!ucbvax!cs.ucla.edu!tek 3804C Boelter Hall PHONE: (213) 206-8696 Los Angeles, CA 90024 ESPnet: tek@ouija.board