Mounting EXT2 or FAT32?

Hello Everyone,

First of all I would like to thank everybody who has worked on JNode for all of the excellent work that has been done; I find the idea of a Java based operating system very exciting.

Now down to business:

I've set up a scheme which I think is similar to the one that Exile in Paradise set up a while back (see, but mine has a few differences. Specifically, I only have one hard drive to work with, so it has four partitions: one for Windows, one for Linux, one for Swap, and then one that I just made for JNode.

I copied the files that JNode needs to boot (jnode32.gz & some various .jgz files depending on what I want to do) onto this new partition. I was then able to successfully boot into JNode with the GRUB installation that exists on my harddrive that I use for my other operating systems.

While it starts up, a large red stacktrace is outputted by JNode complaining that it "Cannot start ide0" (actually, it could be ide1, if this is critical information I will look). In the end, however, it reaches the shell that I can play around in.

However, my file system is not mounted. I don't know if this is supposed to take place automatically; maybe that was precluded by the inability to start ide0. In any case, I thought I'd try manually. So I've tried a few different mount commands, none of which work. The one which seems most successful is "mount hda someDir /", but it complains that no filesystem could be found on hda. Other attempts always yield some message to the effect that the command ran out of alternatives, which I think means that I gave a silly command that could not be interpreted (i.e. some argument was incorrect).

So then I thought that hda wasn't the right device. So I tried the device command, and there are a few possibilities that I saw there: ide0, ide1, and some serial options. I use a SATA drive, so ide0 and 1 seemed dubious to me, but I tried them anyway. I got the "ran out of alternatives" message with a command that seemed correct in syntax, so I concluded that ide0 and 1 must not represent drives. The devices that started with "serial" also seemed like candidates, since I'm using a *serial* ATA drive. This too gave me a "ran out of alternatives."

I've tried switching the formatting of JNode's partition around, from EXT2 to FAT32 (as was recommended here:, but that makes no difference.

Does anybody know how to get this working, or have some idea how to start troubleshooting?

Thank you very much!

EDIT: P.S. If this is not the correct forum, I apologize for posting this here. If you could point me in the right direction, I'd appreciate it Laughing out loud.

SATA is not supported

Hi Lithrium,
Thank you for the detailed description of your interesting JNode experiment.
The short answer is that JNode has no SATA support yet. The JNode boot files are loaded by GRUB but later on when JNode tries to detect the hard disk it asumes the presence of an IDE disk which is not found and the SATA disk remains undetected. Therefor the hda device is not started up, there are no file systems on it etc. You can list the devices detected by JNode and their status with the device command.
I think the "ran out of alternatives" messages from certain commands are simply misleading because they make you belive you used the command with the wrong syntax while the situation might be that the syntax was correct but the underlaying entity refered to by a command argument like a file or device does not exists.
We have an open issue for SATA support but there is none working on it.

Thanks for your feedback.
Regards, Levente

Improvements to command syntax diagnostics

I've committed some changes to make the diagnostics for command syntax errors more consistent and (hopefully) more intelligible. It shouldn't say "out of alternatives" now. Instead, it should output the diagnostics for the most likely alternatives tried during the parse. (In this case "most likely" means the alternatives that matched the most arguments before failing.)

However, you need to realize that we are limited in what we can do to improve these diagnostics. By doing command line / argument parsing using a common syntax mechanism, we have made it hard to output error messages that reflect the semantics of the actual command ... and what the user was presumably trying to do.