From owner-freebsd-alpha Fri Jul 21 16:14:44 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from phy.ucsf.edu (phy.ucsf.edu [128.218.64.200]) by hub.freebsd.org (Postfix) with ESMTP id 32F1737C145; Fri, 21 Jul 2000 16:14:40 -0700 (PDT) (envelope-from dkleinh@phy.ucsf.edu) Received: from amadeus.ucsf.edu (dkleinh@amadeus.ucsf.edu [128.218.65.107]) by phy.ucsf.edu (8.10.1/8.10.1) with ESMTP id e6LNEdk26235; Fri, 21 Jul 2000 16:14:40 -0700 (PDT) Received: from localhost by amadeus.ucsf.edu (8.8.6) id QAA22550; Fri, 21 Jul 2000 16:14:39 -0700 (PDT) Date: Fri, 21 Jul 2000 16:14:39 -0700 (PDT) From: Dirk Kleinhesselink X-Sender: dkleinh@amadeus.ucsf.edu To: wilko@freebsd.org Cc: "Jordan K. Hubbard" , mjacob@feral.com, alpha@freebsd.org Subject: Re: 4.1-20000719-RC#2 In-Reply-To: <20000722002214.A22611@freebie.demon.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I got the problem on my PC164 system with, if I remember correctly, Tru64 on my one SCSI disk and Linux on the 2nd IDE disk. I was going to replace the Tru64 with FreeBSD on the SCSI disk. I also installed NetBSD on the SCSI and got the problem. I may have also wiped the SCSI disk using linux making a DOS style partition table and Linux ext2 filesystem but it still failed by having Linux bootable on the ide disk. On Sat, 22 Jul 2000, Wilko Bulte wrote: > On Fri, Jul 21, 2000 at 01:57:08PM -0700, Dirk Kleinhesselink wrote: > > Is there any ordering involved? Meaning that the FreeBSD install is > aimed at a disk with a higher SCSI ID than the existing T64/VMS/whatever > disk? > > Does it matter if it is a floppy boot or a CD boot? > > I cannot reproduce it here when aiming the new FreeBSD install at a > disk with ID0, so the 2 other disks with T64 and FreeBSD respectively are > obviously higher numbered ones. > > Long shot.. > > W/ > > > At least for myself and several others who had this problem: > > > > you will never get to the install setup up if your system already has a > > BSD (Tru64/NetBSD/Linux (using BSD disk label) and from Matt's example, a > > FreeBSD disk with the /sbin/init clobbered) or OpenVMS system disk. > > FreeBSD will load the kernel, load the install MFS but then will fail to > > find the MFS init routine -- I guess it will try to look for it on the > > BSD/VMS disk and will fail to find it. > > > > On Fri, 21 Jul 2000, Jordan K. Hubbard wrote: > > > > > > > > > > > > > > > Seems like it would be an easy thing to try to reproduce: just put a > > > > > couple of disks on the system and install Tru64/NetBSD/Linux/OpenVMS on > > > > > one of them and then try to install FreeBSD on the other disk... > > > > > > > > You don't even have to do that. Just take a previous FreeBSD installation and > > > > move /sbin/init aside and create a zero length /sbin/init. > > > > > > I'm still not sure I understand how that should have any effect. > > > You're doing an install here, right? And the install is going to > > > newfs the root filesystem and repopulate it with distribution bits, > > > right? > > > > > > If you're somehow electing to preserve the existing root partition > > > and/or not extract, at a minimum, bindist then this isn't an > > > installation at all, this is some sort of "you must know what you're > > > doing well enough not to shoot your feet off" quasi-upgrade operation. > > > Please clarify. Thanks. > > > > > > - Jordan > > -- > Wilko Bulte http://www.freebsd.org > wilko@freebsd.org http://www.nlfug.nl > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message