SourceFiles.org - Use the Source, Luke

Back to files

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN> <HTML>
<HEAD> <TITLE> HOWTO & FAQ Gujin </TITLE></HEAD> <BODY BGCOLOR="eeeeee" LINK="6666aa" ALINK="aa6666" VLINK="6666aa" TEXT="#0000ff">

<HR SIZE="4" WIDTH="50%">
<CENTER><BIG>FAQ Questions:</BIG></CENTER>

<LI><a href="quick_describe">
Please quickly describe Gujin.
</a></LI>
<LI><a href="why">
Why should I use Gujin?
</a></LI>
<LI><a href="describe_install">
I just want to install, do you have a quick documentation? </a></LI>
<LI><a href="howto_precompiled">
How do I use a precompiled configuration in file standard.tar.gz? </a></LI>
<LI><a href="standard_content">
What is the content of file standard.tar.gz? </a></LI>
<LI><a href="recompile_from_source">
How do I recompile from sources?
</a></LI>
<LI><a href="nothing_started">
When I reboot my computer, I do not see anything changed, Gujin is not started. </a></LI>
<LI><a href="no_kbd_mouse">
When I reboot my computer, I see Gujin screen but the keboard and/or mouse are not working. </a></LI>
<LI><a href="partnotfound">
Gujin does not find my kernel files and/or my Linux partition! (partition types) </a></LI>
<LI><a href="FSsupported">
Which are the filesystem supported by Gujin? </a></LI>
<LI><a href="startgraphic">
I would like to start the Linux kernel in graphic mode... Linux seems to start correctly but the screen is black/white/strange after message "Starting kernel."... </a></LI>
<LI><a href="needlilo">
Do I still need LILO, loadlin, GRUB... when using Gujin? </a></LI>
<LI><a href="twohd">
My Hard Disks are detected two times.
</a></LI>
<LI><a href="reprobe">
Can I force re-probing the disk after initial boot. </a></LI>
<LI><a href="configfile">
Where is the configuration file?
</a></LI>
<LI><a href="keyboardmapping">
What about my non-US keyboard mapping?
</a></LI>
<LI><a href="fontchange">
I do not like the font used, can I change it? </a></LI>
<LI><a href="floppykind">
Which kind of floppy can I use when I type "./instboot boot.bin /dev/fd0"? </a></LI>
<LI><a href="crashhd">
Can the test crash my hard drive?
</a></LI>
<LI><a href="scanning">
Why all my disks are scanned at the start-up of Gujin? </a></LI>
<LI><a href="loadinitrd">
Can Gujin load an initrd, can Gujin load an initramfs? </a></LI>
<LI><a href="describe_bdi">
What is a *.BDI (Boot Device Image) file? </a></LI>
<LI><a href="bdi_on_usb">
Can I create a set of floppy bootable images on a USB drive/CDROM? </a></LI>
<LI><a href="bdi_on_partition">
Can I create a set of floppy bootable images on a FAT or E2/3FS partition? </a></LI>
<LI><a href="findroot">
The kernel starts correctly - but then stops with the message "Kernel panic: VFS: Unable to mount root fs on ..." - what is the problem? 
Can Gujin find alone the root partition of a kernel? </a></LI>
<LI><a href="oldideonly">
Why, on this "old" PC, the root filesystem is only guessed on the IDE interface?
</a></LI>
<LI><a href="idechanging">
Sometimes I see my IDE master as BIOS 0x80, and sometimes as BIOS 0x81! </a></LI>
<LI><a href="replaceloadlin">
Can Gujin replace loadlin?
</a></LI>
<LI><a href="errorcode">
How to interpret Gujin's error code when loading the kernel/initrd? </a></LI>
<LI><a href="debuggujin">
How can I debug a problem in Gujin?
</a></LI>
<LI><a href="gujinstable">
Is Gujin ready and stable enough for production? </a></LI>
<LI><a href="colocation_server">
How to use Gujin remotely on a colocation server? </a></LI>
<LI><a href="videoaccess">
What are letters between brackets at the top of the screen? </a></LI>
<LI><a href="videodetect">
Why is there three commands to detect video modes, how to use them? </a></LI>
<LI><a href="lastpartition">
I have messages like "last partition over disk limit detected", what does it mean?
</a></LI>
<LI><a href="will_work_with_PCI_IDE">
Does Gujin scan other PCI IDE ports?
</a></LI>
<LI><a href="whatis_ignore_kernel_IDE_options"> What is the option "ignore kernel IDE options"? </a></LI>
<LI><a href="security_issue">
This IDE password system, isn't it a security issue? </a></LI>
<LI><a href="whyname">
Why the name Gujin ?
</a></LI>
<LI><a href="floppyerror">
I have errors while Gujin loads, during this line: Gujin1, Gujin2....ERROR. 
or: 
Gujin1, Gujin2.......CHECKSUM ERROR. and it eventually loads after few tries. </a></LI>
<LI><a href="quickserial">
How to quickly test a serial interface configuration (without a VT420)? </a></LI>
<LI><a href="largekernel">
You said that I can boot a very large kernel - but I can not even get it to compile!
</a></LI>
<LI><a href="nojoystick">
My Joystick does not work.
</a></LI>
<LI><a href="whyforcerootprobe">
What is the "force root probing" option? </a></LI>
<LI><a href="extendpartnotfound">
I have messages like "Extended partition block not found at LBA = " on Gujin-0.6 or later.
</a></LI>
<LI><a href="whatissmart">
Gujin report "SMART threshold exceeded condition" or "present and disabled!"? </a></LI>
<LI><a href="windowcodepage">
When I boot MS-DOS/Windows, I get a message saying that the codepage has been successfully prepared, and then that the specified pagecode has not been prepared...
</a></LI>
<LI><a href="saveparams">
Automatic running of a kernel after timeout do not work? Parameter (or list of VGA modes) not saved in between boots? </a></LI>
<LI><a href="winextended">
Can Gujin boot Windows95/98/Me on an extended partition or on a secondary drive?
</a></LI>
<LI><a href="winnotbootable">
I achieved to boot DOS or Window95/98/Me on another hard disk, but now, when I try to boot without Gujin, the BIOS says me that the hard drive is not bootable?
</a></LI>
<LI><a href="nobiosedid">
My screen is automagically recognized under Windows but not under Gujin? </a></LI>
<LI><a href="comment">
Which field are recognized by Gujin in the comment field of the GZIP kernel? </a></LI>
<LI><a href="disk_sign">
Meaning of the letter in parenthesis after disk names in the startup screen? </a></LI>
<LI><a href="cdrom_boot">
Can Gujin boot El-torito CDROMs? Can Gujin be installed on a CDROM to boot from it? </a></LI>
<LI><a href="cdrom_floppy">
How do I boot from CDROM with a simulated floppy containing Gujin? </a></LI>
<LI><a href="cdrom_hd">
How do I boot from CDROM with a simulated hard disk containing Gujin? </a></LI>
<LI><a href="CDROM_nowork">
I cannot achieve to boot any CDROM containing Gujin, unlike standard distribution CDROMs? </a></LI>
<LI><a href="no_write_enable">
I cannot check the "write enable" box after booting from CDROM or floppy? </a></LI>
<LI><a href="terminate_CDROM_emul">
When does Gujin terminate the HD or floppy emulation by calling the CDROM BIOS? </a></LI>
<LI><a href="cdrom_noemul">
How do I boot from CDROM in no-emulation mode with Gujin? </a></LI>
<LI><a href="create_disk_image">
Can I use Gujin just to create a disk image of any size? Initialise a bootable USB thumb drive? </a></LI>
<LI><a href="gpg_signature">
What is your PGP signature?
</a></LI>
<LI><a href="#TODO">
Do you have a TODO list?
</a></LI>

<HR SIZE="4" WIDTH="50%">
<CENTER><BIG>FAQ Answers:</BIG></CENTER>

<DL>

<HR WIDTH="10%">
<DT><a name="quick_describe">Please quickly describe Gujin.</a> <DD>
The Gujin description at <A HREF="http://freshmeat.net/projects/gujin/" TARGET="_blank">freshmeat</A>: Gujin is a PC boot loader which can analyze your filesystems. It finds the Linux kernel images available, as well as other bootable partitions (for *BSD, MS-DOS, Windows, etc.), and displays a graphical menu for selecting which system to boot. Because it understand the structure of Linux kernel images, Gujin does not need LILO and can even load very big kernels. There is no need to execute anything after making a new kernel: just copy the kernel image file into the "/boot" directory. Gujin is written almost entirely in C with GCC, and it fully executes in real mode to be as compatible as possible.

<HR WIDTH="10%">
<DT><a name="why">Why should I use Gujin?</a> <DD>
Some of the reasons I think of: 
<UL TYPE=CIRCLE>
<LI>The boot floppy and/or the boot hard drive do not depend on the physical position of the file on the drive: you can create a new kernel, copy it in /boot, rename it (as long as its name begin with "vmlinuz", "zImage" or "bzImage") and just reboot.
<LI>The boot sector do not need to be modified each time you build a new kernel (risk of unbootable system).
<LI>All partitions are checked (limits outside of the disk, partition overlap, filesystem FAT12/16/32 and E2/3FS bigger than the partition) just in case you used a buggy partitioning software. <LI>disks SMART status (health of the hard disks) are checked and reported if error or SMART present but not enabled. IDE passwords are frozen. <LI>The boot sector (first 512 bytes) saves register initial value, you should be able to load whatever OS (WinNT...) without any problem. <LI>The complete process is protected by checksums, so you can detect easily bad sectors on the floppy/HD, or recover from a bad/corrupted vmlinuz (its CRC32 is checked before the "big jump").
<LI>Gujin is nearly completely written in C, so easily modifiable/extendable: it does few things differently considering the version of Linux loaded... <LI>You can boot in graphic all the time, even with a old PC with only a VESA1 or VGA-only video card (CGA/EGA works also on my test system). The video mode used by the kernel is easier to select. <LI>Most of the subsystems are written using BIOS or direct hardware access, so it will work if it is either BIOS compatible or hardware compatible. <LI>Gujin runs in i386 real mode and so is compatible with PC BIOSes generating special interrupts (power saving initialisation...) during the boot loading process.
<LI>The mouse (PS2 or 3 types of serial mouse on COM1..COM4) is detected at the right time and used. This info is passed to the kernel. <LI>You are fed up executing linux/arch/i386/boot/{bootsect.s,setup.s,video.s} <LI>You want to build a floppy distribution, with max 30Kb of bootloader and an easy way to change the kernel (and its initrd). </UL>

<HR WIDTH="10%">
<DT><a name="describe_install">I just want to install, do you have a quick documentation?</a> <DD>
If your aim is to install Gujin on your floppy and/or hard disk, first download install.tar.gz and extract it in a directory. Then start by reading install.txt. You can come back to this FAQ if you have a problem. You can also use the Ultimate Bootable CDROM: <a href="http://www.ultimatebootcd.com/" TARGET="_blank"><img src="http://www.ultimatebootcd.com/button.gif" border="0" alt="UBCD button"></a> <UL>Note: If you are using MS-Windows XP to download Gujin files from sourceforge, you may notice that downloaded filenames change on the way to your PC: the "tgz" extension is changed to "gz" without any reason. Double check the name of the files you have downloaded before opening them - rename if needed. </UL>
<UL>Note: DO NOT play with the floppy under Win98 (and maybe other versions) when you are in DOS mode (i.e. start->shutdown->reboot in DOS mode, not in a DOS window). There is one way to physically break a floppy drive, just ask a cylinder higher than 80 and you immediately hear the "sound of death". My drivers (in Gujin) will never ask a too high cylinder on a floppy, but the drivers of Windows in a DOS environment do that quite easily. It has cost me two floppy drives (one to detect, one to check) in 5 minutes, and I was not even using Gujin... You can still safely copy (drag & drop) files under the graphic interface and then reboot to DOS mode. </UL>

<HR WIDTH="10%">
<DT><a name="howto_precompiled">How do I use a precompiled configuration in file standard.tar.gz?</a> <DD>
<LI>Download the file "standard-1.4.tar.gz", un-tar it "mkdir standard; cd standard; tar -xzf ../standard-1.4.tar.gz" or open it with <A HREF="http://www.winzip.com" TARGET="_blank">winzip</A> or <A HREF="http://www.rarlab.com" TARGET="_blank">winrar</A> if you have another operating system.</LI> <LI>Select the image/executable you want to try: begin with "full.img.gz"/"full.exe", you can play with others later.</LI> <LI>Insert a clean 1.44Mb floppy on your drive, the data on this floppy will be erased (no bad sectors).</LI> <LI>Do "zcat full.img.gz > /dev/fd0", or if you do not have "zcat", type "gunzip -c full.img.gz > /dev/fd0" <UL>
If you have an error accessing the drive and are using automount/supermount, try "umount /mnt/floppy" before retrying the zcat. If you are using another OS, try "rawrite.exe" (after decompressing "full.img.gz" to "floppy.144" again using winzip/winrar), see: <A HREF="http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm" TARGET="_blank">

