Loading a kernel directly using boot2 causes the invalid-opcode fault like the following: int=00000006 err=00000000 efl=00010046 eip=c0300000 eax=002ff000 ebx=000213d0 ecx=00000000 edx=a030ff1e esi=00018504 edi=0008eb78 ebp=0008ebc8 esp=0000940b cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 cs:eip=ff ff ff ff ff ff ff ff-7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ss:esp=36 80 0d 07 90 00 00 01-e9 ba fc ff ff aa ac 84 c0 0f 84 86 00 00 00 a8-80 74 f2 88 c5 b0 3d aa BTX halted This is using a GENERIC unmodified amd64 kernel (installed from HD from DVD iso source (11p1) and trying /boot/kernel/kernel at boot: prompt. SAS/SATA drive environment. Tested both MBR and GPTBOOT versions of boot2 (/boot/boot and /boot/gptboot)-no joy. /boot/loader works with no problem as well as just press [return] at the prompt. We need this feature to be working in our secure server environments (bypassing the loader and directly booting a highly customized, self contained kernel). RE: boot(8) man page, 'it is possible to dispense with the third stage altogether'. However, hitting a key and specifying '/boot/kernel/kernel' results in hard stop (impossible to reboot with crtl-alt-del) after BTX halted message--requires power cycle. Booting '/boot/loader' works ok. Thanks in advance. -Mark
AFAIK, this boot mode has never been supported for amd64.
As I understand the theory of boot0/boot1/boot2/loader operations, boot2 should have all the registers, bios calls, and setup correct for direct execution of the kernel. Assuming, of course, that the kernel has everything that it needs compiled into the kernel [with the exception of kernel modules] and does not need any of the modifications or the boot time services, e.g. device.hints, loader.conf, etc., that the loader would supply. Assuming there is no support for AMD64s in boot2 then-- 1) there is no support for any 64 bit based CPUs (intel or amd), effectively limiting its use for booting directly into the kernel to ancient 32-bit i386 machines 2) boot.config, for the same purposes, will not work 3) boot2 cannot be used to bypass loader problems on 64 bit machines 4) boot2 can only be used to look at or changing certain temporary variables, select a different loader (very unlikely), or to fiddle with video/serial console options 5) the documentation is in error in a number of places (e.g. handbook, man, internals) and needs to note this major limitation so that others don't go down rabbit hole as well. I did do some additional checking and it appears that you are correct at least as far back as FreeBSD 8.x. A similar error/outcome came up on a different server/bios/config. I also noted that boot2 does say 'FreeBSD/i386 BOOT' at its prompt (although, since i386/amd64 are the core lines for freebsd I've always thought of i386 as a subset of AMD64--anything i386 could do amd64 could do better--guess I was wrong). Is it possible that AMD64s *could* work if the appropriate device.hints were statically linked in the kernel itself as well as any other "external" required setup done by the loader at boot time is compiled in or is there something fundamental about the architecture/BIOS support that makes this unlikely?
12.0-release r341666 generic amd64 The situation exactly as it is described above, boot2 can not directly boot kernel. I have found two other cases : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=84555 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=96430 It looks like boot2 can never boot kernel directly.