From owner-freebsd-bugs@FreeBSD.ORG Mon Jan 9 07:30:13 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 904181065675 for ; Mon, 9 Jan 2012 07:30:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3D5378FC12 for ; Mon, 9 Jan 2012 07:30:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q097UCne026939 for ; Mon, 9 Jan 2012 07:30:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q097UC7i026938; Mon, 9 Jan 2012 07:30:12 GMT (envelope-from gnats) Resent-Date: Mon, 9 Jan 2012 07:30:12 GMT Resent-Message-Id: <201201090730.q097UC7i026938@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Garrett Cooper Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEEC6106566B for ; Mon, 9 Jan 2012 07:25:33 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id CDB068FC13 for ; Mon, 9 Jan 2012 07:25:33 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q097PXTv061228 for ; Mon, 9 Jan 2012 07:25:33 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q097PXsJ061227; Mon, 9 Jan 2012 07:25:33 GMT (envelope-from nobody) Message-Id: <201201090725.q097PXsJ061227@red.freebsd.org> Date: Mon, 9 Jan 2012 07:25:33 GMT From: Garrett Cooper To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: bin/163943: bsdinstall fails to detect CD device when booting with some media devices X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 07:30:13 -0000 >Number: 163943 >Category: bin >Synopsis: bsdinstall fails to detect CD device when booting with some media devices >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jan 09 07:30:11 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Garrett Cooper >Release: 9.0-RELEASE >Organization: iXsystems, Inc. >Environment: FreeBSD freebsd-release.local 9.0-RELEASE FreeBSD 9.0-RELEASE #0: True Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: I started reinstalling 9.0-RELEASE on a handful of test boxes at iXsystems, and the problem I've run into is that /dev/iso9660/FREEBSD_INSTALL doesn't exist as the IPMI-provided virtual CD drive (/dev/cd1) isn't attached to the system yet. If I use ? at the panic screen and wait long enough, eventually the device and the label will appear, but not until then. That being said I've also seen the issue with a handful of physical media drives as well with earlier 9.0 BETAs and RCs. This issue no doubt also will occur with some USB media, given past experience with sysinstall. >How-To-Repeat: 1. Get access to the IPMI controller on a Supermicro box that's x86_64 capable. 2. Mount the 9.0-RELEASE-amd64 image via the virtual media manager. 3. Boot from the virtual CD drive. >Fix: There are a couple ways to either resolve or work around this issue. 1. Set kern.cam.boot_delay to 20 seconds on the install media. This should quickly hack around the problem. 2. Rewrite the installer to instead bootstrap from an mfsroot, like sysinstall, then 'pivot' the root over to the CD, USB, etc media once it becomes available (a dumb while loop with a timeout should suffice). A detection mechanism for PXE booters should probably be added as a special case as I'm sure someday someone will hack the 9.0+ media to PXE boot. 3. Some other ata/cam fix could probably be applied to fix the overall general case, but I'm not sure what the solution might be... >Release-Note: >Audit-Trail: >Unformatted: