Another example how to create a grub image in Bare Bones

[Jezze]

I'm just posting this here and then you can decide if it is necessary or not.

In Bare Bones it says you can use pad-files to get your data on the right place in your disk image. I found a somewhat simpler way.

Create an image of 4MB (You can set 2880 instead of 8000 for floppy size)
dd if=/dev/zero of=os.img bs=512 count=8000

Copy grub stage files
dd if=stage1 conv=notrunc of=os.img bs=512 seek=0
dd if=stage2 conv=notrunc of=os.img bs=512 seek=1

Copy your kernel
dd if=kernel.bin conv=notrunc of=os.img bs=512 seek=200

If you have any modules like this init ramdisk you can add them also like this for example
dd if=initrd conv=notrunc of=os.img bs=512 seek=300

EDIT:

Solar pointed out that this assumes that the kernel isn't bigger than 100 blocks and the stage2 isn't bigger than 199 blocks. If that is the case you'll have to increase the value of seek.

[Solar]

Hm... what happens if stage2 is larger than 199 blocks, or your kernel larger than 100 blocks?

[Candy]

I'll add my current grub booting method which creates a regular e2fs and boots it with grub. It's 100% Windows compatible (requirements: Cygwin with e2fsimage and dd installed) and gives you a 32MB disk with whatever you want on it.

Haven't been able to get grub to autoload my configuration yet

I'll gzip it up pretty soon.

[Jezze]

Solar: Then of course you'll have to change the offset of where to put the kernel or extra files. But that is easier than having to keep track of your kernel size every time you add something new and correct the pad files accordingly.

[xenos]

This approach is nice in the sense that it doesn't require mounting a disk image as a loopback device. However, it lacks a file system, and hence requires manual booting from the GRUB command prompt, using the sector offsets of the kernel and the modules. This can get quite annoying on a large number of reboots (which is the usual debugging situation in OS development).

For this reason, I recently moved to using ISO CD images instead of floppy images for my kernel. One simply needs to put GRUB and the required files into some folder and mkisofs does the rest. I placed this step in my build script, so whenever I build a new kernel, it creates an updated ISO image.

I wonder whether there exists a similar way to create a formatted floppy image containing the directory structure and files from some existing directory. Of course the task is very simple, and in fact this is what happens when one mounts a loopback device. The thing that bothers me is that at some point one needs root privileges to mount a loopback device, and I would prefer to avoid this. It would certainly be very simple to write a small program that just creates a formatted floppy image, puts the bootloader in place and finally copies the files to that image, and I wonder whether there is already a standard tool for this, just like mkisofs for ISO images.

[Jezze]

XenOS: Yeah I'm using mkisofs too but when creating a disk image I had to resort to this solution because I couldn't find anything simular to mkisofs for disk images.

[Candy]

... couldn't find anything simular to mkisofs for disk images.

There's this tool that's installed on cygwin if you do a full install called e2fsimage, which does something similar to mkisofs for disk images.

Just saying...

[Jezze]

Ah great tool. Why isn't there a universal tool like that for every filesystem?

[Candy]

Ah great tool. Why isn't there a universal tool like that for every filesystem?

For one, because you're not writing one

Essentially, because nobody sees it as something they need so much that they'll make a basic one of them. For the first FS I designed myself I have one of these tools. I'll be developing a new one when I start on the new FS.

[xenos]

Great! e2fsimage is ecactly what I've been looking for. (Although it would be even better to have something similar for more file systems, but having a tool for EXT2 it's certainly better that nothing.) Furtunately it also works with Linux and not only CygWin...

I was once working on a small assembler kernel assembled with FASM and linked with JLOC. With these tools it was quite simple to build a bootable, FAT formatted floppy image. I simply defined some macros in FASM to binary include the files that should be placed on the image, with proper sector alignment, and to "assemble" the FAT and root directory. With JLOC I then placed the boot sector, FAT, root directory and data at the right places where they should appear in a disk image. That worked flawlessly! Unfortunately I could not find a way to do this using GAS / LD, due to the lack of some macros...

[js]

Tools similar to e2fsimage :
* genext2fs : can create ext2 images of desired size, you can choose the owner of the files on the disk (not individually last I checked), create char/block devices on the image from a listing, etc. Used it for my own OS, wonderful tool. Dunno if it works under cygwin though. Works as non-root.
* mtools : Can access read/write FAT images. (And even, there's an obscure option *somewhere* that allows it to operate on a chosen partition of a hard disk image with partitions on it. Yes sir.). Used it to script access to qemu disk images, works fine as non-root.
* If you're interested in a tool which creates SFS (Simple FileSystem) disk images, I have written one so just ask (bash script - uses dd and hexdump, works as non-root).

For "bare" grub disk images, you can use raw offsets in your menu.lst. Here are the commands (adapted from Jezze's commands) :

Code: Select all

dd if=/dev/zero of=os.img bs=512 count=2880
dd if=stage1 conv=notrunc of=os.img bs=512 seek=0
dd if=stage2 conv=notrunc of=os.img bs=512 seek=1

Generate the menu.lst, add it to the image and tell grub to use it :

Code: Select all

cat > menu.lst <<EOF
# grub's menu.lst for your awesome OS.
title My Awesome OS
# 200 is kernel offset, 100 is kernel length (can be greater)
kernel (fd0)300+100
# 300 is module offset, 50 is module length (can be greater)
module (fd0)400+50
EOF

dd if=menu.lst conv=notrunc of=os.img bs=512 seek=200

grub <<EOF
device (fd0) os.img
install (fd0)0+1 (fd0) (fd0)1+199 (fd0)200+1
EOF

Add the kernel & modules :

Code: Select all

dd if=kernel.bin conv=notrunc of=os.img bs=512 seek=300
dd if=module conv=notrunc of=os.img bs=512 seek=400

Can't remember the "raw sectors offset" syntax for grub off the top of my head, so it might be slightly different.

Also, IIRC, grub auto-detects the menu.lst if you put it just after stage2, with no gap inbetween, so in that case you wouldn't need the grub-install part, but I might be mistaken.

P.S. : I'll correct the grub syntax and upload my SFS tool somewhere when I find the relevant pieces of code in my archives...

[Jezze]

I totally forgot about this thread. I tested your script and it worked perfectly. Thanks alot! I've been very close to figuring that out myself but I never got it to work.

I would like to see your SFS code too so when you find it let me know!

[js]

I tested your script and it worked perfectly.

Well, my memory isn't as bad as I thought

Here's the sfs generator (bash script, comments and variable names in French, might be plain-sh compatible) :
http://gist.github.com/539080

When I was working on that OS project, I used a versionning filesystem... The versionned data structure is rather simple, so it shouldn't be too hard to convert to git / svn / whatever, but I kind of scattered my history(*) in several .tar.gz files so I need to find those before I can get a usable history of that project... But given the state of my sleep deprivation, it'll be for another day .

(*) As the number of revisions grew up, that versionning filesystem became more and more slow and sluggish, so I often had to manually purge the revision history into one bit .tar.gz .