FAQ Questions:

  • Please quickly describe Gujin.
  • Why should I use Gujin?
  • I just want to install, do you have a quick documentation?
  • How do I use a precompiled configuration in file standard.tar.gz?
  • What is the content of file standard.tar.gz?
  • How do I recompile from sources?
  • When I reboot my computer, I do not see anything changed, Gujin is not started.
  • When I reboot my computer, I see Gujin screen but the keboard and/or mouse are not working.
  • Gujin does not find my kernel files and/or my Linux partition! (partition types)
  • Which are the filesystem supported by Gujin?
  • 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."...
  • Do I still need LILO, loadlin, GRUB... when using Gujin?
  • My Hard Disks are detected two times.
  • Can I force re-probing the disk after initial boot.
  • Where is the configuration file?
  • What about my non-US keyboard mapping?
  • I do not like the font used, can I change it?
  • What should I know about languages?
  • Which kind of floppy can I use when I type "./gujin /dev/fd0"?
  • Can the test crash my hard drive?
  • Why all my disks are scanned at the start-up of Gujin?
  • Can Gujin load an initrd, can Gujin load an initramfs?
  • What is a *.BDI (Boot Device Image) file?
  • What is the difference in between *.BDI and *.ISO?
  • Can I create a set of floppy bootable images on a USB drive/CDROM?
  • Can I create a set of floppy bootable images on a FAT or E2/3/4FS partition?
  • 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?
  • Why, on this "old" PC, the root filesystem is only guessed on the IDE interface?
  • Sometimes I see my IDE master as BIOS 0x80, and sometimes as BIOS 0x81!
  • Can Gujin replace loadlin?
  • How to interpret Gujin's error code when loading the kernel/initrd?
  • How can I debug a problem in Gujin?
  • Is Gujin ready and stable enough for production?
  • How to use Gujin remotely on a colocation server?
  • What are letters between brackets at the top of the screen?
  • Why is there three commands to detect video modes, how to use them?
  • I have messages like "last partition over disk limit detected", what does it mean?
  • Does Gujin scan other PCI IDE ports?
  • What is the option "ignore kernel IDE options"?
  • Why the name Gujin ?
  • I have errors while Gujin loads, during this line:
    Gujin1, Gujin2....ERROR.
    or:
    Gujin1, Gujin2.......CHECKSUM ERROR.
    and it eventually loads after few tries.
  • How to quickly test a serial interface configuration (without a VT420)?
  • You said that I can boot a very large kernel - but I can not even get it to compile!
  • My Joystick does not work.
  • How to check/edit the command line of a kernel?
  • How to abort loading a Linux kernel, I have been too quick to press the wrong Fn key?
  • What is the "force root probing" option?
  • When does the root= parameter use the filesystem label, /dev/hda or /dev/sda?
  • I have messages like "Extended partition block not found at LBA = " on Gujin-0.6 or later.
  • Gujin report "SMART threshold exceeded condition" or "present and disabled!"?
  • 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...
  • Automatic running of a kernel after timeout do not work?
    Parameter (or list of VGA modes) not saved in between boots?
  • Can Gujin boot Windows95/98/Me on an extended partition or on a secondary drive?
  • 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?
  • My screen is automagically recognized under Windows but not under Gujin?
  • Which field are recognized by Gujin in the comment field of the GZIP kernel?
  • Meaning of the letter in parenthesis after disk names in the startup screen?
  • Can Gujin boot El-torito CDROMs? Can Gujin be installed on a CDROM to boot from it?
  • How do I boot from CDROM with a simulated floppy containing Gujin?
  • How do I boot from CDROM with a simulated hard disk containing Gujin?
  • I cannot achieve to boot any CDROM containing Gujin, unlike standard distribution CDROMs?
  • When does Gujin terminate the HD or floppy emulation by calling the CDROM BIOS?
  • How do I boot from CDROM in no-emulation mode with Gujin?
  • Can I use Gujin just to create a disk image of any size? Initialise a bootable USB thumb drive?
  • My IDE disk boots from the IDE interface but no more when enclosed in an IDE-USB external box?
  • Can I use Gujin to create a DVD-RAM disk?
  • What is your PGP signature?
  • Do you have a TODO list?

  • FAQ Answers:

    Please quickly describe Gujin.
    The Gujin description at freshmeat:
    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 or Grub, it can even load ELF kernel images. 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.
    Why should I use Gujin?
    Some of the reasons I think of:

    I just want to install, do you have a quick documentation?
    If you are runing a Debian or Fedora distribution (also tested on Ubuntu and Mandrive), just download the gujin.deb/.rpm corresponding to your environment (32 or 64 bits) and install it using the standard package manager: it will install the executable "/sbin/gujin", its man page in section 8, and install the bootloader on your first hard disk, using second stage "/boot/gujin.ebios".
    To remove Gujin, just uninstall the package, or type "/sbin/gujin --remove /boot/gujin.ebios" as root, or uninstall from the Gujin setup screen at boot time.
    The default installation method assumes that the second stage bootloader (/boot/gujin.ebios) is on a partition of the main disk and modify its MBR. If this file is located on a secondary disk, you may have to uninstall Gujin and then re-install adding parameter "--mbr-device=/dev/sda".
    If you do not want to use the package manager and your aim is to install Gujin on your floppy and/or hard disk, first download install.tar.gz and extract it in a directory; you will have the executable "install/gujin" which is the same for all 32 bits Linux, and also "install/gujin64" for 64 bits Linux PCs.
    Then start by reading the man page, and then the older install.txt.
    You can come back to this FAQ if you have a problem.
    You also have in install.tar.gz the file "cleandisk.kgz" which is a quick demo of a standalone program that Gujin can boot natively (compressed ELF32 file).
    You can also use the Ultimate Bootable CDROM:
    UBCD button
    How do I use a precompiled configuration in file standard.tar.gz?
  • Download the file "standard-1.5.tar.gz", un-tar it "mkdir standard; cd standard; tar -xzf ../standard-1.5.tar.gz" or open it with winzip or winrar if you have another operating system.
  • Select the image/executable you want to try: begin with "full.img.gz"/"full.exe", you can play with others later.
  • Insert a clean 1.44Mb floppy on your drive, the data on this floppy will be erased (no bad sectors).
  • Do "zcat full.img.gz > /dev/fd0", or if you do not have "zcat", type "gunzip -c full.img.gz > /dev/fd0"
      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: http://www.chrysocome.net/rawwrite.
      If you do not like previous software, you can also try: floppyimage.
  • If you have DOS/Windows (excluding NT), you can now copy "full.exe" on the floppy, for instance "mcopy full.exe a:"
  • Reboot your computer keeping the floppy in place, you can after a short time play with the mouse.
  • If you have a DOS installation, boot its Master Boot Record to play with "A:\full.exe".
  • The other files you get in "standard.tar.gz" are described in this FAQ question.
  • 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 "./gujin 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 gujin.exe in previous directory, do "chmod a+r /var/lib/dosemu/freedos/gujin.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 "gujin.exe".
    See also "/etc/mtools.conf" (drive o: file="/var/lib/dosemu/floppyimage").
  • You can also use Gujin to debug "Bochs" (full.img being the virtual floppy), "Plex86" or "VMware"... if you want to.

    What is the content of file standard.tar.gz?
    Once decompressed, the file "standard.tar.gz" contains: 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...
    How do I recompile from sources?
  • Download gujin-2.8.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 UNICODE, of serial terminal like VT420...).
    It is better to use gcc-4.4.3/gmp-5.0.0/mpfr-2.4.2/binutils-2.20 bootstrapped manually by "make toolchain".
  • create a directory structure like this: projet/
    projet/gujin-2.8.tar.gz
    projet/binutils-*.tar.bz2 (if you want to rebuild it)
    projet/gcc-core-*.tar.bz2 (if you want to rebuild it)
    projet/gmp-*.tar.bz2 (if you want to rebuild gcc after version 4.3)
    projet/mpfr-*.tar.bz2 (if you want to rebuild gcc after version 4.3)
    projet/ppl-*.tar.bz2 (if you want to rebuild gcc after version 4.4)
    projet/cloog-ppl-*.tar.gz (if you want to rebuild gcc after version 4.4)
  • Go in "projet" directory and type "tar -xzf gujin-2.8.tar.gz" which creates the "projet/gujin" directory, go in it.
  • Type "make" without parameter, this recreate the full gujin executable with internal images. If you type "make debian" it will recreate the .deb packages, "make fedora" will recreate the .rpm.
  • 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.
  • Now, you can type things like: "./gujin /dev/fd0" or "./gujin gujin.exe" or "./gujin -t mingujin.exe" or "./gujin /dev/fd0.com1"...
    and you can then reboot your computer.
  • You can also type "make standard.tar.gz" or "make install.tar.gz" to re-produce the precompiled file.
  • 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.

  • When I reboot my computer, I do not see anything changed, Gujin is not started.
    Check that you have selected "floppy before hard drive" in the boot order in your BIOS set-up.
    When I reboot my computer, I see Gujin screen but the keboard and/or mouse are not working.
    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).
    Gujin does not find my kernel files and/or my Linux partition! (partition types)
    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.
    Which are the filesystem supported by Gujin?
    Gujin supports FAT12, FAT16, FAT32, ISO9660, EXT2/EXT3FS and EXT4FS with constant inode size 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.
    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."...
    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.
    Do I still need LILO, loadlin, GRUB... when using Gujin?
    No, Gujin is not only a boot loader but also a Linux system loader; you can load system files (vmlinuz) of unlimited size (well, below the size of your physical memory), and even ELF kernel under some conditions.
    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.
    My Hard Disks are detected two times.
    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).
    Can I force re-probing the disk after initial boot.
    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.

    Where is the configuration file?
    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 and holding "Alternate"; 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.
    What about my non-US keyboard mapping?
    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:
    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).
    I do not like the font used, can I change it?
    Yes, but you need to recompile. Gujin is designed to handle only fixed font size, with at least 8x8, 8x14 and 8x16 resolution for text modes.
    The graphic subsystem (VESA graphic) will use a bigger definitions like 10x20 if the screen heigh is over 768 lines, but still only fixed size.
    Gujin's internal representation is a big array of char or short, initialised like (see font.c):
        ['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 (_,_,_,_,_,_,_,_),
    	},
    
    The source for the 8x8 and 8x14 font has been written manually (for the lack of valid ANSI font) and do not handle chars over 256, so the screen will be full of '?' when in Russian language.
    The source for the 8x16 font (used in most video modes) is the Internet file unifont-5.1.20080820.hex, see http://www.unifont.org/, and thanks to Roman Czyborra, see also: http://en.wikipedia.org/wiki/Free_software_Unicode_typefaces
    If you want to regenerate that part, type "make fnthex2h" and execute:
    ./fnthex2h -m=0x500 -g=0x200 -l=0x200 unifont-5.1.20080820.hex unifont.h
    Then insert that unmodified file after comment "// start unifont-5.1.20080820.hex" and before "// end unifont-5.1.20080820.hex" in Gujin file "font.c".
    The source of the 10x20 font used in VESA video modes with more than 768 lines is the X-window font 10x20.bdf, the UNICODE one, see "http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html"
    Extract that file from "http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz", and convert it to an hex file for instance by using gbdfed-1.5.tbz2 (http://www.math.nmsu.edu/~mleisher/Software/gbdfed/), untar and compile, for me I had to rename all getline() into Getline() to get it compiled, run it and load the font 10x20.bdf and export as 10x20.hex; then execute:
    ./fnthex2h -w=10 -h=20 -m=0x500 -g=0x200 -l=0x200 10x20.hex 10x20.h
    Then insert that unmodified file after comment "// start ucs-fonts-10x20.hex" and before "// end ucs-fonts-10x20.hex" in Gujin file "font.c".
    The font is stored in the extra data segment in Gujin executable so there is some spare space, but there is no need for some chars so we skip 0x200 chars at 0x200 as parameters "-g=0x200 -l=0x200" describes.

    What should I know about languages?
    You can switch almost at any time in between the supported languages (English, French, Russian, Spanish, Italian, Portugese, German, Dutch) by typing Contrl-T (forward) or Alt-T (backward), and can save the language you want if Gujin is allowed to write to disks.
    For DOS modes (mingujin.exe and gujin.exe), the default language can be set by the environment variable "lang" or "LANG", i.e. type "set LANG=fr" before gujin.exe to get French.
    You can set the default language at installation by "./gujin --lang=xx".
    Abreviation supported are: "lang=en", "lang=fr", "lang=ru", "lang=sp", "lang=it", "lang=pt", "lang=de", "lang=nl", and should not be in capital letters.
    French and English should be used as reference because the other languages have been through automatic translators so are probably really bad translations.
    The language is written on the Linux command line if it is known.

    Which kind of floppy can I use when I type "./gujin /dev/fd0"?
    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: ./gujin --fs=FAT:2880,4,1,1,1 /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:
    $ ./gujin /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
    
    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.
    Can the test crash my hard drive?
    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.
    Why all my disks are scanned at the start-up of Gujin?
    Gujin is looking for all files named "vmlinuz*", "bzImage*", "linux*" 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" (or since v2.8.2 "install.386", "install.amd", "isolinux", "casper" or "live" - but for DOS interface) - 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.

    Can Gujin load an initrd, can Gujin load an initramfs?
    Yes, and yes, it will load the file "initrd*" if it exist in the same disk, partition and directory as the file "vmlinuz*"/"bzImage*"/"linux*"/"*.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*"/"linux*" 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 ./gujin 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:
    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
    

    What is a *.BDI (Boot Device Image) file?
    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"/"*.BIN", but these extensions are 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.
    Since Gujin-2.8, files with extension "*.IMG"/"*.BIN" are recognised as BDI files if they have the 0xAA55 signature at offset 510, so for instance the file memtest+.bin present on some distributions in /boot is directly bootable.
    You can get those files by doing "cat /dev/fd0 > floppy.bdi" or by renaming Gujin files: "./gujin --full 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 size of of emulated disk is the one described in the MBR, it may be bigger than the size of the real file and any unmapped sectors returns nulls bytes.
    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 3 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).
    Since Gujin v2.8, the BDI file do not need to be contiguous, and can even contain holes (will be read as zero and produce a "sector not found" error when written in unmapped sectors).
    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 then 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".
    What is the difference in between *.BDI and *.ISO?
    Gujin scans files with extension *.BDI and *.ISO but treat them completely differently.
    The *.BDI will generate a disk simulation with their content so most real mode application (DOS, other bootloaders ...) will work without noticing there isn't a real disk there.
    The *.ISO is treated like a disk in a partition: no BIOS simulation will be provided.
    Gujin will just scan those *.ISO files to try to detect kernel or *.kgz files on one of the filesystem it can analyse (FAT*, EXT*FS, ISO9660), in the root or in /boot directory.
    If kernel/kgz can be found in those directories, entries in the menu will be displayed.
    Then it will load the kernel found and provide the "fromiso=" cheatcode to tell the kernel it has been loaded from an ISO file - so the linux distribution has to support "fromiso" (at least "sidux" do).
    Gujin will not scan El-Torito boot system from the *.ISO file because it can not use it.
    Gujin can handle *.ISO file with filesystem holes, but a BIOS disk write in a hole will return an error.
    Gujin will not search *.ISO files inside *.ISO, but using *.BDI files inside *.ISO may work.
    Probing ISO files can be disabled in the Gujin menu, if enabled the full gujin.exe can select them.
    There is a limit to the length of the *.ISO filename + length of kernel/initrd/compressed ELF filename, try to be reasonable in the length of each: you should see the complete name of the ISO in the menu, before the semicolon (64 chars for iso filename, including "/boot/"), and there should not be spaces in this filename.
    There is a compile time maximum of 15 *.ISO per partition.
    It should be possible to put the tiny Gujin BIOS bootloader on a USB key with a FAT filesystem, and copy an ISO file in the filesystem to autoload the linux distribution but keep the unused size as available for general use. The FAT filesystem cannot deal with files of more than 4 Gb.
    Update for Gujin-v2.8+ : ISO files are tested if they have a 0xAA55 signature at offset 510, some ISO can directly be booted if they are copied on a USB drive - and then ISO are treated also as BDI files.
    Can I create a set of floppy bootable images on a USB drive/CDROM?
    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.
    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 -s".
    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, you can also run single floppy Linux distributions like those:
    http://chris.silmor.de/hal91/hal91.img
    http://www.giannone.eu/rescue/0.4.1/rescue-0.4.1.img
    http://www.ibiblio.org/pub/Linux/system/recovery/tomsrtbt-2.0.103.ElTorito.288.img.bz2 (unzip and rename to shorter name)
    )
    (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_files=0 --search_subdir_files=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
    ./gujin /tmp/cdrom/gujin.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
    ./gujin /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
    ./gujin /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
    ./gujin /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
    mkisoimage -R -no-emul-boot -boot-load-size 4 -b gujin.bcd /tmp/cdrom | cdrecord -tao -
    
    
    Note that if you want to just create a DOS filesystem on a CDROM, you can type:
    ./gujin /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...
    # UPDATE: you can use -o offset= for VFAT mount, offset in byte: 32 * 512 = 16384
    # ./gujin /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/disk/
    
    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.
    If you want to try a 512 bytes/sector FAT16 filesystem to write on a CDROM, you have to take care that the FAT starts on a sector boundary, so the last ",4" of --fs and that data blocks start on a sector boundary (NRS 14->16):
    ./gujin ~/tmpcd640M.iso --full -d=EBIOS:0x80,auto --geometry=1179648,0,16,32,512 --fs=FAT:1179648,32,16,4
    For a FAT32, use (reserved area before FAT is always 32):
    ./gujin ~/tmpcd640M.iso --full -d=EBIOS:0x80,auto --geometry=1179648,0,16,32,512 --fs=FAT:1179648,8,0,32
    To have a partition table you need the "--mbr --partition_index=1" parameter:
    ./gujin ~/tmpcd640Mmbr.iso --full -d=EBIOS:0x80,auto --geometry=1179648,0,16,32,512 --fs=FAT:1179616,8,0,32 --partition_index=1 --mbr
    and mount the partition of this last CDROM image (seen with "/sbin/fdisk -l ~/tmpcd640Mmbr.iso") by:
    mount -t vfat -o loop,offset=$((32*512)) /home/etienne/tmpcd640Mmbr.iso /mnt/
    BUT having a partition table in 512 bytes/sector on a 2048 bytes/sector medium is not going to work, and you get dbgdisk.exe displaying: "Ignoring partition 0x20+0x11FFE0, end disk at 0x48002". (TODO: instboot --partition_sector_size=2048)
    Commands to try on a USB in /dev/sdg (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 "./gujin" to answer "yes" to the creation of the filesystem on the USB device, unless you are using the "--force" argument to ./gujin.
    # IF YOU HAVE A SUDO distribution, type first:
    sudo su
    export TARGET_DEV="/dev/sdg"
    # 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_files=0 --search_subdir_files=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:
    #./gujin $TARGET_DEV --disk=BIOS:0x00,auto $USB_BDI_SETUP --search_part_mbr=0 --stop_emulation=0 --mbr-device=$TARGET_DEV --partition_index=1
    ./gujin $TARGET_DEV --disk=BIOS:0x00,auto $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
    ./gujin /mnt/usbdisk/boot/boot_disk.bdi      --disk=BIOS:0x00,auto --geometry=floppy:320 $USB_BDI_SETUP  --search_part_mbr=1 --stop_emulation=1 --full --bootdir=boot_disk
    ./gujin /mnt/usbdisk/boot/boot_partition.bdi --disk=BIOS:0x00,auto --geometry=floppy:320 $USB_BDI_SETUP  --search_part_mbr=1 --stop_emulation=1 --full --bootdir=boot_partition
    ./gujin /mnt/usbdisk/boot/boot_flash.bdi     --disk=BIOS:0x00,auto --geometry=floppy:320 $USB_BDI_SETUP  --search_part_mbr=1 --stop_emulation=1 --full --bootdir=boot_flash
    cp /boot/msdos.bin /mnt/usbdisk/boot_partition/partition.bdi
    cp /boot/msdos6.bin /mnt/usbdisk/boot_partition/msdos6.bdi
    cp /boot/memtest86+-1.55.1 /mnt/usbdisk/boot_flash/flash.bdi
    cp /boot/gm668.bin /mnt/usbdisk/boot_disk/disk.bdi
    umount /mnt/usbdisk
    
    If this USB key cannot boot, you can run some tests (on a test key, backup data first):
    dd if=/dev/zero of=/dev/sdg bs=512 count=64
    make clean dep myboot.bin CFLAGS=-DONLY_PRINT_GEOMETRY
    ./gujin myboot.bin /dev/sdg --disk=BIOS:0x00
    
    Such a floppy (if $TARGET_DEV == /dev/fd0) or USB drive (if $TARGET_DEV == /dev/sdg) shall display:
    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
    
    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 "INT13/02:, C/H/S: 000001" 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.
    Can I create a set of floppy bootable images on a FAT or E2/3/4FS partition?
    Since Gujin-2.8, *.BDI files no more need to be contiguous on disk, so you can simply add those files in the /boot directory and click on them to run them.
    Also, the 2.8 version recognises file *.BIN and *.IMG to be equivalent of *.BDI when they have a 0xAA55 signature, so most of the time you do not even need to rename them.
    If you do not want to see these bootable images all the time, you could put them in the /rescue directory - so then only when you modify the "parsed directory" in Gujin setup screen will you see those boot images.
    You can now have a (Gujin) bootable USB stick with all those HD rescue utilities in a convenient place.
    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?
    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,ext3 or ext4) first on current HD then on all HD - then it declares it as the root partition.

    Why, on this "old" PC, the root filesystem is only guessed on the IDE interface?
    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.
    Sometimes I see my IDE master as BIOS 0x80, and sometimes as BIOS 0x81!
    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.
    Can Gujin replace loadlin?
    When you type "make gujin.exe" (or "make gujin.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 "mingujin.exe", it is as simple as:
    mingujin A:\boot\kernel A:\boot\initrd root=/dev/hda3 ...other cmdline params...
    or:
    mingujin A:\boot\kernel initrd=A:\boot\initrd root=/dev/hda3 ...other cmdline params...
    or without initrd (note the minus sign):
    mingujin 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, "mingujin.exe /V" display a list of VESA2 video mode which can be set by "mingujin.exe /V=800x600x16 linux.kgz ...", not as complete as the real VESA support of "gujin.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 mingujin.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.
    How to interpret Gujin's error code when loading the kernel/initrd?
    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:
    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;
    
    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.
    How can I debug a problem in Gujin?
    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 gujin.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:
    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
    

    Is Gujin ready and stable enough for production?
    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".
    How to use Gujin remotely on a colocation server?
    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 COM1" 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.
    What are letters between brackets at the top of the screen?
    It defines the way the video memory is accessed:
    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.
    Why is there three commands to detect video modes, how to use them?
    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.
    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. 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.
    I have messages like "last partition over disk limit detected", what does it mean?
    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.

    Does Gujin scan other PCI IDE ports?
    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/PCI BIOS. 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: 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.
    Update: if PCI BIOS information is present (most/all PCs) Gujin will not probe random I/O address.
    What is the option "ignore kernel IDE options"?
    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 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.
    The difference in between that protection system and the keys of your new, shiny and powerfull car is that if you loose the key, you can still enter the car by breaking a window.
    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.
    To initialise the IDE password from Gujin, you type '{' letter to open (remove password) and '}' letter to close (set password) when the verbose checkbox is active, probing IDE is enabled and you are displaying the "setup" menu.
    A user password of exactly "MASTER PASSWORD" will enable you to enter the master password.
    The level is alsways set to "high" (and not "max") so you will be able to unlock/remove password with the master password (not only erase the disk content with the master password). So first program a master password, then a user password, then power OFF the PC.
    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/USB disk/CDROM then.
    I have tested it with my SEAGATE, WESTERN DIGITAL and IBM hard drives, it may work for you. My SATA drives and my OCZ SSD drive work too.
    For more information and utilities about IDE disks, have a look at MHDD site and the associated forums.
    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.
    Your BIOS may already freeze the disk password subsystem (of disk not currently locked) at power-on like my new AMI BIOS, in this case a (not really recomended) solution to initialise the passwords is to unplug and replug the power plug of the hard disk after the PC has booted, inside Gujin, and type ^R to re-probe disks after exiting the Gujin setup screen.
    If the IDE disk is on the primary IDE at 0x1F0, you can also boot with the disk unplugged and once in Gujin, plug-in the disk, but most BIOS will hide I/O ports of IDE interfaces without any disk connected (usually the first IDE is kept).
    You may be able to set these passwords under Linux with hdparm, but that will involve to at least reset the hard disk (which shall be unused and alone in the master/slave interface, even for SATA) or use hot plugging.
    Officially the password system shall only be reverted to non-frozen by a power-off.
    I also used "hdparm -K 0 /dev/sdc" (capital K) to clear "keep features over reset", I am not sure if it is needed or not, and if that flag is valid for next boot only.
    Note that there is a strange problem with my AMI BIOS and my OCZ SSD, when a password is active the AMI BIOS wait a long time and then display "hardware disk error, press F1 to continue", obviously only if the BIOS is not set to display its graphic image telling how great AMI BIOS are (else you do not see anything). That is not a real problem, as long as you know to press F1, Gujin will work correctly one you have given the password - or else (no/invalid password) ignore the disk.
    This AMI BIOS react the same way if a hard disk is set to power-up in standby.
    If the "ignore kernel IDE options" box is unchecked, it will rely on the "option" GZIP comment of the *.kgz file.
    Why the name Gujin ?
    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!
    I have errors while Gujin loads, during this line:
    Gujin1, Gujin2....ERROR.
    or:
    Gujin1, Gujin2.......CHECKSUM ERROR.
    and it eventually loads after few tries.
    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:
    cat /dev/fd0 > /dev/null
    
    You will probably get something like:
    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
    
    Note also that you will get this kind of error on (for instance) a USB thumb drive if you tried to install Gujin whilst the partition is mounted: at umount time some data is written to the device to say the partition has been cleanly unmounted; but the partition is no more there, that random write corrupts Gujin. There is/was a protection in the Gujin installer, because ./gujin open the device in exclusive mode - so an error is reported if the mounted partition is mounted manually - but that no more works with current automount'ers.
    How to quickly test a serial interface configuration (without a VT420)?
    First, you need a twisted serial cable (fully wired null modem from the local shop).
    Install Gujin on a floppy with "make /dev/fd0.com1" or "./gujin /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, without hardware (CTS/RTS) flow control (because else you can't send keypressed to Gujin).
    I also had success using PuTTY (Backspace sends ^H) and GtkTerm (you have to be able to read/write /dev/ttyS0), but sending UTF-8 is still not written.
    Power up the PC with the Gujin floppy/USB stick.
    If you want to, you can use the mouse - but only the one of the Gujin's PC! Use Crontol-A and Control-E for resp. Home and End key.
    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).
    You said that I can boot a very large kernel - but I can not even get it to compile!
    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:
    	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
    
    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".
    My Joystick does not work.
    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).
    How to check/edit the command line of a kernel?
    If you select the kernel to boot while the shift key is pressed (i.e. Shift-F1 or Shift mouse selection) you are presented with few informations about where the kernel will be loaded in memory, and the (editable) kernel command line that will be used. Unfortunately you cannot save that command line if you modify it, it will just be used for the following boot - nothing more.
    How to abort loading a Linux kernel, I have been too quick to press the wrong Fn key?
    You can abort loading/running a kernel by pressing Control-Break.
    What is the "force root probing" option?
    You should uncheck it only if those two are true: 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.
    When does the root= parameter use the filesystem label, /dev/hda or /dev/sda?
    If the filesystem has a label (EXT2/3/4FS, DOSFS, ISOFS label), then that name is used for parameter "root=LABEL=" if it does not contain spaces and "root=no-label" is not given.
    You can force the use of "sd" drives by giving the parameter "root=/dev/sd*" (with the star), and force the use of "hd" drives by giving the parameter "root=/dev/hd*" on the command line in setup, by default from Gujin-2.3 drives with "sd" names are used.
    I have messages like "Extended partition block not found at LBA = " on Gujin-0.6 or later.
    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 ??/??!
    Gujin report "SMART threshold exceeded condition" or "present and disabled!"?
    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.
    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...
    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.
    Automatic running of a kernel after timeout do not work?
    Parameter (or list of VGA modes) not saved in between boots?
    Do not forget to "enable disk write", else absolutely nothing is written to disks, not even the configuration.
    Can Gujin boot Windows95/98/Me on an extended partition or on a secondary drive?
    There should not be any problem to boot those, but you have to take care of some Windows restrictions:
    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?
    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.
    My screen is automagically recognised under Windows but not under Gujin?
    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...
    Which field are recognised by Gujin in the comment field of the GZIP kernel?
    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 mingujin.exe/mingujin.img:

    Meaning of the letter in parenthesis after disk names in the startup screen?
    If you do not have parenthesis, the disk cannot do anything special, at least with this interface. If you have "(failconf)" at the end of the disk line, reading the IDE disk configuration has failed so capabilities and/or disk length may already have been reduced when Gujin is run.
    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.
    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):
    Can Gujin boot El-torito CDROMs? Can Gujin be installed on a CDROM to boot from it?
    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 (./gujin) 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, and you may have to adjust BIOS/EBIOS support of this simulated floppy, and its disk number.
    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 the emulated disk, you will need a bigger floppy disk or maybe even an emulated hard disk - and you want the bootloader to probe its FAT content: you need the emulation to be stopped after loading the kernel and initrd but before calling the real-mode function of the kernel which probes the BIOS information.
    If you want to have a complete operating system like FreeDos you probably want a hard disk and a permanent emulation.
    Depending on the motherboard BIOS, some of those emulations may not work as they should. Gujin itself can boot all of them as described. It has even some more functionalities:

    How do I boot from CDROM with a simulated floppy containing Gujin?
    You should have the cdrecord/wodim and mkisofs/genisofs/mkisoimage packages installed for this task.
    You need to decide which floppy size you want to simulate: Bootable CDROM are defined to contain either 1.2 Mbytes, 1.44 Mbytes or 2.88 Mbytes floppy image (or a Hard Disk image - see next question); 360 Kbytes, 720 Kbytes or 1.68 Mbytes are not accepted.
    You get the "./gujin" executable and type:
    ./gujin boot.288 --full
    mkdir /tmp/cdrom
    cp boot.288 /tmp/cdrom
    mkisoimage -R -b boot.288 /tmp/cdrom | cdrecord -v dev=ATAPI:0,0 -
    rm -rf /tmp/cdrom
    Double check that mkisoimage did correctly recognised the simulated boot floppy boot.288 using its size, it shall display: "Size of boot image is 5760 sectors -> Emulating a 2880 kB floppy". Note also that the cdrecord command line finishes by a minus...
    I used the current directory "/tmp/cdrom" as a directory to copy on the ISO9660 filesystem of the CDROM, you can use anything.
    If you would like to put a kernel on the simulated floppy, you will have to use either the mtools package: see /etc/mtools.conf, for instance add a line like:
    drive b: file="/home/etienne/projet/gujin/boot.288" exclusive
    Then (if you used the right path!) you can do:
    $ mdir b:
     Volume in drive B is EL-BOOT-V09
     Volume Serial Number is 3939-4C45
    Directory for B:/
     
    No files
                              2 779 136 bytes free
    $ mcopy /boot/vmlinuz-2.4.20-8  b:
    $ mcopy /boot/initrd-2.4.20-8.img b:
    $ mdir b:
     Volume in drive B is EL-BOOT-V09
     Volume Serial Number is 3939-4C45
    Directory for B:/
     
    VMLINU~1 20-   1117254 10-24-2003  18:57  vmlinuz-2.4.20-8
    INITRD~1 IMG    147277 10-24-2003  18:58  initrd-2.4.20-8.img
            2 files           1 264 531 bytes
                              1 513 472 bytes free
    
    Then you redo the "cp boot.288 /tmp/cdrom" and the following commands
    If you do not have (or do not want to use) the mtools package, but can gain root access to mount loop devices, just type as root:
    $ mount boot.288 /mnt/floppy -t vfat -o loop
    and you can add/remove/list files in /mnt/floppy. Do not forget to "umount /mnt/floppy" before using file "boot.288" in "cp boot.288 /tmp/cdrom".
    You can now reboot a PC with this CDROM inserted (and the correct boot order on the PC BIOS).
    You can also read the target "CD120FD", "CD144FD" and "CD288FD", and also "CD288FD-late" in Makefile.
    You still have to take care of the --disk=BIOS:0x80,auto parameter if your PC do not handle BIOS or EBIOS for the CDROM floppy emulation, or do not pass the boot drive number in the DX register, the default work on my PC.
    You can use the "-t" option of ./gujin to automatically load a kernel/initrd or *.kgz file without going through the menu, see also Makefile target CDtiny.
    You can use multisession and have a boot image per session, see target CDallEmul.

    How do I boot from CDROM with a simulated hard disk containing Gujin?
    Well, the simplest is to ask the boot installer to create a disk image and not a partition image, just by typing:
    # You can add -w or --verbose parameter to the following line:
    ./gujin ../cd --full --mbr -d=BIOS:0x80,auto --geometry=1032129,63,16,63,512,1032192,0
    You can then check:
    /sbin/fdisk -b 512 -S 63 -H 16 -C 1024 ../cd -lu
     
    Disk ../cd: 0 MB, 0 bytes
    16 heads, 63 sectors/track, 1024 cylinders, total 0 sectors
    Units = sectors of 1 * 512 = 512 bytes
     
    Device Boot    Start       End    Blocks   Id  System
    ../cd1   *        63   1032191    516064+   6  FAT16
    
    Note that giving the option "-d=EBIOS:0x80" would change partition type to 0x0E, i.e. "Win95 FAT16 (LBA)" and use extended BIOS to load Gujin at startup, some PC may only handle EBIOS, or use disk number 0 at boot (use -b=EBIOS:0x80,0x00).
    Note also that the start of a partition (2nd parameter of --geometry) shall be a multiple of the sectors/track (4th parameter) and the partition size (1st parameter) plus its start (2nd parameter) shall be below (or better equal to) the disk size (6th parameter).
    It is better to keep the end of the partition on a cylinder boundary, so if only one partition, its end (1st parameter) is (cylinders * heads * sectors/track - start).
    Keep the disk start (7th param) at 0, and the sector size (5th param) to 512 for now...
    If you want to increase/decrease the simulated disk size, change the disk size (the last non null parameter of --geometry) keeping it a multiple of 16 * 63 - in my example I had hard_disk_size = 1024*16*63 = 1032192.
    For instance, we can generate a 16 Mbytes hard disk like this: 16 * 1024 * 1024 bytes organised in 512 bytes sectors means 32768 sectors - 16 heads and 63 sectors per track means 32 cylinders (rounded down because your FLASH hard drive has this maximum). So the nearest "simple" disk size is 32 * 16 * 63 = 32256 sectors.
    Having a start sector multiple of sectors per track means its minimum is 63, so the total size of partition is: 32256 - 63 = 32193. So:
    ./gujin ../cd16Mb --full --mbr -d=BIOS:0x80 --geometry=32193,63,16,63,512,32256,0
    Note that this example leads to a FAT12 and 4 Kb/cluster (8 Sectors/Cluster) (option --verbose or -w), you could change it if you do not like it by "--fs=FAT:32193,4" so force FAT16 2 Kb/block.
    If you want to add files to your simulated hard drive, you just need the mtools package: add a line like:
    drive m: file="/home/etienne/projet/cd" offset=32256
    to you /etc/mtools.conf (note that 63 * 512 = 32256) and use mcopy, mdir...
    WARNING: This is the image of a complete Hard Drive - if you copy that to your Hard Drive using "cp ../cd /dev/hda" you will LOOSE all the data of your hard drive!
    Note that only the first partition is created - if you need the 4th partition, use fdisk.
    # Then write it on the CDRW:
    cdrecord -v dev=ATAPI:0,0 blank=fast
    mkdir /tmp/cdrom
    ln ../cd /tmp/cdrom/boot.hd	# or cp if the file is not too big for you.
    mkisoimage -R -hard-disk-boot -b boot.hd /tmp/cdrom | cdrecord dev=ATAPI:0,0 -
    # note that disk size is correct: "Size of boot image is 1032192 sectors -> Emulating a hard disk"
    rm -rf /tmp/cdrom
    
    In short, the difference between "--geometry=32705,0,16,63,512" and "--geometry=32705,63,16,63,512,32768,0" is that the partition is offseted in the output - so the former is the partition image and the later is the device image. The option "--mbr-device=" adds the bootloader to the device image, else only the partition is bootable: nothing is there to load the partition boot record from the device boot record - "fdisk /mbr" boot record loading the active partition boot record should work when no EBIOS is needed but I did not try it.
    You can also read the target "CDsmallHD", "CDsmallHD-late" and "CDbigHD" in Makefile.
    If you do not like the mtools, have rights to mount filesystems and directory /mnt/disk exists, you can type:
    mount -t vfat /home/etienne/projet/gujin/boot.hd /mnt/disk -o loop,offset=32256 -o umask=0
    

    I cannot achieve to boot any CDROM containing Gujin, unlike standard distribution CDROMs?
    Are you using an old CDROM drive, with a "speed" of x1, x2 x4 or even time 8 ?
    Those CDROM drives have difficulties reading writeable CDs, that is why standard distribution CDROMs are printed not written.
    Also sometimes newer read-only CDROM drives have problems reading R/W CDROMs.
    That is not a software problem, not even a BIOS problem - just get a newer CDROM drive.
    There is probably also some compatibility problems with CDROM in DVD readers - I am not a specialist in this area.
    When does Gujin terminate the HD or floppy emulation by calling the CDROM BIOS?
    If done too early, for instance at startup - before analysis of the BIOS disks, you cannot load a kernel file from this simulated HD or floppy because it has disappeared.
    If Gujin does not terminate this emulation, most versions of MS-Windows are seriously confused when simulating floppy because they think the PC has two physical floppy disks drives...
    Note that when this floppy emulation is terminated, the floppy drive letters are changed:
    If you have a PC with one and only one floppy, its BIOS disk number is 0x00. When starting the simulated floppy from CDROM, the simulated floppy gets number 0x00 (to be able to boot the PC) and your real floppy becomes 0x01; when the simulation is terminated the BIOS number are back to their initial value.
    Same for Hard Disk simulation: the simulated HD get the BIOS number 0x80 and change all the others by adding one to their BIOS number, and the Hard Disk BIOS number changes when simulation is stopped.
    If you have a PC with at least two physical floppy drives, it seems that usually the second one disappear while the CDROM floppy emulation is active. Normally the PC can have a maximum of 4 floppy drives (see _BIOS_equipment_flags(), floppy_present and nb_floppy_less_1 fields) but the limit has been reduced to two at DOS time.
    If you add USB floppy or FLASH hard disk -> USB adapter with a BIOS which maps those drives as floppy, I'll tell you what happen when you send me the PC... I need a new portable one.
    I did not found a logical way to solve all the possibilities, you can configure in the menu whether you do not want the BIOS to terminate the floppy emulation (for instance the simulated hard disk contains a read only DOS partition that you want to boot), whether you want to stop this emulation before Gujin analysis of the content of the disks (so choose early stop, the default) or after the user has chosen a partition to boot (so choose late stop). This emulation is never stopped when booting a kernel (vmlinuz, *.kgz ...) because the stop can be done manually when probing for BIOS parameters, and Linux does not care too much because it will not use BIOS services anyway.
    Because the emulated FD/HD on the CDROM is not writable, you use it by giving the parameter "--stop_emulation=<1> stop CDROM emulation 0:never, 1:early, 2:late" to ./gujin.
    What happens when you have two CDROM drives, each with a bootable CDROM in them, and you terminate the first floppy emulation on the first CDROM to restart the floppy emulation on the second CDROM by saying "the first BOOT attempt fails, find another boot device", is left as an exercise to the reader.

    How do I boot from CDROM in no-emulation mode with Gujin?
    If you have a way to load in memory a file and then start executing it, like a bootable CDROM in non emulation mode, you need "./gujin" to generate a Position Independent Code boot file. So:
    ./gujin boot.pic -w
    You can examine the content of this file with:
    objdump -m i8086 -b binary boot.pic -D | less
    or:
    objdump --start-address=0x204 -m i8086 -b binary boot.pic -D | less
    And you can write this file to the CDROM like:
    mkisoimage -R -no-emul-boot -b boot.pic /tmp/cdrom | cdrecord dev=ATAPI:0,0 -
    See also target CDnoemul of Makefile and its "gujin.bcd" semi-no-emulation system.
    The execution has to start a the first loaded byte, it will check itself it checksum and copy itself at its own address (relocation of 0 bytes) like files gujin.com/gujin.exe.
    The process to check the complete file checksum is done in the first 512 bytes sector in 80286 compatible code, so the maximum checksum size at a time is 64 Kbytes. That sets a minimum limit in how many dots are displayed on the first Gujin line. You can reduce the checksum calculus size for instance to 16 * 512 = 8 Kbytes by (2880 is not meaningful, head = 0 has the special meaning of max treatment size in sector/track):
    ./gujin /tmp/cdrom/boot.pic --geometry=2880,0,0,16,512 --disk=PIC -w
    That would enable you to know where happen the checksum error: if it happen always at the same place, maybe you BIOS did not load the file completely?
    The file boot.pic has to be loaded at a segment boundary (base address multiple of 16) in memory accessible in real mode (below 1 Mbyte) and has to be loaded in RAM (to manage its own variable and stack which follow the code segment). The file to load is quite big, bigger than the standard EEPROM of network cards so there is some work if you want to try.
    The file boot.pic is also usually too big to be renamed as "IO.SYS" and loaded by the standard DOS partition bootsector - see Makefile for more information on this.
    Can I use Gujin just to create a disk image of any size? Initialise a bootable USB thumb drive?
    No, you can only create a bootable disk image with a FAT16/32 filesystem of any size -:)
    ./gujin boot.144
    creates a image of the filesystem of a 1.44 Mb, so you can do:
    cat boot.144 > /dev/fd0
    For a 2.88 Mb floppy image (5760 sectors of 512 bytes, 2 heads, 36 sectors):
    ./gujin --full --disk=BIOS:0x0 --geometry=5760,0,2,36,512 boot.tst
    For a 16 Mbytes Hard Disk image without a partition scheme (like a 16 Mb floppy):
    ./gujin --full --disk=BIOS:0x80 --geometry=32256,0,16,63,512 boot.tst
    For a 16 Mbytes Hard Disk image with the first partition (starting at lba=63 and of size 32193) bootable, on a disk of 32256 sectors (i.e. C/H/S=32/16/63) of 512 bytes, and a bootable MBR:
    ./gujin --full --disk=EBIOS:0x80 --geometry=32193,63,16,63,512,32256,0 boot.tst --mbr-device=boot.tst --partition_index=1
    You may change the partition (if needed to) using --partition_index=[1-4] or simply fdisk (works on disk images with 16 heads 63 sectors/track with /sbin/fdisk -C 32 -H 16 -S 63 boot.tst), and generally mount this file in loop mode, or use mtools, to access it.
    Note that since Gujin-v1.6, --partition_index=[1-4] changes the default disk size (to partition start + partition size) and default disk start (to 0) so that the previous "--geometry=32193,63,16,63,512,32256,0" can be shorten to: "--geometry=32193,63,16,63".
    The "--partition_index=" parameter is new in version 1.1. Before version 1.0 included the partition table was generated only for files and not for devices. Now if the device is blank (i.e. the MBR does not have 0xAA55 signature) and "--partition_index=" is given with a value in between 1 and 4, the old partition table is erased and a new partition table containing only one partition is created. This is needed to initialise a bootable USB thumb drive from scratch. You need to type this to completely initialise a USB thumb drive with one FAT16 filesystem having this drive on /dev/sdg (change if needed):
    dd if=/dev/zero of=/dev/sdg bs=512 count=1
    ./gujin /dev/sdg --disk=BIOS:0x80 --mbr-device=/dev/sdg --partition_index=1
    The easiest way to check if it is working is to install DOSEMU and modify it configuration file /etc/dosemu/dosemu.conf to have an uncommented line like:
    $_hdimage = "/dev/sdg1 drives/*"
    The typing "xdosemu" will hopefully boot this thumb drive.
    To start Qemu with a simulated floppy, type something like: "qemu -fda /tmp/boot.144".
    You can check the partition table of this drive with "/sbin/fdisk -l /dev/sdg" and access its content by mounting "/dev/sdg1" or by using mtools (see file /etc/mtools.conf), and check the filesystem by "/sbin/fsck.vfat /dev/sdg1" as root.
    Some people (having USB-FDD message at boot) will better like the parameter --disk=BIOS:0x00.
    If you really want to save space on the floppy image, you can replace the file boot.bin by tinystd.bin: it will take 30 Kb instead of 130 Kbytes.

    My IDE disk boots from the IDE interface but no more when enclosed in an IDE-USB external box?
    You are using the BIOS interface to boot this hard drive, and not the Gujin IDE interface nor the EBIOS interface while your USB-BIOS does not provide this interface, aren't you?
    There is also some specific stuff with USB booting. For instance, the USB BIOS needs to know the geometry of the hard drive, to implement the old C/H/S BIOS behaviour - and that is independant of the fact that they implement or not the Extended BIOS interface.
    The USB<->IDE bridge is so bad it cannot forward correctly the ATA IDE_IDENTIFY_DEVICE or IDE_IDENTIFY_PACKET_DEVICE command and provide the result in a transparent manner.
    So the solution is to get the disk C/H/S description from the disk content itself, i.e. find a "partition boot record" (some people call that the Volume Boot Record), i.e. the first 512 bytes of a FAT initialised partition containning this data and few signatures. Basically it means searching the first sector containning the filled type "bootbefore_t" or "bootbefore_FAT32_t" described in Gujin/instboot.h.
    There was an alternative solution, considering that a floppy has this sector as its sector zero, and a hard disk has it (often) in the first sector of the first partition, to scan all the sectors of the disk in increasing order to find the signatures (0x29 and 0xAA55) and so deduce the probable geometry, then simulate the complete disk with this C/H/S.
    That would have nicely worked with Gujin which put the right information even in its Master Boot Record (the MBR follow the 0x29 mapping).
    There is a non obvious solution using an analysis of the partition table (the first partition start at sector/track boundary, and all partition finish at a (head*sector/track boundary), but the head cannot be deduced all the times (you could deduce 32 heads when there is only 16) without also using the start/end C/H/S fields of partitions in this table.
    That is not the solution they have chosen, they have chosen to simulate - when using USB-HDD - a floppy covering the first partition - and the first sector simulated (BIOS C/H/S = 0/0/1) is the first sector of the partition and _not_ the first sector of the disk. The BIOS disk interface can "forget" to give you the size of the disk, so I cannot tell if you can access more than the first partition with this USB BIOS disk simulation. Their solution imply that they are rewritting field NbHiddensector when accessing sector C/H/S=0/0/1 because else DOS will not work.
    This offset in the disk simulation will kill any bootloader loading sequence, even the Gujin partition-relative access, because this Gujin partition relative access needs the EBIOS interface - not available at least on my PC (it is quite difficult to relocate in C/H/S mode).
    What is worse is that BIOSes either do not implement USB-FDD or only use it if there isn't any partition defined - so even if you have a bootable floppy image on your USB hard drive, the drive is no more bootable as soon as you define the first new partition.
    There seems to be some BIOS which also demand an USB-ZIP interface under conditions I do not know, for those the first partition defined has to be the fourth one, so no way to have more than one partition on your USB Thumb drive or USB hard disk enclosure if you want to boot from it on those BIOSes. USB-ZIP is said to better like the number of heads forced to 16 and the number of sector/track forced to 32, you'll do that simpler in Gujin-v1.6 by new ./gujin options: --head=16 and --sectorpertrack=32.
    It is better to have a power of two as the number of sector per track, because then all partitions start at a multiple of 4 Kbytes or more - and hard disks or Flash devices usually have bigger than 512 bytes hardware sectors (to calculate Error Correction Codes) and simulate smaller (512 bytes) write access but have to calculate ECC on the complete hardware sector. The biggest possible value for sector/track is 63, so the biggest possible power of two value is 32, and shall be chosen as a default as often as possible (i.e. when the hardware do not impose anything else) to increase disk performances.
    I have added an option named "--usb_hdd" to ./gujin which, when used to generate a complete disk image on a USB Thumb drive, creates a modified Partition Boot Record (Volume boot record) removing 1 from the head (and so adjusting Cylinder) in the C/H/S to load Gujin2. The Partition Boot Record is not usually executed when Gujin is in the MBR of the disk, so an USB Thumb drive initialised to have a Gujin bootable partition starting at C/H/S=0/1/0 (this partition could cover the total size of the disk or a small FAT16 partition to be mounted later as /boot because it contains the kernel and initrd) will boot in FDD-USB *and* in USB-HDD mode (using the same loading chain but two different first stage).
    To initialise a single FAT partition covering the whole disk:
    dd if=/dev/zero of=/dev/sdg bs=512 count=1024 # Gujin never erases a valid partition table
    ./gujin /dev/sdg --disk=BIOS:0x0 --cmdline="" --mbr-device=/dev/sdg --usb_hdd
    
    You can add parameters --partition_index=4 and --single_sector_load and --disk=BIOS:0x0,auto if you need them.
    Adding --head=16 and --sectorpertrack=32 may also be a very good idea (partition created aligned on 4 Kbytes boundary).
    To have a small 64 Mbytes partition at the beginning of the disk, to be able to add partitions later, you would do:
    dd if=/dev/zero of=/dev/sdg bs=512 count=1024 # Gujin never erases a valid partition table
    ./gujin /dev/sdg --disk=BIOS:0x0 --geometry=131104,32,16,32,512,`cat /sys/block/sdg/size`,0 --cmdline="" --mbr-device=/dev/sdg --usb_hdd
    
    Note that it seems that the BIOS disk emulated is always 0x00, and a partition relative loading could be used if EBIOS is available. Note also 131104 = 256 cylinders * 16 heads * 32 sector/track + 32 partition_offset.
    I have got USB key booting with the two previous "./gujin" command line, but ran into one problem:
    The boot process of most (all?) distribution cannot accept to have /dev/sdg1 mounted as FAT16 on /boot, and the device /dev/sdg2 to use as EXT2 as root is not present (i.e. autodetected into local initrd) at the time it is needed (--cmdline="root=/dev/sdg2")...
    If you really need EXT2 partition, a dirty trick would be to create a single FAT partition, install Gujin *after* the filesystem with "--position=afterfs", note the free FAT size available, create an image of an EXT2 that would not overwrite Gujin2 at the end of the partition and overwrite the FAT filesystem with your EXT2 image, taking care of not overwriting (or doing a quick backup of) the partition PBR, first 512 bytes. It is needed because creating a B.E.E.R. partition may not work because the BIOS simulated disk may not be able to access more than the first partition...
    Note that "dd if=/dev/zero of=/dev/sdg bs=512 count=1024" *does not work* to erase the partition table if one of the partition is mounted, check with "xxd /dev/sdg | less", maybe temporarily disable auto-mounting on your desktop!

    Can I use Gujin to create a DVD-RAM disk?
    I do not know if that will work everywhere, but I get the total size on my DVD-RAM device by just:
    # cat /sys/block/sr0/size
    8946816
    
    The unit here is strangely 512 bytes/sectors, so I have 8946816*512/2048 = 2236704 sectors of 2048 bytes.
    Then I erase the beginning of the DVD-RAM by:
    # dd if=/dev/zero of=/dev/sr0 bs=2048 count=100
    
    Then I tried to have a reasonable partition table by using fdisk WITHOUT saving the result (create a new partition using defaults, do not type 'w', just quit by 'q')(switch unit to sectors else the "Blocks" field is in Kbytes):
    # /sbin/fdisk /dev/sr0
    Note: sector size is 2048 (not 512)
    Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
    Building a new DOS disklabel. Changes will remain in memory only,
    until you decide to write them. After that, of course, the previous
    content won't be recoverable.
    
    Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
    
    Command (m for help): n
    Command action
       e   extended
       p   primary partition (1-4)
    p
    Partition number (1-4): 1
    First cylinder (1-139, default 1):
    Using default value 1
    Last cylinder or +size or +sizeM or +sizeK (1-139, default 139):
    Using default value 139
    
    Command (m for help): u
    Changing display/entry units to sectors
    
    Command (m for help): p
    
    Disk /dev/sr0: 4580 MB, 4580769792 bytes
    255 heads, 63 sectors/track, 139 cylinders, total 2236704 sectors
    Units = sectors of 1 * 2048 = 2048 bytes
    
       Device Boot      Start         End      Blocks   Id  System
    /dev/sr0p1              63     2233034     4465944   83  Linux
    
    Command (m for help): q
    
    So I have the start of the first partition at 63 sectors, its end at 2233034 so its size is 2233034 - 63 = 2232971, on a device with 255 heads and 63 sectors/track; ./gujin -hg remind me the format of --geometry: "-g=partition size,partition start,head,sector/track,sectorsize,disk size,disk start"; so I type:
    # ./gujin /dev/cdrw --disk=BIOS:0x80 --geometry=2232971,63,255,63,2048,2236704,0 --cmdline="" --mbr --partition_index=1
    
    I had to double check /dev/sr0p1 was not automounted on my desktop...
    After waiting a bit, I can mount that partition like:
    # mount /dev/sr0 /mnt/disk -t vfat -o offset=129024 -o blocksize=2048
    
    note that the offset is exactly 63 * 2048, the start of the partition offset in bytes. On Linux, mounting directly /dev/sr0p1 is not possible.
    Then, I can just do:
    # ls -l /mnt/disk
    total 256
    -r-xr-xr-x 1 root root 172032 Mar 15  1999 boot-bio.sys
    # cp /boot/memtest86+.bin /mnt/disk
    # cp /boot/vmlinuz-2.6.31.12-174.2.19.fc12.i686.PAE /mnt/disk/vmlinuz
    # cp /boot/initramfs-2.6.31.12-174.2.19.fc12.i686.PAE.img /mnt/disk/initramfs
    # # ls -l /mnt/disk
    total 15688
    -r-xr-xr-x. 1 root root   329728 1999-03-15 12:34 boot-bio.sys
    -rwxr-xr-x. 1 root root 12136285 2010-02-20 12:11 initramfs
    -rwxr-xr-x. 1 root root   128796 2010-02-20 12:10 memtest86+.bin
    -rwxr-xr-x. 1 root root  3462272 2010-02-20 12:11 vmlinuz
    
    As I said, I do not know if that will work everywhere, but the rest is left as an exercise to the reader. It is easy to create a big floppy (i.e. no partition table) or install Gujin in a B.E.E.R. partition at the end of the DVD-RAM.
    Answer for the reader - for a 4580 MB floppy on a DVDRAM, just type:
    ./gujin /dev/cdrw --disk=BIOS:0x00 --geometry=2236704,0,255,63,2048 --cmdline=""
    

    What is your PGP signature?
    Well, grab you local keyserver, go and visit: subkeys.pgp.net:
    In short, Key Id: 2D3AF3EA
    Fingerprint = 2471 DF64 9DEE 41D4 C8DB 9667 E448 FF8C 2D3A F3EA
    Type "gpg --import" and cut & paste the following:
    -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: GnuPG v1.4.11 (GNU/Linux)
    
    mQGiBDoLHI4RBACfJqPVwlrq8tyoA0bH/fber7aXYs+dpRH1uucjOhi9zdMAcinA
    wDGlLTNbToAF/WwD1+fCQokXzWtbhm5NK4UT2MY0URjuGGJ9VX5EecxwHvx4zRSc
    E3jVpj2rtFWRjg6c6LNnyC6K/5qbDpfkxDTgKsc96IW7a9FuqyT0ObDijwCgkRHu
    QcKuG3hFivhYtJ+lSRKEniMD/2Ca548GlqOYVJYehEpXba4xbKTtNCS0YPnolnWi
    QC3B4bgz+ZbVKH/322dNDmBZ50EgebcZgWEiQFZqgQkFQM8wfnTIa5y+x4LgQO9s
    Ge4WRZUHnhTnymbaSM9vA4eLNRghlFO66JmcaxyexQRVtnzn+WXrsqH7cdl32N21
    X7XoBACdiyBesbxxq4jNTluG51E2M9qig4kwULV+Xxi6XMOvpy5Kf0Fk/IsXNGix
    xI+tajHWXMGo4QgEAP6rlC7qRj+0av22bTt3N/osH5QAZrCO2xZ+upAzx0axPtC9
    L1s9pbUZbC9714sOI3v3g+MGGNKhSeTR/8SBmjWCFSkgfN/IlbRCRXRpZW5uZSBM
    T1JSQUlOIChHdWppbiBjb3B5cmlnaHQgb3duZXIpIDxldGllbm5lX2xvcnJhaW5A
    eWFob28uZnI+iFcEExECABcFCwcKAwQDFQMCAxYCAQIXgAUCTzFypAAKCRDkSP+M
    LTrz6gHyAJ93y4l04DtbdBDifIgN4yzAoBTdUgCfVRZBbzhIGOXnERcfnP7ira8v
    WPS5AQ0EOgsc1hAEALTFQfw9EUIBzRCbaeRUxXAJuumAJzm79N958vBX6Qnf9CHL
    lQIvBAkApRdnDExR+HYRorXTp8QYTGAf8CFL+/M/SR4WJDzPPyOJwJn+wJUXt0Ch
    1AW6kjHlLCnpmtTKeeV4PEWT9F9HeYgvihBWpMYWY344/oVqkebj5siGuc9LAAMF
    A/9oQo66S9DKXJ0eBg9r34CfPMlPBrP0/7v7x/rq8Lfrudp2Smg4wbuBczT76HS2
    w52QsEqkbHDzoNNIUylWpIdwvHgxYs8DyELcw6mjSGkx9LNdbHlgQCZg2oh7aThQ
    Rlb9I/R+ePiRid6mDTLR1Dzhh6/A1p5N5/ONL2K/y4DDnIhMBBgRAgAMBQI6CxzW
    BQkNKGiAAAoJEORI/4wtOvPq60YAniw/o8T5G9L/8GLyb56hOWxsuMW9AJ9VoVFw
    d4IGw3VWQ7ZfJGacCS5ZBrkCDQRPMXbRARAAucu/Nl8Wp0D537+xRCyN+8DLJYcN
    LVZGhcpOPQD1dY3Yty+4Rf7GIFHPQQMi6KAaVHH0tXqyme07zoFllGyoZRfSjIPK
    veAA0ULh448beKvi2YGzwFlAlvNMSFEPM3o2J8XKVLwmMjUz5YxA9VSwn7WwPyjP
    btH0Ao22UGmdR4+8t/aYCR8DsYCYrHVkTbEsA3GIj9uYV4TG9lpbvUkaDYR6AP5i
    iFl3Wh9m7iZcIyLd8A9ZOzGaVctxuqaxB6ZVnMxa3fyngxnc57OTlfxHMykE+xcl
    NEliZ6lqbwrDDstdAvRW/tkyABO0oLaZqJCK70Z6QgbO8Qd8iRrss+1WYyHPrYHf
    mLLtrvJG/ZIYoWiO98RXQIOb7ZqojfuMO5kRKOehX88kaaxfBFjXIvDEieRAI1iU
    H41brY8KtbE5Kk0bCnTNIpll284+8d0nyb18eiZcrizYQJH39G798tV7NOXlYVQr
    zQhBVH9D13bySNUtbgjfrLEdztyD/VXqaPgS4vRfp5cSgEMd26CpxovvfI9SuRgJ
    Tw7xBEPK/OYWQ1/mjdoARCIm8/7ZVa+0o+TYe4PBIZ/RzzrPD9C5ErZOYEb77xZF
    tFXPvq0Ij7LX7D/iJC8KAG3nAOK1pZXBFICnlFkCAC4V6cQXNZm+YibS4UBg3WAV
    KJpU0BCkkOYBfZ8AEQEAAYhJBBgRAgAJBQJPMXbRAhsMAAoJEORI/4wtOvPqVEAA
    nAkAWMAlXmTJaTlz0AzCcCKcYPkzAJ9003N2a4Ha8bEEbLPTH51sV9YICLkCDQRP
    MXefARAA8RCz2WNo35i5lvBL1yOaG4ZlQ7Qwp3HvOaTe/2WnQ4aqvClIFfJCLi1A
    F/cL6AbgAMPFjqs+qFvhoDdH7TafiNlBbeYxQ+wve3S5oJ/8Omi5kauwrZ7i/jg7
    GpBRgkabwEAYhChdyCVpHR52b5L5u5uUgix/o+rLIteVJdhW8AK0msFq0V7dLehZ
    lYzJvOVZaEOcyjN4P/bNdF+Ve+PjWHm7YmvMgMi+Oo06ML5dnhjPgzjjBJHRsfHG
    BxGAF0DizH+X3bP+md7lCtl5xUED9LafVQlElBWLKzZzA4hdpz5ESwzRdF1mecAc
    i5pQKSQzshXfN/bwgItoAeg5VJBcGKvnYuhF4YOQSLz990Pof87AQ2WbxbqkTork
    cNa7e+uv2UVg0ZXbz0fiYY+ATTAZL6wnnKQ4pZ6DmQ3AbGu8oZaPjNG/30ccP6xP
    kBAysHvrhSQ3syAMKnpT/RT+P0fFESn/c5rpK7wK2nc/9YRcH/+1iO8QlxfjxV7z
    fBpNA42M9J29O6iVYQr6E9iNkaH0zUUQ+fb2H7Ei+TQnRBXSwgqShb4q9d2Udg0+
    Cs1J6rMRR/jidGrwuBnd5wDZUVDd8mHYumd7nObiFabPI9plj7xl28gTT/AzuKOh
    DxVnfNhhdENcFDAjWQKuNDiG5JbcZlTU6El60GsH24nqrjLdrBMAEQEAAYkCaAQY
    EQIACQUCTzF3nwIbAgIpCRDkSP+MLTrz6sFdIAQZAQIABgUCTzF3nwAKCRDAWQU5
    gV8OvBbeD/0Z4L+xSCywb3u1pNLR1SLVbzO37AxIfZ3MGv78L3gkADM5CdKvWH4O
    Ir7blH5jFBz0PutadoIE19wflfOB9S5b2LO1WZzdqPZja79wvTpk6xBn1U612wtR
    u3R6KPytCje/opSes+VeoMXZ4HPt53ytPfe0gwRrka06eO7HYtsqBOzRq659aWO+
    znKItrEW0J4/GZRFVhU/IzCx85RWsgB1FW4RNoo2ZFqVHVqQA4eXGS0FOeiRn+uc
    nSJhAvkNcJP9OSoy3fjGmXoa+dd6dQ1Ne0usZ7axSmwal66SDT9VFNh/W85GcslF
    OHl7W5DAWSp3gf+hiA9KkcQ9rIah3gFnemXPRQ1d/RRYbtnAsMSeEj5FllNqX9Sw
    2GucBrS+KvurfJTqbtvyCPzjiRoDaP+QQZfWkkyf9+HMLgvcZiZdw3vWUsrdrWHp
    Fq1xhGR7j6y++oUxCOoXj8bdaVKMlwrdEOTv9cMfxrNP6ISZET+okKmQdQRL1pbu
    ugi+j7o9KlGXSs0B62tvXczaQOmtiicqYFLcn72XsWibt65qxQgGBGyBIZVhLG39
    GUAw1W1OMK4yvbly+hBFU43ZgypFIY5jGoMoXfwDsRR4HE8DJ2N9ouUCdv2o6BXt
    wRJu3/ouY/u6UyL7zQQF7H2Etn1vLyaUkKCtRCqESQuuOK2CD0VwF7KeAJ92f+AE
    xlWY9N3rVSRC/RsctzrjyACdHsr/YkTW/fpgynQgO8t3h5ULIlM=
    =icS6
    -----END PGP PUBLIC KEY BLOCK-----
    
    The file gpg_sign.txt contains my initial key expired few years ago, which has been extended and new encryption/signature keys have been added.
    You can verify (using initial or new "ultimate" key): "gpg --verify gpg_sign.txt", this file has not changed.
    New signatures/encryptions will use the new respective subkeys.
    Note that if you just want to read my ID card, here is what it says:
                 EARTH Guest
            VISA Nb 59265358979323846
       Validity 80 earth years - non renewable
      Non telepathic - No physical shape control
         Originating from ZZ9 plural regions
           Alcohol sensitive lifeform
         Warning: may use strong language
    

    Do you have a TODO list?