egg run can't find disk image, egg run foo.iso exits immediately after grub

[jspc]

I've written a really simple app at https://github.com/jspc/primes which I'd like to package and run via eggos.

(The app calculates primes- it seemed like a simple use case to play with eggos).

The problem I'm facing is that trying to run the app directly with egg run gives me:

qemu-system-x86_64: multiboot knows VBE. we don't                           
Could not open option rom 'multiboot_dma.bin': No such file or directory
SeaBIOS (version ArchLinux 1.15.0-1)
                                                                                               
                                               
iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+0FF914E0+0FEF14E0 CA00
                                                                                                                                                                                           
Booting from Hard Disk...
Boot failed: could not read the boot disk

Booting from Floppy...
Boot failed: could not read the boot disk

Booting from DVD/CD...
Boot failed: Could not read from CDROM (code 0003)
Booting from ROM...
iPXE (PCI 00:03.0) starting execution...ok
iPXE initialising devices...ok

iPXE 1.20.1+ (g4bd0) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS HTTP iSCSI TFTP AoE ELF MBOOT PXE bzImage Menu PXEXT

net0: 52:54:00:12:34:56 using 82540em on 0000:00:03.0 (open)
  [Link:up, TX:0 TXE:0 RX:0 RXE:0]
Configuring (net0 52:54:00:12:34:56)...... ok
net0: 10.0.2.15/255.255.255.0 gw 10.0.2.2
Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b)
No more network devices

No bootable device.          

I've read #91, and so I get that the first two lines can be ignored, but the fact qemu can't find the boot disk is worrying.

If I compile an iso file, then I get the grub menu, then just the line Loading /boot/kernel.elf... and then it all quits.

Am I doing something wrong? I can see a segfault when I run gdb kernel.elf, but I'm not sure whether that's just because running a ring0 app on linux fails fast and loud, or whether there's a different reason.

Any pointers you can give me toward figuring this out would be really appreciated!

[jspc]

Sorry, useful information; I have tried installing via both methods in the README- go install github.com/icexin/eggos/cmd/egg and via the releases page.

Same thing happens in both instance

edit: similarly, if I clone this repo, build egg with mage egg, and then call that binary as above, same problem
edit 2: I wanted to rule out my machine/ qemu so I used ventoy (as per the docs) to boot from another machine, and the same as above happened- grub started, same output, then my machine rebooted. I also tried the examples in this repo and none of them worked for me.

[icexin]

Sorry for responding so late. What's the version of go compiler? Currently only the 1.16.x version of the go compiler works.

[jspc]

Thanks @icexin , and no worries- you're not here to be my unpaid tech support; I can wait as long as you need me to.

I completely missed that part of the docs, and so that's completely my fault. I've installed 1.16.13 via go get golang.org/dl/go1.16.13 but the problem I'm now having is telling egg build to use this version.

How do you build locally? I can see the github workflow sets the toolchain to 1.16.x, but do you do anything special on your own machine? Or just never upgrade go?

I can think of a couple of ways which could work here, either performing a local build in a container, or by tweaking cmd/egg/build/builder.go to accept a different go binary (in the same way it accepts a different go root).

Containers would require a change to the readme (which I'm happy to submit a PR for), whereas a change to builder.go requires a larger PR, and might also introduce complexity you don't want (the method of using go get golang.org/dl/go1.16.13; go1.16.3 download; go1.16.3 build (etc) is the method recommended by the go docs but it does require forcing a workflow on users).

Do you have any recommendations?

---

edit1: I've written a simple dockerfile to use as a builder, which looks like:

FROM golang:1.16.3

RUN go install github.com/icexin/eggos/cmd/egg@latest

If I build this, then run it as per:

$ docker build -t egg . && docker run -v $(pwd):/app -w /app egg build -o kernel.elf

And then run that locally with egg run kernel.elf I receive the same error as in the first post.

I can't see anything in the command that suggests it's trying to rebuild that image (when passing an argument containing the kernel) in the newer go I have installed (and timestamps suggest this is not the case, too), so I can't see where the issue is.

[icexin]

The egg command accepts the GOROOT environment variable to change the version of go. You can use a command like this to get egg to use the correct go version.

GOROOT=`go1.16.13 env GOROOT` egg build

Maybe it would be better to add a FAQ to the README.

[jspc]

Of course, sorry- I saw the GOROOT arg and forgot that I could get it from go 1.16.13 env GOROOT.

Interestingly, when I do it that way I get the same error from

GOROOT=`go1.16.13 env GOROOT` egg run kernel.elf

But building an iso and running the same with the iso path works fine.

I'll open a PR later today which:

1. Adds an FAQ, including getting the right version of go/ setting properly (linking to this issue)
2. Adds an issues template (I'll need your help to translate it to Chinese properly) that gets people to check the version of go

Does that work?

[icexin]

Perhaps kernel.elf is the compiled output of the previous go version, it should work after recompiling with the new go version.

I compiled and ran your project as follows:

$ git clone https://github.com/jspc/primes.git
$ cd primes
$ GOROOT=`go1.16.13 env GOROOT` egg build -o primes.elf 
$ egg run -p 11111:11111 primes.elf

# another terminal tab
$ nc 127.0.0.1 11111

{"i":10407932194664399081925240327364085538615262247266704805319112350403608059673360298012239441732324184842421613954281007791383566248323464908139906605677320762924129509389220345773183349661583550472959420547689811211693677147548478866962501384438260291732348885311160828538416585028255604666224831890918801847068222203140521026698435488732958028878050869736186900714720710555703168729087,"v":10407932194664399081925240327364085538615262247266704805319112350403608059673360298012239441732324184842421613954281007791383566248323464908139906605677320762924129509389220345773183349661583550472959420547689811211693677147548478866962501384438260291732348885311160828538416585028255604666224831890918801847068222203140521026698435488732958028878050869736186900714720710555703168729087,"len(v)":386}

I'll open a PR later today which:

1. Adds an FAQ, including getting the right version of go/ setting properly (linking to this issue)
2. Adds an issues template (I'll need your help to translate it to Chinese properly) that gets people to check the version of go

Your proposal is very good, welcome to submit PR! Thanks!

[jspc]

Closing this issue now, we can track the changes/ work in this issue in #95

[mewmew]

Sorry for responding so late. What's the version of go compiler? Currently only the 1.16.x version of the go compiler works.

Should we open an issue to track implementing support for newer versions of Go in eggos? I am guessing that the calling convention changes in Go 1.17 will be the biggest hurdle, but since there is relatively little assmbly code in eggos, it should be fine to handle those functions with special cases.

[jspc]

@mewmew I personally think it's well worth planning and doing. At the very least, the lessons learned will help if the compiler changes how binaries work as dramatically.

[icexin]

Good suggestion, I will open a separate issue about supporting go1.17 to track the progress