DrCereal wrote:
Well, I ran the command after putting test.bin back on to the flash drive, and GRUB loaded correctly and booted into the test file. :/ So the problem is most likely my machine.
The test with QEMU would still utilize QEMU's own BIOS instead of the machine's. If the problem lies within the BIOS, the difference in the behaviour is expected.
DrCereal wrote:
right? GRUB hangs right before printing "loaded". I have no access to the grub command prompt. After a little more testing, I found that GRUB or the BIOS (I don't know the details on how GRUB works.
) is consistently reading from my flash drive while it hangs. My guess is either that that GRUB is taking a very long time to load (I timed a boot, and it didn't load after 25+ minutes), or it can't load at all; I.e., BIOS loads the bootsector of GRUB, but GRUB can't finish loading.
The 'GRUB loading.\r\n' message is printed in pieces of 4: 'GRUB', 'loading', '.', and '\r\n'.
The message 'GRUB' is printed by the
code inserted into the BPB (since the image is partitionless, LBA 0 has the BPB.)
After printing 'GRUB', the code reads a sector from the disk to load what it calls the 'kernel'. The 'kernel' prints the other 3 message chunks:
here,
here, and
hereIn between the printing of the two messages, 'GRUB' and 'loading', boot.S reads the 'kernel' using either LBA, or CHS if LBA mode isn't available, or the floppy mode if CHS geometry isn't available. So, GRUB is stuck somewhere here, feverishly reading the disk.
In place of GRUB, a custom boot loader, which verifies the presence/absence of LBA, or proper CHS geometry, of the value of the drive number assigned, and of other factors, can help expose the cause.
Alternatively, GRUB can be modified, recompiled and reinstalled on the flash drive to carry out the required checks.