gets stuck at "Booting first stage..." when chainloading via grub in an iso

[xacrimon]

Done some testing. Seems to happen after entering protected mode. CPU at 100% and frozen

[phil-opp]

Thanks for testing! I replied to you on gitter:

@xacrimon We only switch to protected mode for a very short time in the first stage, then we switch back to real mode (at the unreal_mode label). The println function should work again after this label.

[phil-opp]

@xacrimon Any updates on this?

[xacrimon]

Haven't had time.

…

On Mon, Apr 1, 2019, 14:26 Philipp Oppermann ***@***.***> wrote: @xacrimon <https://github.com/xacrimon> Any updates on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUDRh9yAK9_NN631RUhW1JkDGvi5G1pdks5vcfr-gaJpZM4bIIkd> .

[xacrimon]

Ill do some more research as soon as i have time. Probably wont be until May comes around.

[phil-opp]

Ok, thanks for the update!

[xacrimon]

Alright, haven't had much time but it seems to be a failure related to loading the rest of the bootloader @phil-opp

[xacrimon]

This is the output while running with qemu-system-x86_64 -cdrom tulip.iso

Booting (first stage)...
Failed to load rest of bootloader

and then it hangs

[xacrimon]

Alright. Ive tried to narrow the instruction down but i have had a hard time. I know spin doesnt get called since i dont get more output when placing the print instructions there. But everywhere else in stage1.asm seems to work. Wierd

[xacrimon]

Ah okay. If i dont supply the -cdrom flag to grub it doesnt call spin and get stuck with no error message. If i supply it it gives the load error and calls spin

[xacrimon]

Alright. Done some more narrowing down. It seems to fail silently and fall into a spin loop or something in stage_1.s line 105 where it jumps to stage 2.

104: lea eax, [stage_2]
105: jmp eax <- hangs here

[xacrimon]

but as i said, it doesnt get to print the booting second stage message so something going wrong when jumping.

[xacrimon]

It might be related to having issues loading. It may load some data that isn't the bootloader since locations get messed up when packed in an iso

[phil-opp]

It might be related to having issues loading. It may load some data that isn't the bootloader since locations get messed up when packed in an iso

Yes, that could be the problem. Could you try removing the "relocation_model": "static" line from the x86_64-bootloader.json file?

[xacrimon]

Will try!

…

On Mon, Apr 29, 2019, 13:05 Philipp Oppermann ***@***.***> wrote: It might be related to having issues loading. It may load some data that isn't the bootloader since locations get messed up when packed in an iso Yes, that could be the problem. Could you try removing the "relocation_model": "static" line <https://github.com/rust-osdev/bootloader/blob/f770e97f6c52420212ff69e7acfec6b4854a46ff/x86_64-bootloader.json#L20> from the x86_64-bootloader.json file? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFANDB2IB32JUFI26KRVX5DPS3JANANCNFSM4GZAREOQ> .

[xacrimon]

No dice. Still hangs without further output. No difference with the -cdrom flag either.

[ethindp]

Tried building a bootable ISO of my kernel using this bootloader with mkisofs (without grub) and it hung at stage 1. Unortunately I couldn't get any output because OCR was being unreliable. However, it hung both on VMware and virtual box, and I could only get it to boot via the .bin file.

[Redrield]

Tried to make a file with grub-mkrescue and told it to chainload to the file produced by bootimage, if I pass -cdrom it says it failed to load the rest of the bootloader in stage 1. If I don't it just hangs indefinitely at Booting (first stage)

[phil-opp]

@ethindp @Redrield Thanks for the reports! Unfortunately I don't have the time to look into this at the moment as I'm currently working on finishing my master thesis.

[64]

I've managed to get it working with grub.

iso/boot/grub/grub.cfg:

menuentry "BlogOS" {
    set root="(hd1)"
    chainloader +1
}

Then:

grub-mkrescue -o grub.iso iso
qemu-system-x86_64 -hda grub.iso -hdb target/x86_64-blog_os/debug/bootimage-blog_os.bin

---

The problem seems to be that if you just chainload with chainloader /file, then although the blog_os binary does get included and put on disk, the blog_os bootloader is expecting it to be the first thing on the disk (partition). With my method, the blog_os bootloader gets put in a separate disk from the grub bootloader (could also put it in a separate partition) so that it is actually the first thing that int 13h sees.

I'm not sure if there's a good way to get the chainload /file method to work - I don't see how you'd be able to locate the rest of the bootloader short of reading and parsing the ISO, which could be a lot of work.

[64]

Closing this for now. Let me know if there are further problems

[ethindp]

I am now running into this issue. How would I put the kernel onto another partition of the ISO so that int 13h sees it? I'd rather not distribute 2 files when an Iso should be good enough.

[phil-opp]

@ethindp

I am now running into this issue

Could you clarify what you mean with "this issue"? Do you mean that it gets stuck in the first stage?

How would I put the kernel onto another partition of the ISO so that int 13h sees it? I'd rather not distribute 2 files when an Iso should be good enough.

I never worked with GRUB chainloading, so I don't think that I can answer this question.

[ethindp]

Yes, it gets stuck when creating an ISO and attempting to boot the .bin file with it.

…

On 1/22/20, Philipp Oppermann ***@***.***> wrote: @ethindp > I am now running into this issue Could you clarify what you mean with "this issue"? Do you mean that it gets stuck in the first stage? > How would I put the kernel onto another partition of the ISO so that int > 13h sees it? I'd rather not distribute 2 files when an Iso should be good > enough. I never worked with GRUB chainloading, so I don't think that I can answer this question. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #49 (comment)

-- Signed, Ethin D. Probst