bug on BTX

[Bruce M. Simpson]

Hi all,

FYI, this change adds  32 bytes to btx leaving 139 bytes free, according 
to btxld(8). As you probably all know, and just as a reminder, size in 
boot2 is at a premium -- it can't go over 8192 bytes as this is the 
boot-sector limit in the BSD disk-label.

Dominic Marks wrote:
> John Baldwin wrote:
>>
>> Hmm, are you willing to test a change that should fix that?  If so, 
>> try http://people.freebsd.org/~jhb/patches/btx_crx.patch  You'll need 
>> to do a 'make clean && make && make install' in /sys/boot after 
>> applying, and if the make install suceeeds, do a 'bsdlabel -B ad0s1' 
>> (replace ad0s1 with the actual slice you boot from).  I think it 
>> should work (I think it was tested a while ago, but boot2 used to not 
>> fit, now it does though).  Be warned though that if it doesn't work, 
>> you won't be able to boot from your disk.  If that happens and you 
>> have a 6.x disc 1 lying around, you can boot into rescue mode and 
>> re-run 'bsdlabel' and move boot/loader.old to boot/loader on the root 
>> partition to get your system back.  Ideally you'd try this on a 
>> system with data you don't care about (i.e., it's ok to just do a 
>> reinstall if it is hosed).

It would be a good thing to solve the real mode problem, as it would 
enable FreeBSD to be booted from memory stick, USB CDROM, and within 
QEMU without resorting to the current workarounds e.g. using GRUB or 
skipping /boot/loader entirely to boot the kernel directly as I 
currently do in QEMU virtualization.

It's pretty important in the big scheme of things as it helps to bring 
FreeBSD to a wider audience. Many people out there may well have run 
into this without

Indeed I recently ran into this myself. Certain 1U machines which I 
acquired had problems booting from USB CDROM. I traced this back to the 
USB BIOS trying to LGDT and causing a general protection fault in vm86 
mode. I worked around this by PXE booting them on a private VLAN with 
most helpful assistance from dwhite at .

The long term solution we've been discussing is to change btx to 
trampoline into real mode before invoking certain INTs. I've been doing 
some tests with QEMU and Etherboot; it looks like its PXE UNDI driver 
sets up the NIC interrupt vector *before* BTX is called; it does not 
call LIDT in any of its paths. Its PXE entry point does however call 
LGDT to enter protected mode which of course kills BTX stone dead as 
we're in vm86 mode at that point.

Per my IRC discussions with jhb@ : given that BTX reflects the hardware 
interrupts, we shouldn't need to reprogram the AT-PICs; indeed GRUB does 
not. This was one of his concerns. We can probably get away with a 
simple trampoline a la GRUB providing the INTs invoked by BTX or LOADER 
don't attempt to rewrite or redirect interrupt vectors once we're up and 
running.

If time permits I may try to make the changes to BTX myself, however, I 
am always happy to review patches and provide feedback with a view to 
getting the problem solved going forward.

Best,
BMS