Re: Booting from usb hard disk

On Tue, 2009-03-24 at 00:46 +0100, Paul B. Mahol wrote:
> On 3/23/09, Robert Noland <rnoland_at_freebsd.org> wrote:
> > On Mon, 2009-03-23 at 11:41 -0400, Douglas Berry wrote:
> >> On Mon, 23 Mar 2009 05:36:15 CDT, Robert Noland wrote:
> >> > So I have my i386 install on a usb hard disk, which I can only boot
> >> > on one machine now.  The one machine that I can make work has a bios
> >> > option that reads "BIOS ehci handoff".  This used to work with the
> >> > old usb stack.  The machines that it doesn't work on, boot the
> >> > kernel, but fail to mount root, giving me the forbidding mountroot>
> >> > prompt, which is immediately followed by the message saying that da0
> >> > is attached.  da0 is however not listed in the available boot
> >> > devices list.  I tried playing around with the timeout in
> >> > vfs_mount.c, but that didn't seem to have any impact.  It has been
> >> > suggested that this may be a "geom" timeout, but I don't know
> >> > anything about the boot system really.
> >>
> >> I have been using tunefs(8) labeled partitions on my usb hard disk
> >> under CURRENT. I changed the fstab entries to match the labels
> >> (eg. assume mylabel is myroot, /dev/da0s1a becomes /dev/ufs/myroot)
> >> It works well on most systems.  On some systems, I see the symptom
> >> you show, but I am saved by the labels showing up just after the
> >> mountroot prompt.  I am then able to type
> >>
> >> 	ufs:/dev/ufs/myroot
> >>
> >> and resume the boot.  Maybe this helps you?
> >
> > Well, I haven't tried labeling the partitions, but ufs:/dev/da0s1a
> > doesn't work from the rootmount> prompt.  Even after da0 shows up.
> 
> That is strange, I just recently have used one of usb sticks (256MB) to fix
> stupid sysinstall error. In my case da0 appeared after some delay but
> usual da0s1a appeared after ? and I was able to mount root
> partition multiple times.
> I used usb via modules, on i386 revision r190297, with "boot -s"
> (I hacked fbsd installation on stick because I didnt have time for fine
> details ....)
> 
> Could try just with uhci (but it will be too sloow)

So, my final work around was to set the tuneable
kern.cam.scsi_delay=10000.  That is probably too long, but it worked and
I haven't had any issues since.

robert.

> 
-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD