I'm using the tools repo to set up a build environment on Windows. I can easily build the needed third-party tools and the kernel, as well as individual packages by going to the src/third-party/build/package_name dir and issuing make there.

Is there some make target or other obvious way to include the opkg binary on the generated OS image, so that I can easily install other packages when testing the image on Qemu with run dx?

If this makes any sense, would it also make sense to include the ipkg files of the third-party packages on the disk image of the OS as well (a quick way to have a local repo for opkg inside the image itself)?

=(

Cedric Picard posted this analysis on the mailing list.

==========
Bug report

Version 0cb08c9

Excluded from the scope

• Debug functions

• Test apps

Bugs found

fprintf format wrong number of parameters

• apps/efiboot/efiboot.c:554

This can become a vulnerbility issue because it ends up leaking a pointer to
the stack which can be used to manipulate precise data when exploiting a
memory corruption vulnerability.

As far as I can tell Minoca doesn't have ASLR so this is less of an issue as
that would normally allow ASLR bypass, in this context is just a normal bug.

va_list resource leak

• apps/lib/chalk/cif.c:1016

"ArgumentList" was opened line 995 but not closed by va_end

File not closed on exit

• apps/swiss/ssdaemon.c:935
• apps/swiss/ssdaemon.c:939

Leak of "File" opened line 924, never closed.

• uefi/plat/veyron/fwbuild/fwbuild.c:481
• uefi/plat/veyron/fwbuild/fwbuild.c:484

Leak of "KeyBlockFile" opened line 263, never closed.

Memory leak

• apps/setup/win32/io.c:247

"IoHandle" isn't freed on error.

Uninitialized variable

• drivers/dma/bcm2709/dmab2709.c:1511

"Size" is never initialized nor used.

• kernel/armv7/prochw.c:167

If PhysicalMode == TRUE line 131 then InterrupTable is never initialized but
used nonetheless line 167.

Shifting 32-bit value by 32 bits is undefined behaviour

• uefi/plat/panda/init/clock.c:480
• uefi/plat/panda/init/clock.c:908
• uefi/plat/panda/init/clock.c:934
• uefi/plat/panda/init/clock.c:937
• uefi/plat/panda/init/clock.c:977
• uefi/plat/panda/init/clock.c:1003
• uefi/plat/panda/init/clock.c:1019
• uefi/plat/panda/init/clock.c:1050
• uefi/plat/panda/init/clock.c:1051
• uefi/plat/panda/init/clock.c:1057
• uefi/plat/panda/init/clock.c:1063
• uefi/plat/panda/init/clock.c:1069
• uefi/plat/panda/init/clock.c:1075
• uefi/plat/panda/init/clock.c:1081
• uefi/plat/panda/init/clock.c:1091
• uefi/plat/panda/init/clock.c:1093
• uefi/plat/panda/init/clock.c:1098
• uefi/plat/panda/init/clock.c:1100
• uefi/plat/panda/init/clock.c:1102
• uefi/plat/panda/init/clock.c:1108
• uefi/plat/panda/init/clock.c:1110
• uefi/plat/panda/init/clock.c:1112
• uefi/plat/panda/init/clock.c:1114
• uefi/plat/panda/init/clock.c:1116
• uefi/plat/panda/init/clock.c:1123
• uefi/plat/panda/init/clock.c:1125
• uefi/plat/panda/init/clock.c:1127
• uefi/plat/panda/init/clock.c:1129
• uefi/plat/panda/init/clock.c:1140
• uefi/plat/panda/init/clock.c:1146
• uefi/plat/panda/init/clock.c:1152
• uefi/plat/panda/init/clock.c:1152
• uefi/plat/panda/init/clock.c:1162
• uefi/plat/panda/init/clock.c:1164
• uefi/plat/panda/init/clock.c:1166
• uefi/plat/panda/init/clock.c:1168
• uefi/plat/panda/init/clock.c:1175
• uefi/plat/panda/init/clock.c:1177
• uefi/plat/panda/init/clock.c:1179
• uefi/plat/panda/init/clock.c:1181
• uefi/plat/panda/init/clock.c:1182
• uefi/plat/panda/init/clock.c:1183
• uefi/plat/panda/init/clock.c:1185
• uefi/plat/panda/init/clock.c:1187
• uefi/plat/panda/init/clock.c:1188
• uefi/plat/panda/init/clock.c:1190
• uefi/plat/panda/init/clock.c:1192
• uefi/plat/panda/init/clock.c:1198
• uefi/plat/panda/init/clock.c:1208
• uefi/plat/panda/init/clock.c:1221
• uefi/plat/panda/init/clock.c:1222

Dangerous style

SwGetUserNameFromId

This function does not present any bug. However it is dangerous in its use.
In apps/swiss/ls/ls.c for example there is no check of the Result of the
function. The code directly checks that UserName is not NULL. This is an
implementation detail as it is not documented anywhere. With a growing
contributor base and an increasing number of line of code it is bound to
become a bug in the future either because someone changes ls.c without
knowing this implementation detail, or because someone changes
SwGetUserNameFromId thinking everybody uses the return value.

Another point is that we still affect Name to UserName when Name is invalid.
Granted it is NULLed beforehand and there is no bug there. However it doesn't
look resilient to change and one could easily forget to change both the
handling of Name and UserName while updating the function, resulting in the
leak of already freed memory and possible memory corruption.

I would recommend keeping a eye on such a function as experience tells me it
is very likely to give bugs in the future. The best would be to be more
explicite : either document the fact that UserName is NULL on error or remove
its direct use completely. And explicitely NULL UserName on failure instead
on relying on the value of Name to avoid future side-effect.

Similar style can be found elsewhere in the code.

What is neccessary to build Minoca for a Transmeta Crusoe based system?

Can I just try the x86q port?

I've got some Fujitsu Siemens Futro S220 thin clients idling and collecting dust which previously were used as x86-OpenWrt guinea pigs. Typically they have 128M RAM and a filesystem on a 128M CF but I can upgrade some of them to 512M RAM (their maximum), 512M CF card (or more but not at hand) and if that's not enough they can boot or run from USB (tested with i586ish Linux) or I can add a harddisk.

Hello, I want to test Minoca OS using Hyper-V 2016 server. But unfortunately, OS can't initialize properly, it can't finish boot sequence. All I can see is initial information. Any ideas, how can I force it to start?

The RSA implementation in os/rsa.c uses the Chinese Remainder Theorem without blinding to efficiently decrypt. This introduces a timing attack, slightly different from the published one, where the variance of the runtime as a function of the argument to the reduction leaks the private components of the key. The standard countermeasure is blinding.

Handbook of Applied Cryptography states Barrett reduction potentially requires two subtractions at the end, not just the one performed in the code.

What about...

1. ...starting the Minoca wiki here on GitHub side by side to the code repository?
   Collecting hints and tips and cheat sheets probably will pay back soon...
2. ...defining which IRC server to use for realtime communication?
   IRC is well known and settled and clients grow everywhere and it perfectly works in character based environments. GitHub's text mode Gitter (Gitter bridged to IRC) is a pain and without IRC bridge it needs a running GUI. Probably I'm not the only one who does not like that.

Minoca OS lacks support for PowerPC host CPUs.

With the following repositories, I am investigating porting:

• https://github.com/mpasteven/minoca-os
• https://github.com/mpasteven/minoca-third-party-patches

Note that I have not signed the contributor agreement.

HP ProBook6470b is not booting

it seems that i didnt see the displaylink monitor driver.

Hi! This is based on https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/minoca-dev/vNyrQ3q0F7w

I have create a super simple but illustrative test suite using sparrow framework, I just looked at http://www.minocacorp.com/documentation/getting-started/tour/ and tried express some points from here as tests.

A test suite page - https://sparrowhub.org/info/minoca-os-test
A test suite source code - https://github.com/melezhik/minoca-os-test
Sparrow framework docs - https://github.com/melezhik/sparrow

I have run this on QEMU instance and this looks good for me.

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.

No df command. OK, install python and use its os.statvfs facility;

~$ python
python
Python 2.7.5 (default, Apr 30 2016, 22:45:47)
[GCC 4.9.2] on minoca0
Type "help", "copyright", "credits" or "license" for more information.

import os
os.statvfs('/')
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 38] Function not implemented: '/'