http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm</A>. ; If you do not like previous software, you can also try: <A HREF="http://www.woundedmoon.org/win32/floppyimage.html" TARGET="_blank">floppyimage</A>.</LI> </UL>
<LI>If you have DOS/Windows (excluding NT), you can now copy "full.exe" on the floppy, for instance "mcopy full.exe a:"</LI> <LI>Reboot your computer keeping the floppy in place, you can after a short time play with the mouse.</LI>
<LI>If you have a DOS installation, boot its Master Boot Record to play with "A:\full.exe".</LI>
<LI>The other files you get in "standard.tar.gz" are described in <a href="#standard_content">this FAQ question</a>.</LI> <LI>If your version of DOSEMU is not too old, you may try to boot from a floppy image: get boot.144 from install.tar.gz or regenerate it by "./instboot boot.bin boot.144" or "make dep boot.144" and edit DOSEMU configuration file "/etc/dosemu/dosemu.conf" to add: $_vbootfloppy = "/home/etienne/projet/gujin/boot.144 +hd", then type "xdosemu" if running X window or "dosemu" in text mode.. You may want "apt-get install dosemu-freedos" and the line: $_hdimage = "/var/lib/dosemu/freedos" You copy boot.exe in previous directory, do "chmod a+r /var/lib/dosemu/freedos/boot.exe" and type "dosemu -C" to boot from "C" drive. Remember to have enough XMS memory ($_xms = (4096)) to load the vmlinuz file when executing "boot.exe". 
See also "/etc/mtools.conf" (drive o: file="/var/lib/dosemu/floppyimage").</LI> You can also use Gujin to debug "Bochs" (full.img being the virtual floppy), "Plex86" or "VMware"... if you want to. <UL>Note: 
<LI>All the images (*.img) are for 1.44 Mb floppies, use the "instboot" executable for other formats.</LI>
<LI>All the images contains the FAT and root directory: the executable size is not as big as the file size.</LI>
<LI>The floppy used should not have "bad sectors".</LI> <LI>For most configurations, there is two independent files: the image (*.img) to be copied to the floppy in raw format (do not use the DOS command "copy" nor drag and drop for this one !), and the standard DOS executable file (*.exe) which is a standard file to be copied the way you want, but needs at least DOS to run.</LI> <LI>If you do not want to execute file AUTOEXEC.BAT (and so do not want COMMAND.COM on the floppy) you can put "SHELL=A:\boot.exe" in file CONFIG.SYS. If you use "SHELL=A:\tiny.exe ...", this CONFIG.SYS line will be probably limited to 128 chars even if FreeDos accept more on the command line, because that is not a command line.</LI> </UL>

