thanks for the help so far...
the pc that is booting from usb gujin but not showing usb partitions is a dell optiplex gx620.
i've installed gujin onto a primary partition here and did 'cat' on a few distros that work for me fine everywhere else.
here's the strange thing.
1. i can boot up gujin fine on this pc from a usb hdd.
2. when i try to boot up gujin from its partition on the internal sata drive i get the following error after it tries to detect disks. everything is in red at the top of the screen.
"GENERAL PROTECTION at address 0xF0007870, codesex 0x17C0 xcodesec 02718 0x41B2
invalid code (check corruption with boot.asm): 0x90, 0x3E, 0x8E, 0x0 0xF
eax = 0x800D ebx = 0x3F02 exc = 0x5 0dx = 0x2710
edi = 0x1C80040 esi = 0xE741 ebp = 0x6C3C flags = 0x213
cs = 0x17C0 ds = 0x40 es = 0xF000 ss = 0x41B2 esp = 0xEB4C"
so the first question is why am i getting the above. I've tried reinstalling gujin but same fault.
3. when i boot up from usb gujin, it can see the partitions on the internal hdd. when i try to boot these up on distros that i know work elsewhere, i get errors such as the following for Parsix:
"ISOLINUX 3.11 Debian -2007-03-12 isolinux: Disk error 01, AX = 4240, drive (goes off screen here)
Boot failed: press a key to retry"
for puppy linux it gives
"Loading stage2 Read error 0x01"
Well, there is an exception in the BIOS itself, at address 0xF0007870,
and the instruction seems to be 0x90 which is a NOP, strange.
I can't explain it. The only way to debug would be to build dbgdisk_com1
and install the boot.bin generated (for instance on a temporary floppy),
then plug in a serial terminal on COM1 and see the debug displayed
there (use minicom).
When booting the distro you have selected, the simulated disk I have
written uses the real BIOS - and this BIOS seem to report an error.
If you can send me the minicom log, I will have a look at it.
i'm not sure how to create a minicom log, unless you have really clear instructions for a complete newbie.
ps. i was able to boot up mepis from this machine by clicking on the gujin direct boot option for mepis. when i tried to click on the gujin el-torito boot option, it gave the same error as above.
It seems there is something wrong in the BIOS, so maybe the first thing to try, is to search on the PC motherboard internet site is there is an upgrade of the BIOS available.
If there isn't any upgrade, you may try to stop Gujin trying to probe BIOS drives by un-ticking the "BIOS probe HD"/"BIOS probe FD" in setup or installing with the options to stop those probing in instboot.
Hi there Etienne!
Unfortunately, I'm receiving a very similar error to the one described by lawman. After probing hard drives, Gujin displays the message about video refresh and etc, and then it crashes.
My platform is a DFI mobo with nforce 680i LT chipset, newest bios. I've tried disabling all hard drives in bios, but this doesn't have any effect on crashing. It's running from a SATA hard drive.
By the way, Gujin is definitely installed ok on the disk because if I add this hard disk as a real disk to a VMware appliance, it boots Gujin off it well. I've also tried booting gujin off the ultimate boot cd - no success, crashes after some beeps with no errors. My laptop boots this older version of gujin from the ultimate boot cd without problems.
I have an iso 9660 partition on my hard drive which I would reeeeally like to boot (this is why I got into gujin the first place - to save me a couple of empty dvd disks by booting their images from the hard drive!), but to my knowledge no other bootloader except Gujin can boot an el torito session off a hard disk partition. So, even if I don't get Gujin to work, I would be grateful if you recommended me another piece of software that can boot an el torito session off a hard disk. :)
If you disabled "BIOS probe HD"/"BIOS probe FD" in setup and it is still crashing (either by
the Gujin setup screen or by the installer), you may try to only disable the IDE interface and
keep the BIOS interface.
But to do anything else, I need at least the address of the code the processor was trying to execute,
to know at least if it is in Gujin itself or in the BIOS (address CS:IP > 0xE000:0x0000).
Gujin is reasonnably easy to debug with a serial line and dbgdisk_com1.img, but I am afraid I will
not buy the same motherboard as yours just for one bug... I am not making any money from Gujin.
If you could find a way to boot DOS and run dbgdisk.exe, that would produce the file DBG that I
may be able to interpret - as the first step to debug.
I do not know any other program booting el-torito, I have written that piece of software from scratch.
I booted Gujin via vmware, disabled both types of probes (and enabled disk write so it saved the settings) and tried to boot it for real. No go, crashed again.
Here's a screenshot of the crash:
(gujin though usually loads its pretty font and colors the crash message with red, don't know why it didn't do it this time)
I also booted freedos and ran the exe version of gujin; it didn't crash but it didn't find that el torrito session (the checkbox for that was disabled).
So, what should I do next?
From the screenshoot of the crash, the problem happens when the video card and the screen are being probed (Gujin do not do things in parallel, and displays the result in synchronisation with its probing).
The general protection appear at address 0xF000ED56 which is inside the BIOS because it is over 0x90000000.
It seems to be a problem with the vmware video BIOS, either VGA/VESA BIOS or EDID BIOS.
Other bootloaders do not probe as many information as Gujin, because Gujin tries to go to graphic mode.
You can force Gujin to stay in text mode by pressing the key "Left Control" alone while Gujin loads itself and a bit later, one of the first lines will be "Control key pressed, forced text mode" (then you can release the Control key). Then you can save that video mode if the boot media is writeable, that will not trigger that vmware bug that other bootloaders do not see. The best would be to fix that vmware bug...
You write that the other crash was displaying things in red, that points to a completely different problem, because it appears at a later time, maybe when Gujin probes the hard disks.
Gujin will not try to probe IDE hard disks by its low level interface when executed from DOS, to not confuse the DOS disk drivers (you can check that in the "setup" screen of Gujin, checkboxes are unchecked).
It is also technically not possible to boot a CDROM once you are in DOS.
But for the debug version dbgdisk.exe, the "DOS disk driver" protection is overwritten once you select to probe IDE and CDROM drives in Gujin menu, and press Control R to reprobe all the disk subsystem. That would create the DBG file that I need, but note that being under DOS is seriously different than being under DOS inside vmware.
Okay, just to clarify: it doesn't crash in VMware (I boot into vmware just to change Gujin's settings on the disk I boot from in the real BIOS, since I can't access the settings screen otherwise; other than that, I don't ever use VMware in this context) - it crashes on my real hardware. And I ran freedos on the real hardware too, not in vmware.
And about these 2 types of crashes - well, this is just odd. When I enabled hard drives in BIOS and EBIOS probing in Gujin, it proceeds to probe them and crashes after that, with a very similar general protection address to the one in the screenshot (0xF...4E), with things in color. When I disabled probing, it crashed like you saw in the screenshot.
BTW, where can I get dbgdisk.exe? I cannot seem to find it in the install package.
OK, no VMware bug.
The different dbg*.exe are in the "standard" package you can download in the sourceforge page:
If it is a disk problem, you need dbgdisk.exe - if a filesystem problem dbgfs.exe - if a video problem dbgvideo.exe.
Those *.exe are not the last resort, because the crash shall not stop the "DBG" file creation; in the last resort you have to send the text to the serial port and capture anything before the crash by another PC on the other side of the serial line. Sometimes, you just want the last line displayed and you can replace the serial line by a direct printing of the messages to the screen - a lot of garbage appear on the screen but usually you get the last few lines readable.
For those last resort debug, you need to recompile yourself with GCC/Binutils, looking at all the possible targets in the Makefile.
You should still try to boot in text mode (go in text mode when gujin works by pressing the dot key, and check boot device is writeable), just to know if the problem is in the VIDEO BIOS.