OSDev.org

Hello, I've been trying to get a basic kernel to run on my physical machine since I started looking at OS programming, but I can never seem to do it.
This time, I decided I was going to use GRUB.

The only file to be loaded as the "kernel" (as this "kernel" is for testing) is an assembly file called "boot.s" that contains the necessary code to print a '0' to the screen and hang.
I assemble and "link" the file using a gcc cross compiler to produce a binary file "test.bin".

To setup my flash drive for the booting, I followed these instructions in the wiki, "https://wiki.osdev.org/GRUB_2#USB_instructions", but instead of "/media/YourLabel", I used my own mount point "/mnt/temp".
I then created the file "/mnt/temp/boot/grub/grub.cfg",

I then moved the test.bin file to it's rightful locaton ("/mnt/temp/boot/test.bin"), and I was done.

I booted from this flash drive in qemu with the command (/dev/sdb is the flash drive I installed GRUB to),

and it worked fine, producing the intended "0" in the console. I then rebooted my 64-bit machine from this flash drive, and it hung at the text (the "_" is the cursor),

This is my first time trying to use GRUB, and I'm not sure why it's hanging. I did a little bit of Google searching, but I couldn't find anything related to OS development. Do any of you guys know what I'm doing wrong?
(Sorry if I'm being a total n00b. I have little experience with booting OSs on physical machines.)

Is your binary a multiboot file?

Do you mean it has a multiboot section?
If so, then yes it does. This code is at the top of the only file being assembled, boot.s:



If it would help you, this is the linker script:

From your brief description it looks as though grub has been installed to expect to find the kernel in the directory /boot on the first hard drive on your computer. (I'm looking at the qemu command.) On your physical computer the flash drive is not the first hard drive; this is why you get the grub command prompt.

Read the grub documentation to see what commands you can use to boot your kernel from this command prompt. Or, disconnect all hard drives and optical drives and try again.

If you are using grub2, read this: https://www.linux.com/learn/how-rescue- ... ub-2-Linux

Huh? Shouldn't GRUB(2) by default set as "root" the drive from which it booted (unless you set it to something else)?

Whatever the cause of the problem, it's a good idea to learn how to boot a system from the grub command prompt. There are a host of things that can go wrong, particularly when you add or remove disks.

BTW, I assume this computer uses a conventional BIOS rather than UEFI.

So, what would you suggest?

Sorry for any ambiguity. When GRUB first loads, it presents the message,

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.

Furthermore, I deleted my binary to see if it had any effect. It's not a surprise to say that qemu's-boot presented a GRUB error while my actual computer hung at GRUB's load screen like before.

I'm going to try using a different flash drive to see if it works, and I'll fiddle around with my BIOS a little bit to see if a setting is inhibiting GRUB to boot from the flash drive.



I'm not sure what you mean. My BIOS uses CSM and is currently in Legacy-only mode. Is this alright?

Try passing the USB drive to QEMU as a usb device, like so:


hostbus and hostaddr are the Bus and the Device parameters of the
corresponding USB drive as seen under the host (check lsusb command on the host.)

This is to prevent qemu from treating the USB drive as a file.

Hopefully, the problem seen with the physical machine reproduces, and that may provide an easier way to debug.

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.

I am not sure what the problem is, but assuming that it is incorrect "root" setting, "root" is derived from "prefix", and grub-install hardcodes this setting with the device name - using either the early GRUB configuration script (which is executed before grub.cfg) or another module inside core.img specifically for that setting. grub-install also uses the filesystem UUID through "search.fs_uuid" if possible, rather than just the bus device name. Probably, because FAT32 does not have true UUID, this does not happen. On the other hand, the "prefix" setting can be specified without device name, in which case, it should default to the boot device.

First, the OP can try "ls" on the GRUB prompt to determine which device holds the image (as described here), check if it matches "echo $prefix" and "echo $root", and possibly correct them and boot manually. Assuming a manual boot is at all possible, one solution is to try to place a "search" command in grub.cfg with the "--fs-uuid" argument derived from the output of blkid in qemu. If that does not work, another possibility is to use grub-mkimage directly, as described in the same OSDev wiki page in the floppies section (with the "-p" argument specified without device name) and then write the boot images with grub-bios-setup.

Edit: Forget about it. Didn't read the OP's post, in which they pointed out that the prompt is unavailable and GRUB fails to move past the boot sector code.

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.



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
here

In 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.

That might explain why GRUB is having such difficulty. What's in the first sector of your disk? A problem with the BPB might cause the CSM to hang trying to calculate the disk's geometry, or perhaps GRUB is asking for an LBA outside the CSM's supported range.

It's also possible there's a bug in the CSM that makes it unable to boot from an unpartitioned disk, so you may want to try partitioning your USB disk and installing GRUB to the MBR.

That wasn't supposed to be a suggestion, but a question regarding your statement, which simeonz answered:

So it doesn't look like a wrong root setting, at least I don't see how it would make GRUB hang instead of a simple error message that GRUB cannot find the kernel file.

Indeed. I didn't read through the posts carefully.

Considering what the other posters have pointed out, it may be worth using a Windows box or any other method to format the USB, if one is available. The CHS setting in the BPB may be for some reason problematic to your firmware. Also, since apparently some exceptional motherboards may fix-up the BPB before booting the stick, according to this patch, it may be worth comparing the boot sector prior to and after booting from the pc.

Interestingly, the boot sector code, which uses very similar logic for LBA and CHS reading has read successfully the kernel sector of the core GRUB image. In any case, for a fast trial, it may be possible to simply disassemble and then patch the CHS conditional branch in diskboot.img (i.e., the one located in /usr/lib/grub/i386-pc/ - make backup first) (Edit: I realized it may be unclear what I meant here. I don't mean disassemble and reassemble, but disassemble to find the offset of the branch and edit the instruction opcode byte.)