<HR WIDTH="10%">
<DT><a name="standard_content">What is the content of file standard.tar.gz?</a> <DD>
Once decompressed, the file "standard.tar.gz" contains: <UL>
<LI>full.img.gz / full.exe : that is the complete configuration, the one I tested the most; you probably do not need all that (mostly the serial interface).</LI>
<LI>french.img.gz / french.exe : same as "full.img.gz / full.exe" but the messages are in French.</LI>
<LI>medium.img.gz / medium.exe : same as "full.img.gz / full.exe" but the support for the "mini-debug", the serial (VT420) support, and the analysis of the I/O ports used by the video card are removed.</LI> <LI>small.img.gz / small.exe : same as "medium.img.gz / medium.exe" but the mouse support, the support of 4 BPP (16 color) graphic and 24 bit VESA modes, the VESA_HARDWINDOW analysis which cannot be used right now by Linux, the support for the VGA only cards, and the verbose messages are removed. Note that even some 486 refuse to boot if the video card is not VESA 1.0+ compliant, so it should be quite safe to remove the VGA support.</LI> <LI>tiny.img.gz : the smallest possible (keeping vmlinuz/initrd/initramfs compatibility), just add "vmlinuz-2.4.16" and "initrd" on the FAT12 floppy (boots the first kernel loaded successfully, Gzip comment fully checked).</LI> <LI>tiny.exe : the smallest possible DOS loader, do not probe disks nor video modes, use it as loadlin.exe:
"tiny.exe c:\dir1\dir2\vmlinuz initrd=c:\dir3\initrd.gz opt1=val1 @optfile opt2=val2". tiny.exe can also switch to a VESA mode with the "/V" option, but it is not a full support of VESA like the one available in "boot.exe".</LI> </UL>
There is also these few DEBUG setup: They put information on a DOS file to be useable by everybody. 
Just create a DOS bootable floppy ("format /s a:" under DOS, preferably DOS6.2 - or a rescue boot floppy from Win9*/WinMe) and copy the executable to this floppy. 
Then, you boot out of this floppy and execute the file. It will do the same as the bootloader but also create a file named "\DBG" (stay in "A:\") to store a lot of information. If you have a problem with Gujin, I need this DBG file to debug! Note that you need to either exit Gujin (^C or ^D will do) or run a kernel to flush and close the file properly: do not reboot. There is different executable (very few are here) because of size restrictions, and readability of the DBG file. Advise: do not play too much with these files under DOSEMU, I already crashed few virtual disks...
<UL>
<LI>dbgvideo.exe : to debug the video (VGA and VESA) subsystem.</LI> <LI>dbgdisk.exe : to debug the disk (BIOS, EBIOS and IDE) subsystem.</LI> <LI>dbgload.exe : to show which parameters are passed to Linux, and some A20 debugging.</LI> <LI>dbgfs.exe : to show the process of selecting files on each filesystem...</LI> </UL>

<HR WIDTH="10%">
<DT><a name="recompile_from_source">How do I recompile from sources?</a> <DD>
<LI>Download gujin-1.4.tar.gz and read the (beginning of) file "Makefile"; you will be able to comment/uncomment lines to select your own configuration (support of VESA, of EDID, of serial terminal like VT420, language...). It is better to have GCC-2.95.4 or newer (GCC-4.1.1), egcs-2.96.* early versions (RH 7.0 and Mandrake 8.0) do _not_ work (because of -fstrict-aliasing), egcs-2.91.* could work, gcc-2.7.* will not. It is necessary to have binutils-2.9.5.0.33.tar.gz or better ("make" will check that), I use GCC-4.1.1 and binutils-2.16.1 bootstrapped manually by "make toolchain". (binutils-2.12 and binutils-2.12-1 have a small problem and Gujin will not link).
</LI>
<LI>create a directory structure like this: <TT>
projet/ 
projet/gujin-1.4.tar.gz 
projet/binutils-*.tar.gz (if you want to rebuild it) projet/gcc-*.tar.gz (better gcc-core-*.tar.bz2 if you want to rebuild it) </TT>
</LI>
<LI>Go in "projet" directory and type "tar -xzf gujin-1.4.tar.gz" which creates the "projet/gujin" directory, go in it. </LI>
<LI>Type "make" without parameter, this recreate dependencies, file "code16.h", and show you some possible parameters. </LI>
<LI>If you want to rebuild the compiler and/or the assembler and linker (binutils), type "make toolchain" and have a cup of coffee. You do not need to be root for this - and it will not install the compiler/binutils as default, just locally. Note that when "make" is called without parameters, it displays the version of compiler and binutils which will be used. </LI>
<LI>Now, you can (as "make" says you), type things like: "make /dev/fd0" or "make boot.exe" or "make tiny_exe" or "make /dev/fd0.com1"... and you can then reboot your computer. </LI>
<LI>You can also type "make standard.tar.gz" or "make install.tar.gz" to re-produce the precompiled file.
</LI>
<LI>Build and use the "gzcopy" command (by "make gzcopy") to specify special command line parameters for *.kgz files. It is also possible to add the gzcopy to Linux Makefiles at the right place. </LI>

<HR WIDTH="10%">
<DT><a name="nothing_started">When I reboot my computer, I do not see anything changed, Gujin is not started.</a> <DD>
Check that you have selected "floppy before hard drive" in the boot order in your BIOS set-up.
<UL>
Note: There could be another reason to just see one copyright line and then a quick boot: if Gujin is configured with autoboot after timeout on the only bootable system detected and verbose mode OFF and writing to disk disabled, it will decide to skip its menu and video initialisation and immediately boot the only detected system. It will still quickboot if exactly two bootable system are detected, but they are the same (partition/filesize/inode) on two disks with different access method (usually EBIOS and IDE) so that SMART status can be checked, and the first (EBIOS) will be loaded. This way, if you have only one partition (for instance FAT32 or NTFS) without any kernel file, you will "quickly" boot it. You still have Gujin checking partition overlap, disk with bad SMART status display when a major problem appear - but nothing else up to the time you install a serious operating system... or you install another hard drive with another version of your initial operating system, or you boot with CAPS-LOCK active. 
The installer has the option "--quickboot=<number of second>" as a shortcut to initialising the "timeout autoload", verbose to OFF, disable disk writing, probe only partition's MBR on the BIOS and standard IDE hard disk, and have a default video mode number 3 (simple text) if the screen is not EDID.
Note version 1.4 and after: The video initialisation is now done even with quickboot; it should not change anything but be a little slower than version 1.3 (because the videomode was set to 0x03) but it enables a kind of tiny.exe with video mode autosetup when using an EDID compatible screen if using those instboot parameters: ./instboot --quickboot=1 --default_video_mode=0xFFFF </UL>

<HR WIDTH="10%">
<DT><a name="no_kbd_mouse">When I reboot my computer, I see Gujin screen but the keboard and/or mouse are not working.</a> <DD>
You are probably using an USB keyboard and/or mouse, i.e. the keyboard/mouse plug you are using is a rectangular plug and not a round plug. You have to enable, in the BIOS screen (at boot), the BIOS emulation of keyboard and mouse (sometimes called DOS emulation). Alternatively, you can use a serial mouse (large rectangular plug in COM port on the back of the PC).

<HR WIDTH="10%">
<DT><a name="partnotfound">Gujin does not find my kernel files and/or my Linux partition! (partition types)</a> <DD>
Check the partition type using fdisk: it has to be 0x83 for a Linux partition, right now Gujin only recognizes E2FS and E3FS. Some installer (at least you can get this problem with RH7.2) forget to set this byte and leave the DOS FAT marker. Linux does not care about the partition marker, and will work without problem with any value (because it uses /etc/fstab to know the kind of filesystem), but Gujin need this information to be correct. <UL>Note: The type of partition is used for: <LI> detection of extended partition (0x05, 0x0F, 0x85) <LI> detection of partition which can be hidden (FATxx and NTFS) <LI> detection of empty partition (0x00) <LI> detection of LBA or CHS access (FATxx) <LI> detection of partition without bootsectors (Swap or extended) </UL>
<UL>Note: Gujin interpret type 0x85 as Linux extended, that is a disk (with transparent offset and size) in a disk. It seems more usefull to do so, you set type 0x85 for your partition, for instance /dev/hda4, then you type "fdisk /dev/hda4" to create a partition table inside this partition. You can also copy byte per byte an older and smaller disk you have by "cat /dev/hdb ⊃ /dev/hda4" and still access everything. If you have the ISO9660 copy of a CDROM inside a partition, by typing "cat /dev/cdrom ⊃ /dev/hda4" or "cat cdrom.iso ⊃ /dev/hda4", you should give it the Linux partition type 0x83 - it will be read and can be booted (El-torito and /boot kernel files) the same way as any other filesystem (works nicely with Damn Small Linux: you can boot it and also mount this partition like "mount -t ISO9660 /dev/hda8 /mnt/usbdisk/"). </UL>

<HR WIDTH="10%">
<DT><a name="FSsupported">Which are the filesystem supported by Gujin?</a> <DD>
Gujin supports FAT12, FAT16, FAT32, ISO9660 and EXT2/EXT3FS on any partition or whole disk or CDROM session. A FAT16 filesystem on a CDROM session (2048 bytes per sectors) works exactly the same as on a partition: you can boot it if it contains a valid bootsector. An El-torito bootable CDROM image on a hard disk partition works also, since Gujin v1.4 even booting it in non-emulation mode works (so you do not need to burn a CDROM each time you want to try a new live distribution). People often ask when Gujin will support other filesystems like ReiserFS v3 and/or v4, or some other filesystem names I have never even used. Well, Gujin is a bootloader, not a filesystem testing tool - but if someone has the time to build a clean patch I can accept it. Gujin is just using 256 Kbytes of the 640 Kbytes available in real mode - so there is plenty of space! Note that you would better check yourself, before starting any work, that you have the right to create a new implementation of the filesystem you want to port: just do not suppose the filesystem is GPL if it is not clearly written somewhere official. Note that any filesystem patch has to be very clean, and shall not crash even if the hard disk contains random data - just skip the malformed partition; so every line of code has to be audited, not just quickly ported from another implementation. Also, Gujin does not force you to use EXT2/3FS as your root partition, you can simply have a small partition which is mounted on directory /boot when the kernel initialise, most distributions handle that transparently.

<HR WIDTH="10%">
<DT><a name="startgraphic">I would like to start the Linux kernel in graphic mode...

Linux seems to start correctly but the screen is black/white/strange after message "Starting kernel."...</a> <DD>
It is possible not to switch to text mode when starting a kernel, this is a configuration option, in the config screen menu. The problem is that Gujin can not (right now) detect if the kernel can/need to start in text or in graphic mode (VESA framebuffer compiled in or not, and which number of BPP are supported). Note that this is not related to compiling a videocard framebuffer as static (and not as module) where a new mode is set when the chipset is initialised. To start in graphic, follow these steps: First check that your kernel is compiled with VESA framebuffer support, supporting all the BitPerPixel you can switch to on the Gujin interface. If you are using 2.6 kernels, check that "Framebuffer Console support" is set in "Graphics support->Console display driver support" (make menuconfig). Now double check that your video board is VESA 2 compilant, Linux cannot handle right now the memory window switching of VESA 1 boards, unlike Gujin. Gujin displays at startup the VESA level of your video card. Then (and only then) you can uncheck the "force last text mode at startup" option in the setup screen. 
Note that most older standard kernels in Linux distributions are not compiled with framebuffer support, or only with 4 BPP support, so use this option with care. 
Note also that some distribution default kernel can only start in graphic mode (some Mandrake start correctly only in 8 BPP modes). RH7.2 start in text and in graphic. 
This feature is a hack - later I would like to put all this kind of kernel description in the "comment" field of the gzip file.

<HR WIDTH="10%">
<DT><a name="needlilo">Do I still need LILO, loadlin, GRUB... when using Gujin?</a> <DD>
No, Gujin is not only a boot loader but also a Linux system loader; for instance you can load system files (vmlinuz) of unlimited size (well, below the size of your physical memory), and so do not really need to use modules even when your kernel is very big. You can also run another loader (i.e. LILO or the FreeBSD loader or the DOS/Win95/Win98/WinNT loader) from Gujin. The source code is not derived from any other bootloader, that is a complete rewrite, from scratch (memcpy(), printf(), malloc() ... are all rewritten). Note that there is different LILO versions named (boot sector at offset 3) slightly differently: LILO, zLILO, lbaLILO and oldLILO.

<HR WIDTH="10%">
<DT><a name="twohd">My Hard Disks are detected two times.</a> <DD>
On a usual PC, the Hard Drives are IDE (not SCSI) and are detected using the BIOS interface and using the IDE interface. Because the BIOS interface may not access the total content of the drive (buggy or too old) - you can use the IDE interface; and because there may be some trick on your partition table (a small software intercepting INT13) which will break IDE interface you can use the BIOS interface. You can select what to probe in the setup screen, this will be saved on the boot medium (if not write protected). <UL>Note: Some BIOS leave empty space on the hard disk depending on the number of heads and the number of sector per track selected for this drive. This probably happens on very old BIOSes and with non LBA compatible hard drives (kind of 220 Mbytes hard drives). Then, Gujin IDE interface may not work correctly - I do not have such a hardware to check. </UL>

<HR WIDTH="10%">
<DT><a name="reprobe">Can I force re-probing the disk after initial boot.</a> <DD>
Gujin will automatically reprobe the disks and partitions inside them if its disks configuration has changed (probing BIOS, EBIOS, IDE, ATAPI), when going from the setup screen to the kernel menu screen (i.e. typing the space key). If you want to reprobe without leaving the kernel menu screen, you can type ^R. If you just wanted to redisplay - for instance if you are on a serial connection - you can simply type ^L. 
Note that CDROM/DVD reader do special caching of CD sessions, and you get more success (reprobing a badly read CDROM/CDRW) by ejecting and re-inserting the CDROM from the drive... that clears the cache of the CDROM drive. Note that typing ESCape in BIOS environment (or ^\ if serial line interface) declare to the BIOS that this boot was unsuccessful and so it shall try the next boot device. While we are here, the ^X keycode is a basic and slow utility to interactively display and/or erase the disk sectors which are outside any partitions, typically the sectors in between the MBR and the first sector of the first partition, the sectors after an extended partition marker and before the first sector of the first partition of this extended partition, and the sectors at the end of the disk, in between the last sector of the last partition and the B.E.E.R. partition when present. To use at your own risks if you have an unclean partition system, also take care that those sector may be used by other bootloader systems. It is better to go in text mode if you intend to clean a lot of those sectors because scrolling the screen is then a lot faster, and note that control-enter in this utility will enter an auto-erase mode, press any key to exit. Note that there is two other control keys active: ^C and ^D to exit Gujin, mostly interesting in DOS to exit and close the only open file: DBG.

<HR WIDTH="10%">
<DT><a name="configfile">Where is the configuration file?</a> <DD>
I do not like configuration files, there is none. Moreover, when a PC has two or three distributions installed, where should Gujin look for this configuration file? In which root filesystem? So you can use the same floppy disk to boot any PC you want. Note that (very) few information are stored in the beginning of file BOOTxxx.SYS, like the preferred text and graphic video modes. On another PC, this video mode may be invalid - so you can force the video mode at beginning (when the first line is being displayed) by pressing "Control"; a message saying "video mode set to simple text" will be displayed. 
To erase all information stored on the floppy, like the setup selection, press CAPS-LOCK before the first line has been completely printed. Do not try to modify the file BOOTxxx.SYS or to rewrite it: the complete boot process is protected by checksums.

<HR WIDTH="10%">
<DT><a name="keyboardmapping">What about my non-US keyboard mapping?</a> <DD>
Gujin sometimes need to know which keyboard language/mapping you are using, to correctly interpret the keys you type, for instance when setting the kernel command line or asking for a password. Gujin may ask you automatically, or you can ask it in the setup screen (near the end), it is simply done by pressing few determinant keys - and it is saved if disk can be written. Basically, Gujin recognise those keyboards: <UL TYPE=SQUARE>
<LI>us: the United State keyboard.</LI> <LI>uk: the United Kingdom keyboard.</LI> <LI>ca: the Canadian keyboard.</LI>
<LI>br: the Brasil/Latin America keyboard.</LI> <LI>no: the Norway keyboard.</LI>
<LI>fi: the Finland/Sweden keyboard.</LI> <LI>dk: the Denmark keyboard.</LI>
<LI>nl: the Netherlands keyboard.</LI>
<LI>sp: the Spain keyboard.</LI>
<LI>pt: the Portugal keyboard.</LI>
<LI>it: the Italy keyboard.</LI>
<LI>qwerty: none of the above recognised, but still a qwerty keyboard.</LI> <LI>fr: the French keyboard.</LI>
<LI>be: the Belgium keyboard.</LI>
<LI>azerty: none of the above recognised, but still an azerty keyboard.</LI> <LI>de: the German keyboard.</LI>
<LI>ch: the Switzerland keyboard.</LI>
<LI>qwertz: none of the above recognised, but still a qwertz keyboard.</LI> </UL>
Note that I have used a book on some keyboards, so if you find an error or if your keyboard is in this list but is just recognised as a qwerty/azerty/qwertz keyboard, please send me corrections. To check, just press each key (with and without shift and alt) while entering a dummy kernel command line. Really take care of all accents and small signs because they look the same in a book. Note also that Gujin display only ANSI characters, so the Euro key cannot be displayed. When "verbose" is active and you are in the standard menu, it shall produce a key error with keycode 0x0, saying the key has been recognised. The book was older than the euro, so the Euro key is a guess most of the times... Keyboards layout dvorak and dvorak_ansi can be enabled by the INCLUDE_DVORAK_KEYBOARD compile option - but I am not sure anybody uses that anymore (they cannot generate ^W and some other control and some alternate letters).

<HR WIDTH="10%">
<DT><a name="fontchange">I do not like the font used, can I change it?</a> <DD>
Yes, but you need to recompile. Moreover Gujin assumes the font is an ANSI one, i.e. not the very old PC mapping with accented letters in between 0x80..0xA0, so that the file "messages.h" can be easily edited on an up to date operating system (not only bare DOS). Gujin is designed to handle only fixed font size, with at least 8x8, 8x14 and 8x16 resolution for text modes. The graphic system (VESA graphic) can probably handle bigger definitions without modification but that has not been really tested. If you want to try, a good starting point is to search on Internet the file 2l8fe122.zip which is a DOS font editor and fntcol16.zip which is a collection of DOS fonts (read included file copyleft.txt). You will need to modify the font files to include accented letters at the right place. Gujin uses font file in C source with an array like (see font.c): <pre>

['8'] = {

        B (_,_,_,_,_,_,_,_),
        B (_,_,_,_,_,_,_,_),
        B (_,X,X,X,X,X,_,_),
        B (X,X,X,X,X,X,X,_),
        B (X,X,_,_,_,X,X,_),
        B (X,X,_,_,_,X,X,_),
        B (_,X,X,X,X,X,_,_),
        B (_,X,X,X,X,X,_,_),
        B (X,X,_,_,_,X,X,_),
        B (X,X,_,_,_,X,X,_),
        B (X,X,X,X,X,X,X,_),
        B (_,X,X,X,X,X,_,_),
        B (_,_,_,_,_,_,_,_),
        B (_,_,_,_,_,_,_,_),
        },

</pre>
and the makefile can convert in between this format and binary format using a simple objcopy, or for the reverse operation the source file fntbin2h.c compiled to ./fntbin2h. If you type "make font8x16.h" having file "font8x16.bin" in the directory with the correct size (no header, no trailer, 8 bit wide font 16 bit high so 16 bytes per letter and 256 letters so 4096 bytes - most fixed font editor use this format to store and retrieve fonts) you will get "font8x16.h". You can then regenerate "font.c" with cut & paste of the three files "font8x8.h", "font8x14.h", "font8x16.h". You can get the current font Gujin is using by "make font8x8.bin", "make font8x14.bin" and "make font8x16.bin" The order of the letters in the include file reflects the ANSI mapping (letter "e" with all its form are grouped together) and the initialisation using the "['achar']" GCC extension enable to check quickly the right shape is used for the right letter. The font is stored in the extra data segment in Gujin executable so there is no space problems.

<HR WIDTH="10%">
<DT><a name="floppykind">Which kind of floppy can I use when I type "./instboot boot.bin /dev/fd0"?</a> <DD>
360K, 1.2M, 720K, 1.44M, 2.88M (last untested but simulated on CD) 1.68 Mbytes floppies are supported if your BIOS is able to read sectors over 18 on a floppy, your BIOS do not need to be able to read more than 18 sectors. 
Note that you can type under Linux (when mtools installed): "mdir -a a:" and you will see the hidden file "BOOTxxx.SYS" where xxx will be 144 for a 1.44 Mb floppy. 
There is no problem to add files to this floppy, that is a real MSDOS FAT12 partition. 
To save space, you can reduce the number of root directory sector (total number of files/directories in root if using 8+3 filenames, 512/32=16 8+3 names per sectors, less if using longer filenames), increase the number of sector per cluster, and/or reduce the number of FAT. 
Reducing the number of FAT (from 2 to 1) decrease the compatibility, DOS is no more able to read the floppy, but mtools works perfectly. Try: ./instboot --fs=FAT:2880,4,1,1,1 boot.bin /dev/fd0 New: How to create a floppy (or whatever FAT12/16) with 1024 bytes per sector instead of 512 bytes? This simply works on a 1.44 Mb floppy: <pre>
$ ./instboot boot.bin /dev/fd0 --geometry=1440,0,2,9,1024 --disk=BIOS:0x0 -w $ mount -t vfat /dev/fd0 /mnt/floppy/ -o blocksize=1024 $ ls -l /mnt/floppy/
total 144
-r-xr-xr-x 1 root root 147456 Mar 15 1999 boot-bio.sys $ mdir -a a:
Volume in drive A is EL-BOOT-V09
Volume Serial Number is 3939-4C45
Directory for A:/

BOOT-BIO SYS 147456 1999-03-15 12:34

        1 file              147 456 bytes
                          1 310 720 bytes free

</pre>
I have reduced the number of sectors from 2880 to 1440 and the sector/track from 18 to 9 because the sectors are twice the size, normally the '-g' option is "--geometry=2880,0,2,18,512" for 1.44 Mb floppies. Which values are valid for sector size? I do not really know, 2048 and 4096 should work (I think Gujin limit it to 64 Kb) but try it yourself. Do not hope to be able to read this large sector floppy in anything else than Linux: even the BIOS will load only the first 512 bytes on such a floppy, so Gujin cannot boot from it (initial checksum error of Gujin2). Smaller sector size (256 or 128 bytes) will not work because Gujin1 is not entirely loaded so cannot load Gujin2.

<HR WIDTH="10%">
<DT><a name="crashhd">Can the test crash my hard drive?</a> <DD>
Gujin is a GPL software, so without guaranties of any kind, but because it is not writing to the hard drives until the user enables it, the risk is very small. Moreover, any write failure will reset Gujin to read-only mode. To enable the writing to the disks, you need to check a checkbox in the setup menu. The only exception is when you select to uninstall Gujin in the menu: it uses a low level driver so you can proceed the uninstall even in read-only mode.

<HR WIDTH="10%">
<DT><a name="scanning">Why all my disks are scanned at the start-up of Gujin?</a> <DD>
Gujin is looking for all files named "vmlinuz", "zImage", "bzImage" or ".kgz" in every E2/3FS or FAT12/16/32 partitions, either in the root directory or in a subdirectory named exactly (but case insensitive) "boot" - to show you a menu where you can click. Gujin also looks for all the Master Boot Sector (first sector of the disks) which have at least one primary partition with the "bootable" flag, and for all Partition Boot Sector (first sector of each partition) if they seem to contain boot code (if it is a FAT partition, you need a file named IO.SYS/IBMBIO.COM in the root directory if not "keep all partition's mbr") to add to the menu. 
So, you can power-up a PC with a fresh Linux installation on a new hard disk, and directly run it. 
<UL>Note: The Master Boot Record will always appear, even if none of its partition are marked "active", to not change the number of bootable systems and to not confuse the autoboot feature. In this case, booting this Master Boot Record will probably display an error. Booting Linux will not modify any hidden/visible partition nor any "active" partition.
</UL>

<HR WIDTH="10%">
<DT><a name="loadinitrd">Can Gujin load an initrd, can Gujin load an initramfs?</a> <DD>
Yes, and yes, it will load the file "initrd" if it exist in the same disk, partition and directory as the file "vmlinuz"/"bzImage"/"zImage"/"*.kgz" selected. The difference in between an initrd and an initramfs is that the initrd is an independant file (compressed or not), the initramfs is a compressed CPIO archive embedded inside the kernel file (so is transparently loaded). For more information, you shoud read: linux-2.6.14/Documentation/filesystems/ramfs-rootfs-initramfs.txt If there is more than one "initrd" in the directory, the file with the nearest ending as "vmlinuz"/"bzImage"/"zImage" will be loaded, nearest ending means either the ending is identical, or the number of identical char at the end of the filename is bigger. 
For instance, if you are clicking on file "/boot/vmlinuz-2.4.10" and there is two files in "/boot" named "initrd-2.gz" and "initrd-2.4.gz", the later is loaded, the number of char matching being 4: "-2.4". For a "*.kgz" file, the ending is defined as the part after the first '-' sign included, if the '+' sign does not appear before: file "linux-2.6.12.kgz" will match "initrd-2.6.12" and file "linux_2.6.12.kgz" or "linux+initrd-2.6.12.kgz" cannot have a separate initrd. 
As an extension, if the initrd file is named "initrd.img-2.4.18", the part ".img" is ignored in the comparison. You can decide of a minimum number of identical ending char to associate an initrd to a kernel, on the setup screen or with the instboot option "--min_nb_initrd="; if this minimum is not achieved, the initrd file will not be loaded - but if the ending is strictly identical, or if the kernel name had not extra chars (i.e. "vmlinuz") then any "initrd*" in the directory will match. 
If this value is more than or equal to 9 chars included, the initrd loading is completely disabled. That is what you want to do (set to 9) if you are only using "initramfs" kernels (i.e. no initrd). It is better for Gujin to load a GZIP compressed initrd, i.e. with the first two bytes being the GZIP signature "0x8B1F", because while decompressing it, Gujin will calculate the CRC32 of this file, and if error you will be able to select another kernel with a known good initrd. Gujin has to load blindly any uncompressed initrd and cannot check its content at all, and that can leave undetected problem: for instance if your USB BIOS simulate USB pen disks for boot up but has a bug accessing the third head, you will have garbage and Gujin cannot detect it. Note that just after loading a kernel file, Gujin look if the two bytes following the compressed kernel file are 0x8B1F. That means that another compressed file has been concatenated to the kernel. In this case, the initrd loading is cancelled and the concatenated file is used instead (whatever is displayed in the initial menu). In short, Gujin will be happy to load file 'linux+initrd-2.6.12.kgz' produced by: 
<pre>
cp /boot/linux-2.6.12.kgz /boot/linux+initrd-2.6.12.kgz cat /boot/initrd-2.6.12 >> /boot/linux+initrd-2.6.12.kgz </pre>

<HR WIDTH="10%">
<DT><a name="describe_bdi">What is a *.BDI (Boot Device Image) file?</a> <DD>
That is a file which has the BDI extension and is the byte per byte copy of a floppy or a hard disk. Those are sometimes called "*.IMG", but this extension is used for too many different kind of files. An example of this file is the El-Torito boot file of a CDROM, the one referenced in the El-Torito boot catalog. 
You can get those files by doing "cat /dev/fd0 > floppy.bdi" or by renaming Gujin files: "./instboot boot.bin boot.144 ; mv boot.144 boot.bdi". Because it is quite difficult to control the content of the boot catalog of an El-Torito CDROM, and because that catalog only appears on CDROMs and not hard/floppy disks, the files with "BDI" extensions are search for in the same place as kernels. They are treated the same way as CDROM boot images when you click on them: a simulation of a hard disk or a floppy disk is started (depending on the content of the first sector - i.e. the MBR), and the first sector of this emulated disk is read at address 0x7c00 like for a normal boot procedure. 
The floppy/hard disk BIOS/EBIOS emulation (BIOS and EBIOS) is a completely newly written code which does not use extended memory at all: it just use less than 2 Kbytes of real mode memory (below 640 Kb) and really convert the BIOS read to a read of the device, converting 2048 to 512 bytes sectors if needed. That has the advantage of maximum compatibility (there isn't any standard way to reserve extended memory) and incomplete disk will work (unused sectors do not need to be readable), but supposes that the disk image data is contiguous on the medium (all files are contiguous on CDROMs, most files are on FAT, but you will need special tools for E2FS). As a consequence, you can only directly rename the usual file "/boot/memtest86+-1.26" to "/boot/memtest.bdi" if /boot is a FAT mounted partition or in an ISOFS CDROM. A non contiguous file will fail the boot with: "error 0x8 loading file." Simulated floppy with 2048 bytes per sectors on FAT may work and may be read/write if the device allows writes. The CDROM drive memory cache is used extensively. 
If the BIOS number of the emulated floppy (in its MBR) is 0x00, the old floppy becomes BIOS 0x01, else if it is 0x01 then a boot is tried on BIOS 0x01. If the BIOS number is 0x80 the other hard disks are shifted up, but if the BIOS number is over the number of BIOS/EBIOS hard disk present then the emulated BIOS number is adjusted to be contiguous and a boot is tried on this disk. The BIOS number of the current boot is contained in register DL and the value in the MBR is the up to date value. The simulated BIOS/EBIOS disk can be removed by the usual CDROM BIOS call to remove El-Torito simulation. To test and build a useful system, have a look at target CD_BDI in Makefile, i.e. "make CD_BDI".

<HR WIDTH="10%">
<DT><a name="bdi_on_usb">Can I create a set of floppy bootable images on a USB drive/CDROM?</a> <DD>
Yes, if you can boot from this device. You can even organise them in submenus, by modifying the directory searched (by default /boot) in different Gujin files, and link backward, as described at the end of this answer. You will need at least install-1.2.tar.gz, and you need to generate contiguous files on your FAT USB drive, so you may want to use "dd if=src of=dst.bdi bs=64M" to copy files instead of a simple "cp". Note that you need supervisor priviledge for most of these commands, so if your distribution enforces "sudo", you may want to begin everything by typing "sudo su". Note also that because Gujin does not have a USB protocol stack, it can only support USB CDROM if they are mapped onto a BIOS drive - i.e. only if you have booted from this CDROM.

Commands known to work on CDROM: 
(have three floppy images named disk.bdi, partition.bdi and flash.bdi - for instance take the file /boot/memtest* present in a lot of distributions, or a FreeDOS floppy image) <pre>
(device /dev/cdrom should point to your CDROM writer for cdrecord)

export QUITE_SETUP="--verbose=0 --menu_with_disk=0 --menu_with_parttype=0 --menu_with_partition=0" export PROBE_SETUP="--probe_bios_floppy_disk=0 --probe_bios_hard_disk=0 --probe_ide_disk=0 --probe_cdrom=1" export SEARCH_SETUP="--search_disk_mbr=0 --search_part_mbr=0 --search_topdir_kernel=0 --search_subdir_kernel=1" export CD_BDI_SETUP="--hide_unhide_partitions=0 --disk_write_enable=0 $QUITE_SETUP $PROBE_SETUP $SEARCH_SETUP" rm -rf /tmp/cdrom
mkdir /tmp/cdrom
cdrecord blank=fast -s
mkdir /tmp/cdrom/boot_menu
./instboot boot.bin /tmp/cdrom/boot.bcd $CD_BDI_SETUP --search_el_torito=0 --full --bootdir=boot_menu mkdir /tmp/cdrom/boot_disk
mkdir /tmp/cdrom/boot_partition
mkdir /tmp/cdrom/boot_flash

./instboot boot.bin /tmp/cdrom/boot_menu/boot_disk.bdi      --geometry=floppy:320 $CD_BDI_SETUP --full --bootdir=boot_disk
cp /boot/msdos.bin      /tmp/cdrom/boot_disk/disk.bdi

./instboot boot.bin /tmp/cdrom/boot_menu/boot_partition.bdi --geometry=floppy:320 $CD_BDI_SETUP --full --bootdir=boot_partition cp /boot/memtest86+-1.55.1 /tmp/cdrom/boot_partition/partition.bdi

./instboot boot.bin /tmp/cdrom/boot_menu/boot_flash.bdi     --geometry=floppy:320 $CD_BDI_SETUP --full --bootdir=boot_flash
cp /boot/gm668.bin     /tmp/cdrom/boot_flash/flash.bdi

mkisofs -untranslated-filenames -no-emul-boot -boot-load-size 4 -b boot.bcd /tmp/cdrom | cdrecord -tao -

</pre>
Note that if you want to just create a DOS filesystem on a CDROM, you can type: <pre>
./instboot boot.bin /tmp/cd --full -d=EBIOS:0xE0 --geometry=327680,0,16,32,2048 -w # You could also create a partition table like an HD, but keep in mind that you cannot # mount a partition on a CDROM, because Linux does not have a device for it... # ./instboot boot.bin /tmp/cd --full -d=EBIOS:0xE0 --geometry=327648,32,16,32,2048,327680,0 --mbr-device=/tmp/cd -w cdrecord blank=fast -s
cdrecord -multi -tao /tmp/cd
mount -t vfat /dev/hdc /mnt/usbdisk/
</pre>
If the CD is CDRW, you may want to try the read/write feature of Gujin, it should work (SCSI write command of 2048 byte sectors is implemented for Gujin own parameters) - I did not test it myself.

Commands to try on a USB in /dev/sda (will erase the content), USB-FDD simulation: (have three floppy images named disk.bin, partition.bin and flash.bin - for instance take the file /boot/memtest* present in a lot of distributions, or a FreeDOS floppy image with cat /dev/fd0 ⊃ freedos.bin, or download GoldMemory SHAREWARE at http://www.goldmemory.cz and rename Floppy.img to tstmem.bin ...) Remember to type "sudo su" or become root before typing those commands, if cut and paste you need to do it in two pass, stoping the first cut/paste after the first "instboot" to answer "yes" to the creation of the filesystem on the USB device, unless you are using the "--force" argument to instboot.
<pre>
# IF YOU HAVE A SUDO distribution, type first: sudo su
export TARGET_DEV="/dev/sda"
# If you want a partition table, comment second line (digit is partition nb), else comment first line: #export TARGET_PART="$TARGET_DEV"1
export TARGET_PART=$TARGET_DEV
umount $TARGET_PART
export QUITE_SETUP="--verbose=0 --menu_with_disk=0 --menu_with_parttype=0 --menu_with_partition=0" export PROBE_SETUP="--probe_bios_floppy_disk=1 --probe_bios_hard_disk=0 --probe_ide_disk=0 --probe_cdrom=0" export SEARCH_SETUP="--search_disk_mbr=0 --search_el_torito=0 --search_topdir_kernel=0 --search_subdir_kernel=1" export USB_BDI_SETUP="--hide_unhide_partitions=0 --disk_write_enable=0 $QUITE_SETUP $PROBE_SETUP $SEARCH_SETUP"

dd if=/dev/zero of=$TARGET_DEV bs=512 count=64 # If you want a partition table, comment second line, else comment first line: #./instboot boot.bin $TARGET_DEV --disk=BIOS:0x00 --geometry=$TARGET_DEV $USB_BDI_SETUP --search_part_mbr=0 --stop_emulation=0 --mbr-device=$TARGET_DEV --partition_index=1 ./instboot boot.bin $TARGET_DEV --disk=BIOS:0x00 --geometry=$TARGET_DEV $USB_BDI_SETUP --search_part_mbr=0 --stop_emulation=0 --force mount -t vfat $TARGET_PART /mnt/usbdisk mkdir /mnt/usbdisk/boot
mkdir /mnt/usbdisk/boot_disk
mkdir /mnt/usbdisk/boot_partition
mkdir /mnt/usbdisk/boot_flash
echo "bootable partition" ⊃ /mnt/usbdisk/io.sys ./instboot boot.bin /mnt/usbdisk/boot/boot_disk.bdi --geometry=floppy:320 $USB_BDI_SETUP --search_part_mbr=1 --stop_emulation=1 --full --bootdir=boot_disk ./instboot boot.bin /mnt/usbdisk/boot/boot_partition.bdi --geometry=floppy:320 $USB_BDI_SETUP --search_part_mbr=1 --stop_emulation=1 --full --bootdir=boot_partition ./instboot boot.bin /mnt/usbdisk/boot/boot_flash.bdi --geometry=floppy:320 $USB_BDI_SETUP --search_part_mbr=1 --stop_emulation=1 --full --bootdir=boot_flash # use "dd" instead of "cp" to have contiguous files on FAT:

dd if=/boot/msdos.bin      of=/mnt/usbdisk/boot_partition/partition.bdi  bs=64M
dd if=/boot/msdos6.bin     of=/mnt/usbdisk/boot_partition/msdos6.bdi  bs=64M
dd if=/boot/memtest86+-1.55.1 of=/mnt/usbdisk/boot_flash/flash.bdi  bs=64M
dd if=/boot/gm668.bin      of=/mnt/usbdisk/boot_disk/disk.bdi bs=64M

umount /mnt/usbdisk
</pre>
If this USB key cannot boot, you can run some tests (on a test key, backup data first): <pre>
dd if=/dev/zero of=/dev/sda bs=512 count=64 make clean dep boot.bin instboot CFLAGS=-DONLY_PRINT_GEOMETRY ./instboot boot.bin /dev/sda --disk=BIOS:0x00 --geometry=/dev/sda </pre>
Such a floppy (if $TARGET_DEV == /dev/fd0) or USB drive (if $TARGET_DEV == /dev/sda) shall display: <pre>
Initial DX= 0x0000 SS= 0x0030 SP= 0x0100 INT13/08: DX= 0x0101 CX= 0x4F12 BX= 0x0004 AX= 0x0000 DI= 0x0000 INT13/02:, C/H/S: 000001, C/H/S: 000002, C/H/S: 000003, C/H/S: 000004, C/H/S: 000005, C/H/S: 000006, C/H/S: 000007, C/H/S: 000008, C/H/S: 000009, C/H/S: 00000A, C/H/S: 00000B, C/H/S: 00000C, C/H/S: 00000D, C/H/S: 00000E, C/H/S: 00000F, C/H/S: 000010, C/H/S: 000011, C/H/S: 000012, C/H/S: 000013 ERROR! , C/H/S: 000112, C/H/S: 000212 ERROR!
, C/H/S: 000112
</pre>
The "Initial" line display values of register as found by the boot block. The "INT13/08" line display the result of the BIOS call "get disk information", first check if BH (the MSB of BX) is 0, that is CARRY not set and so there was no error. For a 1.44 Mb floppy, BL shall be 4, DH shall be the maximum HEAD (1 is two heads, 0 and 1, for a floppy), and the lowest 5 bits of CL (i.e. CX & 0x003F) is the maximum SECTOR (0x12 = 18 for a 1.44 floppy) (sector start at one, head at zero). The "INT13/02" lines are (one sector) reads of the medium with increasing SECTOR until an error, the 6 digits number shall be interpreted as 3 hexadecimal bytes, the leftmost being the cylinder, the middle the HEAD, the rightmost the SECTOR. So the first line display increasing sectors and the first error is at 0x13, so there is 0x12 sectors per track - it shall be identical to the 5 bits of CL on the INT13/08 line. If you just get <TT>"INT13/02:, C/H/S: 000001"</TT> then you have problem reading the first block from the device. Try to change BIOS parameters (USB emulation of devices like keyboard, mouse, port 60/64, remove standard floppy support, or even reset to safe default) to "fix" your BIOS bugs. The second line (after the first "ERROR!") is increasing heads, first error at 0x02 so there is two heads, zero and one - it shall be identical to DH on the INT13/08 line. The last line show the last read working before changing cylinder, to quickly check.

<HR WIDTH="10%">
<DT><a name="bdi_on_partition">Can I create a set of floppy bootable images on a FAT or E2/3FS partition?</a> <DD>
For a FAT16 partition, there is no problem and you can proceed like creating a USB set of floppy images, note that if you use a special name for this partition (like floppy_boot) and a directory different of "/boot" to not probe this list of floppy on a standard boot, you will just see those "emergency boot floppies" when you chain-boot this partition. If you just have two or three bootable floppies to simulate, and/or you do not want to make a special partition for that, you will want to put those floppy images on an E2FS partition in /boot. 
You will then have the problem of creating contiguous files on an E2FS filesystem. In short, that is not possible. But the E2FS support in Gujin has a problem: it ignores file HOLES, an optimisation to not store the clusters which are only full of zero bytes. Those holes do not happen in kernel files (compressed files do not contain holes!), or only at the end of the files so there is no problems to boot. There also seems to be some holes at the end of the directory blocks, no problem neither. Holes are not possible on FAT filesystems. Because of the internal structure of E2FS, and because future version of Gujin will take care of keeping this behaviour, you can insert a hole of exactly 12 blocks (usually 12 times 4096 bytes) at the beginning of your floppy image and you will then have a contigous file. You cannot create those 12 * blocksize holes at beginning and then a contigous file using dd because the "seek=BLOCKS" parameter is in blocks so the block size is smaller than 12*4096 and the last part of the file will not be contigous, so the file "addhole.c" is provided in this package to create those files: <TT>gcc -Wall addhole.c -o addhole ; ./addhole srcfile dstfile.bdi </TT> and the file "showmap.c" is provided to display the exact allocation on disk: <TT>make showmap ; ./showmap dstfile.bdi </TT> You should get this kind of output, for a good contigous (i.e. 1 fragment) file: <pre>
[root@localhost gujin]# ./showmap /boot/memtest86.bdi File "/boot/memtest86.bdi" of size 143752 is on filesystem 0x303 with block size 4096. The device start at 97691265, has 19551105 blocks of 512 bytes, C/H/S: 20019/255/63. File (281 blocks) begin with a hole of 12 block, and start at block 1479005 for 269 blocks, end at block 1479274 and has 1 fragments. </pre>

<HR WIDTH="10%">
<DT><a name="findroot">The kernel starts correctly - but then stops with the message "Kernel panic: VFS: Unable to mount root fs on ..." - what is the problem? Can Gujin find alone the root partition of a kernel?</a> <DD>
By default, the kernel file (vmlinuz-2.*.xx) contains the root partition to mount first as "/" - it is set to the current root of the machine compiling the kernel. 
On most distribution (if you are using the distribution default kernel), this is a SCSI hard drive, like /dev/sda3 - and LILO will change it depending on "/etc/lilo.conf". 
This default root can be seen by "rdev /boot/vmlinuz", and can be set by (for instance) "rdev /boot/vmlinuz /dev/hda2". If the default root of a vmlinuz file is zero - or is a SCSI disk on a PC which has no SCSI disk - or when the root detection is forced in the setup screen, then Gujin tries to find a valid root partition: If the "vmlinuz" file is in a "/boot" directory and the filesystem is E2FS, the root is the current partition; else Gujin looks for a directory which contains a subdirectory "/boot" in each Linux-type partition (0x83, usually ext2 or ext3) first on current HD then on all HD - then it declares it as the root partition. 
<UL>Note: Now, at least RedHat 7.2 has switch to an IDE machine to produce its default distribution kernels, hence the addition of the "force root detection" option.
</UL>
<UL>Note: there is another and different message which will appear on some distributions, later in the boot process (at root filesystem ext2/3 checking) when the root partition passed to the kernel is not the one described in /etc/fstab. If you have such a problem, first check that you did not check the "keep BIOS disk order" in the setup screen. If you have a strange IDE order, you can setup the "ide[0-9]=0x" options on the command line, that will disable autodetection/autoorder of IDE interface (but keep the "root=" autodetection unless you write it manually) - take care "ide*=0x" hexadecimal numbers have to be in lower case. Another solution is to boot another Linux and change /etc/fstab manually - until the distribution implement better startup files. You could also try (dangerous) to mount the root filesystem in read/write mode (kernel command line "ro" or "rw").
</UL>

<HR WIDTH="10%">
<DT><a name="oldideonly">Why, on this "old" PC, the root filesystem is only guessed on the IDE interface?</a> <DD>
Because Gujin will not try to guess the relationship between a BIOS drive (0x80, 0x81...) and an IDE drive (IDE at I/O 0x1F0, 0x170, 0x1E8...). 
For new PCs a BIOS field describes on which IDE the BIOS drive is, but not on 386/486 BIOSes.

<HR WIDTH="10%">
<DT><a name="idechanging">Sometimes I see my IDE master as BIOS 0x80, and sometimes as BIOS 0x81!</a> <DD>
Some BIOS on newer motherboards are able to detect that there isn't any bootable partitions on the master drive of the first IDE interface, and the slave drive of the first IDE interface has a bootable partition. They are then able to swap BIOS drives 0x80 and 0x81 to keep a bootable disk on disk number 0x80. Well I cannot really help you there, but there should not be any problem if you just have one Win* setup, because booting Linux does not hide/unhide partitions. 
Note that when you boot from a floppy disk, you have the real order of drives.

<HR WIDTH="10%">
<DT><a name="replaceloadlin">Can Gujin replace loadlin?</a> <DD>
When you type "make boot.exe" (or "make boot.com" if the file is smaller than 64 Kbytes), you get an MSDOS executable which is able to load a vmlinuz and an initrd file (or an embeded initramfs). Note that in DOSEMU and WinNT/whatever they call that now, the kernel file is loaded correctly but the DOS emulator stops the execution of Gujin when it tries to switch to protected mode, and that cannot be "corrected"! In the default configuration (no BIG_MALLOC and text or VESA1 video modes), the executable is 100% compatible with MSDOS, and so the "subst.exe", network redirector software and DOS USB device drivers should work. If you do not want the graphical interface, you can use "tiny.exe", it is as simple as: 
tiny A:\boot\kernel A:\boot\initrd root=/dev/hda3 ...other cmdline params... or: 
tiny A:\boot\kernel initrd=A:\boot\initrd root=/dev/hda3 ...other cmdline params... or without initrd (note the minus sign): tiny C:\kernel - root=/dev/hda3 ...other cmdline params... Since version 1.2, if the initrd (2nd parameter) contains the letter "=" (equal), then no initrd is loaded and the command line includes this parameter. Since version 1.4, "tiny.exe /V" display a list of VESA2 video mode which can be set by "tiny.exe /V=800x600x16 linux.kgz ...", not as complete as the real VESA support of "boot.exe" (no check of EDID screen maximum definition, no support of VESA1 modes even temporarily while EMM386 is active). You can even run that with EMM386 and a disk cache loaded on DOS, but it will not autodetect the root filesystem alone because it does not probe any disk. 
Note also that you cannot use wildcards on the kernel/initrd names, and you must execute it either in text modes or in VESA2 modes (i.e. graphic VGA modes are a no no!) mostly because tiny.exe is just 30 Kbytes! Note that if HIMEM is loaded its interface is used (DOS in high memory works), but you shall have enought HIMEM memory to load the kernel and its initrd in the same XMS block (else you get error message: "error 0x229B loading file"). If HIMEM is not loaded then the BIOS INT 0x15/0x87 is generally used (see function treat_data() of gzlib.c). Gujin uses the fact that HIMEM memory blocks can be locked - and when locked their physical base address is identical to their virtual address, and they are contiguous in physical memory. That has always been true because DOS drivers (mostly sound drivers) used to do DMA to those memory blocks. If you use a DOS emulation which does not implement those HIMEM locks then you are out of luck. It may be possible to forbit the memory manager to implement a swap file to get back the HIMEM lock functionality. The EMM memory has always been a lot more complex to use because some drivers were inverting 4Kb pages in 16Kb blocks (so you need to XOR the last two bits of the virtual page address to get the physical address) to prevent reverse engineering - and other drivers had to be compatible.

<HR WIDTH="10%">
<DT><a name="errorcode">How to interpret Gujin's error code when loading the kernel/initrd?</a> <DD>
If Gujin gives you an error code like 0x2296 when loading/decompressing an initrd like c:\image.gz, you should interpreted it one digit at a time like this: <pre>
0x2??? : error in function system_file_load() for DOS read file function 0x?2?? : error in DOS_system_file_load() for gzlib extraction 0x??9? : error in gzlib_extract() for inflate data 0x???6 : Z_OUPUT_FULL error.

The last digit is one of:
typedef enum {

Z_OK = 0,
Z_STREAM_END = 1,
Z_STREAM_ERROR = 2,
Z_DATA_ERROR = 3,
Z_MEM_ERROR = 4,
Z_BUF_ERROR = 5,
Z_OUPUT_FULL = 6,
Z_BAD_LENGTH = 7,
Z_BAD_CRC = 8,
Z_BASE_MEMCOPY_ERROR = 9
} zret_t;
</pre>
If you were loading starting from a DOS boot floppy, type "mem" under DOS to know how much free memory you had (if HIMEM was loaded you should check how much free HIMEM you had), and check how much space the uncompressed c:\image.gz will take. Some HIMEM.SYS versions will only manage the first 64 Mbytes of the memory whatever you have installed.

<HR WIDTH="10%">
<DT><a name="debuggujin">How can I debug a problem in Gujin?</a> <DD>
Well, because I do not see a solution to plug-in a debugger, at least at an acceptable price, you can use the built-in logger, by defining the DEBUG variable in Makefile to send log messages to a serial or parallel (printer) port, or to a DOS file (if boot.exe), or to the screen, to know where exactly is the problem. 
The DOS file method is easier but cannot handle complete crash because of the buffering, and you have to close the file cleanly by exiting Gujin (^C or ^D will do) - use a serial line in extreme cases. Note also that IDE probing is completely disabled under DOS/Windows because it is a bad idea to access directly the IDE under an operating system, but if you are running dbgdisk.exe or dbgfs.exe - you can re-enable them on the setup screen even if they are grayed. It is a very bad idea to do it on something else than the bare DOS. Also, you may not want to probe the DOS drives when logging to the floppy for dbgdisk.exe, due to the re-entrancy problem when logging message: 
Probing disk B: INT0x24 called with AH=0x1A, DI=0x8, BP:SI=0x70006B: sector not found Note that to read the bootsectors (Master Boot Record or Partition Boot Record) you can use 'hexdump /dev/hda | less' or 'hexdump /dev/hdb1 | less' You can get their assembly by doing:
<pre>
dd if=/dev/hdb of=copy_hdb bs=512 count=1 objdump -D -m i8086 -b binary copy_hdb | less objdump -D -m i8086 -b binary --start-address=0x71 copy_hdb | less </pre>

<HR WIDTH="10%">
<DT><a name="gujinstable">Is Gujin ready and stable enough for production?</a> <DD>
Well, it is up to you to say! I still have to write some new features, but there are probably still some bugs I am not aware of... To write this software I had to re-write nearly everything, up to the memory and string management functions (malloc, memcpy, strlen, printf...), the GZIP decompression functions and the FAT12/16/32 and E2FS (read only) functions. 
I really welcome success story, bug report (or better patches) at: etienne@gujin.org 
If you have compiled yourself the code, please check before reporting a bug that it is still present after a "make proper dep /dev/fd0".

<HR WIDTH="10%">
<DT><a name="colocation_server">How to use Gujin remotely on a colocation server?</a> <DD>
If you want to keep all the functions of Gujin on a remote PC, the cheapest is probably to use the serial interface of Gujin on this remote PC and a TCP/IP to serial converter. On the first serial of this box, you connect the PC first serial port COM1 (for keyboard/screen), on the second serial interface you connect some relay to power up/down the remote PC. You can probably try to connect COM2 to the third port of this IP/serial converter to simulate the mouse, but I did not try it. MSDOS can be controlled using the serial ports (CTTY command if I remember well) but not any windows environments, only the command line. Linux will boot and Gujin will add command parameter to see boot messages on this serial line (console=...), at 9600 bauds 8 bits no parity; you may want to add getty on this serial line if you want to connect after initial boot (man getty), for instance if the boot is not successfull.

<HR WIDTH="10%">
<DT><a name="videoaccess">What are letters between brackets at the top of the screen?</a> <DD>
It defines the way the video memory is accessed: <UL>
<LI>[VGA] : all characters are displayed using only VGA BIOS functions</LI> <LI>[INT] : in VESA modes, use the interrupt to change graphic window</LI> <LI>[FCT] : in VESA modes, use the function to change graphic window</LI> <LI>[hard] : My recorder works - access I/O ports to change graphic window</LI> <LI>[hardc] : Same as [hard] but array is compressed (VESA 1.* default)</LI> <LI>[lin] : Linear window used in real mode (VESA 2+ default)</LI> <LI>[nowin] : The complete video memory fit in 64 Kbytes (VESA 1 or 2+)</LI> </UL>
There could be two [hardc][hardc] to say that a separate read window and a write window are used. 
It is abnormal to have something else than [lin] on VESA 2 or VESA 3 cards - but maybe for 16 color modes, under some memory managers, or when VESA2 support is removed from the configuration in the setup screen or in the Makefile.

<HR WIDTH="10%">
<DT><a name="videodetect">Why is there three commands to detect video modes, how to use them?</a> <DD>
First, you probably need them only if you want a video mode which has not been detected at startup. Gujin should detect (and manage) all VESA video modes with more than 4 Bits Per Pixel and with an identification number higher than 0x100. If you have a VESA video card, and you know it supports some video modes which are not detected at startup (usually you would like some extended text modes), then ask to "probe VESA modes 0..0x7F" first. This check is safe and fast. If Gujin has write access to the disks, it will save the current video mode, and use it at next startup; that is working without any problem for VESA mode below 0x100. The total number of video mode available is written on the first line of the screen. 
If you do not have a VESA compatible video card (VGA only, look at messages when Gujin starts) or the previous VESA probing did not give you the mode you are looking for, you can probe VGA video modes. <UL>Note:
Because it is not possible to get information about a VGA mode without switching to it, this probing is slower and a bit less safe. If you have a correctly written video BIOS, when asking it to switch to a mode it does not support, it should either not switch to this mode, execute an invalid instruction, execute a division by 0, or do an infinite loop. All of these cases are correctly handled by Gujin. The only thing it should not do is an infinite loop when interrupts are disabled, because then the timeout manager cannot execute the timeout... 
Because the later case may happen, and if the disks are in read/write mode, a tag is written on the disk before trying to switch to each mode. If you have to do a manual reset, then this VGA video mode is saved as "unusable". You can then, when you get back Gujin interface, restart the VGA probing - this mode will be skipped. Note that writing to the disk twice per VGA mode test is slower, mostly if Gujin is on a floppy disk. </UL> To probe for VGA mode, you should first test the standard ones, from 0 to 0x13. 
This is probably working without problem on all PCs. Then you can stop here if you have found the mode you were looking for. If you switch to one of these video modes and disks are read/write, the default video mode is saved and you will get this mode at next startup.
</UL>
<UL>Note:
The video modes known from the VESA interface (by the first probing) are not re-probed in the VGA interface, that why the order is important. The VESA driver of Gujin do not manage video modes below 4 BPP (i.e. less than 16 colors), the VGA driver will detect them.
</UL>
Finally, if you want to do an extensive probing of you VGA interface - for instance because your video card is "SuperVGA" and supports mode like 1024x768 in 256 colors but has no VESA interface - like some Compaq P120 systems, you can run the probing of VGA mode between 0x14 and 0x7F. You should then have all the modes you video card is able to do. Gujin will propose you to turn OFF your screen until the end bip because some (very old?) monitor can have problems with the too high refresh frequency that the BIOS may produce in some video modes - even if it stay in this mode just long enough to get its characteristics. <UL>Note:
The list of "unusable" VGA video mode, the basic characteristics of "usable" VGA modes and the default video mode (default text and graphic) are saved in between boots in the "boot*.sys" file. These parameter are reseted if the video card has physically been changed (detected by the change of the card name of the VESA interface) or manually by pressing Caps-Lock before booting Gujin. If you physically exchange VGA-only video cards in your PC, it is up to you to press Caps-Lock at next reboot. 
Also, the default video mode being stored, you do not need to have the screen powered ON to start Gujin (the EDID is not re-checked). But it is a lot safer to restart Gujin with Caps-Lock active if you have physically downgraded the screen.
</UL>
<UL>Note:
It is better to "reset VGA/VESA modes 0..0x7F" in a VESA mode, or switch back to VESA (and re-switch to VGA if you want) after this command, or simply restart the computer. If not, the invalid modes disabled in VGA initialisation are no more disabled (because VGA initialisation is not done) and you will test for instance mode 0x8..0xC at next VGA video mode probing. It still can be usefull when you know what you do, so I keep it. </UL>

<HR WIDTH="10%">
<DT><a name="lastpartition">I have messages like "last partition over disk limit detected", what does it mean?</a> <DD>
It is probably with hard disks using BIOS or EBIOS interface. It means your BIOS cannot access the entire content of this disk. If the access is using BIOS, your hard disk has probably over 1024 sectors; if access uses EBIOS, your Extended BIOS may not be able to access more than 8 Gbytes. 
In the later case, double-check the BIOS set-up: the autodetect feature of your BIOS (accessed at boot time) may not detect more than 16383 cylinders. 
Try to set manually the cylinder field correctly. If you cannot, use only the IDE interface on this drive. 
This message also appear when your [E]BIOS is reporting a size a bit smaller than the real disk size, and you have created the last partition under Linux: 
The [E]BIOS will probably not be able to read a file if it is mapped in the last few Mbytes of the drive - but that is not usually a problem. <UL>Note: The [E]BIOS may decide to report one sector less to the operating system because it is using this last sector for test purposes, at boot time. Then, it is really unsafe to store anything in this sector, because it may be written at each/some boot - so this sector shall not be mapped in a partition. Also some EBIOS no more support the indianess problem on the disk size of very old drives (< 512 Mb), and that can produce such a message.
</UL>

<HR WIDTH="10%">
<DT><a name="will_work_with_PCI_IDE">Does Gujin scan other PCI IDE ports?</a> <DD>
Gujin will detect extra IDE ports if they are at standard addresses (0x1F0, 0x170, 0x1E8, 0x168, 0x1E0, 0x160) or if that IDE I/O address is reported by EBIOS. The PCMCIA IDEs are not handled because they are not enabled at boot time. CompactFlash to IDE converter works for me. USB disks are not IDE so are not handled. Usually, extra PCI/IDE hardware are hem... less compatible ... than standard motherboards IDEs.
I just had to handle those features on my board: <UL>
<LI>HTP BIOS do not handle ATA1 disks, where the IDE size reported is zero, you just need to multiply headcylsect to know its size (HTP size is -1).</LI> <LI>HTP BIOS do not handle ATA2 disks, where the size reported has a strange half indianess, and they remove 65536 sectors instead of 1.</LI> <LI>HTP BIOS crash - at least interrupt disabled or worse - when you try to reset disks after requesting PIO data with IDE interrupt disabled.</LI> <LI>HTP BIOS do not initialise nIEN of the IDE control register before performing a read or a write to the disks.</LI> <LI>HTP BIOS report one sector less than the real disk size on extended BIOS call, so you can get the message "EBIOS: disk ... last partition over disk limit detected (0 Kb)!". The 0 Kb is because there is 512 bytes (1/2 Kb) lost if the disk has been formatted on Linux and fills completely the disk...</LI> <LI>Lots of BIOSes do not report the size of the disk on INT 0x13/ax=0x1500</LI> <LI>ALI BIOS is partly EBIOS but does not report the IDE base address in EBIOS.</LI> <LI>Silicon Image does not have IDE Alternate Status register (always reads 0) so will not work in IDE hardware mode.</LI> </UL>
If your hardware/BIOS has more bugs than that, Gujin will not work, you may still try to disable either the IDE or the BIOS interface. If you need an PCI/IDE board, I recommend Promise Technology, Inc Ultra100 TX2 (v2.20.0.15) which works perfectly for me - EBIOS and IDE - and it is the cheapest on the market. It is important to have a compatible hardware IDE interface because the hardware IDE password system is then correctly frozen before running the operating system, and having compatible ATA registers is the best (or only) way to handle correctly transient errors of hard disks (like DMA checksum error on write) and prevent crashing the filesystem at the first error.

<HR WIDTH="10%">
<DT><a name="whatis_ignore_kernel_IDE_options">What is the option "ignore kernel IDE options"?</a> <DD>
This hasn't anything to do with Linux parameters. This has to be checked at all time, but when you intend to use trusted kernel files (*.kgz) to setup IDE passwords/configuration or IDE aware partition tables manager. 
In short, newer hard disk may have a password protection system, that is a very high protection system - transforming a hard drive in a real brick if you forget the password. 
You should never enable this password protection system if the data you store on the hard drive does not worth AT LEAST few times the price you paid for the disk. 
The IDE password can be initialised with newer version of hdparm, look at its manual pages and at the end of the output of "hdparm -I /dev/hd", or "atactl /dev/wd0 security status" if you are using NetBSD. Gujin cannot initialise the IDE password from its interface. If Gujin find at boot a hard disk protected by password, it will ask you this password (it needs the layout of the keyboard, so may ask you to type few keys before, see also the read only mode of Gujin). Gujin just handle the standard ASCII characters, i.e. from ' ' to '~', for the password (no accented letters). I need to say that: GUJIN IS A GPL SOFTWARE WITHOUT WARRANTY OF ANY KIND, THERE MAY BE A BUG SOMEWHERE, IN GUJIN OR IN YOUR HARD DRIVE OR IN THE IDE INTERFACE, WHICH TRANSFORM YOUR HARD DISK TO A BRICK, I AM NOT RESPONSIBLE. 
And also: I DO NOT STORE THE PASSWORD YOU TYPE ANYWHERE, DO NOT EVEN E-MAIL ME IF YOU HAVE FORGOTTEN YOUR PASSWORD - I DO NOT CARE. EVEN YOUR COMPUTER SUPPORT HELPDESK CANNOT KNOW THIS PASSWORD. And logically: DO NOT PROTECT BY PASSWORD THE BOOT DISK IF YOU WANT TO LOAD GUJIN FROM THIS HARD DRIVE, you will only be able to boot from a Gujin floppy/CDROM then. 
I have tested it with my SEAGATE, WESTERN DIGITAL and IBM hard drives, it may work for you. 
For more information and utilities about IDE disks, have a look at <A href="http://hddguru.com" TARGET="_blank">MHDD site</A> and the associated <A href="http://forum.hddguru.com" TARGET="_blank">forums</A>. The problem of those drive appear when you are running an unsafe operating system, a virus may activate the password system with a random password... So gujin will by default freeze passwords on drives having this capability, as recommended in the ATA specification, freeze their configuration and set a maximum LBA, so that nothing will be able to modify the password subsystem or any vital drive information until the next power off. It will do so before running any operating system, even Linux, a MBR based loader or even Gujin itself (Gujin can load Gujin), if this box is checked. 
If the box is unchecked, it will rely on the "option" GZIP comment of the .kgz file.

<HR WIDTH="10%">
<DT><a name="security_issue">This IDE password system, isn't it a security issue?</a> <DD>
Well, probably not because the following message has been refused from bugtrack. I would still advise you to only boot using Gujin on a system containing at least one IDE hard disk bigger than 8Gb. Do not wait for any help from the manufacturer of your hard drive if you have this problem: by helping you they would also help thieves having stolen a PC and wanting its hard drive content. If they release a way to bypass the IDE password, some people (the owner of stolen PCs) will probably go to court against them...
<pre>
From: BugTraq@gujin.org
Subject: Disk2Brick virus: a fix
Date: Mon, July 18, 2005 12:14 pm
To: bugtraq@securityfocus.com

Does the "Disk2Brick virus" exists now? No.
Is it easy to create it? Yes, relatively easy.
Where this name "Disk2Brick" comes from? I do not know who invented this name, it appeared when the security feature appeared on IDE hard disks. People stop talking about this feature few years ago because there wasn't any fix anyway. I am just re-using this name because it summarises nicely the problem, transforming an IDE hard disk into something looking like a brick - i.e. no way to extract any information previously stored on it.
What is the specific problem? All the IDE hard disks compatible with ATA4 or later (approximately all the IDE hard disks bigger than 8 Gbytes) can have a set of features called "security" - and all usual brands of IDE disks actually have it. This is quite a nice solution to protect the content of stolen hard disks, when it is correctly used. To be working, HD producer cannot release the same drive with and without the feature: it missing the point because you can then exchange electronic parts to read a previously protected hard disk. When a hard disk is protected by password, it correctly identifies itself as a hard disk but returns an error to any command to read or write its content, up to the right password is entered. The password has to be entered at each power-up. The security is located inside the hard disk, so there is no point in installing the hard disk in another PC to read it content, we are not talking of a weak "BIOS password" but a much more efficient "IDE password".
How is this security system supposed to work? At boot time, the PC executes the BIOS boot code and shall detect if some of its hard drives are protected by password, and if true ask the password to the user to unlock the disk and access its content. If the user doesn't know the related password, the BIOS shall continue booting assuming that this hard disk is not needed (for instance a PC system with two hard disks - and only one will be used). Just before running an Operating System (like Windows, Linux, *BSD, DOS...) the BIOS is supposed to freeze the IDE password subsystem by sending a special IDE command to the hard disks. This freeze will block all commands related to the IDE password subsytem, up to the next power down. After the freeze, you will no more be able to change IDE passwords, you have to do a real power cycle if you want to.

I repeat myself: the real important thing is to freeze the password system of all the IDE hard disks present, independant to the fact that you have set up a password in the hard disk or not, before running untrusted software.

Note that you can decide not to freeze a hard disk which is still protected by an IDE password before booting the Operating System (because the user doesn't know the password), to be able to have another software unlocking itself the IDE hard disk - and freezing it afterwards. If you freeze an IDE hard disk which is still locked by password, you will no more be able to enter the password until next power cycle.

6: What is the problem?
Basically, the BIOS manufacturer do not want to know the keyboard mapping you are using - there is simply too many of them. And to enter a password, you absolutely need to know where each letter are placed on the keyboard. There is no way to electronically detect the keyboard mapping, the user has to tell what he is using. Some BIOS manufacturer have implemented this IDE password subsystem on laptops: they then exactly know the keyboard used because it is not plugged in but physically built-in.

If the BIOS manufacturer ignores the IDE security system, like most BIOS do, it will not freeze the IDE password system. It is too late to have a driver freezing the IDE hard disks if this driver is loaded after a possible virus has taken control of the PC, because then the virus can itself put a random password and freeze itself the IDE password subsystem, so the content of the hard disk is totally lost - forever. At next power up you will not be able to give the right password.

7: Are SCSI disk better?
An equivalent password system is said to exist for SCSI hard disk - but I do not have more information. The virus problem is lower risk because the hard disk is not accessible before the SCSI driver is loaded.

8: Is there a problem with HD plugged in PCI-IDE extension cards? Some of those PCI-IDE cards are not completely compatible at register level, for instance can only do extremely fast read and write using DMA. You cannot enter a password using DMA in the ATA spec - you need a slow polling mode (you do not need speed for security command - but reliability). Those cards may be unsafe - check by yourself if they are compatible enough to at least accept the SECURITY FREEZE PASSWORD command.

9: More details - references
ATA4 specifications (Revision 18 released 19 August 1998) is a smaller document than latest ATA7, so just download it at: http://www.t13.org/project/d1153r18-ATA-ATAPI-4.pdf and read "6.10 Security Mode feature set" around page 30 / page 46. Pay attentiong to the last sentense of "6.10.4 Frozen mode".

10: a fix?
If your bootloader detects the IDE hard disks of your PC, knows the keyboard mapping to enable you to type possible passwords, detects if the disks support the security feature set, and finally if the bootloader freezes the IDE password system before running either Windows, DOS or Unix, you should be safe. The only one I know of is there: http://gujin.org This bootloader does not enable you to activate the password system of IDE hard disk, i.e. you have to use another software to set a password and lock a hard disk, but it asks for password to unlock if needed and freezes each IDE disks.
</pre>

<HR WIDTH="10%">
<DT><a name="whyname">Why the name Gujin ?</a> <DD>
Gpl Use of the Jnp INstruction. 
I do not think anybody has used this 80x86 assembly instruction (jump if no parity) during the last 10 years, mostly for a GPL software. It saved me a byte in the boot sector - and there is only 0x1B6-0x3E = 376 bytes available there to do a lot of things, even if you have, on your PC, multi-gigabytes of RAM and few hundred of gigabytes of Hard Drives!

<HR WIDTH="10%">
<DT><a name="floppyerror">I have errors while Gujin loads, during this line: Gujin1, Gujin2....ERROR. 
or: 
Gujin1, Gujin2.......CHECKSUM ERROR. and it eventually loads after few tries.</a> <DD>
Well, try another floppy disk. Also there is sometime quite a lot of dust in the floppy drive... but that is a cheap device. If you want to check, you can boot Linux and type: <pre>
cat /dev/fd0 > /dev/null
</pre>
You will probably get something like:
<pre>
floppy0: data CRC error: track 2, head 0, sector 17, size 2 floppy0: data CRC error: track 2, head 0, sector 17, size 2 cat: /dev/fd0: input/output error
</pre>

<HR WIDTH="10%">
<DT><a name="quickserial">How to quickly test a serial interface configuration (without a VT420)?</a> <DD>
First, you need a twisted serial cable. Install Gujin on a floppy with "make dep /dev/fd0.com1" or "./instboot boot.bin /dev/fd0 --serial=com1,9600,n,8,1". Start "minicom" on the second PC running Linux and configure it to 9600 bauds (the BIOS maximum) on the port you plugged the serial cable. Power up the PC with the Gujin floppy. If you want to, you can use the mouse - but only the one of the Gujin's PC! 
Note also that message concerning the modem at the beginning: if you set up an ATDT sequence, you can remote boot through a modem (distant computer).

<HR WIDTH="10%">
<DT><a name="largekernel">You said that I can boot a very large kernel - but I can not even get it to compile!</a> <DD>
There is a test in "linux/arch/i386/boot/tools/build.c" to abort the generation of a kernel bigger than 2.5 MB uncompressed, because those kernel cannot be loaded by LILO. 
If (and only if) you have a 2.4.1 or later kernel, it does not matter: you will still have in the top Linux directory the file "vmlinux". Type:
<pre>

        objcopy -O binary -R .note -R .comment -S /usr/src/linux/vmlinux linux-2.5.1
        gzip -9 linux-2.5.4
        mv linux-2.5.4.gz linux-2.5.4.kgz

</pre>
Then copy this "linux-2.5.4.kgz" to "/boot" and reboot. If you want to boot a 2.2 kernel, you will have to remove the test in "build.c".

<HR WIDTH="10%">
<DT><a name="nojoystick">My Joystick does not work.</a> <DD>
Note first that only BIOS compatible joystick will work, they should work if they are detected at startup (in between number of serial ports and type of mouse).
<UL>Note: Most of the newest joystick (who have more buttons to press than fingers you have) are not BIOS compatible - joystick manufacturer do not believe hardware compatibility is important. Maybe one day the USB Joystick will be managed by the BIOS, like USB keyboard and USB mouse. </UL>

<HR WIDTH="10%">
<DT><a name="whyforcerootprobe">What is the "force root probing" option?</a> <DD>
You should uncheck it only if those two are true: <UL>
<LI> if you are sure that the default root coded in file vmlinuz is valid (i.e. you have compiled the kernel yourself and you will use it with the current filesystem, or you have set it up manually with rdev)</LI> <LI> Gujin is not able to find alone the root filesystem (You have different distribution of Linux and all the kernel are in the same "/boot/" directory; or the root partition is a FAT filesystem).</LI> </UL>
Setting manually a "root=" parameter on the command line will still override this option, whether it is on the Gujin "extra command line" or in the comment field of the GZIP file.
</UL>
<UL>History: Before, it was possible to detect that a distribution default kernel was booted because its root was on a SCSI drive, and the user's PC did not usually have an SCSI interface. Now, some distribution (RH7.2 at least) are using IDE only machines

and so the default root coded in file vmlinuz seems valid, but is not on your own machine. It is a hack, standard distribution should reset this "root" parameter to zero to show that they do not have a clue of the root filesystem of the user's PC; but rdev do not allow to enter such an invalid "root". </UL>

<HR WIDTH="10%">
<DT><a name="extendpartnotfound">I have messages like "Extended partition block not found at LBA = " on Gujin-0.6 or later.</a> <DD>
I think you should use partition type "extended" (0x05) or "extended LBA" (0x0F) in your partition tool instead of "Linux extended" (0x85). If that is not the problem, then your partition table is corrupted, or your disk description is wrong. 
If Gujin always follow this message by "trying ... OK", it has probably perfectly recovered and you can continue using it, if it display "trying ... : failed." or "stop.", you should better fix your partition table or your PC BIOS setup as soon as possible. If such an error appear, the Hard Disk write support is turned OFF automatically, you would better not turn it ON again. This can appear when the BIOS did not correctly detect the number of heads and sectors-per-track of an older disk, when it is not using the "large" model for accessing the hard disk, or when this hard disk has been partitioned on another PC with another BIOS. You may be able to change the BIOS setup, for instance not auto detecting the hard disks but giving the values present on the PC where it has been partitioned - try to play there. 
There is an error message which may help you in this game: DISK 0x?? heads, sect/track mismatch: MBR ??/??, BIOS ??/??!

<HR WIDTH="10%">
<DT><a name="whatissmart">Gujin report "SMART threshold exceeded condition" or "present and disabled!"?</a> <DD>
SMART is a protocol which describe the health of you hard disk(s). In short, when newer hard disk (> 1 Gbyte, > ATA3) have a problem writing to the magnetic disk in a certain place, they record this error condition and automatically remap faulty sectors to spare (i.e. hidden) ones. So you will not notice small errors, and will not loose your data - at least as long as there is spare sectors left! "Threshold exceeded condition" is a message described in the SMART protocol to say that you should better call your local dealer and get a new drive, because you will soon (or you are already) loosing data because there is no more spare sector - or for any other reason. Having a disk new enough for the SMART protocol but someone forgot to enable it (the second message) is for me an error - so I report it. Do not ask me how to enable SMART - I am just writing a bootloader! Note: Some other operating systems did never care about the SMART status of your disk - but you do not need a bad disk to loose data with them. I may report to you, for the first time, that your hard disk is dying: It is not my fault and I will not pay you a new one -:) Note also that it is not unusual for a disk to report a strange status on the very first time you ask its SMART status - because it has then to do a lot of scanning. If you see something wrong on the first time you try Gujin, wait few second (until the disk stop colleting its own data) and reboot. If it is still wrong you may begin to talk about discount in your usual shop - the disk may fail in ten minutes or in few years, but it will fail.

<HR WIDTH="10%">
<DT><a name="windowcodepage">When I boot MS-DOS/Windows, I get a message saying that the codepage has been successfully prepared, and then that the specified pagecode has not been prepared...</a> <DD>
It seems that DOS only accept to boot in "simple text mode", i.e. mode 3, 80x25. 
Gujin will force mode 3 if it detects that a FAT boot sector is loaded, the message only happen if you boot the MBR of a hard disk, which in turns select a FAT boot sector. Switch to mode 3 as the text mode before booting.
<UL>Note: When booting a partition's boot sector, or the Master Boot Record of the disk, Gujin ask to the video card if it supports the standard BIOS calls to display strings in the current (VESA) video mode. If it does, Gujin does not switch to text mode because the user may want to stay in graphic - if it does not support BIOS calls, Gujin switches automatically to the last text mode used. </UL>

<HR WIDTH="10%">
<DT><a name="saveparams">Automatic running of a kernel after timeout do not work? Parameter (or list of VGA modes) not saved in between boots?</a> <DD>
Do not forget to "enable disk write", else absolutely nothing is written to disks, not even the configuration.

<HR WIDTH="10%">
<DT><a name="winextended">Can Gujin boot Windows95/98/Me on an extended partition or on a secondary drive?</a> <DD>
There should not be any problem to boot those, but you have to take care of some Windows restrictions: <UL>
<LI>The partition table has to be clean, use FDISK.EXE of Windows to create it. The best way is to use Windows FDISK.EXE on a blank disk to create all partitions at once, this tool will easily create overlapping partition when you try to modify an already existing partition table (I tested that). Plan to leave few unused Mbytes at the end of the disk, they may be really useful later: Plan 16 Mb + 4 Kb free.</LI> <LI>You have to play the best Microsoft games: DLCATT (Drive Letters Changing All The Time). Better install every software on C: - and so you will get a different C: for each Windows boot. Have also a look at file "srdiskid.dat" in the "_restore" hidden directory of the top level directory.</LI> <LI>Windows cannot be installed in an extended partition nor on a secondary hard drive: install it on a primary partition and then copy all files (including hidden files and system files) to the new partition. The order of files is not important (unlike on MSDOS where IO.SYS had to be the first file), but it is easier to copy the files under Linux with "cp -a"</LI> <LI>If your partition is over 8 Gbytes, you have to set its type to be either "Windows FAT 16 LBA" or "Windows FAT 32 LBA". FDISK.EXE will set only partition types "Windows FAT 16" and "Windows FAT 32" for extended partitions, so you need Linux to do that last bit.</LI>
</UL>

<HR WIDTH="10%">
<DT><a name="winnotbootable">I achieved to boot DOS or Window95/98/Me on another hard disk, but now, when I try to boot without Gujin, the BIOS says me that the hard drive is not bootable?</a> <DD>
To boot DOS or Window95/98/Me, you have to hide some partitions and unhide some others. This is done automagically (when "enable disk write" and "manage visible/hidden partitions" are checked), but you can go in a configuration where none of the primary partition of the first disk are unhidden, and none are "active". Newer BIOSes will then look in the following hard disks to find an "active" partition, but some do not. Simply boot another time with Gujin and then select a FAT operating system on the first disk, still having "enable disk write" checked. Next time you will boot without Gujin, it will get the last OS Gujin has booted. <UL>Note: For the auto-hiding feature of Gujin, you need to be able to read and write every hard disks. Windows want to boot on C:, and so if this C: partition is an extended one on the first hard disk, Gujin needs to hide all primaries of every hard disks. There is a two step process, first one is read only - and if everything is OK the write process begins. If you have a broken hard disk as secondary or third drive, Gujin will not be able to read its MBR and it will abort early the process and report you an error (before writing anything), even if you just wanted to boot Win* on the first hard disk and did not care of the third HD. Moreover, I heard that you cannot have more than one primary partition visible per disk else Win* may be confused, so Gujin will not do that. If you want to try the opposite it is a simple compilation switch. </UL>

<HR WIDTH="10%">
<DT><a name="nobiosedid">My screen is automagically recognised under Windows but not under Gujin?</a> <DD>
Gujin uses the video BIOS EDID interface to recognise the screen and select the default video mode resolution. If you know that your screen answer the EDID request, that your screen cable connect the EDID wires, and that your video card has the hardware interface to interrogate your screen, it is possible that your video BIOS has a bug and so do not correctly report the kind of screen you have. Under other operating systems, you will have a floppy or a CDROM to replace the video BIOS - and that extra software may have the bug corrected - but its interface is only working on that other operating system...

<HR WIDTH="10%">
<DT><a name="comment">Which field are recognised by Gujin in the comment field of the GZIP kernel?</a> <DD>
First, to modify this comment field of the GZIP kernel, you will need to use the "gzcopy" executable given with Gujin. The easiest way is to produce a kgz kernel by typing "make /boot/linux-2.6.10.kgz" instead of your usual "make vmlinuz" in the kernel tree - once this tree has been patched. These comment fields are recognised (only hexadecimal) by all possible configuration of Gujin, but for "maskvesa" and "maskresolution" which need a complete user interface - not available in tiny.exe/tiny.img: <UL>
<LI>loadadr=0x00100000 : you can modify the default load address, this will only work with a kernel linked at this address. If this field is zero, do not relocate the PIC kernel (EMM alloc'ed memory), very special use.</LI>
<LI>runadr=0x00100000 : you can modify the default run address, this will only work with a kernel specially modified. If this field is zero, use value of loadadr.</LI> <LI>paramadr=0x00080000 : you can modify the default address to load the Linux parameters, or completely disable the probing (and relocation) by setting it to zero (do not do that now). Since 2.4.1, exactly 2.4.0-test3-pre3, this address is configurable in Linux, if a vmlinuz file before 2.4.0 (included) is loaded, this address defaults to 0x90000 - else to 0x80000. This address has to be in real mode addressable area (below 0x100000), and if it is exactly 0x90000 (the default for 2.2- kernels), a reset of the PIC is generated before running the kernel. No check is currently done on this value, so keep it quite high (DOS bootloader may be loaded quite high), the theoretical minimum value for the tiny BIOS bootloader is 0xBC00 (base) + 30 K (code) + 64K (stack) = 0x25000</LI> <LI>realfct_size=0x001234 : number of bytes of the realmode function to be copied and executed by the bootloader in real mode for the kernel to get information from the BIOS.</LI>
<LI>minram=0x00001000 : Minimum number of kilobytes of RAM (hexadecimal only) to have to be able to start the kernel. The default is zero, but anyway another error is generated if the uncompressed kernel does not fit in memory. It is the amount of contiguous memory available at 0x100000, i.e. 15 Mbytes if there is a hole at 16 Mbytes. 
<LI>min_gujin_version=0x0100 : Refuse to load this kernel if the version of Gujin is too low, strictly below the given number - in this case 1.0.</LI> <LI>option=0x00000000 : The options of this kernel file, none by default. This is only taken into account when the setup screen has "ignore kernel IDE options" unchecked, else this field is zero-ed unconditionally. Only those bits are currently defined: If bit 0 is set, say that this "kernel" file wants the IDE system (hard disks) without the maximum LBA set. It has only to be done when this "kernel" is a safe and standalone IDE aware partition manager. See BEER in ATA T13 D1367. If bit 1 is set, say that this "kernel" file wants the IDE system (hard disks) without the disk size set. It has only to be done when this "kernel" is a safe and standalone IDE aware partition manager. See BEER in ATA T13 D1367. If bit 2 is set, say that this "kernel" file wants the IDE system (hard disks) with unfrozen passwords - so that it can manage password itself. It has only to be done when this "kernel" is a trusted, safe and standalone IDE manager. If bit 3 is set, say that this "kernel" file wants the IDE system (hard disks) with unfrozen overlayed config - so that it can manage this itself. It has only to be done when this "kernel" is a trusted, safe and standalone IDE manager. If bit 4 is set, say that this "kernel" file wants the IDE system (hard disks) with Host Protected Area unfrozen. If bit 5 is set, say that this "kernel" file wants the IDE system (hard disks) with Host Protected Area unlocked. If bit 6 is set, say that this "kernel" file does not want the password for HPA (HPA only password) to be set to the name of the disk in the BEER sector, or to all zero if no BEER detected. It has then to be set another way if Gujin has to lock or freeze the HPA. 
If bit 7 is set, say that this "kernel" file wants the IDE system (hard disks) with hidden Host Protected Area (Is it useful?). If bit 8 is set, say that this "kernel" file wants the IDE system (hard disks) with unhidden password.
</LI>
<LI>maskcpu=0x80000007 : you can declare which microprocessors are not supported by this kernel (if bit (1 << [01234567]) set, 80[01234567]86 excluded - see the family from CPUID). Maskcpu is only taken into account when it is not null (so when it is present on the comment line). When family is 0x0F, the bit taken into account is (0xF + extra_family). Some extra bits are used here: 
if bit 31 is set, the kernel is made for BIOS IA32 systems, i.e. PCs. if bit 30 is set, the kernel cannot run from DOS/windows environment. if bit 29 is set, the kernel cannot run from DOS/windows with EMM386 environment. </LI>
<LI>maskDflags=0x00000000 : Which bit have to be set in cpuid 0x00000001, in edx, for instance "maskDflags=0x00000010" if kernel requires the TSC capability.</LI> <LI>maskCflags=0x00000000 : Which bit have to be set in cpuid 0x00000001 in ecx.</LI> <LI>maskAflags=0x00000000 : Which bit have to be set in cpuid 0x80000001 (AMD processor only).</LI>
<LI>maskvesa=0x00000000 : (Only if the loader isn't tiny.exe/tiny.img) if bit ([8] - 1) set, VESA [8]BPP supported; if bit 16 set, able to boot in text mode; if bit 17 set, able to boot in VESA1 mode; if bit 18 set, able to boot in VESA2 linear mode; if bit 19 set, will switch to VESA1 if in VESA2 modes; if bit 20 set, UNable to boot in VGA graphic modes. </LI>
<LI>maskresolution=0x00000000 : (Only if the loader isn't tiny.exe/tiny.img) if bit set, this resolution (see vmlinuz.h) is supported.</LI> Few other strings are recognised, but they are only needed if the kernel will access the data area of Gujin - i.e. if you want to build a special "my_application.kgz" to do low level stuff: special partitioning software, hardware memory checker, partition backups... without having to load an operating system, but still using graphic video modes, disks and mouse. These future applications will be linked to Gujin in its GPL meaning. </UL>

<HR WIDTH="10%">
<DT><a name="disk_sign">Meaning of the letter in parenthesis after disk names in the startup screen?</a> <DD>
If you do not have parenthesis, the disk cannot do anything special, at least with this interface. 
If you have a star, like this:
disk 1: EBIOS 0x80, size 40000 Mb (*), 4 partitions. Then the disk contains a B.E.E.R. sector, see: http://www.t13.org/project/d1367r3.pdf ; Gujin uses some data in this sector (shall be mapped in the last 4 Kbytes, i.e. the last 8 sectors of the disk). It uses the "Host Protected Area" and the "reported.sectorperdevice" fields. FIXME: to be described when I understand every bits of it. 
Note that setting the "Host Protected Area" may create a difference in between resetting by control-alt-del, by the reset button and by a real power off. Note also that on a BIOS only PC (no EBIOS), you will probably not be able to read this sector at end of the device... If you have letters (IDE interface only): <UL>
<LI>H: the disk support the "Host Protected Area".</LI> <LI>P: the disk support the "password".</LI> <LI>C: the disk support the "config overlay".</LI> <LI>R: the disk support the "removeable".</LI> <LI>B: the disk support the "SAORAB".</LI> </UL>

<HR WIDTH="10%">
<DT><a name="cdrom_boot">Can Gujin boot El-torito CDROMs? Can Gujin be installed on a CDROM to boot from it?</a> <DD>
Yes and Yes. Gujin will detect if the CDROM/DVD is bootable (i.e. it has an El-torito signature) and display it in the menu like any other way to boot the system. Gujin installer (instboot) is also able to generate the El-torito signature to create a bootable CDROM. Note that Gujin can only detect ATAPI CDROM drives (most of them), so it will not display SCSI connected CDROMs. Note also that CDROM probing can be disabled in the menu because it can take few seconds (slow device). There is multiple ways to generate a bootable CDROM, you have to decide which disk to emulate and how long you want to emulate it. 
You can choose to emulate a standard floppy (1.2 Mb, 1.44Mb or 2.88Mb), a standard hard disk having 512 bytes per sector or a special hard disk of 2048 bytes per sector. The choice is usually depending on what you plan to put on the emulated drive: you can put a bootloader only (minimum choice for a bootable CDROM), and so search for kernel in the /BOOT directory of the ISO9660 filesystem (then you want to stop the drive emulation as soon as the bootloader is completely in memory - and use the smallest possible disk for emulation to not waste CDROM storage). If you want to add one or more kernel(s) and initrd(s) to t