~$

Maybe go back to basics and use this program in statvfs.c:

#include <stdio.h>
#include <sys/statvfs.h>

int statvfs(const char *path, struct statvfs *s);

int main()
{
struct statvfs s;
int rc;
rc = statvfs("/", &s);
printf("sizeof f_blocks = %d, f_avail = %d\n", sizeof(s.f_blocks), sizeof(s.f_bavail));
printf("sizeof f_files = %d, f_avail = %d\n", sizeof(s.f_files), sizeof(s.f_favail));
printf("sizeof f_namemax = %d\n", sizeof(s.f_namemax));
printf("blocks=%llu, avail=%llu (%.2f%%), files=%llu, avail=%llu, maxname=%lu\n", s.f_blocks, s.f_bavail, (float) s.f_bavail / s.f_blocks, s.f_files, s.f_favail, s.f_namemax);
return rc;
}

Compiles fine...

~$ gcc -o statvfs statvfs.c
gcc -o statvfs statvfs.c
~$

but the compiled program is not executable:

~$ ls -l
ls -l
total 40
-rw-r--r-- 1 ryniker ryniker 13132 Jan 01 10:15 statvfs
-rw-r--r-- 1 ryniker ryniker 609 Jan 01 09:54 statvfs.c
~$ pwd
pwd
/home/ryniker
~$ id
id
uid=501(ryniker) gid=501(ryniker) groups=501(ryniker)
~$ chmod a+x statvfs
chmod a+x statvfs
chmod: Could not change mode of 'statvfs': Operation not permitted.
~$

