Help! Invalid Instruction...

Chris Z
  • Chris Z
    Chris Z

    Hello everyone.

    Does anybody have experience building Gujin in a pure 64 bit environment? I found the first problem was when I tried to run instboot and it reported the MBR was 548 bytes.

    I went through the instboot.c and instboot.h file, and meticulously replaced every reference to long with int, and every reference to long long with long, and this at least gave me an MBR structure that was 512 bytes, but now, when I try to boot, I get the following:

    Have found 1 disks:
    0: EBIOS 0x80 (*), size 7647 Mb, 4 partitions.
    sizeof struct desc_str: 64, sizeof struct BOOTWAY_str: 16
    Analyse filesystems:    found 0 ways to boot and 0 initial RAM disks

    INVALID INSTRUCTION at address 0x5008 (content: 0x0 0x8EFFF), codeseg 0x17C0, xcodeseg 0x2298
    INVALID INSTRUCTION at address 0x5008, codeseg 0x17C0 xcodeseg 0x2298 dataseg 0x3688
    Invalid code (check corruption with boot.asm): 0xFF, 0xEF, 0x8, 0x0, 0x0, 0x0
    eax = 0x0 ebx = 0xEFA5ABFB ecx = 0x0 edx = 0x7
    edi = 0xEE0008 esi = 0x5AE8 epb = 0x4 flags = 0x246
    cs = 0x17C0 ds = 0x3688 es = 0x3688 xx = 0x3688 esp = 0xFDA2

    Press PAUSE to stop display...

    Has anyone ever tried this before? Is this because I have missed some references somewhere, or am I simply not configuring the bootloader correctly.

    For reference, I am installing to an Intel D945GCLF Atom board running a Linux From Scratch pure 64 bit OS onto an 8GB  USB thumb driver that is configured with 4 ext2 partitions, and gujin is installed in the B.E.E.R. partition.

    I accomplished this with:

    instboot boot.bin /dev/sdb0 --disk=EBIOS:0x80,auto --mbr-device=/dev/sdb --usb_hdd
    Reprint: instboot boot.bin /dev/sdb0  \ Reprint:    --cmdline="" \ Reprint:    --geometry=65536,15596536,32,32,512,15662080,0,32,32,512 \ Reprint:    --disk=EBIOS:0x80,auto --fs=FAT:65536,4,11,1,2,16,0x80,0xF8 \ Error: Cannot process USB_HDD patch when Gujin2 loaded without standard BIOS
    try verbose mode with '-w'
    Reprint:    --beer-device=/dev/sdb --mbr-device=/dev/sdb
    You asked to create a new FAT filesystem on B.E.E.R. device of '/dev/sdb',
    and so ERASE completely this partition, confirm [NO/yes]: yes
    Finishing write (flushing buffers) and then checking...

    Partition 1 is formatted as ext2 and marked as active, and has a file called linux- which is bootable. There is also a SATA drive plugged in which has several other bootable linux bzImage kernels.

    First, why did it not find my SATA disk? The BIOS is Intel and very modern.

    Second, it clearly found the USB thumb drive. Why could it not find the linux kernel in the active ext2 partition?

    Finally, what is going on with the INVALID INSTRUCTION message?

    Can anyone give me some suggestions on how to proceed? Has anyone ever successfully managed to get to gujin to work on a 64 bit architecture?

    Thank you in advance for any assistance,


    • Chris Z
      Chris Z

      This is an update to the current issue:

      I completely rebuilt gujin starting over from source. I made 2 directories, each including the source of gujin. The first I left alone, and in the second I performed the following series of sed scripts on every file:

      for name in *; do
      sed 's/long long/DBL_LONG/g' < $file > $; mv $ $file
      sed 's/long/int/g' < $file > $; mv $ $file
      sed 's/DBL_LONG/long' < $file > $; mv $ $file
      sed 's/%ll/PRINTF_LONG/g' < $file > $; mv $ $file
      sed 's/%l/%/g' < $file > $; mv $ $file
      sed 's/PRINTF_LONG/%l/g' < $file > $; mv $ $file

      I then compiled boot.bin in the original directory using no special procedures. ( I needed to change USER_SUPPORT =USER_STD and include BIOS_ONLY in the original directory to get it to fit in the .text segment. Otherwise, everything was left unmodified.) I then compiled instboot in the second directory using the 64 bit model.

      I tried several other combinations trying to build them in the same directory, but this is the only thing that worked for me. With a new instboot from the 64 bit directory and boot.bin from the 32 bit directory, I did the following:

      instboot boot.bin /dev/sdb0 --disk=EBIOS:0x80,auto --mbr-device=/dev/sdb --usb_hdd

      After completing this and rebooting, I now get a boot loader on my USB thumbdrive and it finds /boot/vmlinuz on my SATA disk.

      I only have 1 problem left. It will not recognize /boot/vmlinuz on the ext2 partition on my USB stick. Can anyone suggest a reason why this is happening?

      Thanks for any assistance,


    • Hello Chris,

      Basically, I also tried to compile Gujin with GCC in 64 bits mode, and its code size was completely different (bigger) than GCC in 32 bits mode - and Gujin was not working.
      Note that the Makefile correctly passes the "-m32" option to gcc-64, so there should not be any modification of code needed: I assume that "gcc-64 -m32" will have long of 32 bits and long long of 64 bits.

      Because it was not working for me neither, I assumed a GCC bug: shouldn't GCC produce the same executable in 64 or 32 bits mode, when the "-m32" flag is passed? I think that is more a question to direct to:
      I did not analyse the assembly generated by "gcc-64 -m32" so cannot say for sure this cross compiler has a problem - and which version of GCC. Maybe newer GCC works without problem.

      For the USB disk, most BIOSes only start the USB emulation when they are using this emulation to boot, i.e. if you boot from hard-disk the BIOS do not have the USB disks accessible (to save the USB enumeration time).
      Also you may want to try to add option "--stop_emulation=0" to instboot in case your BIOS re-used the CDROM BIOS calls to map USB BIOS.


    • Chris Z
      Chris Z

      Thanks for your response Etienne.

      My problem was, if I tried to compile instboot with CFLAGS = -m32, I received many, many errors about incompatible header files. I didn't have time to trace this down, so I left it compiling with -m64, being host only code.

      The boot.elf file, on the other hand, did compile with -m32, but you are correct that the code size is bigger. I believe this has something to do with the model GCC is using, to make sure that the code can still be linked with 64 bit binaries and libraries, and call in and out of 64 bit applications. This is probably wrong as a general rule, but in my case it helps, because I ONLY have 64 bit libraries available due to space concerns. I can't afford the extra disk overhead for a 32 bit multilib setup.

      In any case, except for a slightly larger boot.elf file, gujin is working for me. The file issue I reported above was because I had vmlinuz soft linked on my USB drive and hard linked on my SATA disk. Oops. I guess gujin does not follow softlinks.

      In any case, yours is officially the ONLY bootloader I could find that can both compile natively in a 64 bit environment, and boot off a USB thumbdrive. The only other contender is Lilo, and it fails for some unknown reason during the second stage boot loading when used on the USB disk. All the other boot loaders require 32 bit libraries, which I don't have.

      So, congratulations. If it wasn't for your project, I would officially not be booting my computer today.

      Great job. If you ever get to Thailand, I'll buy you a beer.


    • Hello Chris,

      Well, the Makefile take care of the -m32 option, obviously the installer and the other few utilities
      should not be compiled with "-m32" because it should run in 64 bits environment.
      boot.elf - even stripped from debug information - is bigger, and I am not sure it is not a bug or
      some missed optimisation from GCC. I do not think you can link any "-m32" application with 64 bits
      libraries. Gujin do not need any library at all - only its installer do.

      Because Gujin only manage one partition and one filesystem at a time, it cannot deal with softlinks
      at all - it even only scan 1 level directory (root and /boot).

      BTW I am flying to Phuket on October 29th for a week liveaboard scubadiving and few days relax, for
      my first time in Thailand - and I can do beer.