Page 1 of 1

Doubt in knowing the file system in the bootloader

Posted: Thu Mar 31, 2011 1:02 am
by richi18007
How can one determine the kind of the filesystem (FAT or etx based) of the disk in the bootloader code
Suppose I have this code :-

Code: Select all

[org 0x7c00]
bits 16
%include "loader.h"
global loaderMain
loaderMain:
	;set the appropriate segments for the loading of the data
	mov ax , cs
	mov ds , ax
	mov es , ax
	mov fs , ax
	mov gs , ax
	;grab the bootdisk information from the local 
What should be my next step .I really seem to be stuck at this .Some modern operating system's bootloader gives the following info

Code: Select all

        ;; We have to grab our boot disk info from the boot sector's
	;; stack.  The boot sector will have pushed this information before 
	;; calling us.  We need this stuff before we can do any disk 
	;; operations -- and therefore continue the boot process

	pop AX
	mov word [DRIVENUMBER], AX
	pop AX
	mov word [BYTESPERSECT], AX
	pop AX
	mov word [SECPERCLUST], AX
	pop AX
	mov word [FSTYPE], AX
	pop AX
	mov word [ROOTDIRENTS], AX
	pop AX
	mov word [FATS], AX
	pop AX
	mov word [FATSECS], AX
	pop AX
	mov word [RESSECS], AX
[\code]
but i have a feeling that this is grub based .
So , should i use grub or something else suggest plz

Re: Doubt in knowing the file system in the bootloader

Posted: Thu Mar 31, 2011 6:42 am
by Combuster
You can't sensibly make a first-stage bootloader filesystem-independent - you just can't fit x filesystem drivers in 512 bytes. There is no good reason to either - if you install a bootloader on a partition you already know that partition's filesystem.

What's worse, GRUB's bootsector does not contain a filesystem driver at all, just a pointer to where the next bit of code is which is injected there by whatever's tool is installing it. If you happen to use the default it will load blocks 2...n and execute that (which where you would have put stage2)

The problem is entirely different for when you already loaded a complete application in memory, like GRUB is. When you got the entire binary from your initial partition, nothing stops you from accessing other storage devices and partitions to see if they contain something useful. But you are essentially beyond the basic bootstrap stage at that point.

Re: Doubt in knowing the file system in the bootloader

Posted: Thu Mar 31, 2011 8:16 am
by richi18007
Thanks , din think this way :P
So , basically , as all of the Linux , Windows etc bootloaders know what filesystem they are in and of course they have to know it .'
So , shud i go by keeping the stage2 to search for other filesystems along with other stuffs ?

Re: Doubt in knowing the file system in the bootloader

Posted: Thu Mar 31, 2011 8:28 am
by turdus
Basically you have two options:
1. parse the partitioning table and look for fs id (not recommended)
2. read the first sector of the boot partition and look for magic (reliable)

Re: Doubt in knowing the file system in the bootloader

Posted: Fri Apr 01, 2011 8:37 am
by Combuster
1. parse the partitioning table and look for fs id (not recommended)
+1. The partition id will probably say "linux", at which point you still don't know if its ext2, ext3, ext4, reiserfs, reiser4, xfs or jfs. And that's not taking into account the possibility of the slightly broken setup where you format a partition with something that definitely does not match the partition id description...

So... just don't :wink:

Re: Doubt in knowing the file system in the bootloader

Posted: Fri Apr 01, 2011 10:34 am
by turdus
Combuster: you are absolutely right. That's why I did not recommend it. I use fs id only as a fallback, so I can handle non-standard GPTs (if it's not starting at LBA 1). This seems to be crazy, but it's a fundamental to my OS that never trust data that come from outside the OS, and always try several methods to interpret it.

For example this is how I look for a valid root fs image (that complies with FHS and contains my kernel, drivers and userspace libraries):
- read sectors at the beginning of a disk
- check EFI magic at 0x200, if found, go to GPT parser.
- if not found, parse the BIOS partitioning table in PMBR for valid fs ids.
- if fs id is GPT, read it, and go to GPT parser.
- otherwise it has to be an active partition with FAT32 or my native fs.
- if it's my native fs, read it, and done.
- if it's FAT32, look for a file called ROOTDISK.BIN, and if found done.
- display an error
GPT parser:
- look for native fs' UUID. If found, done.
- if EFI System partition found, go to FAT32 parser, and look for ROOTDISK.BIN
- display an error if neither

I think it's quite bulletproof and gives freedom on how to create the disk image. I'm also working on an EFI bootloader (it's simply says hello for now), so at the end I will have a single disk image that can be booted on BIOS compliant machines as well as on EFI machines.