i386/70525: [boot] boot0cfg: -o packet not effective

[Thomas Pornin]

The following reply was made to PR i386/70525; it has been noted by GNATS.

From: Thomas Pornin <pornin at bolet.org>
To: freebsd-gnats-submit at FreeBSD.org, hampi at 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