Not working on NodeOS

[piranna]

When launched on NodeOS, cursor keeps blinking and CPU gets to 100% (maybe an infinite loop somewhere?), but nothing more happens. This is not a blessed or terminator issue since now by using -curses instead of nographic blessed demos are being shown (with bad characters, but at least it's not an empty screen). I've also lauched it with slap --help and slap --logger.level debug with no result, so seems the problem would be before this steps.

[dbkaplun]

@piranna I was trying to get a more recent NodeOS running on my computer but could not, as the NodeOS docker image very old. Is there a NodeOS IRC channel or some other support channel?

[piranna]

Docker images are unmaintained, but you have easy and updated instructions for QEmu, and also now it can run on real hardware... :-) On QEmu you'll need to use the curses flag, but on real hardware it should work as is.

[dbkaplun]

I can't build NodeOS on OSX for a variety of reasons. First it complained about elf.h, then byteswap.h. I remember it failing on an Ubuntu VM as well, but I'll try again.

[piranna]

It can't be build on OSX, but some people got to build it on an Ubuntu VM. I'm thinking if using crosstools-ng would allow to build it on other systems like OSX or Windows without problems...

[dbkaplun]

@piranna here's my traceback after building on a fresh Ubuntu 14.04 VM: https://gist.github.com/secrettriangle/9bb9175ba631c33f30e0

[piranna]

From the traceback I can't be able to identify the problem, but definitelly it's possible to build it on Ubuntu 14.04 VM (it's what's being used on SemaphoreCI servers). Since the process is killed, maybe it's an out of memory problem? How much memory has the virtual machine?

By the way, maybe you are interested in using the autogenerated releases instead of generate them yourself, and also someone could be able to convert them to VirtualBox... :-)

[dbkaplun]

Output of run.sh as well as npm install

[piranna]

There's something really awful on your virtual machine... Dumb question, but you have exec bin/install-dependencies previously to build NodeOS with npm install?

The problem of run.sh is because it's prepared to exec QEmu on a real machine, KVM is not available inside virtual machines. Just remove the KVM support and try again, it will be slower but you should be able to run it :-)

[dbkaplun]

dan@dan-VirtualBox:~/Downloads$ ls
bzImage            README.md  usersfs.img
initramfs.cpio.gz  run.sh     x86_64-pc_qemu.zip
dan@dan-VirtualBox:~/Downloads$ ./run.sh 
./run.sh: 5: ./run.sh: --kernel: not found

Same thing with an absolute path to bzImage in run.sh.

After running install-dependencies I get the exact same error.

[piranna]

Sh*t, that's annoying! :-( What's the actual content of run.sh after changing it?

[dbkaplun]

OK, I'm able to run it now... Had to remove the kvm line, not just comment it out. Everything is very slow in this VM-within-a-VM, but I will do some debugging when I can.

[dbkaplun]

Does NodeOS support environment variables? Also where is /home? slap relies on process.env.HOME.

[piranna]

OK, I'm able to run it now... Had to remove the kvm line, not just comment it out.

Great! :-D Yeah, bash scripting sucks, but for run.sh could be the best one, since this allow people to test NodeOS without need to have Node.js installed. Maybe add an option to disable KVM?

Everything is very slow in this VM-within-a-VM, but I will do some debugging when I can.

Yeah, it's normal :-P It will last more time to boot it but it's usable anyway :-)

Does NodeOS support environment variables?

Yes, you can access them opening a node shell and executing process.env. nsh (the NodeOS shell) currently don't support to define them... definitely, nsh needs to get a huge priority status...

Also where is /home? slap relies on process.env.HOME.

Your $HOME is / :-) It's an OverlayFS filesystem stacking the initramfs and your home directory, and later chroot'ed to it at /. This way users have the feeling to have all the filesystem to themselves while at the same time can't be able to access others $HOME to sneak their files ;-) Cool, eh? :-D

[dbkaplun]

Interesting -- if I comment out the KVM line in run.sh, I can run it natively on OSX. FYI :)

[piranna]

Hum? Define "natively"... using an OSX QEmu binary? Yeah it would makes sense, I don't know but KVM probably would be a Linux-expecific virtualization mechanism... :-)

