Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!mcnc!uvaarpa!murdoch!sasha.acc.Virginia.EDU!scl From: scl@sasha.acc.Virginia.EDU (Steve Losen) Newsgroups: comp.unix.aix Subject: rs6000 as diskless sun server Message-ID: <1991May28.122737.15826@murdoch.acc.Virginia.EDU> Date: 28 May 91 12:27:37 GMT Sender: usenet@murdoch.acc.Virginia.EDU Organization: University of Virginia Lines: 32 Originator: scl@sasha.acc.Virginia.EDU I finally managed to get a diskless sun 3/50 to boot from a rs6000. I already had the 3/50 booting off a sun server, but wanted to switch to the rs6000. I followed the instructions in /usr/etc/install/README on the rs6000. I copied over the root partition, /tftpboot stuff, enabled the bootparamd and tftpd on the rs6000 and ran the arp command, etc. I couldn't copy the /dev files (neither tar nor cpio would build them on the rs6000) so I had to build the /dev files for the 3/50 root on the rs6000 with MAKEDEV and that's where I ran into trouble. Evidently SunOS and AIX encode the major/minor device numbers differently, so when I booted up the 3/50, as soon as it tried to use a file in /dev, it bombed. When I ran "ls -l" on the rs6000 all the major/minor numbers were correct, i.e., identical to /dev on a sun. But when I NFS mounted the 3/50 root partition on a sun and inspected the dev directory with "ls -l", the major/minor numbers were completely different (and wrong). To fix the problem I had to NFS mount the 3/50 root partition read/write with root access on a sun and run MAKEDEV on the sun. This left the major/minor device numbers looking correct on the sun, but wrong on the rs6000. The 3/50 booted and ran fine, however. We are running AIX 3.1.3 on the rs6000 and SunOS 4.1 on the sun. Actually we are running "xkernel" on the 3/50, which essentially turns it into a X terminal. You boot up a very stripped down SunOS kernel and replace "init" with a shell script that runs a single process -- the X server. This makes a sun 3/50 with only 4M of memory quite useful. -- Steve Losen scl@virginia.edu University of Virginia Academic Computing Center