mkisofs fail...

[ATC]

Just installed latest Cygwin package available that comes with all the tools. I decided I wanted to try Grub out bad enough, lol. However, I've encountered epic fail in the 10th degree of magnitude (<- very bad).

I followed instructions EXACTLY as written in the Wiki about making a no emulation El Torito ISO. It simply does not work. It says over and over:
I: -input-charset not specified
Missing pathspec.
<blah blah>...report errors to...<blah blah>

(and mind you, I checked for EXACT spelling over and over and I typed it perfectly)

Deviating from the path a bit and just creating my own directories by hand, it simply claims:
genisoimage cannot find stage2_eltorito

Playing around with different parameters crashed Cygwin, lol. I guess when it says it can't find the bootloader (stage2_eltorito) that it's a step forward, but it makes no sense. I tried using different paths, making an extra copy, etc and it doesn't work. I have VERY little experience with Unix environments (like this emulation), so I could be missing something obvious. :-/ Can anyone help a brudda out? I've been dying to try Grub out and simply can't.

EDIT: I tried replacing that final $ISO_DIR with a / and it acts like it's about to do something then says:

genisoimage: Device or resources busy. File /cygdrive/c/pagefile.sys is not readable - ignoring

Looked in that folder, and it's totally empty. Something ominous??

::EDIT AGAIN: I think I got it figured out! I used the subtly different way from the official Grub manual and it actually output. Now I'll rig it up for real and see how it works.

[ATC]

Just a quick Grub question...

I got Grub to boot my PE kernel, but I'm a bit curious now. After it boots, my code simply manipulates video memory to write some text. Just wanted to ensure everything was working without too many variables in the failure vs success equation. But it prints out this little message right after this:

[Multiboot-kludge, loadaddr=0x101000, text-and-data=0x100f, bss=0x0, symtab=
0xb8, strtab=0x666f736b(bad), entry=0x101030]

Hmmm... Not sure if I should be alarmed by this or not. There is an __asm{hlt} instruction in my code, so I don't see how it could be "returning control" to Grub or anything. This "(bad)" has me concerned as well.

Is this harmless/normal or indicative of some screw-ups? Note: I tried without printing anything and it still prints this Grub message after boot. The weird thing is, when I DO print some text this is BELOW it for some reason. Anyone know what's going on here? My first time ever using Grub.

[celtic]

No sweat - I'm pretty sure that's fairly normal.

If your code is outputting beneath that, then it must be reading in the cursor position (?) or something like that before writing out to video memory.

I'm not sure about the "(bad)" bit, as that message flicks by so quickly for me that I can barely read it!

[ATC]

Ok, got rid of the "(bad)" thing. Just some minor code mistakes. The message from Grub is still printed, but maybe that is normal as you suggested. If anyone knows for sure, please speak up! I'm sort of thinking about abandoning my homemade bootloader from Grub now though! Lol! Grub is much sexier and better written, lol. Btw, I was saying that my code prints BEFORE the Grub message, NOT after. So I suppose that is normal too? I just don't understand how that happens if my kernel takes control and hlt's the processor. Well... Maybe Grub has already manipulated the video memory before my kernel launches, but it's just below the point I use? Only thing I can think of. Because there's no returning control to it that I can see.

Only problem I'm experiencing now is mangling of the char* (string) I'm trying to print. Really wacky characters getting printed out. I suppose that lies therein my implementation though? This was just a simple "see if it works" implementation. I haven't integrated any of my real code into this yet. Can't imagine any other cause for it.

[celtic]

You're absolutely right - it is normal for this to appear (though better that '(bad)' is gone, I guess) - but GRUB actually writes this out to the screen just before transferring control to your code. (and I would recommend letting GRUB do the bootloading work for you - you can let it be and work on the interesting stuff; your kernel!)

Since GRUB (or any bootloader) could leave your screen in an undefined state, you can just simply wipe it before you set to work writing stuff to video mem yourself!

Wacky characters? Check your string storage, I guess.

[ATC]

Thanks! I confirmed that too. I can easily overwrite it, so we were right, and it's just printed to video memory before handing off to the kernel. Yeah, I think my string printing wacky stuff is just a case of me falling victim to my own macros, lol.

I've gotten a nearly perfect workflow now. I build the kernel and all supporting files/code in Visual Studio, it gets output into my Cygwin>>home>>... folders, then Visual Studio invokes my post-build event batchfile which calls mkisofs to build the ISO. Then mkisofs kindly plops it right by my feet on the desktop in arms reach of Virtual PC! <3 Now I want automatic deployment to the emulator ffs! With kernel-level debugging! lol.. Gotta find a solution to that. It could make me work WAY faster still. Seconds add up!

Yeah... Definitely sticking with Grub. Much more professional and robust than my hack n' splice pseudo-1337 bootloaders, lol. Even some of the "big boys" aren't too good to use it, heheh. I suppose when perfectly good wheels are available, one should focus on building a (better) cart. So that looks like my new plan.

EDIT: Yeah, my Debug/Write text function was printing junk due to not having all the supporting files/macros in the project. Fix'd...