I stumbled across a GRUB problem, so I started reading some documentation, and finally I got the system running again.
However, a few questions are left…
First, regarding GRUB stage 1.5: The documentation is rather poor. It just says it is the same as stage 1 with dedicated file system support. But when do I need this file system support in stage 1.5?
The goal of stage 1 (and stage 1.5) is to load and execute the stage 2 code. As far as I see, stage 2 is always located in a boot sector (at least it seems not to be part of the filesystem). The address can be obtained from the partition table. So when is the file system support actually required in stage 1.5?
Second, just playing around, I tried to setup a dedicated partion for grub. Unfortunately, the root command can not access the partition (error 18), complaining the cylinder exeeds the maximum supported by BIOS. Indeed, that’s true. However, regarding the documentation, GRUB stage1 supports LBA. So what?
Thanks for answers, or maybe you can point me to other forum/resources…
When you use GRUB for more than just booting an OS. GRUB has a lot more facilities than you may realise.
Stage 2 is normally on a Linux partition and is normally accessed before an OS is chosen.
This is a well-known bug/feature of GRUB which was first demonstrated a decade ago when a few Gb was all anyone had. It has to be placed within a certain number of cylinders of the start of the disk. Where the Linux / partition falls within this limit, it normally goes in the / partition (within the /boot folder). Where this is not practical, you need to create a very small /boot partition within the limit to hold the /boot folder including GRUB.
It’s not GRUB’s fault. Since GRUB has to read the filesystem and the BIOS calls are all that it has, the files it needs must be within reach of BIOS calls. I suppose a more primitive or OS-specific bootloader might all fit within the first track and not have to read files from the main part of the disk.
There were a couple of limits due to the number of addressing bits in the BIOS calls, one some 15 years or so ago of 500MB, then one around 10 years ago of 128GB, and I think but don’t quote me, the limit is some huge amount, for the moment at least.
As far as I see, stage 2 is always located in a boot sector (at least it seems not to be part of the filesystem)
stage 1.5 and stage 2 are both in the file system located in /boot or /boot/grub (I’m on XP so can not check). Stage 1 can be in the MBR (Master Partition Table),first EMBR (Extended Master Partition Table) or linux partition first sector. If you look there are 4 or so stage 1 files, the one in use will depend on the linux file system type. Stage 1 can not read the file system so the start sector # for the correct stage 1.5 is embedded into it, I think at data offset 42. As far as I know stage 2 can not read any file system, so stage 1.5 tells it how.
I do not know just what happens if a dedicated partition is used for grub of different file system then the main linux file system.
There has to be a stage1.5 that knows how to look into the type of filesystem that is used to hold stage2. And of course the disk has to be readable by the BIOS (usually the first two, sometimes more).
There has to be a stage1.5 that knows how to look into the type of filesystem that is used to hold stage2.
My understanding (very limited) if using a dedicated boot partition the stage2 would be on it. So lets say the dedicated partition is fat32 and linux root is ext3. Is it possible to mix file systems and if yes, how would stage2 know how to read the root file system if fat32 stage1 is used ?
It looks like with a dedicated boot partition one must use “chainloader +1” and it will then load a new grub stage1 from the linux root partition along with stage1.5 and stage2 .
So one must manualy install grub and its needed files to the dedicated partition.
Grub must also be installed on each linux root partition. (Hope I’m somewhat clear on my thinking)
Sure. You don’t need to chainload to achieve this, though you may want to chainload for other reasons. If you look in /boot/grub you will see a whole bunch of stage1.5 files, for different filesystems. The one that would be used in your case is fat_stage1_5. At the time you install GRUB, the installer looks at the filesystem type of the boot partition and chooses the right stage1.5 to embed in the boot track. It’s stage1.5 that knows enough about the filesystem to read stage2 which does the rest. Stage2 is filesystem independent. It doesn’t actually read the root filesystem. It just loads the kernel. What happens afterwards is the kernel’s problem. Generally the name of the root system’s partition is passed in as a boot parameter.
Thanks a lot for your contribution. It reveals (at least it appears to me) that grub handling is not that easy, not only for me.
As far as I can see, there is no descent answer for what stage1_5 is good for. So I will probably carry on with GRUB people directly.
Since other interested people may read this thread, please let me make some corrections. Some of the answers are, hmpf, might be misleading and may confuse other readers.
– The error 18 (“the cylinder exeeds the maximum supported by BIOS”) should never appear nowadays. Current BIOS versions support LBA up to 2TB. I got this problem because I use an old year 2000 BIOS, which can’t handle a 250GB disk properly (only about the first 130GB).
– You can find the GRUB loaders in the file system, however, this is only used to install the bootloader. I.e. to copy them to the bootsectors. In the process of bootstrapping, the file system is not accessed by GRUB until stage2 is up and running (in order to read menu.lst and look for the kernel in the target’s partition file system).
I could run GRUB without stage1_5 in many different scenarios, i.e. on different grub file systems, with several target file systems, I could also boot an extended partition directly. Even without GRUB stage1 you can do all of this (but not boot an extended partition).
So I continue wondering what stage1_5 could be good for… On the other hand, there is one reason not to install stage1_5: if you have RAID or other exotic device driver which make also use of first disk track.
[QUOTE=nonokey;2004188]As far as I can see, there is no descent answer for what stage1_5 is good for. So I will probably carry on with GRUB people directly./QUOTE]
I explained it in the last post. stage1.5 handles access for other filesystems and also makes it unnecessary to embed the block numbers of stage2, so that can be moved around if needed. Also without stage1.5, stage2 would know how to access only the filesystems it knows about. 1.5 widens the range to exotic filesystems and makes the architecture more modular.
If you are really curious, some of it is documented in the texinfo of grub, access it by “info grub” and go to Internals. Or you could have easily found it by search, here’s an article which has many gory details:
To elaborage a bit, if stage1.5 is present, the installer embeds the number of its first block in stage1 so that it can be found. Otherwise, in the absence of stage1.5, the installer embeds the numbers of stage2 blocks in the first block of stage2 and then embeds the number of the first block of stage2 in stage1. So if the stage2 file is moved on the filesystem, the boot process fails. This would be a source of failure if the filesystem was one where things could get moved around, e.g. by backup and restore programs, optimisers, etc.
On the other hand, stage1.5 has been written to the first track so it doesn’t matter if you move the stage1.5 files on the filesystem, a copy has already been taken. This illustrates one of the advantages of stage1.5, aside from being extending GRUB to handle other filesystems.
Thanx for the explanation! I was looking around for something like this. However…
…As long as stage2 is placed in the boot records of a partition, you can move the partition around as you want. The (standard/dos) boot loader in the mbr will use the given offset in the partition table, load the first block and execute it. So no need for such GRUB stage1_5 feature in this case. Please correct me if I’m wrong.
Eventually, the stage1_5 appears to me only useful if you frequently update your stage2 code. You don’t need to rewrite the boot records after that with the new boot loader (thou this would also not take much effort).
Writing the first disk track leaves a bad taste and is’nt worth the gained “flexibility”, to my mind. Thou, people should decide themselves.
Ah but if you look at the documentation, you will see that there is no space to write all the block numbers of stage2, or stage 1.5 for that matter, in stage1. So their trick is to embed the first block number in stage1, and this first part is responsible for loading the other blocks. How does it find the remaining blocks? Because the remaining numbers are embedded in that first block of stage2. So if you move stage2, you invalidate those block numbers.
The first track of a disk is reserved for boot purposes in the PC architecture. So GRUB is entitled to use it.
The first block of the disk (mbr) contains the 440 byte bootloader. The bios loads the block and executes the bootloader.
The bootloader examines the partition table. The bootable entry is selected. This entry defines the offset of the related partition. So the bootloader loads this block and executes it (2nd stage bootloader)
When you move the partition (e.g. with partition manager, parted, whatever), the partition table is updated. So when the bootloader (mbr) starts next time, it takes the (new) offset. No change to the boot loader itself is required.
In those cases, there is no need for any fixed address within the mbr bootloader for the (second stage) boot loader. Also no need to extend the boot loader to the remaining sectors of the first track, or to load a file system driver to access any file system directly.
I played around with a standard/dos mbr and with moving a window partition and suse partition (suse partition with grub stage2). There is no problem after moving. The os is successfully started in every case.
There is one exception: if you want to place (for any reasons) the (second stage) boot manager in an extended partition.
Yes, but you are describing a DOS bootloader. GRUB is different. You may not agree with its design decisions, but you wanted an explanation of how it works and you got it. I’m not here to defend it.
In the case that you described, GRUB is a secondary loader residing in the partition sector, and it moves along with the partition as you say. But if you are using GRUB as a primary bootloader and you are using only stage2, then it will break if you move the stage2 file. But if you use stage1.5, there is no problem moving the stage2 file.
…And I’m not accusing grub. In fact I’m happy with grub. Just want to get the details. Based on this what I know atm, I think I won’t choose the mbr setup again. Instead, either the installation on the Linux partition or chose a dedicated grub partition (both with setup (hdx,x), so mbr untouched).
Thanks for your patience explaining me the mechanism! kind regards, Steffen
btw: I was now looking for ext2/3fs boot record setup, but couldn’t find much details. It seems the boot record contains at offset nul a jump somewhere into the file system where the stage2 image is placed (but this can’t be the actual stage2 file, can it?). Hmpf.
In fact I’m happy with grub. Just want to get the details. Based on this what I know atm, I think I won’t choose the mbr setup again. Instead, either the installation on the Linux partition or chose a dedicated grub partition (both with setup (hdx,x), so mbr untouched).