Root can change permissions to make the compiled file executable.
Now:

~$ ./statvfs
./statvfs
sizeof f_blocks = 8, f_avail = 8
sizeof f_files = 8, f_avail = 8
sizeof f_namemax = 4
blocks=268596740, avail=17594333523788 (65504.64%), files=1153688929363336160, avail=695529151393660, maxname=39684
~$

I would love to be able to use a serial cable to access the BBB.

Since I'm an embedded developer, most of my "administrative" work is done over SSH and serial cables. It would be nice to be able to edit a text file somewhere, and assign a hardware serial port to the console!

a software request:
gluster
mono
openzfs

This one came in from Ilya via email:

The debugger hardly ever starts on windows when using the .bat file provided in the Minoca OS Starter Pack, the only time it ever started was on the first ever time i started the OS from the bat file. It doesn't appear even when the exe is launched

We save the last debugger location and size in a preferences file so that it returns to the same spot the next time you launch it. There appears to be a corner case where the location is saved as (0,0) and the (height,width) is saved as (0,0).

The work around is to delete C:\Users\YourUserName\AppData\Roaming\Minoca\DebugUI\prefs.

The debugger already tries to guard against saving minimized or maximize state, as that doesn't work well either. The appropriate fix at this point is to refuse to save the zero state to the prefs file.

How would I build a GUI ?

Screenshots shows running Git, so maybe one can also run the compiler and tools?

There should be FAQ with such question and answer.

Vegax 87 requested support for the D programming be added to the repositories in third-party. He writes:

Hi, I discovered Minoca today and I wanna ask you: what do you think about adding D language on Minoca? IMHO D language with Gdc or Ldc2 compiler has achieved excellent results and also is one of the most scalable languages out there and it has a very low memory usage which is perfect for Minoca, I think it deserves a chance to be included on Minoca 3rd-party repos, unfortunately I don't have enough knowledge to port it on Minoca...

P.S: You can see some reliable benchmarks here: https://github.com/kostya/benchmarks

If GNU release a later version, then GPL-3 code will probably be incompatible with GPL-4.

Rationale from http://opensource.stackexchange.com/questions/1777/why-is-gplv2-incompatible-with-gplv3:

Both the GPLv2 and the GPLv3 have clauses that

Require the combined product to adhere to the license terms of the license of the GPL licensed component.

Require that no additional restrictions may be placed on the combined work:

