Getting Started

To start using JNode you have two options:

  1. Download the latest released CD-ROM image
  2. Download the latest sources and build them

Getting the latest released CD-ROM image

  • Download the bootable CDROM image from here.
  • Unzip it
  • Burn it to CD-ROM
  • Boot a test PC from it or start in in VMWare

Getting the latest sources and building them

  • Checkout the jnode module from GitHub. See the GitHub jnode repository page for details.
  • Build JNode using the build.bat (on windows) or build.sh (on unix) script.
    Without parameters, these scripts will give all build options. You probably want to use the cd-x86 option that builds the CD-ROM image.
  • Boot a test PC from it or start in in VMWare

Getting nightly builds

  • Download the nightly-builds
  • You can also get the sources and a ready-to-use vmx file for VMWare

Running JNode

Once JNode has booted, you will see a JNode > command prompt. See the shell reference for available commands.

‹ Applications starting with TupThe 20 minute guided tour. ›

Running in Qemu

Submitted by florian on Thu, 12/31/2009 - 21:49.

I read the documentation very carefully and concluded, that VMWare is the only virtualization software known to run JNode well under Windows XP. As VMWare requires to enter a whole bunch of personal information before allowing you to download the player and I personally dislike the idea of just giving away my data, I decided to give a try to Qemu, a virtualization software not yet documented to be tested before. And: voila, JNode booted smoothly.


I used the following command line:

qemu.exe -L . -m 512 -cdrom jnode-x86-0.2.8.iso -soundhw all -localtime -M isapc


After that, the virtual machine started and after some three minutes, the jnode prompt appeared. I tried to enter several commands, such as ls and gc, which all worked successfully. The only drawback is, that I did not manage to startawt. After some time I received the following error message: Fatal error in command. After reading the documentation, I rebooted several times with trying to

  • double the physical memory to 1024 MB,

  • play around with different graphic card BIOSes, and

  • to boot in VESA mode,

    • all without success. Maybe, I will find some time to dig into this problem. If so, I will keep you updated.


    All the best,
    Florian

    One Step Further

    Submitted by florian on Sun, 03/21/2010 - 14:02.

    After I finally had some free time at my hands, my couriosity made me give JNode a couple of more tries. As my first approach to boot the GUI of JNode failed miserably (refer to posts above for details), I looked for new ways of starting the OS.

    Try number 1: I burned JNode on a CD and booted my machine right from CD ROM. Along with some useful output I received a message close to "IRQ-11: maybe trapped in high priority" continously filling my screen. Well, it was worth a try.

    Try number 2: I previously used QEMU and Fabien suggested to use KVM instead. As I did not find a KVM implementation for Windows (which does not seem to be too surprising, as the 'K' in KVM stands for 'Kernel'), I played with the command line options a bit. And, what a surprise, if you replace -M isapc with -M pc, you do not get the "Fatal error in command". Instead, I get a set of reasonable messages, then the resolution of my monitor changes and the screen becomes all black.

    This leads me to the following conclusions:

    • Firstly, standard PCs are supported by JNode, whereas ISA-only PCs are not.
    • Secondly, the graphic driver still seems to have some troubles (even with the VESA option at startup). Mybe exchanging the graphics BIOS will help.
    • Thirdly, the handling of IRQs is buggy.

    All the best, Florian.

    Please give mode details

    Submitted by Fabien D on Fri, 01/01/2010 - 17:47.

    To enable output of stacktraces, you should use the propset -s jnode.debug true command before calling startawt.

    If necessary, to avoid writing here the stacktrace by hand, you can use the "-serial" option available for kvm (based on qemu) : see our running in KVM page. With that option, you should be able to redirect kernel debugger messages (sent to the serial line) to a file on the host OS (windows xp in your case).
    You might also need to add some "Unsafe.debug(...)" calls in the source code to actually get the stacktrace outputed to the serial line.

    Fabien

    my blog : en français, in english or both.

    More Details Provided

    Submitted by florian on Fri, 01/01/2010 - 22:48.

    Fabien,

    thank you for your precious hint-off. Before continuing writing, I want to explicitly state, that you and your team have created an amazing approach to an operating system. I assume, you already knew that before, but I just feel like stating this once more. Setting the jnode.debug property to true was exectly what I was looking for. Here comes the requested stacktrace:

    java.awt.AWTError: No framebuffer fbDevice found
    at org.jnode.awt.JNodeToolkit.incRefCount(JNodeToolkit.java:695)
    at org.jnode.awt.JNodeToolkit.startGui(JNodeToolkit.java:185)
    at org.jnode.awt.JNodeToolkit.startAwt(JNodeToolkit.java:1163)
    at org.jnode.awt.StartAwt.run(StartAwt.java:38)
    at org.jnode.awt.StartAwt.main(StartAwt.java:31)
    at org.jnode.vm.VmReflection.invoke(VmReflection.java:503)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:40)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:617)
    at gnu.java.security.action.InvokeAction.run(InvokeAction.java:55)
    at org.jnode.vm.VmAccessController.doPrivileged(VmAccessController.java:197)
    at java.security.AccessController.doPrivileged(AccessController.java:141)
    at org.jnode.shell.CommandRunner.run(CommandRunner.java:100)
    at java.lang.Thread.run(Thread.java:785)
    at org.jnode.shell.CommandThreadImpl.run(CommandThreadImpl.java:67)
    at org.jnode.vm.scheduler.VmThread(VmThread.java:767)

    For me as an experienced Java developer (and a JNode newbe), this stack trace seems to be straight forward. As the JNodeToolKit fails to detect any framebuffer devices, I looked for suspicious messages during boot up, without any luck. Although there are some messages written to stderr, they do not contain real error messages. They all look something like

    DeviceListener (in manager) took ???ms in deviceStarted: org.jnode.???

    The weird part of the stacktrace is, it is always the same, no matter which startup option I choose (all plugins / all plugins, VESA mode). As there is a suspision crawling up in me, that fixing this issue will take a whole lot of effort, it comes to me to decide between the following options

  • Getting into it and spending a whole lot of time while taking the risk that my wife will fill out her divorce papers meanwhile.
  • Overcoming my own skeptisism against filling out the form on VMWare's homepage.
  • Waiting for JNode 0.3

    • Right now I feel like taking the last option.

    Take care,
    Florian.