From owner-freebsd-questions Mon Feb 19 13:53:56 2001 Delivered-To: freebsd-questions@freebsd.org Received: from mass.dis.org (user-uinjtfm.biz.mindspring.com [165.121.245.246]) by hub.freebsd.org (Postfix) with ESMTP id 9E1B137B4EC; Mon, 19 Feb 2001 13:53:50 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f1JLt4c00783; Mon, 19 Feb 2001 13:55:05 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102192155.f1JLt4c00783@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mark Cc: freebsd-questions@FreeBSD.ORG, dennis@etinc.com, sos@FreeBSD.ORG Subject: Re: FreeBSD cant boot from ZIP - Is it true? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Feb 2001 13:55:04 -0800 From: Mike Smith Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (Mark, please don't send HTML mail to the list; your mailer produces *terrible* output.) > >> Whats the "trick"? > > > > There shouldn't be any trick; as long as you have the 'atapifd' driver > > in your kernel, and the correct entries in /etc/fstab on the disk, you > > should be fine. > > > > Where does the confusion arise? When you're trying to find the kernel, > > or when you're mounting root? Are you installing to the disk, or > > building a root filesystem manually? > > > > If you're having trouble mounting root, check what the kernel says it's > > trying to mount and if it's not /dev/afd0-something then you should > > suspect your /etc/fstab's / entry. > > > > The confusion arises between the boot loader and the kernel. The > ATAPI Zip drives emulate an IDE hard drive, so for example one installed > as the primary IDE master would show up as "ad0c" to the loader. Er, no, it doesn't. The loader doesn't use that nomenclature at all; disks are strictly identified by their order in the BIOS drive list, ie. disk0, disk1, etc. > If you then select > > 0:ad(0,c) kernel You aren't talking to the loader here, you're talking to boot2, which is not smart enough for this application. Boot2 will generally cause the root mount to fail unless it's on the first disk in the system. > and now / is being recognized as afd0c, not ad0c. I've tried both > entries in /etc/fstab, neither work. Of course they don't; you are bypassing the loader completely, which is where /etc/fstab is read. > This wouldn't seem to be a fatal problem, since FreeBSD will prompt you > for a manual location of /. But overriding the fstab doesn't work - > here's an old message containing a capture of this behavior, using a > Zip configured as /dev/afd0a. > > Times New Romanafd0: 239MB < ATAPI> [239/64/32] at ata0-master using PIO3 > > Mounting root from ufs:ad0s1a This is guaranteed to fail... > Mounting root from ufs:ad0sa This looks ugly; I get the impression that something is misformatting the second fallback hint. 8( > Manual root filesystem specification: > > <:< Mount < using filesystem < > eg. ufs:/dev/da0s1a > ? List valid disk boot devices > < Abort manual input > > mountroot> /dev/afd0a > > Mounting root from /dev/afd0a You really need a filesystem type here. > mountroot> ufs:/dev/afd0a > > Mounting root from ufs:/dev/afd0a Zip disks come from the factory sliced; depending on how you configured this one, you may well have needed afd0s4a (eg. if you just converted the DOS slice to a UFS slice), although the fact that the mount succeeded would suggest you're OK. > spec_getpages:(#afd/0) IO read failure: (error=0) bp 0xc1c78438 vp > 0xc5ae1d40 > size: 53248, resid: 32768, a_count: 53248, valid: 0x0 > nread: 20480, reqpage: 7, pindex: 51, pcount: 13 This is an I/O error (like it said). Stuff doesn't tend to work when you get these. 8) It's kinda ominous though that the residual is exactly 32k; this looks like a bad interaction with the code that tries to avoid bugs in the Zip firmware relating to large transfers. You might want to pursue Soren about this a bit more aggressively; I don't think he has a Zip 250, and whilst I can't see how the code could fail to detect it as a Zip and apply the fix, this *does* look _exactly_ like the bug I ran into the first time around. Can you boot with -v and verify that the transfersize limit is 64 blocks? I'm also worried that if the ATAPI queue ever got sorted, you might see the last fragmentary I/O complete *before* one or more of the early ones, which would be Bad. > I'm wondering if this kind of operation is even supported? There don't > seem to be any problems with the drive or the media, I can read and write > files w/o errors with the drive mounted on a running system. As I said, yes, it's supported. I worked on this a few years back, and part of that included making bootable FreeBSD Zip and LS-120 disks (in fact, until I converted to using PXE, I used to boot my test systems from LS120s). Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message