Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

bios boots from usb but gujin can't see usb

law man
2008-05-01
2013-10-08
1 2 > >> (Page 1 of 2)
  • law man
    law man
    2008-05-01

    OK, I've got a lot of stuff working with Gujin and it's great.

    I have numerous ISO cd files that I have used 'cat' to put into partitions on my usb hdd.  this is great and I can usually boot from my usb hdd and then from the gujin menu select my usb partitions to boot from el-torito style.

    however...

    on a few computers, i've switched the bios to boot from the usb device.  it then boots ok into gujin, but gujin does not find the usb device (even though it is on it itself), so gujin only shows the internal hdd partitions.

    this is really strange.  how can i make gujin show the usb hdd partitions on these types of computers?

    i've tried 3 dell computers, and it's been the same on all 3 of them.

     
    • I am not sure, but maybe...
      Do you see the message " (CDROM emulation on BIOS 0x%X stopped)" after "Detecting disks:"
      when Gujin boots in verbose mode, on the Dell computers?
      The only way for Gujin to know if it has booted from CDROM is to ask the BIOS using
      the CDROM BIOS extensions, and this CDROM BIOS may also be used for USB (a virtual disk
      is simulated by BIOS approximately the same way).
      In this case, try to install Gujin with instboot --stop_emulation=0 to check if that is
      the problem (or modify in the menu the field "set stop CDROM FD/HD emulation" to 0).

      If not, can you tell me which BIOS disks Gujin displays when in "verbose" mode, on the
      startup "text" screen - for those Dell?

      Cheers,
      Etienne.

       
    • law man
      law man
      2008-09-16

      hi,

      i modified the 'set stop cdrom/ fd/hod emulation' to 0, and nothing happened.  tried rebooting with the new setting, but it doesn't seem to save the setting.

      not sure how to display 'verbose' mode in bootup (or do u mean installation?), but when the screen boots up and i press pause, i have the following info:

      detecting disks (booted from BIOS0 0x80):
      Have found 2 disks:
      0: ATAPI/lba master@0x1F0,0xF6, no media detected.
      1. IDE/lba48 master"0xFE00,0xFE12 (HP), size 74 Gb, 2 partitions.
      Analyse filesystems: found 0 ways to boot and 0 initial RAM disks.

      does that help?

       
    • Hi,

      > i modified the 'set stop cdrom/ fd/hod emulation' to 0, and nothing happened.
      > tried rebooting with the new setting, but it doesn't seem to save the setting.

      That may be another problem: Did you enable the tick box "write enable" ?
      If not, nothing is written to disk and you re-test the same configuration.
      Also, some BIOSes emulate a read-only BIOS disk from a USB Thumb drive.
      The "verbose" mode is also enabled by a tick box, but you have it enabled
      if you see "detecting disks (booted from BIOS 0x80):".

      If for any reason you cannot check tickboxes and save them to disks,
      you can use options from instboot to set those switches at installation time.

      The 'set stop cdrom/fd/hd emulation' is quite special because it does not
      influence the probing (you can re-proble with CTRL-R) but calls the BIOS
      to say "I have finished with the [CDROM] disk simulation, please stop it", which
      is needed in some cases - either before probing disks or after probing them,
      or not at all. So you cannot change 'set stop cdrom/fd/hd emulation' value
      and then just reprobe by CTRL-R, you have to reboot.

      Etienne.

       
    • law man
      law man
      2008-09-17

      ok, i made it write enabled and changed that setting for emulation.  i rebooted the system and saw that all the settings had been saved.

      still cannot see partitions on the usb hdd.

      also, when tried to boot windows ntfs partition through usb gujin, (with write enabled) i get:

      "error 0x4 while partition hiding/unhiding (disk content unchanged)"

      ps. manage visible partition is ticked.
      pps. see 'general protection fault' posting for addition similar problems on this same machine.

       
    • So there is a problem on the partition table of the USB HDD and Gujin prefer not
      to continue with this disk.
      Can you please do, using linux, an "/sbin/fdisk -l /dev/sd?" and post the result.

      But I may know what is happening on those DELLs: the BIOS simulate a disk which
      covers only the first partition, i.e. the first sector of the emulated disk is
      the first sector of the partition and not the first sector of the disk.
      There is no partition table in the first sector of the partition - so Gujin cannot
      display other partition.

      Do you use instboot option "--usb_hdd"? I assume it else Gujin would not have booted
      on those DELLs. You may be able to play dirty tricks by putting a false partition
      table (offseted by the start of the first partition) in the first sector of the
      first partition - assuming that DELL BIOS offset sector number but do not check
      the end of first partition to end the disk, but you are entering very dirty hacking.

      The system to hide or un-hide partitions is made for Windows98, because the booted
      partition has to appear as the first un-hidden partition on disk, i.e. C:.
      If you do not need it (i.e. booting Windows NT), it is better not to enable the
      tickbox. The problem there is that Gujin did not find the partition table on
      the USB, so it has to be a "floppy - like" disk and that kind of disk will always
      take the letter "C:", and window98 cannot boot anyway because the main Window
      directory will always be on D: when the USB disk is inserted.

      p.s. can you tell the size and filesystem type of your first partition of this
      USB disk? And do you have the tickbox "probe BIOS disks" active - because
      your USB drive is only a BIOS disk.

      p.s. I like to see 'general protection fault' messages (with the exact version number
      and the GCC version if Gujin has been rebuilt) - even a photo of the screen to my E-mail
      is sufficient.

      Etienne.

       
  • Malo
    Malo
    2009-11-22

    HI.. I've notice the same error on my 16gb usb pen. Still can't able to see the device on Gujin menu. Only partition from my local hd.. I've tried changing BIOS, EBIOS, -usb_hdd option, making only one fat16 partition, making only one primary partition with gujin inside and other logical partition with isos "catted" inside.
    Still not working
    :(

     
  • Hi malo87,

    Your message is not really precise. Process in order:

    - if you do, with gujin-2.7, the dd to erase the beginning of USB disk and then "./gujin /dev/sdg -mbr", does that USB boot the system and the disk is displayed in verbose mode?
    - Then, if you do an "fdisk /dev/sdg", delete the only partition and create two or more primary partition, and re-install Gujin like "./gujin /dev/sdg1 -mbr-device=/dev/sdg", does that USB still boot the system and do you see the partitions count in the initial (text) screen?
    - Then, if you cat some ISO into the partitions where Gujin is not installed, do you see them in the menu?

    There can be a lot of possible failure mode, bad partition table, no filesystem in the partition, it is difficult to tell what is happening in your case.

    Etienne.

     
  • Hello Etienne!

    I have similar problem. My USB stick with many partions works fine on one laptop. But it doesn't work on Asus P5QL with latest BIOS. When I run it successfully on laptops it shows 'Detecting EBIOS 0x80'. But on Asus it shows 'BIOS 0x80'. What is the difference between 'BIOS' and 'EBIOS'? Also I have all tickboxes set (otherwise it wouldn't work on laptop): 'probe BIOS hard disks'.

    The output of fdisk -l:

    Disk /dev/sdb: 32.0 GB, 32006733824 bytes
    255 heads, 63 sectors/track, 3891 cylinders, total 62513152 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x0002361b

       Device Boot      Start         End      Blocks   Id  System
    /dev/sdb1   *          63      192779       96358+   e  W95 FAT16 (LBA)
    /dev/sdb2          192780     7807589     3807405   83  Linux
    /dev/sdb4         7807590    62508914    27350662+   f  W95 Ext'd (LBA)
    /dev/sdb5         7807653     9253439      722893+  83  Linux
    /dev/sdb6         9253503    10699289      722893+  83  Linux
    /dev/sdb7        10699353    12145139      722893+  83  Linux
    /dev/sdb8        12145203    13590989      722893+  83  Linux
    /dev/sdb9        13591053    15036839      722893+  83  Linux
    /dev/sdb10       15036903    16482689      722893+  83  Linux
    /dev/sdb11       16482753    17928539      722893+  83  Linux

    But it should be fine because it works on laptop, isn't it? Also in Asus BIOS there are boot USB option as hard disk, floppy, DVD. I tried every option. In 'hard disk' mode it at least starts Gujin which succesfully enters menu. So, I suppose, it found succesfully second stage boot-loader which is on first partition (100Mb FAT). Can we debug the problem together?

     
  • I also tried it on third computer. It worked fine! So, there is something wrong with some kind of BIOS.

     
  • Hello Midenok,

    > What is the difference between 'BIOS' and 'EBIOS'?

    The difference is that BIOS interface is older (made when disks were small in size) and can read sectors up to the limit (Heads*Cylinder*Sectorpertrack), that is why Gujin displays those three numbers Heads, Cylinder, Sectorpertrack when detecting a BIOS only hard disk.
    The EBIOS (Extended BIOS) interface has no such limit and can read any sectors.
    So, at best, Gujin will only propose you to boot the partitions below the limit (see fdisk -u) if it does not find an EBIOS interface.
    It is possible that the BIOS on your Asus P5QL do not implement the "Extended BIOS", then there is no other solution than having a full USB driver in Gujin and considering the number of chipsets existing, that would be a lot of code to write.
    It is also possible that you Asus P5QL implement a buggy "Extended BIOS", and Gujin may be able not to trigger the bug, there is already some "dirty patchs" there to work with some ASUS problem.
    You can find why Gujin did not find/choose not to use the EBIOS interface by booting DOS on your ASUS and executing dbgdisk.exe (type Control D to exit Gujin) and then reading the DBG file produced (on another PC).
    If you wonder how to boot DOS, take a similar USB disk and format it with a software called HPBOOT (HP Drive Key Boot Utility), then copy dbgdisk.exe (I think it is in standard.tar.gz) on that key and boot that key.
    This DBG file may tell you exactly what is the problem, if you do not understand I may help but I need to read this file too.

    Cheers, Etienne.

     
  • Hello Etienne,

    I have added output from dbgdisk.exe of good and bad BIOSes. I suppose, that problem is with this message:

    BIOS only or unknown ideIOadr/ideIOctrladr

    Aleksey.

     
  • Hello Aleksey,
    I have read good.dbg and bad.dbg and have a problem: nothing seems really wrong.
    The only bad thing for "bad.dbg" is that only one "hard disk" is found, number 0x80, which would mean that when booting from USB the real internal hard disk is not accessible (I assume there is one internal hard disk on the ASUS).
    The message "BIOS only or unknown ideIOadr/ideIOctrladr" at the end is to send an ATA command to all IDE hard disk, and only to them, so it is normal that the message appear for USB disks.
    So to repeat, the USB disk in bad.dbg is accessed using EBIOS by the ASUS, and Gujin should be able to see all its partitions.
    There are two possible causes:
    1) there is a bit in the USB description that the BIOS is reading which tells if the disk is removable or not. This bit is not accessible to Gujin, some BIOS will only implement Extended BIOS disk access when this bit is set, because they assume a removable disk is like a floppy and do not have a large capacity. That would explain why the USB disk used for the test in BAD.DBG can have access to EBIOS while your "production" 32 Mbytes USB cannot (two different USB disks with different USB descriptions).
    2) The BIOS of your ASUS is reading the MBR (first sector) of your 32 Mbytes USB disk and do not like what it is reading, and decides to only implement BIOS and no EBIOS for whatever reason. The MBR read is the Gujin MBR, so it may be possible to do something (When you boot HP DOS disk the first sector is HP MBR).
    I would say, to test that case, there are two solutions (shown from simple to complex):
    - Reinstall Gujin the way you do it usually, but add the option to the installer "-sig0x29=0x28" - that changes a signature from 0x29 (the most used value) to 0x28 (another value declared as valid in the documentation) and test if that solves your problem. If not you could use any other value than 0x29 or 0x28 and re-test.
    - Reset the MBR of your 32 Mbytes USB disk (for instance with the one of the HP disk) and then re-install Gujin in the first partition, taking care not to overwrite the MBR. That would be done with such Linux commands:
       $ sudo -s
       # dd if=/dev/sdb of=/save_sdb_mbr bs=512 count=1   # just saving for safety reasons, /dev/sdb has to be your 32 Mb USB
       # dd if=/dev/sdc of=/HPMBR bs=410 count=1 # the HP MBR WITHOUT its partition table, /dev/sdc has to be the HP key
       # dd if=/HPMBR of=/dev/sdb bs=410 count=1 # use the HP MBR on your 32 Mb USB, no partition overwrite
       The part in between bytes 410 and 512 is the partition table, you do not want to replace the 32 Mb partition table by the HP partition table, that is why the "bs=" parameter is different in previous commands…
       Then you have to use fdisk on /dev/sdb to activate (command A) the first FAT partition, and only that partition.
       Then you have to reinstall Gujin in your first partition (installing Gujin that way is not the simplest way), I assume you used
        # gujin /dev/sdb1  # will erase everything on sdb1 so backup before / restore after
    The second solution is more complex, so really take care of what you are typing…

    Can you tell me success/failure after these tests?

     
  • Etienne,

    I have forgotten to attach 32gb multiboot pen that was the cause of trouble. Now here are the results of dbgdisk with that pen attached:

    good2.dbg
    bad2.dbg

    So on working laptop here are 3 disks:
    0x80: 32mb USB pen with DOS and DBGDISK.EXE
    0x81: 32gb USB multiboot pan with many ISO images
    0x82: Internal HDD

    On ASUS there are 2 disks:
    0x80: 32mb USB pen with DOS and DBGDISK.EXE
    0x81: 32gb USB multiboot pan with many ISO images
    (no internal HDD attached, as you rightly supposed)

    Diff between bad.dbg and bad2.dbg apart from some number differences shows that:

    - done probe_bios base_disk 0x80
    +
    +Hard disk 0x81: BIOSDISK_gettype: write protect
    +   done probe_bios base_disk 0x80

    Maybe this is the cause of problem: BIOSDISK_gettype() tells Gujin 'write protect' and Gujin decides to not use that disk.

    Also, I've noticed strange number difference:

    -Probing BIOS Hard drives (total = 1):
    -Hard disk 0x80: BIOSDISK_gettype: returns 0x3, i.e. hard disk, probably nb sector = 0x8181 i.e. 33,153
    +Probing BIOS Hard drives (total = 2):
    +Hard disk 0x80: BIOSDISK_gettype: returns 0x3, i.e. hard disk, probably nb sector = 0x8182 i.e. 33,154
    EBIOS detected: version 0x3000, features(0x5): extended_fct enhanced

    That is what Gujin found for 32mb pen drive I suppose. The total number of sectors differs by 1 with and without second USB pen attached. Is that normal?

     
  • I have tried -sig0x29=0x28 option and that didn't helped.

     
  • Hello Aleksey,
    You correctly spotted the problem:
    Hard disk 0x81: BIOSDISK_gettype: write protect   done probe_bios base_disk 0x80
    What happens is that Gujin want to detect if hard disk 0x81 is present in function  BIOSDISK_gettype() of file disk.c, Gujin calls _BIOSDISK_gettype() of file bios.h which returns carry set, then Gujin ask what the error was to the BIOS by calling BIOSDISK_error() of disk.c and _BIOSDISK_getstatus() of bios.h and reads AH=3 which means "disk write-protected".
    For more info on those BIOS calls you can look at:
    http://www.ctyme.com/intr/rb-0639.htm
    http://www.ctyme.com/intr/rb-0606.htm
    http://en.wikipedia.org/wiki/INT_13H
    But there is a bug in _BIOSDISK_gettype() of file bios.h, in that this function only saves the carry flag after having modified it by the "shll" assembly instruction.
    If you can recompile Gujin after modifying the function in bios.h from:
    extern inline unsigned char
    _BIOSDISK_gettype (unsigned char disk, unsigned *nbsect,
       unsigned char *status)
      {
      unsigned char carry;
      unsigned dummy;

      asm ASMREAD (
    " xor %%dh,%%dh \n"
    " xor %%cx,%%cx \n"
    " int $0x13 # _BIOSDISK_gettype \n"
    " shll $16,%%ecx \n"
    " movw %%dx,%%cx \n"
    " movb %%ah,%1 \n"
    " setc %0 \n"
    : "=qm" (carry), "=qm" (*status), "=c" (*nbsect), "=d" (dummy)
    : "a"((unsigned short)0x1500), "d" (disk) /* disk = 0x80..0x8F else buggy Compaq */
    );

      return carry;
      }
    to:
    extern inline unsigned char
    _BIOSDISK_gettype (unsigned char disk, unsigned *nbsect,
       unsigned char *status)
      {
      struct { unsigned char carry, status; } ax;

      asm ASMREAD (
    " xor %%dh,%%dh \n"
    " xor %%cx,%%cx \n"
    " int $0x13 # _BIOSDISK_gettype \n"
    " setc %%al \n"
    " shll $16,%%ecx \n"
    " movw %%dx,%%cx \n"
    : "=a" (ax), "=c" (*nbsect), "+d" (disk) /* disk = 0x80..0x8F else buggy Compaq */
    : "a"((unsigned short)0x1500)
    );
      *status = ax.status;
      return ax.carry;
      }
    Your problem may disappear. Note that I did not test that patch at all, I am at work and should really do something else right now…
    Cheers,
    Etienne.

     
  • > The total number of sectors differs by 1 with and without second USB pen attached. Is that normal?

    Well, that is a very usual bug, that is why it is writen as "probably nb sector".
    This number is not used if Extended BIOS is present because you have another way to get the number of sectors.
    Determining the number of sector of a disk is quite complex, Gujin has quite some "dirty patch" there, mostly when you begin to talk about SCSI disks (CDROMs/DVDs attached over ATAPI are more SCSI than ATA).

     
  • Hi Etienne,

    yes, that fix has perfectly worked!

    Also, I have tested byte order in ax structure. It works good: al gets to carry, ah gets to status.

    Thank you!

     
  • Etienne,

    I was premature with my 'perfectly' adverb. :) Yes, it shows menu items on Asus now. But it can't correctly start any of them (on laptop it still starts with no problems). Seems like execution goes to wrong address. This leads to senseless boot errors or just halts with garbled screen.

    I will supply dbgdisk output later.

     
  • At least there is improvement, it would be nice to have this dbgdisk to see if the disk has been detected correctly.
    If selecting the item do not work, it may be a problem with another subsystem, so maybe it is not dbgdisk.exe but dbgfs.exe or dbgload.exe which would give the right information.
    If you have a "General Protection", it may be the compiler you are using - it then would be nice to see the message (taking a photo of the screen may be the easiest) and I would need you to generate and send me the boot.asm you get by typing "make boot.asm" with that compiler.
    I will try to generate the installer "gujin" on a known good debian 32bits today and attach it to the tracker, I am sorry I am a bit busy at work and at home these days…

     
  • Aleksey,
    The tracker is limited to 256 Kb files, so you can download a temporary patched version here:
    http://sourceforge.net/projects/gujin/files/temporary_patches/gujin/download
    It will identify as version 2.8.* in the bottom of the screen.
    You may have to make this file executable after downloading it, use this installer as usual.
    It has been checked working on one of my PC.

     
  • Hi Etienne,

    I have compiled standard.tar.gz myself. I don't think that this causes some additional troubles.

    GOOD3.DBG
    BAD3.DBG

    Diff between bad2.dbg and BAD3.DBG:

    -Hard disk 0x81: BIOSDISK_gettype: write protect
    -   done probe_bios base_disk 0x80
    +Hard disk 0x81: BIOSDISK_gettype: returns 0x3, i.e. hard disk, probably nb sector = 0xB9000181 i.e. -1,191,181,951

    No doubt, that there is an error with number of sectors detection (right value should be close to 0x3B9E000).

     
  • Hi Aleksey,

    As I said, a lot of BIOSes are buggy there and Gujin only trust that value if it does not have anything else more safe.
    In your case, after the line:
    Hard disk 0x81: BIOSDISK_gettype: returns 0x3, i.e. hard disk, probably nb sector = 0xB9000181 i.e. -1,191,181,951
    you have:
    EBIOS (buffersize before 0x4A after 0x42) reports: nbhead: 255, nbsectorpertrack: 63, nbcylinder: 3891, bytepersector: 512, nbtotalsector: 62,513,152 …
    So gujin has found a better value and use it from now on:
    fully trusting disk content, adjusting bytepersector 512, nbtotalsector 62513152
    Basically there is three size reported: the one with BIOS (unreliable), the one with ExtendedBIOS (more reliable) and the one recognised by Linux and written into the MBR (only there if Gujin has been installed on that device).
    The last two are identical in your case and that is the ones that Gujin is using.
    So I know there was a bug in Gujin, triggered by your BIOS, and I need to generate a new version.
    The thing I am bothered with, is that you said there was a General Protection Exception or something like that when you try to load a kernel of your USB disk; that would be another problem, possibly unrelated.
    That is why I would like to know if you can use my gujin installer I have put on the WEB server to fully load your USB kernels, and I would still be interested to know (if my version works) which compiler you used to create that other problem.
    I would also like to know which exact problem is triggered, so would like the first few line of what Gujin displays (you can usually pause the screen with the "Pause" key), or take a photo of the screen.

    Cheers,
    Etienne.

     
  • Hi, Etienne!

    Yes, I\'ve tried your installer. No difference. As I said before, execution (of booted OS) goes to wrong address. As a consequence, the errors are senseless (and random per particular OS image). You can examine some photoshots here.

    Lyosha.

     
  • Correction: constant per particular OS image and random between different OS images.

     
1 2 > >> (Page 1 of 2)