> 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@.
>
> 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
we encountered the same problem when trying to boot pxe the PCEngines/WRAP
so if you need testers, i'm willing.
danny