From hampi@rootshell.be  Mon Aug 16 09:40:01 2004
Return-Path: <hampi@rootshell.be>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id B573B16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 16 Aug 2004 09:40:01 +0000 (GMT)
Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 9099A43D46
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 16 Aug 2004 09:40:00 +0000 (GMT)
	(envelope-from hampi@rootshell.be)
Received: from gicco.homeip.net (80-218-73-163.dclient.hispeed.ch [80.218.73.163])
	by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id i7G9dwBG022715
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 16 Aug 2004 11:39:59 +0200
Received: from goofy.here (localhost.here [127.0.0.1])
	by gicco.homeip.net (8.13.1/8.13.1) with ESMTP id i7G9dpJN000982
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 16 Aug 2004 11:39:51 +0200 (CEST)
	(envelope-from idefix@goofy.here)
Received: (from idefix@localhost)
	by goofy.here (8.13.1/8.13.1/Submit) id i7G9dolN000981;
	Mon, 16 Aug 2004 11:39:50 +0200 (CEST)
	(envelope-from idefix)
Message-Id: <200408160939.i7G9dolN000981@goofy.here>
Date: Mon, 16 Aug 2004 11:39:50 +0200 (CEST)
From: Hanspeter Roth <hampi@rootshell.be>
Reply-To: hampi@rootshell.be
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: boot0cfg: -o packet not effective
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         70525
>Category:       i386
>Synopsis:       [boot] boot0cfg: -o packet not effective
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-i386
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 16 09:40:10 GMT 2004
>Closed-Date:    Tue Dec 02 22:55:36 UTC 2008
>Last-Modified:  Tue Dec 02 22:55:36 UTC 2008
>Originator:     Hanspeter Roth
>Release:        FreeBSD 5.2-CURRENT i386
>Organization:
>Environment:
System: FreeBSD goofy.here 5.2-CURRENT FreeBSD 5.2-CURRENT #2: Sat Aug 14 16:52:51 CEST 2004 uesr@goofy.here:/usr/src/sys/i386/compile/F5 i386


	
>Description:
	After running `boot0cfg -Bv -o packet /dev/ad0' the slices beyond
	the 1024th cylinder will be displayed but are no more accessible by
	the boot selector.
	Using an older boot0cfg (from 5.2-RC2) does work.
>How-To-Repeat:
	
>Fix:

	Since my FreeBSD slice is beyond the 1024th cylinder I have to boot
	a 5.2-RC2 rescue CD and perform boot0cfg. It works whether boot0
	is taken from 5.2-RC2 or from 5.2-CURRENT (Aug 7th). The only 
	difference is that the one from 5.2-CURRENT beeps when the menu
	is displayed which makes sense.


>Release-Note:
>Audit-Trail:

From: Thomas Pornin <pornin@bolet.org>
To: freebsd-gnats-submit@FreeBSD.org, hampi@rootshell.be
Cc:  
Subject: Re: i386/70525: [boot] boot0cfg: -o packet not effective
Date: Thu, 2 Sep 2004 18:59:41 +0200

 Hello,
 
 I got a similar problem with 5.3-BETA1 (from August 21st) and I have found
 the cause: boot0cfg gets the "packet" option reversed. If the most
 significant bit in byte 0x1BB is set, then the "packet" option is
 activated, since this is what is tested in sys/boot/i386/boot0.S:
 
                 testb $0x80,_FLAGS(%bp)         # Use packet interface?
                 jz intx13.1                     # No
 
 But in usr/sbin/boot0cfg/boot0cfg.c, the following array is set:
 
 static const struct {
     const char *tok;
     int def;
 } opttbl[] = {
     {"packet", 1},
     {"update", 1},
     {"setdrv", 0}
 };
 
 where the integer is set to 1 if the flag works in "reverse" (bit
 whecleared n the option is activated). The integer for "packet" is
 wrong: it makes boot0cfg believe that the "packet" option is set when
 the most significant bit in byte 0x1BB is cleared, and that the option
 is unset when the bit is set, whereas the assembly code in boot0.S
 believes otherwise.
 
 Therefore, right now, the quick workaround is to pass "-o nopacket" to
 boot0cfg to _activate_ the packet option, and to remember that when
 "boot0cfg -v" returns "nopacket", it means that the option is activated.
 
 
 A relatively clean fix would be to change line 64 in boot0cfg.c back to:
 
     {"packet", 0},
 
 but maybe it would be better to make the "packet" option the default,
 at least for new installations of the boot manager.
 
 
 	--Thomas Pornin

From: Brian Candler <B.Candler@pobox.com>
To: bug-followup@FreeBSD.org, hampi@rootshell.be
Cc:  
Subject: Re: i386/70525: [boot] boot0cfg: -o packet not effective
Date: Mon, 4 Dec 2006 11:24:40 +0000

 I see a related problem with FreeBSD-6.1: an initial install seems to set
 the MBR with -o nopacket, but explicitly doing "boot0cfg -Bv ad0" correctly
 sets -o packet in the MBR.
 
 I have not observed this directly in the MBR, but is based on the following
 sequence:
 
 - divide a 40GB HD into two primary partitions
 - install FreeBSD in the first 20GB, with its bootloader in the MBR
 - install OpenBSD in the second 20GB
 - the FreeBSD bootloader then offers
 
   F1 FreeBSD
   F2 BSD
 
   but F2 just beeps (i.e. cannot boot OpenBSD)
 
 - booting into FreeBSD and issuing "boot0cfg -Bv ad0" fixes the problem.
 
 Therefore my guess is that the initial installation of the MBR is setting -o
 nopacket, even though boot0cfg has -o packet as its default.
 
 Also reported at
 http://lists.freebsd.org/pipermail/freebsd-i386/2006-December/004892.html
 
 Regards,
 
 Brian.
State-Changed-From-To: open->closed 
State-Changed-By: luigi 
State-Changed-When: Tue Dec 2 22:54:42 UTC 2008 
State-Changed-Why:  
Report is no more relevant, boot0 and boot0cfg now have the same defaults. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=70525 
>Unformatted:
