Date: Mon, 19 Feb 2001 13:55:04 -0800 From: Mike Smith <msmith@freebsd.org> To: Mark <mark@etinc.com> Cc: freebsd-questions@FreeBSD.ORG, dennis@etinc.com, sos@FreeBSD.ORG Subject: Re: FreeBSD cant boot from ZIP - Is it true? Message-ID: <200102192155.f1JLt4c00783@mass.dis.org>
next in thread | raw e-mail | index | archive | help
(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.
>
> <fontfamily><param>Times New Roman</param>afd0: 239MB <<IOMEGA ZIP 250
> 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:
>
> <<fstype>:<<device> Mount <<device> using filesystem <<fstype>
> eg. ufs:/dev/da0s1a
> ? List valid disk boot devices
> <<empty line> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102192155.f1JLt4c00783>