GRUB...

[Solar]

Regarding this thread about a user's problems getting GRUB installed... is anyone up to date on the state of affairs regarding GRUB 2?

Anyone using it to boot his OS?

Anyone willing to update the Wiki with the relevant information?

It strikes me as a bit odd that we're still referring to GRUB "legacy", but I've been out of the OS dev loop for too long and haven't kept in touch with the why and how.

[xenos]

My kernel can be booted with either GRUB Legacy or GRUB2. Adding support for GRUB2 took me a while... The main difficulty I encountered is that GRUB2 puts kernel modules and multiboot info structures at ridiculously high physical memory addresses - in contrast to GRUB Legacy, where kernel modules are loaded right after the kernel, and multiboot info structures are located below the 1MB mark. In my previous kernel design this led to a chicken-and-egg-problem: In order to add the upper physical memory to my physical memory manager, I need to know which address ranges are available and which are occupied by things such as kernel modules. In order to check that, I need to parse the multiboot info. In order to access the multiboot info, I need to map it into virtual memory. In order to map anything into virtual memory, I need the physical memory manager up and running... Completely re-designing my memory manager solved the problem.

One thing I like about GRUB2 is the improved boot menu / config interface.

However, there's many things I haven't tried, such as Multiboot 2 (or at least GRUB2's implementation) or directly booting an Elf64 kernel (my Elf64 kernel uses a 32 bit stub and an a.out kludge to be recognized as Multiboot 1 kernel).

I'll have a look at the relevant wiki articles and see whether I can improve them a bit.

[rdos]

I use GRUB legacy on a few PCs, but not GRUB2. However, I don't think I would have any issues with GRUB 2 as I assume nothing about the locations and just "kill" their environment real quick.

The only problem would be if something used the first few kbs, but that seems rather unlikely.

[AJ]

Hi,

I have an ELF64 kernel which boots with GRUB2 (v1.99, using Multiboot 2). I have a few issues with some apparently spurious data between the fixed part of the boot tags structure (3.4.2 in the Multiboot2) and the variable (requested) tags. The project was abandoned due to time constraints but I could dig out the source (still on a live git repo) which includes shell scripts to create the ISO image using grub-mkimage and mkisofs.

I'll see what I can find...

Cheers,
Adam

[Combuster]

Completely re-designing my memory manager solved the problem.

I abused the A.Out kludge for grub 1 to tell it I had a BSS section of 1MB. Which makes it easy to bootstrap memory management as 1MB of ram is more than enough for initial configuration, and GRUB isn't screwing up plans to put anything meaningful there. A quick look at the new multiboot spec shows that tag 2 can do the very same thing for GRUB 2.

Slightly OT: It is pretty annoying that people use multiboot 2 when the spec will be indexed by google as multiboot 1.6.

[xenos]

I abused the A.Out kludge for grub 1 to tell it I had a BSS section of 1MB.

Sounds a bit similar to what I did in the end. I finally created another section in my linker script (with the same attributes as .bss) which holds anything I need for the physical memory manager, including space for page tables.

[jnc100]

I am currently using grub 1.98. This can boot multiboot 1 kernels with the 'multiboot' option in grub.cfg. This is stated in our wiki page for grub 2. As far as I can see the newer update of multiboot (tags etc) is not finalized yet and doesn't provide much more useful information to the kernel than the original multiboot specification did. Do we really need to provide step by step instructions for the newer format when 1) it is liable to change and 2) recent grubs still support the existing well-documented format? The answer is probably yes if we want to collate all available information for the os developer, but it should probably either in its own wiki page or added to the bottom of the current one as I feel we should still recommend the original multiboot format to beginner os developers.

Regards,
John.

[Solar]

This is stated in our wiki page for grub 2.

Which was neither linked from the start page nor categorized in the "Bootloaders" group. I fixed both, and feel that this goes a long way towards addressing my original issues. From quickly scanning the GRUB page, I was under the impression that we don't provide info on how to use / install GRUB 2, only GRUB legacy.

[rdos]

I still think the GRUB page has many problems. It basically only describes how to install GRUB from a Linux-distribution, which I find quite inadequate. The disk images of GRUB that can be used to install GRUB without having Linux is only mentioned in a link. The part related to GRUB in the disk-images wiki page should be moved to the GRUB page instead, along with a description how to install GRUB from the command-line (which is part of the Grub Legacy document linked to).

And no flaming that Windows users will need to download Linux, thank you.

[Solar]

It basically only describes how to install GRUB from a Linux-distribution, which I find quite inadequate.

GRUB 2 is perfectly available through the Cygwin distribution. That is part of why I was asking for GRUB 2 instructions in the first place.

Since we canonically suggest Windows users to use Cygwin anyway, that should be the angle for "Windows users do..." descriptions.

[rdos]

And no flaming that Windows users will need to download Linux, thank you.

It's a wiki, you can go and edit it.

Yes, but am I allowed to take the portion about binary images and move it to the GRUB wiki page?

[rdos]

GRUB 2 is perfectly available through the Cygwin distribution. That is part of why I was asking for GRUB 2 instructions in the first place.

Since we canonically suggest Windows users to use Cygwin anyway, that should be the angle for "Windows users do..." descriptions.

But the issue is not Windows users, but users that don't want to build and install GRUB, but just want test it and possibly install it from a CD/DVD/floppy.

I don't see most ordinary users building and installing GRUB and/or an OS from source in order to check if it is any good. They would want something simpler than that. A bootable GRUB image + OS image is far easier to test.

[Solar]

But the issue is not Windows users, but users that don't want to build and install GRUB, but just want test it and possibly install it from a CD/DVD/floppy.

Huh? You don't have to build GRUB to install it via Cygwin, it comes readily packaged in the current version, and no-one from OSDev.org has to do any updating work for that.

I don't see most ordinary users building and installing GRUB and/or an OS from source in order to check if it is any good. They would want something simpler than that. A bootable GRUB image + OS image is far easier to test.

I get that nagging suspicion that you are confusing two completely different concepts:

1) Getting GRUB installed on your specific machine (or image) so you can try GRUB.

2) Getting GRUB installed in an OS image that you then distribute so that others can try your OS.

Neither requires having Linux installed, either works through the GRUB 2 package provided by Cygwin. I don't see the problem, or why we would need to provide ready-made disk images. They were a crutch to begin with.

[rdos]

I get that nagging suspicion that you are confusing two completely different concepts:

1) Getting GRUB installed on your specific machine (or image) so you can try GRUB.

2) Getting GRUB installed in an OS image that you then distribute so that others can try your OS.

For me they are the same. I tell people that they should install (or boot) GRUB, and then I tell them how to load my OS image from their harddrive (from GRUBs command line or menu.lst file). I'm not installing GRUB into my OS images.

[Solar]

...and you expect OSDev.org to provide them with the how-to to install GRUB?

In that case, I'd still prefer them to go through Cygwin, instead of providing some binary images ourselves.