docs/faq.html - grub4dos-solaris - Rivoreo Source Code Repositories

 <HTML>

 <HEAD>
 <TITLE>GRUB FAQ -- Frequently Asked Questions</TITLE>
 </HEAD>

 <BODY>

 <CENTER><H1>GRUB FAQ -- Frequently Asked Questions</H1></CENTER>
 <CENTER><H3>for version 0.4</H3></CENTER>

 <HR>

 <H2>Contents</H2>

 <UL>
 <LI> <A HREF="#general">General</A>
 <LI> <A HREF="#commands">Commands</A>
 <LI> <A HREF="#filesys">Filesystems</A>
 <LI> <A HREF="#install">Installation</A>
 </UL>

 <HR>

 <H2><A NAME="general">General</A></H2>

 <UL>
 <LI><B>I thought there was no way to autodetect all of the RAM
 on a PC, can GRUB really do it reliably?</B><P>
 For any fairly modern machine, yes.  GRUB can also generally detect
 more than 64MB, as described in the
 <A HREF=technical.html>GRUB Technical Info</A>.  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
 <A HREF=commands.txt>list of commands</A>.<P>
 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.<P>
 <LI><B>Is there any way to abort operations?</B><P>
 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).<P>
 <LI><B>What does GRUB do if there is an error during booting a config
 file entry (such as a disk read error) ?</B><P>
 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.<P>
 </UL>

 <HR>

 <H2><A NAME="commands">Commands</A></H2>

 Here is the generic
 <A HREF=commands.txt>list of commands</A>.<P>

 <UL>
 <LI><B>When editing the config file for GRUB in DOS/Windows/NT, do I
 have to worry about CR/LF translation?</B><P>
 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.<P>
 <LI><B>I noticed that there are some command examples in hexidecimal and
 some in decimal, what formats are supported and where?</B><P>
 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.<P>
 <LI><B>Some commands corrupt some memory state</B><P>
 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.<P>
 <LI><B>When running interactively, can an a different chainloader/kernel
 be loaded after one has already been, or do I have to reset all the
 internal state with the ESC key?</B><P>
 Any "chainloader=" or "kernel=" command used overrides any previous ones,
 and in the case of Multiboot-compatible kernels, requires that modules
 be reloaded.<P>
 </UL>

 <HR>

 <H2><A NAME="filesys">Filesystems</A></H2>

 Here is the listing of
 <A HREF=filesystem.txt>GRUB Filesystems and Interfaces</A>.<P>

 <UL>
 <LI><B>What is the "root partition" ?</B><P>
 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
 <A HREF=http://www.uruk.org/embedded_data.txt>embedded data</A> of the
 stage1.5/stage2, and can be changed via the "root=" or "rootnoverify="
 commands.<P>
 <LI><B>What filesystems are supported, and how do I tell it which one
 to use?</B><P>
 GRUB comes with support for <B>DOS FAT</B>, <B>BSD FFS</B>, and <B>Linux
 ext2fs</B> filesystems, plus a blocklisting notation for accessing blocks
 directly.  When using the normal file syntax, GRUB will autodetect the
 filesystem type.<P>
 <LI><B>When booting an OS, how do I tell the OS what the root
 partition is?</B><P>
 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:<P>
 <UL>
 <LI><B>FreeBSD</B>:  GRUB passes it in the same manner as it's original
 bootloader, as of the version 2.1.0 release.<P>
 <LI><B>NetBSD</B>:  GRUB passes it in the same manner as it's original
 bootloader, as of the version 1.1 release.<P>
 <LI><B>Linux</B>:  GRUB doesn't pass any special root partition info,
 so unless the root partition is set on the command-line, the default
 one complied into the image will be used.<P>
 <LI><B>Mach4</B>:  Mach4 currently ignores the root partition info
 passed in the Multiboot info structure.  You have to explicitly
 put it on the command-line via a "root=hd0a" or "root=hd0s1" type
 of command; see the release notes on Mach4 for details.<P>
 <B>NOTE:</B>  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.<P>
 <LI><B>Chainloaded OS's such as DOS or NT</B>:  The only way they
 have of knowing anything about a root or boot partition is via
 preset offsets in their boot sectors (such as the "hidden sectors"
 parameter of the DOS BIOS parameter block) or
 the "active partition" marker (see "makeactive" in the list of
 commands).<P>
 </UL>
 </UL>

 <HR>

 <H2><A NAME="install">Installation</A></H2>

 Here is the
 <A HREF=install.html>GRUB Installation Guide</A>.<P>

 <UL>
 <LI><B>What partition does GRUB look for the config file on?</B><P>
 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).<P>
 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).<P>
 <LI><B>How do I install taking a stage1 from a floppy and
 placing it on another floppy in the same drive</B><P>
 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.<P>
 <LI><B>When trying to install using the stage1 from my hard disk,
 it complained about a "bad or corrupt version"</B><P>
 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.<P>
 <LI><B>When using a stage1.5 AND stage2, does the "install_partition"
 need to be set in the stage2?</B><P>
 After the Stage 2 is loaded, the Stage 1.5 will patch the
 "install_partition" in the
 <A HREF=embedded_data.txt>embedded data</A> 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.<P>
 <LI><B>Is there anywhere on a hard disk I can put GRUB's stage2 which is
 separate from the rest of the filesystems?</B><P>
 Sometimes.  This is something of an advanced operation to set up, and is
 not recommended for general use.<P>
 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.<P>
 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):
 <pre>
 dd if=stage2 of=/dev/sda bs=512 seek=1
 </pre>
 ...then run the install command mostly normally, but for the stage2 file
 use the blocklist string "1+63", which will point to this area.<P>
 </UL>

 <HR>

 <A HREF=mailto:erich@uruk.org><I>erich@uruk.org</I></A><P>

 </BODY>
 </HTML>
	<HTML>

	<HEAD>
	<TITLE>GRUB FAQ -- Frequently Asked Questions</TITLE>
	</HEAD>

	<BODY>

	<CENTER><H1>GRUB FAQ -- Frequently Asked Questions</H1></CENTER>
	<CENTER><H3>for version 0.4</H3></CENTER>

	<HR>

	<H2>Contents</H2>

	<UL>
	<LI> <A HREF="#general">General</A>
	<LI> <A HREF="#commands">Commands</A>
	<LI> <A HREF="#filesys">Filesystems</A>
	<LI> <A HREF="#install">Installation</A>
	</UL>

	<HR>

	<H2><A NAME="general">General</A></H2>

	<UL>
	<LI><B>I thought there was no way to autodetect all of the RAM
	on a PC, can GRUB really do it reliably?</B><P>
	For any fairly modern machine, yes. GRUB can also generally detect
	more than 64MB, as described in the
	<A HREF=technical.html>GRUB Technical Info</A>. 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
	<A HREF=commands.txt>list of commands</A>.<P>
	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.<P>
	<LI><B>Is there any way to abort operations?</B><P>
	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).<P>
	<LI><B>What does GRUB do if there is an error during booting a config
	file entry (such as a disk read error) ?</B><P>
	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.<P>
	</UL>

	<HR>

	<H2><A NAME="commands">Commands</A></H2>

	Here is the generic
	<A HREF=commands.txt>list of commands</A>.<P>

	<UL>
	<LI><B>When editing the config file for GRUB in DOS/Windows/NT, do I
	have to worry about CR/LF translation?</B><P>
	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.<P>
	<LI><B>I noticed that there are some command examples in hexidecimal and
	some in decimal, what formats are supported and where?</B><P>
	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.<P>
	<LI><B>Some commands corrupt some memory state</B><P>
	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.<P>
	<LI><B>When running interactively, can an a different chainloader/kernel
	be loaded after one has already been, or do I have to reset all the
	internal state with the ESC key?</B><P>
	Any "chainloader=" or "kernel=" command used overrides any previous ones,
	and in the case of Multiboot-compatible kernels, requires that modules
	be reloaded.<P>
	</UL>

	<HR>

	<H2><A NAME="filesys">Filesystems</A></H2>

	Here is the listing of
	<A HREF=filesystem.txt>GRUB Filesystems and Interfaces</A>.<P>

	<UL>
	<LI><B>What is the "root partition" ?</B><P>
	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
	<A HREF=http://www.uruk.org/embedded_data.txt>embedded data</A> of the
	stage1.5/stage2, and can be changed via the "root=" or "rootnoverify="
	commands.<P>
	<LI><B>What filesystems are supported, and how do I tell it which one
	to use?</B><P>
	GRUB comes with support for <B>DOS FAT</B>, <B>BSD FFS</B>, and <B>Linux
	ext2fs</B> filesystems, plus a blocklisting notation for accessing blocks
	directly. When using the normal file syntax, GRUB will autodetect the
	filesystem type.<P>
	<LI><B>When booting an OS, how do I tell the OS what the root
	partition is?</B><P>
	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:<P>
	<UL>
	<LI><B>FreeBSD</B>: GRUB passes it in the same manner as it's original
	bootloader, as of the version 2.1.0 release.<P>
	<LI><B>NetBSD</B>: GRUB passes it in the same manner as it's original
	bootloader, as of the version 1.1 release.<P>
	<LI><B>Linux</B>: GRUB doesn't pass any special root partition info,
	so unless the root partition is set on the command-line, the default
	one complied into the image will be used.<P>
	<LI><B>Mach4</B>: Mach4 currently ignores the root partition info
	passed in the Multiboot info structure. You have to explicitly
	put it on the command-line via a "root=hd0a" or "root=hd0s1" type
	of command; see the release notes on Mach4 for details.<P>
	<B>NOTE:</B> 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.<P>
	<LI><B>Chainloaded OS's such as DOS or NT</B>: The only way they
	have of knowing anything about a root or boot partition is via
	preset offsets in their boot sectors (such as the "hidden sectors"
	parameter of the DOS BIOS parameter block) or
	the "active partition" marker (see "makeactive" in the list of
	commands).<P>
	</UL>
	</UL>

	<HR>

	<H2><A NAME="install">Installation</A></H2>

	Here is the
	<A HREF=install.html>GRUB Installation Guide</A>.<P>

	<UL>
	<LI><B>What partition does GRUB look for the config file on?</B><P>
	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).<P>
	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).<P>
	<LI><B>How do I install taking a stage1 from a floppy and
	placing it on another floppy in the same drive</B><P>
	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.<P>
	<LI><B>When trying to install using the stage1 from my hard disk,
	it complained about a "bad or corrupt version"</B><P>
	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.<P>
	<LI><B>When using a stage1.5 AND stage2, does the "install_partition"
	need to be set in the stage2?</B><P>
	After the Stage 2 is loaded, the Stage 1.5 will patch the
	"install_partition" in the
	<A HREF=embedded_data.txt>embedded data</A> 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.<P>
	<LI><B>Is there anywhere on a hard disk I can put GRUB's stage2 which is
	separate from the rest of the filesystems?</B><P>
	Sometimes. This is something of an advanced operation to set up, and is
	not recommended for general use.<P>
	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.<P>
	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):
	<pre>
	dd if=stage2 of=/dev/sda bs=512 seek=1
	</pre>
	...then run the install command mostly normally, but for the stage2 file
	use the blocklist string "1+63", which will point to this area.<P>
	</UL>

	<HR>

	<A HREF=mailto:erich@uruk.org><I>erich@uruk.org</I></A><P>

	</BODY>
	</HTML>