Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!mit-eddie!uw-beaver!rice!sun-spots-request From: ji@read.cs.columbia.edu (John Ioannidis) Newsgroups: comp.sys.sun Subject: Re: making xd1 bootable Keywords: SunOS Message-ID: <8905072007.AA28711@read.cs.columbia.edu> Date: 11 May 89 07:54:50 GMT Sender: usenet@rice.edu Organization: Columbia University Department of Computer Science Lines: 31 Approved: Sun-Spots@rice.edu Original-Date: Sun, 7 May 89 16:07:28 EDT X-Sun-Spots-Digest: Volume 7, Issue 282, message 9 of 19 In article <8905011601.AA08948@natinst.com> you write: >X-Sun-Spots-Digest: Volume 7, Issue 273, message 19 of 23 > [Description of how the author tried to boot from xd1 after cloning > xd0 on it and ended up with root and swap on xd0] The kernel (/vmunix) that you had on xd1a was either a generic kernel or a `config vmunix root on xd swap on xd' kernel. The boot program correctly loaded vmunix from xd1's root partition, but after the kernel was given control, it used the first device that matched the config file specification, namely xd0a nad xd0b respectively. To make it boot off of xd1 without resorting to b -a, make a new kernel whose config clause is config vmunix root on xd1 swap on xd1 and put that in xd1a's /vmunix (don't replace /vmunix in the original root disk, xd0a). Now, if you boot from xd(0,1,0) either manually or by setting it as the default path using eeprom(8), you should get your root and swap filesystems on xd1a and xd1b respectively. Also, make sure that /etc/fstab on xd1a contains the proper entries for /, /usr etc. (/dev/xd1a / 4.2 rw 1 1 etc), otherwise you are in for a surprise after fsck is done. /ji #include In-Real-Life: John Ioannidis E-Mail-To: P-Mail-To: 450 Computer Science, Columbia University, New York, NY 10027 V-Mail-To: +1 212 854 5510 ... It's all greek to me