[dbkaplun]

@piranna it works using a prebuilt binary by running ./run.sh after only removing the KVM line.

[piranna]

Oh cool, then maybe we should set KVM it as an opt-in instead as by default?

[dbkaplun]

Exactly what I was thinking... maybe add a command-line option, like --with-kvm (if it's easy enough). NodeOS/NodeOS#143

Also IMO the zip should container a folder with files rather than a bunch of files. NodeOS/NodeOS#142

[chjj]

KVM is a linux virtualization module, without KVM, QEMU just does emulation as far as I know. It's a bit slower, but it will work.

[piranna]

Also IMO the zip should container a folder with files rather than a bunch of files. NodeOS/NodeOS#142

Maybe it's a question of taste, I don't like when I de-compress a file and inside there a lonely folder, I find it redundant... :-P

KVM is a linux virtualization module, without KVM, QEMU just does emulation as far as I know. It's a bit slower, but it will work.

Yes, definitely the flag seems to be a good thing :-)

[dbkaplun]

What's the easiest way to add/change files in the NodeOS VM?

[piranna]

At this moment, probably to edit the build scripts and rebuild, specially node_modules/nodeos-usersfs module. Also, the npm packages are defined in .txt files as a list, just add there the name of the module and it will be downloaded. Probably you'll need to delete the obj & out folders or comment th if statement to force to recreate them...

[piranna]

I've just tested slap 0.1.28 on NodeOS (I couldn't test any more recent because we don't support nan2 yet) running on real hardware... and it works! :-D Seems the problem was due to an out-of-memory error, since the default QEmu virtual machine has only 128mb and after booting NodeOS it left free only 40mb (I need to fix the memory consumption...). The same happened to npm, that "at least" I've been able to exec npm -v without crashing :-)

It has showed an strange error though, specially because all seems to work correctly after that:

usrbinenv is an implementation of /usr/bin/env in Javascript, and since it's a common item it has too restrictive permissions in NodeOS (no read or write permissions, only execution to allow to traverse the directories). This work correctly, that's not the problem, but I don't understand why it try to read its package.json file... :-/

[dbkaplun]

@piranna so glad to hear it! Wish it would support a newer version of slap but 0.1.28 will do. :P

The only reason I can see that error appearing is because slap checks all global installed packages to see if they have a slap-plugin keyword to load slap plugins. Maybe that's the issue?

[piranna]

@piranna so glad to hear it! Wish it would support a newer version of slap but 0.1.28 will do. :P

Me too, there's a lot of packages that has upgraded to nan2 and latest Node.js versions. Don't know if another more recent will work, I was going back in time each month until I found the version of May 15 worked :-) There's a bug on v8 that don't allow to use a newer version and also it's needed gcc 4.8 or bigger (we are using 4.7.3), but @heavyk has done some huge progress on this aspects :-) I hope to find some time to git bisect the v8 bug, I think it will be a something really stupid bug...

The only reason I can see that error appearing is because slap checks all global installed packages to see if they have a slap-plugin keyword to load slap plugins. Maybe that's the issue?

usrbinenv is installed globally for all the system, and the package.json file don't have read permissions, so it makes sense. Maybe you would check the EACCESS error and ignore if? It's not an usual situation, but it's a harmless check for this use case anyway...

[piranna]

I've given read permissions to the usrbinenv module and now the error don't appear :-) Next steps, mouse support and upgrade Node.js version to be able to exec last version of slap :-P

[piranna]

Now that NodeOS use latest Node.js 4.3.1 I've been able to install latest version of Slap (hoorray!!! :-D) but I'm not able to use it because it doesn't respond to the keystrokes, also Ctrl+Q to quit. What could I be able to look for to make it work? :-)

[dbkaplun]

That is strange indeed. Try passing --logger.level silly and tailing ~/.slap/slap.log. Does it acknowledge keystrokes at all?

[piranna]

Does it acknowledge keystrokes at all?

Regular shell works flawlessly. Are you talking about blessed-based applications?

[dbkaplun]

I'm talking about in ~/.slap/slap.log.