For any fairly modern machine, yes. GRUB can also generally detect more than 64MB, as described in the GRUB Technical Info. It has been tried in many machines with memory sizes ranging from 72MB up to 2 GB in one case. There are some machines still in use which don't report most of their RAM using any of the well-known BIOS memory interfaces. For those, there really is no recourse but to use the "uppermem=" command to set it manually, which is described in the list of commands.
Note that passing this value correctly to Linux involved patching a "mem=" statement onto the beginning of the command-line, and for FreeBSD required a fix to some earlier versions (as it figured any value over 64MB was a bug and it would panic on this). A Multiboot compliant kernel has no problem.
Whenever GRUB is waiting for input, if the user presses the ESC key, then as much of the internal state changes as possible is cancelled and GRUB goes up one interface level (if at the top level, it just redraws the screen).
Unless otherwise told to (via the "fallback=" command), GRUB will drop into the interactive command-line after displaying the error message to the user. If the user presses enter (perhaps after some editing), then it will attempt to execute this line and if successful continue from where it left off in the config file entry.
No. GRUB will work with CR/LF or LF only line endings in it's configuration file perfectly fine. I have created and managed a config file from Windows 95 using the NOTEPAD program with no problems after installing GRUB on the hard disk using a floppy created from Windows 95 as well.
Whenever there is a number entered by the user from either a command-line or the config file, it can be entered in decimal or hexidecimal as desired (the letters used for hex numbers are case-insensitive). The way GRUB uses to distinguish them is that hex numbers start with "0x", so one could type "128" or "0x80" alternately.
Performing an "install=" or "testload=" command will corrupt any chainloaders/kernels currently loaded into memory. I.e. simply redo the loads or always make sure that installs or testloads are done first.
Any "chainloader=" or "kernel=" command used overrides any previous ones, and in the case of Multiboot-compatible kernels, requires that modules be reloaded.
This is both the default partition for searching for/loading files and the source of the "root partition" information used for chainloaders and data passed to kernels in various formats. This defaults to the "install_partition" variable in the embedded data of the stage1.5/stage2, and can be changed via the "root=" or "rootnoverify=" commands.
GRUB comes with support for DOS FAT, BSD FFS, and Linux ext2fs filesystems, plus a blocklisting notation for accessing blocks directly. When using the normal file syntax, GRUB will autodetect the filesystem type.
The root partition setting in GRUB is mostly for it's own use (where it looks for data by default if no device is specified), and is passed to a fully Multiboot-compliant OS. When possible, the information is passed along to the OS being booted. Here is a listing of where each of the major OSes GRUB is being used for gets it's root partition from:
NOTE: The default version of the UK22 release is compliant with an earlier and incompatible multiboot version. A patch to bring it up to Multiboot 0.6 is available in the GRUB FTP area. The version distributed with the GNU HURD already has this patch.
GRUB looks for the config file in the default root partition, unless a partition name was included at the beginning of the config file name when it was installed (in that case it ignores the default).
To keep matters simple, it is recommended that when installing, ALWAYS use the "p" option in the "install=" command when the stage2 file is in a partition type readable by GRUB, which will force default root partition to be the same as where the stage2 is (i.e. that's where it looks for the config file).
You don't. There is currently no provision to pause an install operation so you can switch floppies in the middle. Placing the stage1 as a file on the destination floppy, or on a hard disk somewhere, is what has to be done here.
When installing to a floppy, you must use a stage1 which has NOT been used to boot off of a hard disk, as an essential piece of code for floppy booting is deleted when installing the stage1 to a hard disk. A "bad or corrupt version" error will be returned if the code is not present.
After the Stage 2 is loaded, the Stage 1.5 will patch the "install_partition" in the embedded data with it's own value. This behavior is to make it easier to install new versions of the Stage 2 without having to patch special values into it each time, since the whole point of the Stage 1.5 is to allow the convenience of reading the largest component as a normal file.
Sometimes. This is something of an advanced operation to set up, and is not recommended for general use.
On all PC-partitioned hard disks, there is an area after the partition table (starting at the second sector) but before the first partition. This can be used for more-or-less any purpose that is desired, as it is usually dead space. On most modern hard disks, it is 31.5K in size (63 disk sectors), which is large enough for the non-debug version of GRUB. If a some other special "multi-OS" bootloader is installed, then this might already be in use by that program.
On Linux or FreeBSD, one would use a "dd" command to place the stage2 on the disk (here's a Linux example using the first SCSI disk):
dd if=stage2 of=/dev/sda bs=512 seek=1...then run the install command mostly normally, but for the stage2 file use the blocklist string "1+63", which will point to this area.