from clause 6 of the GPLv2:

Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. (Part 1) You may not impose any further restrictions on the recipients' exercise of the rights granted herein. (Part 2)

The GPLv3 has additional restrictions over the GPLv2, specifically, a patent grant and anti-tivoisation provisions, so 1 and 2 can't hold simultaneously.

To prevent this issue, the Free Software Foundation advises people who want to license their work under the GPL to use the following phrasing:

You can redistribute it and/or modify [the work] under the terms of the GNU General Public License as published by the Free Software Foundation, either version [x] of the License, or (at your option) any later version.

That way, you release your work under multiple licenses; the one you name explicitly, and any possible future version of the GPL. This makes the resuser free to use the software under any future version of the GPL, and this license incompatibility becomes a non-issue.

After pulling in the fix for ckcore I run into a new issue when compiling under OSX. I'm using the Howebrew GCC, but I have also experienced issues with Xcode 8 and Xcode CLI tools. Could you maybe document the recommended compiler/environment for building?

Compiling - uos.c
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c: In function 'SwGetMonotonicClock':
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c:3158:12: error: implicit declaration of function 'clock_gettime' [-Werror=implicit-function-declaration]
     return clock_gettime(CLOCK_MONOTONIC, Time);
            ^~~~~~~~~~~~~
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c:3158:26: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)
     return clock_gettime(CLOCK_MONOTONIC, Time);
                          ^~~~~~~~~~~~~~~
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c:3158:26: note: each undeclared identifier is reported only once for each function it appears in
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c:3159:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c: At top level:
cc1: error: unrecognized command line option '-Wno-parentheses-equality' [-Werror]
cc1: all warnings being treated as errors
make[5]: *** [swlib/uos.o] Error 1
make[4]: *** [uos] Error 2
make[3]: *** [swiss] Error 2
make[2]: *** [apps] Error 2
make[1]: *** [/Users/johan/Projecten/raspberrypi/armv6dbg/obj/os] Error 2
make: *** [img] Error 2

~/P/raspberrypi (master|✚5…2) $ ls -l (which gcc); armv6dbg/tools/bin/arm-none-minoca-gcc --version; gcc --version; sw_vers
lrwxr-xr-x  1 johan  staff  28 Nov  2 22:49 /Users/johan/Projecten/raspberrypi/.bin/gcc -> /Users/johan/.brew/bin/gcc-6
arm-none-minoca-gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gcc (Homebrew gcc 6.2.0) 6.2.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ProductName:	Mac OS X
ProductVersion:	10.11.6
BuildVersion:	15G1108

Hi guys! This is in "a spirit of" - discussion started at https://groups.google.com/forum/#!topic/minoca-dev/vNyrQ3q0F7w

https://github.com/melezhik/minoca-pkg-test

Let me know if sound interesting, so I can go further with other packages.

Probably missed dependency on readline?

While browsing through the code, I noticed that the change in licensing was only for the source files and not the Makefiles. It would be nicer if they were included, if possible.

I don't know if any thought has been given to any unique-to-minoca user mode api's, but a proper asynchronous IO mechanism would be nice (preferably using a proactor pattern rather than a polling pattern) .

1. is there a reason for INT/LONG proliferation?
2. MIN_CHAR and MIN_WCHAR are signed?
3. mutable strings everywhere, is it a good practice or should one assume that PSTR is always const?
4. what's the reason to use both null terminator and string length including null terminator, can't the terminator be left for posix compatibility layer?
5. is fork,exec combo more efficient than spawning a new process from scratch?
6. headers are licensed under GPL3, this means any software that includes them becomes a derived work and has to comply with GPL?

Hello, It would be nice to add support golang in minoca, it even possible?

Hiya minoca OS folks,

Quite interested in minocaOS, I immediately cloned the repo, downloaded the toolchain for my dev system (macOS 10.12.1), set up the paths, .'ed my setenv.sh, and attempted a fresh, clean build as an interested OS developer is wont to do..

Out of the box tho', seems that something is borked:

