- 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:
- The boot floppy and/or the boot hard drive do not depend on the physical
position of the file on the drive: you can create a new kernel, copy it
in /boot, rename it (as long as its name begin with "vmlinuz" or
"bzImage" or "linux") and just reboot.
- The boot sector do not need to be modified each time you build a new kernel
(risk of unbootable system).
- All partitions are checked (limits outside of the disk, partition overlap,
filesystem FAT12/16/32 and E2/3FS bigger than the partition) just in case
you used a buggy partitioning software.
- disks SMART status (health of the hard disks) are checked and reported
if error or SMART present but not enabled. IDE passwords are frozen.
- The boot sector (first 512 bytes) saves register initial value, you should
be able to load whatever OS (WinNT...) without _any_ problem.
- The complete process is protected by checksums, so you can detect easily
bad sectors on the floppy/HD, or recover from a bad/corrupted vmlinuz (its CRC32
is checked before the "big jump").
- Gujin is nearly completely written in C, so easily modifiable/extendable:
it does few things differently considering the version of Linux loaded...
- You can boot in graphic all the time, even with a old PC with only a VESA1
or VGA-only video card (CGA/EGA works also on my test system).
The video mode used by the kernel is easier to select.
- Most of the subsystems are written using BIOS _or_ direct hardware access,
so it will work if it is either BIOS compatible or hardware compatible.
- Gujin runs in i386 real mode and so is compatible with PC BIOSes generating
special interrupts (power saving initialisation...) during the boot
loading process.
- The mouse (PS2 or 3 types of serial mouse on COM1..COM4) is detected at
the right time and used. This info is passed to the kernel.
- You want to build a floppy distribution, with max 30Kb of bootloader and
an easy way to change the kernel (and its initrd).
- 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:
Note: If you are using MS-Windows tools to download Gujin files from
sourceforge, you may notice that downloaded filenames change on the way to your
PC: the "tgz" extension is changed to "gz" without any reason. Double check the
name of the files you have downloaded before opening them - rename if needed.
Note: DO NOT play with the floppy under Win98 (and maybe other
versions) when you are in DOS mode (i.e. start->shutdown->reboot in DOS mode,
not in a DOS window). There is one way to physically break a floppy drive,
just ask a cylinder higher than 80 and you immediately hear the "sound of death".
My drivers (in Gujin) will never ask a too high cylinder on a floppy, but
the drivers of Windows in a DOS environment do that quite easily. It has cost
me two floppy drives (one to detect, one to check) in 5 minutes, and I was
not even using Gujin... You can still safely copy (drag & drop) files under
the graphic interface and then reboot to DOS mode.
- 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.
Note:
- All the images (*.img) are for 1.44 Mb floppies, use the "./gujin"
executable for other formats.
- All the images contains the FAT and root directory: the executable size
is not as big as the file size.
- The floppy used should not have "bad sectors".
- For most configurations, there is two independent files: the image
(*.img) to be copied to the floppy in raw format (do _not_ use the DOS
command "copy" nor drag and drop for this one !), and the standard DOS
executable file (*.exe) which is a standard file to be copied the way
you want, but needs at least DOS to run.
- If you do not want to execute file AUTOEXEC.BAT (and so do not
want COMMAND.COM on the floppy) you can put "SHELL=A:\gujin.exe" in
file CONFIG.SYS. If you use "SHELL=A:\mingujin.exe ...", this CONFIG.SYS
line will be probably limited to 128 chars even if FreeDos accept
more on the command line, because that is not a command line.
- What is the content of file standard.tar.gz?
-
Once decompressed, the file "standard.tar.gz" contains:
- full.img.gz / full.exe : that is the complete configuration, the one I
tested the most; you probably do not need all that (mostly the serial
interface).
- medium.img.gz / medium.exe : same as "full.img.gz / full.exe" but the
support for the "mini-debug", the serial (VT420) support, and the analysis
of the I/O ports used by the video card are removed.
- small.img.gz / small.exe : same as "medium.img.gz / medium.exe" but the
mouse support, the support of 4 BPP (16 color) graphic and 24 bit VESA modes,
the VESA_HARDWINDOW analysis which cannot be used right now by Linux, the
support for the VGA only cards, and the verbose messages are removed.
Note that even some 486 refuse to boot if the video card is not VESA 1.0+
compliant, so it should be quite safe to remove the VGA support.
- tiny.img.gz : the smallest possible (keeping vmlinuz/initrd/initramfs
compatibility), just add "vmlinuz-2.4.16" and "initrd" on the FAT12 floppy
(boots the first kernel loaded successfully, Gzip comment fully checked).
- mingujin.exe : the smallest possible DOS loader, do not probe disks nor
video modes, use it as loadlin.exe:
"mingujin.exe c:\dir1\dir2\vmlinuz initrd=c:\dir3\initrd.gz opt1=val1 @optfile opt2=val2".
mingujin.exe can also switch to a VESA mode with the "/V" option, but it
is not a full support of VESA like the one available in "gujin.exe".
- lotiny.exe : the previous executable in its "debug loader" version,
it creates file "DBG" in current directory giving informations on
what happend, what gave the BIOS gathering, etc...
- lodtiny.exe : lotiny.exe displaying the debug on screen
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...
- dbgvideo.exe : to debug the video (VGA and VESA) subsystem.
- dbgdisk.exe : to debug the disk (BIOS, EBIOS and IDE) subsystem.
- dbgload.exe : to show which parameters are passed to Linux, and some A20 debugging.
- dbgfs.exe : to show the process of selecting files on each filesystem...
- 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.
Note: There could be another reason to just see one copyright
line and then a quick boot: if Gujin is configured with autoboot after
timeout on the only bootable system detected and verbose mode OFF and
writing to disk disabled, it will decide to skip its menu and video
initialisation and immediately boot the only detected system.
It will still quickboot if exactly two bootable system are detected,
but they are the same (partition/filesize/inode) on two disks with
different access method (usually EBIOS and IDE) so that SMART
status can be checked, and the first (EBIOS) will be loaded.
This way, if you have only one partition (for instance FAT32 or NTFS)
without any kernel file, you will "quickly" boot it.
You still have Gujin checking partition overlap, disk with bad SMART status
display when a major problem appear - but nothing else up to the time you
install a serious operating system... or you install another hard drive
with another version of your initial operating system, or you boot with
CAPS-LOCK active.
The installer has the option "--quickboot=<number of second>" as a
shortcut to initialising the "timeout autoload", verbose to OFF,
disable disk writing, probe only partition's MBR on the BIOS and standard IDE
hard disk, and have a default video mode number 3 (simple text) if
the screen is not EDID.
Note version 1.4 and after: The video initialisation is now done
even with quickboot; it should not change anything but be a little slower
than version 1.3 (because the videomode was set to 0x03) but it enables
a kind of mingujin.exe with video mode autosetup when using an EDID compatible
screen if using those ./gujin parameters:
./gujin --quickboot=1 --default_video_mode=0xFFFF ...
- 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.
Note: The type of partition is used for:
- detection of extended partition (0x05, 0x0F, 0x85)
- detection of partition which can be hidden (FATxx and NTFS)
- detection of empty partition (0x00)
- detection of LBA or CHS access (FATxx)
- detection of partition without bootsectors (Swap or extended)
Note: Gujin interpret type 0x85 as Linux extended,
that is a disk (with transparent offset and size) in a disk.
It seems more usefull to do so, you set type 0x85 for your partition,
for instance /dev/hda4, then you type "fdisk /dev/hda4" to create a
partition table inside this partition, and mount inside partitions
with lomount: lomount -t ext2 -diskimage /dev/hda4 -partition 2 /mnt
http://www.dad-answers.com/download/qemu/utilities/QEMU-HD-Mounter/lomount/
You can also use the "-o offset=" option of mount for VFAT.
You can also copy byte per byte an older and smaller disk you have by
"cat /dev/hdb ⊃ /dev/hda4" and still access everything.
If you have the ISO9660 copy of a CDROM inside a partition, by typing
"cat /dev/cdrom ⊃ /dev/hda4" or "cat cdrom.iso ⊃ /dev/hda4",
you should give it the Linux partition type 0x83 - it will be read
and can be booted (El-torito and /boot kernel files) the same way
as any other filesystem (works nicely with Damn Small Linux:
you can boot it and also mount this partition like
"mount -t ISO9660 /dev/hda8 /mnt/usbdisk/").
- 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).
Note: Some BIOS leave empty space on the hard disk depending
on the number of heads and the number of sector per track selected for
this drive. This probably happens on very old BIOSes and with non LBA
compatible hard drives (kind of 220 Mbytes hard drives). Then, Gujin IDE
interface may not work correctly - I do not have such a hardware to check.
- 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:
- us: the United State keyboard.
- uk: the United Kingdom keyboard.
- ca: the Canadian keyboard.
- br: the Brasil/Latin America keyboard.
- no: the Norway keyboard.
- fi: the Finland/Sweden keyboard.
- dk: the Denmark keyboard.
- nl: the Netherlands keyboard.
- sp: the Spain keyboard.
- pt: the Portugal keyboard.
- it: the Italy keyboard.
- qwerty: none of the above recognised, but still a qwerty keyboard.
- fr: the French keyboard.
- be: the Belgium keyboard.
- azerty: none of the above recognised, but still an azerty keyboard.
- de: the German keyboard.
- ch: the Switzerland keyboard.
- qwertz: none of the above recognised, but still a qwertz keyboard.
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.
Note: The Master Boot Record will always appear, even if
none of its partition are marked "active", to not change the number
of bootable systems and to not confuse the autoboot feature. In this
case, booting this Master Boot Record will probably display an error.
Booting Linux will not modify any hidden/visible partition nor any
"active" partition.
- 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.
Note: Now, at least RedHat 7.2 has switch to an IDE machine
to produce its default distribution kernels, hence the addition of the
"force root detection" option.
Note: there is another and different message which will
appear on some distributions, later in the boot process (at root filesystem
ext2/3/4 checking) when the root partition passed to the kernel is not the one
described in /etc/fstab. If you have such a problem, first check that
you did not check the "keep BIOS disk order" in the setup screen. If you
have a strange IDE order, you can setup the "ide[0-9]=0x" options on the
command line, that will disable autodetection/autoorder of IDE interface
(but keep the "root=" autodetection unless you write it manually) - take
care "ide*=0x" hexadecimal numbers have to be in lower case. Another
solution is to boot another Linux and change /etc/fstab manually - until
the distribution implement better startup files. You could also try
(dangerous) to mount the root filesystem in read/write mode (kernel command
line "ro" or "rw").
- 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:
- [VGA] : all characters are displayed using _only_ VGA BIOS functions
- [INT] : in VESA modes, use the interrupt to change graphic window
- [FCT] : in VESA modes, use the function to change graphic window
- [hard] : My recorder works - access I/O ports to change graphic window
- [hardc] : Same as [hard] but array is compressed (VESA 1.* default)
- [lin] : Linear window used in real mode (VESA 2+ default)
- [nowin] : The complete video memory fit in 64 Kbytes (VESA 1 or 2+)
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.
Note:
Because it is not possible to get information about a VGA mode without switching
to it, this probing is slower and a bit less safe. If you have a correctly
written video BIOS, when asking it to switch to a mode it does not support,
it should either not switch to this mode, execute an invalid instruction,
execute a division by 0, or do an infinite loop. All of these cases are
correctly handled by Gujin. The only thing it should not do is an infinite
loop when interrupts are disabled, because then the timeout manager cannot
execute the timeout...
Because the later case may happen, and if the disks are in read/write mode, a
tag is written on the disk before trying to switch to each mode. If you have
to do a manual reset, then this VGA video mode is saved as "unusable". You can
then, when you get back Gujin interface, restart the VGA probing - this mode
will be skipped. Note that writing to the disk twice per VGA mode test is
slower, mostly if Gujin is on a floppy disk.
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.
Note:
The video modes known from the VESA interface (by the first probing) are not
re-probed in the VGA interface, that why the order is important. The VESA driver
of Gujin do not manage video modes below 4 BPP (i.e. less than 16 colors), the
VGA driver will detect them.
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.
Note:
The list of "unusable" VGA video mode, the basic characteristics of
"usable" VGA modes and the default video mode (default text and graphic)
are saved in between boots in the "boot*.sys" file. These parameter
are reseted if the video card has physically been changed (detected
by the change of the card name of the VESA interface) or manually
by pressing Caps-Lock before booting Gujin. If you physically exchange
VGA-only video cards in your PC, it is up to you to press Caps-Lock
at next reboot.
Also, the default video mode being stored, you do not need to have the
screen powered ON to start Gujin (the EDID is not re-checked). But it
is a lot safer to restart Gujin with Caps-Lock active if you have
physically downgraded the screen.
Note:
It is better to "reset VGA/VESA modes 0..0x7F" in a VESA mode, or
switch back to VESA (and re-switch to VGA if you want) after this
command, or simply restart the computer. If not, the invalid modes
disabled in VGA initialisation are no more disabled (because VGA
initialisation is not done) and you will test for instance mode
0x8..0xC at next VGA video mode probing. It still can be usefull
when you know what you do, so I keep it.
- 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.
Note: The [E]BIOS may decide to report one sector less to the
operating system because it is using this last sector for test purposes,
at boot time. Then, it is really unsafe to store anything in this sector,
because it may be written at each/some boot - so this sector shall
not be mapped in a partition. Also some EBIOS no more support the indianess
problem on the disk size of very old drives (< 512 Mb), and that can
produce such a message.
- 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:
- HTP BIOS do not handle ATA1 disks, where the IDE size reported is zero, you
just need to multiply head*cyl*sect to know its size (HTP size is -1).
- HTP BIOS do not handle ATA2 disks, where the size reported has a
strange half indianess, and they remove 65536 sectors instead of 1.
- HTP BIOS crash - at least interrupt disabled or worse - when you
try to reset disks after requesting PIO data with IDE interrupt disabled.
- HTP BIOS do not initialise nIEN of the IDE control register before
performing a read or a write to the disks.
- HTP BIOS report _one_ sector less than the real disk size on extended
BIOS call, so you can get the message "EBIOS: disk ... last partition over
disk limit detected (0 Kb)!". The 0 Kb is because there is 512 bytes (1/2 Kb)
lost if the disk has been formatted on Linux and fills completely the disk...
- Lots of BIOSes do not report the size of the disk on INT 0x13/ax=0x1500
- ALI BIOS is partly EBIOS but does not report the IDE base address in EBIOS.
- Silicon Image does not have IDE Alternate Status register (always reads 0)
so will not work in IDE hardware mode.
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).
Note: Most of the newest joystick (who have more buttons to
press than fingers you have) are not BIOS compatible - joystick manufacturer
do not believe hardware compatibility is important. Maybe one day the
USB Joystick will be managed by the BIOS, like USB keyboard and USB mouse.
- 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:
- if you are sure that the default root coded in file vmlinuz is valid
(i.e. you have compiled the kernel yourself and you will use it with the
current filesystem, or you have set it up manually with rdev)
- Gujin is not able to find alone the root filesystem (You have different
distribution of Linux and all the kernel are in the same "/boot/"
directory; or the root partition is a FAT filesystem).
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.
History: Before, it was possible to detect that a distribution
default kernel was booted because its root was on a SCSI drive, and the
user's PC did not usually have an SCSI interface.
Now, some distribution (RH7.2 at least) are using IDE only machines
- and so the default root coded in file vmlinuz seems valid, but is not
on your own machine.
It is a hack, standard distribution should reset this "root" parameter
to zero to show that they do not have a clue of the root filesystem of
the user's PC; but rdev do not allow to enter such an invalid "root".
- 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.
Note: When booting a partition's boot sector, or the Master Boot
Record of the disk, Gujin ask to the video card if it supports the
standard BIOS calls to display strings in the current (VESA) video mode.
If it does, Gujin does not switch to text mode because the user may want
to stay in graphic - if it does not support BIOS calls, Gujin switches
automatically to the last text mode used.
- 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:
- The partition table has to be clean, use FDISK.EXE of Windows
to create it. The best way is to use Windows FDISK.EXE on a blank
disk to create all partitions at once, this tool will
easily create overlapping partition when you try to modify an
already existing partition table (I tested that). Plan to leave
few unused Mbytes at the end of the disk, they may be _really_ useful later: Plan 16 Mb + 4 Kb free.
- You have to play the best Microsoft games: DLCATT
(Drive Letters Changing All The Time). Better install every
software on C: - and so you will get a different C: for each
Windows boot. Have also a look at file "srdiskid.dat" in the "_restore"
hidden directory of the top level directory.
- Windows cannot be installed in an extended partition nor
on a secondary hard drive: install it on a primary partition
and then copy all files (including hidden files _and_ system
files) to the new partition. The order of files is not important
(unlike on MSDOS where IO.SYS had to be the first file), but
it is easier to copy the files under Linux with "cp -a"
- If your partition is over 8 Gbytes, you have to set its
type to be either "Windows FAT 16 LBA" or "Windows FAT 32 LBA".
FDISK.EXE will set only partition types "Windows FAT 16" and
"Windows FAT 32" for extended partitions, so you need Linux
to do that last bit.
- 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.
Note: For the auto-hiding feature of Gujin, you need to be able to
read and write every hard disks. Windows want to boot on C:, and so if
this C: partition is an extended one on the first hard disk, Gujin needs
to hide all primaries of every hard disks. There is a two step process,
first one is read only - and if everything is OK the write process begins.
If you have a broken hard disk as secondary or third drive, Gujin will
not be able to read its MBR and it will abort early the process and
report you an error (before writing anything), even if you just wanted
to boot Win* on the first hard disk and did not care of the third HD.
Moreover, I heard that you cannot have more than one primary partition
visible per disk else Win* may be confused, so Gujin will not do that.
If you want to try the opposite it is a simple compilation switch.
- 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:
- loadadr=0x00100000 : you can modify the default load address, this will
only work with a kernel linked at this address.
If this field is zero, do not relocate the PIC kernel (EMM alloc'ed memory),
very special use.
- runadr=0x00100000 : you can modify the default run address, this will
only work with a kernel specially modified.
If this field is zero, use value of loadadr.
- paramadr=0x00080000 : you can modify the default address to load
the Linux parameters, or completely disable the probing (and relocation) by
setting it to zero (do not do that now).
Since 2.4.1, exactly 2.4.0-test3-pre3, this address is configurable in
Linux, if a vmlinuz file before 2.4.0 (included) is loaded, this address
defaults to 0x90000 - else to 0x80000.
This address has to be in real mode addressable area (below 0x100000), and if
it is exactly 0x90000 (the default for 2.2- kernels), a reset of the PIC
is generated before running the kernel. No check is currently done on this
value, so keep it quite high (DOS bootloader may be loaded quite high),
the theoretical minimum value for mingujin.exe bootloader is 0xBC00 (base)
+ 30 K (code) + 64K (stack) = 0x25000
- realfct_size=0x001234 : number of bytes of the realmode function to be copied
and executed by the bootloader in real mode for the kernel to get information
from the BIOS, do not use if loading an ELF kernel file.
- minram=0x00001000 : Minimum number of kilobytes of RAM (hexadecimal only)
to have to be able to start the kernel. The default is zero, but anyway
another error is generated if the uncompressed kernel does not fit in memory.
It is the amount of contiguous memory available at 0x100000, i.e. 15 Mbytes
if there is a hole at 16 Mbytes.
- min_gujin_version=0x0100 : Refuse to load this kernel if the version of
Gujin is too low, strictly below the given number - in this case 1.0.
- option=0x00000000 : The options of this kernel file, none by default.
This is only taken into account when the setup screen has "ignore kernel IDE options"
unchecked, else this field is zero-ed unconditionally.
Only those bits are currently defined:
If bit 0 is set, say that this "kernel" file wants the IDE system (hard disks)
without the maximum LBA set. It has only to be done when this "kernel" is a
safe and standalone IDE aware partition manager. See BEER in ATA T13 D1367.
If bit 1 is set, say that this "kernel" file wants the IDE system (hard disks)
without the disk size set. It has only to be done when this "kernel" is a
safe and standalone IDE aware partition manager. See BEER in ATA T13 D1367.
If bit 2 is set, say that this "kernel" file wants the IDE system (hard disks)
with _unfrozen_ passwords - so that it can manage password itself. It has only
to be done when this "kernel" is a trusted, safe and standalone IDE manager.
If bit 3 is set, say that this "kernel" file wants the IDE system (hard disks)
with _unfrozen_ overlayed config - so that it can manage this itself. It has only
to be done when this "kernel" is a trusted, safe and standalone IDE manager.
If bit 4 is set, say that this "kernel" file wants the IDE system (hard disks)
with Host Protected Area unfrozen.
If bit 5 is set, say that this "kernel" file wants the IDE system (hard disks)
with Host Protected Area unlocked.
If bit 6 is set, say that this "kernel" file does not want the password for HPA
(HPA only password) to be set to the name of the disk in the BEER sector, or to
all zero if no BEER detected. It has then to be set another way if Gujin has to
lock or freeze the HPA.
If bit 7 is set, say that this "kernel" file wants the IDE system (hard disks)
with hidden Host Protected Area (Is it useful?).
If bit 8 is set, say that this "kernel" file wants the IDE system (hard disks)
with unhidden password.
- maskcpu=0x80000007 : you can declare which microprocessors are _not_
supported by this kernel (if bit (1 << [01234567]) set, 80[01234567]86
excluded - see the family from CPUID). Maskcpu is only taken into account
when it is not null (so when it is present on the comment line).
When family is 0x0F, the bit taken into account is (0xF + extra_family).
Some extra bits are used here:
if bit 31 is set, the kernel is made for BIOS IA32 systems, i.e. PCs.
if bit 30 is set, the kernel cannot run from DOS/windows environment.
if bit 29 is set, the kernel cannot run from DOS/windows with EMM386 environment.
- maskDflags=0x00000000 : Which bit _have_ to be set in cpuid 0x00000001, in edx,
for instance "maskDflags=0x00000010" if kernel requires the TSC capability.
- maskCflags=0x00000000 : Which bit _have_ to be set in cpuid 0x00000001 in ecx.
- maskAflags=0x00000000 : Which bit _have_ to be set in cpuid 0x80000001 (AMD
processor only).
- maskvesa=0x00000000 : (Only if the loader isn't mingujin.exe/mingujin.img)
if bit ([8] - 1) set, VESA [8]BPP supported;
if bit 16 set, able to boot in text mode;
if bit 17 set, able to boot in VESA1 mode;
if bit 18 set, able to boot in VESA2 linear mode;
if bit 19 set, will switch to VESA1 if in VESA2 modes;
if bit 20 set, UNable to boot in VGA graphic modes.
- maskresolution=0x00000000 : (Only if the loader isn't mingujin.exe/mingujin.img)
if bit set, this resolution (see vmlinuz.h) is supported.
Few other strings are recognised, but they are only needed if the kernel
will access the data area of Gujin - i.e. if you want to build a special
"my_application.kgz" to do low level stuff: special partitioning software,
hardware memory checker, partition backups... without having to load an
operating system, but still using graphic video modes, disks and mouse.
These future applications will be linked to Gujin in its GPL meaning.
- 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):
- H: the disk support the "Host Protected Area".
- P: the disk support the "password".
- C: the disk support the "config overlay".
- R: the disk support the "removeable".
- B: the disk support the "SAORAB".
- 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:
- The intended Master Boot Sector of the emulated disk is read just before emulation begins and if the 0x29 signature
is found the geometry and BIOS disk number is read from the MBR, so that you can emulate any floppies (like 360 Kb
or 5.76Mb, twice 2.88Mb) and any hard disk (you can emulate and boot from the last BIOS disk as an extension)
- If the 0x29 signature is present the sector size is taken from the MBR. If the device is read/write (CDRW formated
as sector per sector writeable or large ATAPI floppy) and the sector size is 2048 then the write command are executed
by the disk emulation.
- There is no data memory associated with the emulated disk, or more exactly the CDROM drive cache is used. Each read
is translated to a SCSI command sent using ATAPI, and the unused data read is discarded (when reading 512 bytes of a
2048 sector). Each write is accepted if it is an exact number of 2048 sectors. Then, the video card is not confused by
having a changed extended memory size in between its initialisation and its use.
- There is no autoselection of the El-torito image to boot as described in the specs, all sessions are treated the same
(not just the last data session), and the boot address of said no-emulation shall not overwrite Gujin code starting
at 0x17C0:0 (if starting at 0x7C0:0, you can load max 32 2048 sectors - if after gujin code, you can load a lot more).
- The emulated floppy/hard drive is BIOS and EBIOS with configurable bytes per sector as long as it is multiple of 512.
Note that more generally Gujin does not link a device to a way of booting, so you can use a hard disk or a
partition to dump byte per byte the content of a CDROM, and boot from it. You also can have a standard hard disk
image on your CDROM (with partitions if you want, mounted by command "mount -t vfat -o offset=") and boot from it - that
is booting from the first sector treated as a MBR.
Note that Gujin correctly treat FAT partitions with 2048 bytes per sectors independently of the number of sector per cluster.
Have a look at the target CDall (multi-session) and CDallEmul in file Makefile for a test CDROM and for more comments.
- 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.
Note:
If you want a bootable (by Gujin) 2048 bytes/sectors 650 Mbytes floppy image (because Linux cannot do
partition on a CDROM, no device for it) to copy onto a RW-CDROM, with a FAT16 filesystem (it may be
good to have big sector size for sector per sector R/W access), you can do:
./gujin /tmp/cd --full -d=EBIOS:0xE0 --geometry=327680,0,16,32,2048
# Add the line 'drive f: file="/tmp/cd"' to /etc/mtools.conf
touch /tmp/io.sys
mcopy /tmp/io.sys f:io.sys
mdir f:
minfo f:
cdrecord blank=fast -s
cdrecord -multi -tao /tmp/cd -v
mkdir /mnt/cd/
mount -t vfat /dev/hdc /mnt/cd/
ls -la /mnt/cd
fsck.vfat /dev/hdc
umount /dev/hdc
You may need to set the FAT16 parameters to get all sectors starting at a block boundary,
something like 64 Kb/cluster and 64Kb per FAT and 64 Kb near empty at 0 to also contain
the El-Torito structures (left as an exercise for the reader).
I also tested once a 2048 bytes/sector 1.44 floppy working with mtools.
Note:
My result are: Intel BIOS is able to autodetect USB drive format and support BIOS and EBIOS, it simulate
a floppy (i.e. BIOS 0x00) and works with --usb_hdd.
Award BIOS is able to autodetect USB drive format and support BIOS only, it simulate
a floppy (i.e. BIOS 0x00) and works with --usb_hdd.
Dell BIOS is reporting a format with sector/track=1 and heads=128 (does not autodetect current USB disk format),
works with BIOS and EBIOS and simulate a hard disk (i.e. BIOS 0x80) shifting other hard disk numbers and that
can bother partition loading like Windows Xp. It works with --usb_hdd.
This HP/Compaq 6720s is able to boot from SD cards or USB thumb drive, but only in EBIOS mode (do not
support BIOS any more) and simulate a hard disk (BIOS 0x80).
- 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?
-
- Read and follow the todo list: action to Etienne. -:)
- Fix bugs, clean source and optimise the code size.
- Implement longcall function attribute support (lcallw/lretw) in GCC.
- Implement segment variable attribute support (%fs: prefix on access) in GCC.
- Implement an option not to use function keys but arrows keys and
an "active" field, to have more than 12 selections per screen.
- Write a USB interface for HD/CDROM/PenDrives, and so for keyboards, joysticks and mouses..
- Support other (GPL) filesystems.
- Is there (and what is) a problem with soft RAID hard drives?
- Find people speaking other languages to complete file "messages.h"
- Check serial getsize() when bad emulation (and maybe code: ESC [ 100 D )
- serial getcontrol aborted on 'r'
- Check VGA ET400 frequency, code VESA3 refresh?
- Generate those ide[0-9]=0x... if the DOS gujin.exe is used.
- Save parameters to the "gujin.exe" file if the DOS gujin.exe is used.
- Is there a special procedure to stop Windows95/98 before running the
kernel (INT0x2F, ax=0x1609).
- Do a better-looking interface. A penguin should run at 100 mph around
the screen showing the user where to click -:)
- Upgrade my English to a better version -:)