Minoca OS fails to boot in VMWare

[evangreen]

hi @Tester768 . Let's move our VMWare thread over here.

Thanks for getting a kernel debugger connected, that helps a lot. The 0.2.0.1375 failure is now understood. From the diff of the two we can see that in 0.2.0.1375 all devices underneath the ISA bus fail, which explains why the keyboard never comes up. In the newer build we see many more devices being enumerated, so we're making progress :)

It seems like some part of the build process isn't getting sh into the right place. Do you have sh, mount, and a few other apps in x86dbg/bin/skel/bin? If not, I wonder if the -nt (newer than) test is not passing for non-existent files during the build process.

Can you try replacing lines 66-68 of apps/swiss/Makefile with just
$(STRIP) -o $(BINROOT)/skel/bin/sh $(BINROOT)/$(BINARY)

and do a make clean + rebuild (essentially just removing the if). If removing the conditional causes sh to show up in x86dbg/bin/skel/bin, then we'll know that's the issue. To fully boot we'll also need to do that fix for mount's postbuild.

[Tester798]

Yes, x86dbg/bin/skel/bin was empty.
After doing what you suggested I see sh there after build.

[evangreen]

Now we're getting somewhere. Can you do the same sort of change in apps/mount/Makefile, a la,
$(STRIP) -o $(BINROOT)/skel/bin/$(BINARY) $(BINROOT)/$(BINARY);

and see if rebuilding (you can just do a make clean in apps/mount and then rebuild in os) gets you to a prompt.

[Tester798]

Now getting

0x1: apps/bin/sh: Failed to find import 'libc.so.1'.
0x1: Failed to load apps/bin/sh: -43

Seems like there are a lot more Makefiles to fix.

[evangreen]

Ha yeah, but we're definitely moving the needle. That one's off in apps/libc/dynamic/Makefile. I'll start working on changing that everywhere.

[Tester798]

Ok, I will wait until all are changed. Seems like the issue with VMware is solved, it's a build issue now.

[evangreen]

Okay, change is pushed. make clean in os, make, and let's see what happens.

[tejasjadhav]

@evangreen Thanks! With the new changes, prompt now shows up in VirtualBox. Qemu still gives Failed: 0xFFFFFFCC error.

[evangreen]

@tejasjadhav Great! Well, sort of. Chris is working on that error that you mentioned.

[Tester798]

@evangreen Seems like you forgot about sh :)

[evangreen]

Ugh, I certainly did. Pushed 76aaf37.

[Tester798]

I can confirm it's booting now.
But still many programs are not present in the image: there is no /usr/bin in the image with all opkg, wget, nano etc.

[ccstevens]

@Tester798 Thanks for confirming. The lack of opkg, wget, nano, etc. is to be expected when you only build the minoca/os repository. All of the third-party packages that we did not write live in the third-party repository. This keeps our builds of the os repository clean and simple.

To get those packages, the best option would be to go build the ones you want (and their dependencies) and then use opkg-extract-data from ~/src/third-party/build/opkg-utils to extract them to ~/src/x86dbg/bin/apps. Running make out of ~/src/third-party will make all packages that can be cross-compiled (e.g. it won't build Python), but takes some time.

Sorry about this inconvenience. The pre-built images on our downloads page include opkg, nano, wget, and a few other necessities to get going. Of course, those images aren't booting. We're working on putting out new images with all the VMWare and QEMU fixes.

Lastly, as a caveat, if you get opkg (and dependencies) in your image and run opkg update, it will go searching in http://www.minocacorp.com/packages/0.3/i686/main/ for packages. Unfortunately, as we haven't pushed the new pre-built images, we also haven't pushed the 0.3 packages. You could try to modify /etc/opkg/opkg.conf to point at the 0.2 packages, but no guarantees on compatibility (we haven't tested the old packages on the new kernel/libc).

[drawkula]

. o O ( There should be a "This is worth being added to the FAQ emoji!". )

[ccstevens]

@drawkula We'll get our emoji team on it right away. And, yup, we're definitely learning about all our FAQ gaps thanks to you all.

[drawkula]

That was not meant as criticism... just as hint...

I definitely know how hard the documentation job is and documenting the own source is one thing, docs for the co-workers or even users are own dimensions...

[ccstevens]

@drawkula Oh, I didn't read it as a criticism at all! You have seriously been awesome this week and we appreciate any and all feedback. (Sorry for the emoji sarcasm...)

[drawkula]

@ccstevens No need for "sorry"... I'm probably something like partial autistic and english not being my native tounge adds another source of possible confusion.

Back to issues... this packages subtopic probably is worth an own issue. Maybe some issue labels fit as markers for HowTo or FAQ stuff?

[ccstevens]

Agreed. Labeling certain issues is a good start. I know you were discussing our knowledge base with Evan over on Issue #31. He and I will sync on this and figure out a plan.

[evangreen]

I think this issue is solved, so I'm going to close it. Feel free to reopen if something's still not working.