$ cat ../../setenv.sh
export SRCROOT=~/Documents/minocaOS/src
export ARCH=x86
export VARIANT=
export DEBUG=dbg
export PATH=$PATH:$SRCROOT/$ARCH$VARIANT$DEBUG/tools/bin
 seclorum@github:~/Documents/minocaOS/src/os {(master)}
$ gb -av
* master                0cb08c9 Makefile build fix.
  remotes/origin/HEAD   -> origin/master
  remotes/origin/master 0cb08c9 Makefile build fix.
 seclorum@github:~/Documents/minocaOS/src/os {(master)}
$ ls
CONTRIBUTING.md WISHLIST.md     docs            include         new.c
LICENSE         apps            drivers         kernel          new.h
Makefile        boot            env.ck          lib             tasks
README.md       build.ck        images          minoca.mk       uefi
 seclorum@github:~/Documents/minocaOS/src/os {(master)}
$ make
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/basevid
make[3]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/basevid
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/bconflib
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/bconflib/build
make[4]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/bconflib/build
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/bconflib
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/boot
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/boot
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/build
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/build
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/intrins
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/intrins
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/wide
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/wide
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/kmode
make[4]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/kmode
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/rtlc
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/rtlc/build
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/rtlc/build
Compiling - stubs.c
/Users/seclorum/Documents/minocaOS/src/os/lib/rtl/rtlc/stubs.c:35:19: fatal error: stdio.h: No such file or directory
 #include <stdio.h>
                   ^
compilation terminated.
make[4]: *** [stubs.o] Error 1
make[3]: *** [rtlc] Error 2
make[2]: *** [rtl] Error 2
make[1]: *** [lib] Error 2
make: *** [/Users/seclorum/Documents/minocaOS/src/x86dbg/obj/os] Error 2
 seclorum@github:~/Documents/minocaOS/src/os {(master)}
$ find .. -name "stdio.h" -print
../armv7dbg/tools/lib/gcc/arm-none-minoca/4.9.2/include/c++/tr1/stdio.h
../armv7dbg/tools/lib/gcc/arm-none-minoca/4.9.2/include/ssp/stdio.h
../armv7dbg/tools/usr/include/stdio.h
../os/apps/libc/include/stdio.h
../x86dbg/tools/lib/gcc/i686-pc-minoca/4.9.2/include/c++/tr1/stdio.h
../x86dbg/tools/lib/gcc/i686-pc-minoca/4.9.2/include/ssp/stdio.h
../x86dbg/tools/usr/include/stdio.h
 seclorum@github:~/Documents/minocaOS/src/os {(master)}

Any clues what I may have exposed here? Perhaps the rtl build is looking for stdio.h in strange places, and not finding it .. anyway, thought I'd report this issue before I come back in a few hours and have another round (next time on a Linux-x64 system..)

I've been trying to port new packages to Minoca OS using the Windows cross-compiling environment and some of those packages require pkg-config.

I simply grabbed a binary here: http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config_0.26-1_win32.zip and moved on with configuration/compilation.

Since this is so ubiquitous, would it be possible to include it on the tools repo for Windows?

NVidia GPU drivers support?

How do you prepare an image to be written to NAND? Is there JFFS2 filesystem option? or something else that may be better for embedded flash?

On the community page at the bottom, the link to the wishlist is given as:
https://github.com/minoca/os/WISHLIST.md
but should instead be:
https://github.com/minoca/os/blob/master/WISHLIST.md

This was the first link I found looking for where to find the source. (I missed the fork-me banner somehow.) Would be nice if it were more prominent.

Just cloned, configured env and started build.

Compiling - io.c
/home/ancient/load/os/apps/setup/uos/io.c: In function ‘SetupOsEnumerateDirectory’:
/home/ancient/load/os/apps/setup/uos/io.c:537:9: error: ‘readdir_r’ is deprecated [-Werror=deprecated-declarations]
         Result = readdir_r(Directory, DirectoryEntry, &ResultPointer);
         ^~~~~~
