OSDev.org

When my OS boots, the boot sector loads the second stage of the bootloader from the disk - stage 2 is a 20KB raw binary file on the file system (EXT2). The position of the stage 2 file on disk is hard coded into the boot sector. My problem is that Linux keeps moving my bootloader to a different position on the disk image. When I need to update my bootloader I mount the disk image and dd my bootloader file to the disk. The result is the same using the copy command ('cp').

Sometimes (not always) Linux will move the file on the disk - examining the disk with a hex editor reveals that the old stage2.sys file contents are on the disk still and the new stage2.sys contents are also on the disk. But my boot sector, of course, isn't aware that the file has moved on disk.

The FAT file system has a feature where a file can be given the system flag which tells the operating system not to move the file contents on disk. Does EXT2 have a similar feature? I checked the wiki page and asked google but couldn't find anything there.
Alternatively, is there a way to reserve more than the first 1024 bytes of the partition so I can store my 20KB bootloader file there?

Any help / ideas are appreciated.

You might want to consider your man pages.

no92 wrote:You might want to consider your man pages.

And of course, man mkfs.ext2 doesn't yield anything helpful.

I looked at the specification and the superblock starts at 1024, which means you have twice the usual bootsector size for your personal use. Everything after that is under influence of the filesystem hierarchy and is fully movable. What probably happens is that the new file is written elsewhere and then the indexes are updated to point to the new file. On a filesystem with no journaling, this is the safest way of preventing any form of corruption from happening.

The only correct solution is to do what is considered completely normal on FAT filesystems: use the space in the bootsector to actually parse the filesystem and load the next stage from it.

The better solution is to teach your bootloader to do EXT2 path resolution and inode reading. It's not too much code. I recommend you have a stage 1.5 that is capable of understanding (read-only) ext2 to the extent it can locate files in the filesystem.

There is a bit of space before the superblock that can be usedful. See http://www.nongnu.org/ext2-doc/ext2.html. I think such a no-move-this-file bit exists. Perhaps EXT2_IMMUTABLE_FL? EXT2_BOOT_LOADER_INO might be of interest.

sortie wrote:The better solution is to teach your bootloader to do EXT2 path resolution and inode reading. It's not too much code. I recommend you have a stage 1.5 that is capable of understanding (read-only) ext2 to the extent it can locate files in the filesystem.

There is a bit of space before the superblock that can be usedful. See http://www.nongnu.org/ext2-doc/ext2.html. I think such a no-move-this-file bit exists. Perhaps EXT2_IMMUTABLE_FL? EXT2_BOOT_LOADER_INO might be of interest.

Thankyou, the EXT2_IMMUTABLE_FL flag will be very useful in stopping Linux moving my bootloader around.

Oh, and my bootloader is already somewhat capable of parsing an EXT2 file system (searches for a file in the root directory with a specific name for now), that's how it loads my kernel (well, elf executable capable of directing hardware interrupts and offering a simple command line featuring an echo command ).
I might have given the impression that I'm a newbie looking for someone to fix my bootloader. I've been OSdeving for over a year now (this is a new project with a fancy bootloader) so in the grand scheme of things I'm just a lot less of a newbie .

Now that the file is immutable I can't write to it to update my bootloader but I've come up with a decent solution for that; whenever I run my OS in an emulator I will create the disk image with the latest version of everything (bootloader and kernel) in RAM.

So, new question: is it possible to create a ramdisk and write bytes directly to it (via dd) under Linux?

Why not just use a regular file instead of a ram-filesystem-thingey?

I don't entirely trust that immutable flag. For instance, my ext2 filesystem implementation doesn't support it, but that's a bug in my code. I believe the immutable-bootloader file scheme to be really poor. It is much more robust and well-designed if the bootloader is capable of reading from the filesystem regardless of where the kernel is on the filesystem. This will make upgrading the kernel must easier, you simply replace the kernel file.

Don't worry, you don't seem like a newbie that wants us to fix the bootloader - after all, you didn't post the source code. ;-)

sortie wrote:Why not just use a regular file instead of a ram-filesystem-thingey?

That's what I'm doing currently; I just thought it might be a little quicker if I created the disk in RAM. It isn't a problem.

Thanks for the assistance.