In file included from /home/ancient/load/os/apps/setup/uos/io.c:36:0:
/usr/include/dirent.h:189:12: note: declared here
 extern int __REDIRECT (readdir_r,
            ^~~~~~~~~
cc1: all warnings being treated as errors
make[4]: *** [/home/ancient/load/os/minoca.mk:509: io.o] Error 1
make[3]: *** [/home/ancient/load/os/minoca.mk:383: uos] Error 2
make[2]: *** [/home/ancient/load/os/minoca.mk:383: setup] Error 2
make[1]: *** [/home/ancient/load/os/minoca.mk:383: apps] Error 2
make: *** [/home/ancient/load/os/minoca.mk:93: /home/ancient/load/i6860/obj/os] Error 2
make  35.87s user 2.33s system 87% cpu 43.552 total

Hi,
it seems you are using some language called "Chalk" throughout the project.

Is it something that existed before Minoca or it was developed for this project only?

(root@minoca:pty8)~# opkg list-installed

...no output.

(root@minoca:pty8)~# opkg -f /etc/opkg/opkg.conf list-installed | wc -l
     77

Without telling opkg which config file to use, it seems to fail.
(The wc part just keeps the output of the example short.)

(root@minoca:pty8)~# opkg install /src/x86rel/bin/packages/vim_7.4_minoca-i686.ipk 
Not selecting vim 7.4 due to incompatible architecture.
Unknown package 'vim'.
Collected errors:
 * opkg_install_cmd: Cannot install package vim.
(root@minoca:pty8)~# opkg -f /etc/opkg/opkg.conf install /src/x86rel/bin/packages/vim_7.4_minoca-i686.ipk
Installing vim (7.4) on root.
Configuring vim.

...so without config file it does not even know the architecture and won't accept packages for minoca-i686. opkg defaults to only acceppt architecture all by default. Again, it works as expected when adding -f /etc/opkg/opkg.conf.

Can someone confirm this behaviour or do I have a local problem here?

Hi, want to share my finding with the VirtualBox here

I have tried Evan's method of manually creating the vmdk file to wrap the pc.img, however I get a miss matched uuid stored in the media registry. To fix this I had to copy out the UUID of the ones in the media registry and replace it
ddb.uuid.image="69a7ab8a-ac25-42c6-b673-6c6ca1a36594"

but an easier approach is to have the pc.img and run
VBoxManage internalcommands createrawvmdk -filename pc.vmdk -rawdisk pc.img
which will generate the pc.vmdk for you, now you can just mount the vmdk as is.

hope this helps anyone who may have issues.

start .\Qemu\qemu.exe -L .\Qemu -m 1024-hda .\Minoca\Image\pc.img -serial pipe:minocapipe -net nic,model=i82559er -net user

When I set -m to a number more than 1924 and then launch run.bat , starter does not up ( see no green terminal screen ). My Host OS has about 10 GB available memory though ...

Could you add image for chipPC board ?
https://getchip.com/pages/chip

Is there any plans to x64 support?

It's stuck in this state, with or without KVM:

(dd-ing to usb-stick)

As reported in #7, macos builds with latest (10.12.1) toolchain (as of nov. 2) fail to find ckcore.ck when expanding the .incbin macro, thus:

Compiling - cdump.c
Assembling - ckcore.S
/Users/seclorum/Documents/minocaOS/src/os/apps/ck/lib/build/../ckcore.S:55:70: error: Could not find incbin file 'ckcore.ck'
.global __binary_ckcore_ck_start; __binary_ckcore_ck_start:; .incbin "ckcore.ck"; .global __binary_ckcore_ck_end; __binary_ckcore_ck_end:
                                                                     ^
make[5]: *** [ckcore.o] Error 1
make[4]: *** [build] Error 2
make[3]: *** [lib] Error 2
make[2]: *** [ck] Error 2
make[1]: *** [apps] Error 2
make: *** [/Users/seclorum/Documents/minocaOS/src/x86dbg/obj/os] Error 2

Hi

Any plans to support NVIDIA Optimus + wine?

Thank you

This is a direct link: https://gitlab.com/minoca/tools/blob/master/win32/bin/xcopy.exe

For me this causes the Minoca thirdparty build on Windows to fail because it fails to execute with an "entry point not found error".
Removing this file results in a successful build of the third party tools.
I suggest that it is removed from the repository.