Jump to content











Photo
- - - - -

access fdubcd.iso content from grub4dos


  • Please log in to reply
179 replies to this topic

#1 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 20 December 2012 - 02:06 PM

I am using UBCD 5.1.1, usually booting it to the isolinux/syslinux menu. There is an alternative grub4dos menu, and both menus can chainload from/to each other.
 
From the syslinux menu, fdubcd.iso (listed as FDUBCD in the initial boot menu of UBCD) can be booted (using MEMDISK), and all the DOS-based programs can be accessed as expected.
 
But, when FDUBCD is booted from grub4dos, the content of fdubcd.iso can't be accessed once in DOS, so most of the DOS programs can't be executed.
 
For those that already know UBCD 5.1.1, the difference is that when booting fdubcd.iso with isolinux -> MEMDISK, then drive "T:" in fdubcd is the content of fdubcd.iso (as expected), but when booting fdubcd.iso with (isolinux ->) grub4dos, then drive "T:" in fdubcd is the content of the full UBCD, so the content of fdubcd.iso can't be accessed.
 
When booting fdubcd.iso from the syslinux/islonux menu, the entry (which works correctly) is:
 
 
LABEL FDUBCD
LINUX /boot/syslinux/memdisk
INITRD /ubcd/images/fdubcd.iso.gz
APPEND iso raw

When booting fdubcd.iso from the grub4dos menu, the entry (which boots fdubcd.iso correctly but doesn't allow the expected access to its content once in DOS) is:
 
 
 
title FDUBCD\n
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook root (hd32)
chainloader (hd32)

If I customize UBCD by expanding the content of fdubcd.iso (and the content of fdubcd.img inside it), thus having the images and their expanded contents in UBCD, then grub4dos can use the DOS programs because it finds them (expanded already) in UBCD.
 
I would like to avoid this "extra" expansion in my customized UBCD, and still have access to the content of fdubcd.iso once in DOS. I am hoping that some improvements to the grub4dos entry could achieve the goal, but if this would be not enough, then any other advice is welcome. If there is a specific grub4dos version that could solve this issue, I'd be happy to know about it.
 
I don't know much about grub4dos commands / parameters, so the menu posted above is just the one that comes in UBCD 5.1.1.

I would appreciate any advice on the potential modifications to the above grub4dos menu so to achieve the goal.
 
If I wasn't clear enough, or some additional info is required, I'll be happy to provide it; just ask.

#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,340 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 20 December 2012 - 03:26 PM

Try

 

Issue has already been reported http://www.ultimateb...pic.php?p=24354

I copied the contents of UBCD 5.1.1 ISO to a USB Flash drive and installed grub4dos (using RMPrepUSB).

Then booted it in QEMU and selected the UBCD FreeDos R1.44 (Based on NwDsk V3.40) entry

I was then given a Boot UMBPCI menu which I allowed to timeout

It then started unpacking files and finally gave me a pop-up box with Launch / NwDisk / Help / Browse options

Launch produces a 'no CD' error

NwDisk - List all drives lists A:  Q: and C:  (no T: drive which should be the virtual CD!)

 

If I then install Syslinux, Launch works and I get  a choice of CD applications - NwDisk lists T:

 

I then tried this entry

title FDUBCD WITH STEVE'S FIX!
map --mem /ubcd/images/fdubcd.iso.gz (0xff)
map --hook
root (0xff)
kernel /memdisk iso
initrd (bd)/ubcd/images/fdubcd.iso.gz 

and it worked! It is messy because it needs to get memdisk from inside the ISO and then reload the same ISO into memory - but, hey, it works!  :clap:


This also works and is better!

title UBCD FreeDOS R1.44 (Based on NwDsk V3.40)\n FreeDOS boot disk used to run many of the other DOS apps on the UBCD. Revised\n version of Eric Veermans' FreeDOS NwDsk 3.40. Addresses many bug fixes,\n performance enhancements and compatibility issues. 
kernel /boot/syslinux/memdisk iso 
initrd (bd)/ubcd/images/fdubcd.iso.gz

 



#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,845 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 December 2012 - 03:41 PM

Hmmm.

 

ady, can you specify the name and path of the .lst from which you took the grub4dos menu entry you posted?

 

There is IMHO little (of none at all) sense to load the whole ISO to memory.

 

:cheers:

Wonko



#4 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,340 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 20 December 2012 - 03:45 PM

A better alternative is to get memdisk from the USB drive directly

 

Original HBCD entry in  \ubcd\menus\grub4dos\main.lst - does not find CD when FreeDos boots from ISO...

 

title UBCD FreeDOS R1.44 (Based on NwDsk V3.40)\n FreeDOS boot disk used to run many of the other DOS apps on the UBCD. Revised\n version of Eric Veermans' FreeDOS NwDsk 3.40. Addresses many bug fixes,\n performance enhancements and compatibility issues.
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook
root (hd32)
chainloader (hd32)
Change it to this and FreeDOS does find the CD!
title UBCD FreeDOS R1.44 (Based on NwDsk V3.40)\n FreeDOS boot disk used to run many of the other DOS apps on the UBCD. Revised\n version of Eric Veermans' FreeDOS NwDsk 3.40. Addresses many bug fixes,\n performance enhancements and compatibility issues.
kernel /boot/syslinux/memdisk iso
initrd (bd)/ubcd/images/fdubcd.iso.gz 

 

 

 


#5 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 20 December 2012 - 04:47 PM

When booting fdubcd.iso from the syslinux/islonux menu, the entry (which works correctly) is:
LABEL FDUBCD
LINUX /boot/syslinux/memdisk
INITRD /ubcd/images/fdubcd.iso.gz
APPEND iso raw

When booting fdubcd.iso from the grub4dos menu, the entry (which boots fdubcd.iso correctly but doesn't allow the expected access to its content once in DOS) is:
title FDUBCD\n
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook root (hd32)
chainloader (hd32)
 


Please try:
title FDUBCD
  map --mem /ubcd/images/fdubcd.iso.gz (hd96)
  map --hook root (hd96)
  chainloader (hd96)
and report your results. MEMDISK uses the same BIOS drive number as (hd96) for .ISOs, by default, so that'd be a good first test.

#6 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,340 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 20 December 2012 - 05:02 PM

(hd96) does not work - still no CD...

 (0xff) or (0a0x) do not work either.

 

I also unzipped the ISO and tried this (no -mem)

map /ubcd/images/fdubcd.iso (hd96)
map --hook root (hd96)
chainloader (hd96)

 

which does not work either.


#7 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 20 December 2012 - 05:12 PM

@Wonko,
 
I copied the entries from the original ubcd511.iso, just skipping the help text and with a shortened title / label, so the commands are the same as the original UBCD 5.1.1. The paths for the respective relevant boot menus inside the iso are:
./ubcd/menus/syslinux/main.cfg
./ubcd/menus/grub4dos/main.lst

BTW, I want to repeat here the relevant code for the grub4dos -> fdubcd.iso entry (because of the little current formatting issues in the forum made me present the code in my first post a little bit different than I wanted to; hopefully this time it will be presented as I intend it):
 
 
 
 
title UBCD\n
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook
root (hd32)
chainloader (hd32)

If the respective entries to chainload between isolinux <-> grub4dos are relevant, please let me know so I will post them too.


@steve,

The idea is not to boot fdubcd.iso with MEMDISK, as it is already done from the syslinux/isolinux menu. The goal is to have an alternative method to boot fdubcd.iso (from grub4dos), instead of using (isolinux ->) memdisk, so to give this alternative for some case where, for whichever reason, memdisk won't work as expected in a certain system/BIOS/whatever. I should have presented these "conditions" (fdubcd.iso and grub4dos without memdisk) clearly.

In any case, the fdubcd.img floppy image inside fdubcd.iso is also booted with memdisk, so if memdisk fails to boot the iso image in a certain system, there is still the potential conflict of the same memdisk booting the floppy image in the same problematic system. Once the first fdubcd.iso can be booted by grub4dos (without memdisk) and used correctly in DOS, the next step would be to also provide an alternative boot method (other than memdisk) to the fdubcd.img inside fdubcd.iso.

I am wondering if the boot of the fdubcd.img floppy image by means of memdisk (after using grub4dos for fdubcd.iso) might have some influence on grub4dos or on DOS recognizing the content of fdubcd.iso as drive "T:"; or if, instead, it is just the DOS mode itself (independently of the fact that DOS is booted from - or resides in - fdubcd.img). If the problem for grub4dos to retain the content of fdubcd.iso is generated by memdisk or by fdubcd.img, that's one thing that might have some workaround. If the problem is the DOS mode itself, then the problem (and potential solution) is completely different than just a few adjustments to the boot entry or a specific grub4dos version.

It is not clear to me why grub4dos can "open" fdubcd.iso, use the content to boot fdubcd.img inside it, but then when the system is already in DOS the same content of fdubcd.iso is "lost" (or, in other words, it is not available for DOS to be used). Since I am not a developer, I probably wouldn't understand the technical details, but I would like to know if there is a solution related to grub4dos (specially if it depends on the menu entry commands or on the specific grub4dos version).

Now that I have added more specific and important details, I hope there is some solution regarding grub4dos and fdubcd.iso.

TIA,
Ady.

PS: While I am writing this post, I see new posts. I am posting this anyway for now and then I'll read the newer ones. Thank you.

#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,845 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 December 2012 - 05:27 PM

No, this is what I a m missing.

the ./ubcd/menus/grub4dos/main.lst in the copy of ubcd511.iso I have has these contents:

 

color cyan/black black/light-gray green/black yellow/black

title BIOS
configfile /ubcd/menus/grub4dos/bios.lst

title CPU
configfile /ubcd/menus/grub4dos/cpu.lst

title HDD
configfile /ubcd/menus/grub4dos/hdd.lst

title Memory
configfile /ubcd/menus/grub4dos/memory.lst

title Others
configfile /ubcd/menus/grub4dos/others.lst

title Peripherals
configfile /ubcd/menus/grub4dos/periph.lst

title System
configfile /ubcd/menus/grub4dos/system.lst

title UBCD FreeDOS R1.44 (Based on NwDsk V3.40)\n FreeDOS boot disk used to run many of the other DOS apps on the UBCD. Revised\n version of Eric Veermans' FreeDOS NwDsk 3.40. Addresses many bug fixes,\n performance enhancements and compatibility issues.
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook
root (hd32)
chainloader (hd32)

title User-defined
configfile /ubcd/custom/custom.lst

title
pause

title Reboot\n Reboot the PC.
reboot

title
pause

title ISOLINUX/SYSLINUX menu\n This entry will bring you back to the ISOLINUX/SYSLINUX menu.
chainloader /boot/isolinux/isolinux.bin || chainloader +1

Let us for the moment assume that you have burned a "real" CD, the CD will be boot disk, and it contains /ubcd/images/fdubcd.iso.gz which is mapped to (hd32) i.e. to a grub4dos "virtual" CD drive.

If I get it right you are using the ubc511.iso on a USB stick or similar, how exactly do you access/boot from it?

Or are you copying the contents of the ubcd511.iso to the root of the stick?

Or what?

 

:cheers:

Wonko


 



#9 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,340 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 20 December 2012 - 05:30 PM

See post #2 - the contents of the HBCD ISO are copied to a USB stick.



#10 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,340 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 20 December 2012 - 05:34 PM

@ady - Yes, It could be that memdisk when loaded after a grub4dos map --mem command, obliterates the grub4dos virtual CD image (held in memory), but if memdisk is used by grub4dos and then memdisk is used again by the syslinux FDD image, it just adds a second virtual image and the first virtual drive CD loaded by grub4dos is not lost.



#11 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 20 December 2012 - 05:46 PM

The idea is not to boot fdubcd.iso with MEMDISK, as it is already done from the syslinux/isolinux menu. The goal is to have an alternative method to boot fdubcd.iso (from grub4dos), instead of using (isolinux ->) memdisk, so to give this alternative for some case where, for whichever reason, memdisk won't work as expected in a certain system/BIOS/whatever. I should have presented these "conditions" (fdubcd.iso and grub4dos without memdisk) clearly.
MEMDISK has raw, bigraw, int, safeint. GRUB4DOS' map --mem has --memdisk-raw=
...
0.4.2 has introduced a new variable, memdisk_raw, to simulate the
memdisk-like raw mode. If the BIOS has no int15/87h, or if it has
buggy int15/87h support, you should set this variable before any
memdrives are used. ...
If there's a system where no combinations of these work, it should be reported and fixed.

In any case, the fdubcd.img floppy image inside fdubcd.iso is also booted with memdisk, so if memdisk fails to boot the iso image in a certain system, there is still the potential conflict of the same memdisk booting the floppy image in the same problematic system. Once the first fdubcd.iso can be booted by grub4dos (without memdisk) and used correctly in DOS, the next step would be to also provide an alternative boot method (other than memdisk) to the fdubcd.img inside fdubcd.iso.
If there's an available work-around, then that lessens the likelihood of a bug being reported and fixed.

I am wondering if the boot of the fdubcd.img floppy image by means of memdisk (after using grub4dos for fdubcd.iso) might have some influence on grub4dos or on DOS recognizing the content of fdubcd.iso as drive "T:"; or if, instead, it is just the DOS mode itself (independently of the fact that DOS is booted from - or resides in - fdubcd.img).
It is trivial to remove MEMDISK from the whole case. Extract fdubcd.img from the .ISO, the use two "map --mem"s; one for the .ISO and one for the floppy image. Then boot the floppy image. If that test fails, well there's no MEMDISK involved.

If the problem for grub4dos to retain the content of fdubcd.iso is generated by memdisk or by fdubcd.img, that's one thing that might have some workaround. If the problem is the DOS mode itself, then the problem (and potential solution) is completely different than just a few adjustments to the boot entry or a specific grub4dos version.
It might be worth-while to test the El Torito stuff from the FreeDOS by using the El Torito DOS utilities included with Syslinux under dosutil/

It is not clear to me why grub4dos can "open" fdubcd.iso, use the content to boot fdubcd.img inside it, but then when the system is already in DOS the same content of fdubcd.iso is "lost" (or, in other words, it is not available for DOS to be used). Since I am not a developer, I probably wouldn't understand the technical details, but I would like to know if there is a solution related to grub4dos (specially if it depends on the menu entry commands or on the specific grub4dos version).
It's possible that there's a bug somewhere that needs fixing.

#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,845 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 December 2012 - 05:47 PM

See post #2 - the contents of the HBCD ISO are copied to a USB stick.

This is what YOU did.

I am asking to ady what HE does (possibly exactly).

 

:cheers:

Wonko



#13 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 20 December 2012 - 05:49 PM

@ady - Yes, It could be that memdisk when loaded after a grub4dos map --mem command, obliterates the grub4dos virtual CD image (held in memory), but if memdisk is used by grub4dos and then memdisk is used again by the syslinux FDD image, it just adds a second virtual image and the first virtual drive CD loaded by grub4dos is not lost.
MEMDISK doesn't "obliterate" unless it's told to with an explicit option, and, given that option, would "obliterate" a previous MEMDISK the same as any other INT 0x13 hook, without bias.

#14 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 20 December 2012 - 06:12 PM

@Sha0,

I tried your "hd96" suggestion. The behavior, once in DOS, seems to be the same as with "hd32". Maybe some other parameter would need changes in the DOS scripts, but I'd rather not get to that point since booting with MEMDISK is currently working as expected.


@Wonko,

I am, currently, testing in a very basic VM, booting with ubcd511.iso as a PATA optical drive (or customized with the suggestions from this topic). Previously I tested with a real CD and also a UFD built with the ubcd2usb script from UBCD.

This problem (booting fdubcd.iso using grub4dos without memdisk and without also adding the expanded content of fdubcd.iso) is a known problem for UBCD, replicated by several users and also by the developer of UBCD.

I am also testing other alternatives (and I think I _might_ have found one), instead of using fdubcd.iso, but each one has its own negative effects. In this topic I am limiting the tests to keep using fdubcd.iso.

The current situation is that booting fdubcd.iso with the grub4dos entry I posted (taken from ubcd 5.1.1), most of the DOS-based programs won't work because the content of drive "T:" is not the expected one in the scripts used by fdubcd. Having fdubcd.iso, and its fdubcd.img inside it, and _also_ having their contents already expanded in the boot media (the burnt ubcd*.iso, or the UFD) "works" because when fdubcd.iso is booted with grub4dos, the resulting "T:" drive under DOS is the boot media (the burnt ubcd*.iso or the UFD), so eventually the DOS scripts are able to find the cab files where the DOS programs reside.

In other words, when booting fdubcd.iso with grub4dos (not memdisk), the resulting "T:" is the content of the original boot media, and when booting fdubcd.iso with memdisk the resulting "T:" is the content of fdubcd.iso (which is the expected and needed one).

I am still trying to find a working grub4dos entry so to make it (fdubcd.iso) work as close as possible as when it is booted with (syslinux/isolinux->) memdisk (but without actually using memdisk). Any advice is appreciated.

TIA,
Ady

PS: For some reason, my connection to reboot.pro is currently very slow, just as my writting skills. I'll read the new posts I am seeing (while I was writing this one) and I'll answer ASAP.

#15 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 20 December 2012 - 07:10 PM

@Sha0,

Indeed the syslinux/isolinux -> memdisk method successfully uses "iso raw" for fdubcd.iso. I don't know if grub4dos has some similar or equivalent command or parameter, or if it is even necessary for grub4dos and fdubcd.iso. If such command exists, I'll appreciate someone suggesting it here.


(of topic)
Regarding some system not booting fdubcd.iso with memdisk, I can't really answer that. All I know is that the developer of UBCD will rather keep the grub4dos alternative for fdubcd (without using memdisk), just in case memdisk doesn't boot fdubcd.iso correctly in a certain system. In older versions, there was only a floppy image, fdubcd.img, and that used to work from either grub4dos or memdisk. Since it is not working correctly with grub4dos + fdubcd.iso, there are several alternatives. One would be finding the adequate grub4dos parameters. Other alternatives involve getting fdubcd.iso out of the equation (and there are already 3 possibilities being evaluated and tested if this second option is the chosen one). But in this topic I am still trying to find a solution to the first possibility: to keep fdubcd.iso with an adequate entry from grub4dos without memdisk.
(/of topic)


Regarding testing eltorito.sys, I am not sure what or how to test (advice?). The dosutils are already used in fdubcd. But before testing eltorito, the first question is whether the described behavior of grub4dos is unexpected. Just as specific drivers or other techniques are used when booting some specific types of iso images (whether from memdisk or from grub4dos), maybe the described behavior is expected, so the answer would be that currently there is no grub4dos parameter(s) or command(s) to solve or workaround the described situation with fdubcd.iso booted from grub4dos without memdisk.

About the possibility of removing fdubcd.img (and using its content directly from fdubcd.iso), it is not likely to happen (I'm not saying it is not possible). But anyway, in this topic I am trying to find the solution from the side of grub4dos, leaving fdubcd.iso and fdubcd.img without changes if at all possible, since they already work correctly for the main case (syslinux/isolinux -> memdisk). If fdubcd.iso has to change, then that's a completely different alternative, which is already being evaluated but it is not part of this topic. To be clear, I am not saying that it must be solved this way. I am just saying that if there is a solution that involves changing the parameters/commands/arguments of grub4dos or using a specific version of grub4dos, it would be very helpful to find it and test it, instead of having to use other alternatives that have their own negative effects.

@Steve:
Yes, It could be that memdisk when loaded after a grub4dos map --mem command, obliterates the grub4dos virtual CD image (held in memory),...
So, is the behavior described in my first posts expected? Is there any grub4dos command that could resolved this situation?
Is there an alternative other than booting fdubcd.img with memdisk (after fdubcd.iso is booted with grub4dos)? I mean a grub4dos alternative for fdubcd.img that would also maintain the content of fdubcd.iso available as "T:".
And what about a grub4dos equivalent to the "append raw" used with "isolinux -> memdisk -> fdubcd.iso"? Again, when I say "grub4dos", I mean without using memdisk.

I really appreciate all your inputs.

TIA,
Ady.

Edited by ady, 20 December 2012 - 07:20 PM.


#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,845 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 December 2012 - 07:17 PM

Yes, but if you try (and other people try in the attempt to help you) n different settings approaches and what not, there will not be n solution but either one or a few solutions for "unidentified" environment or no solutions at all.

I would propose a "plan". :unsure:

Let's see what happens ONLY with the ubcd511.iso mounted as CD in a VM. (and solve *somehow* this).

Then (and only after a solution for this environment, replicable by everyone, has been found) go to next step, contents of the ubcd511.iso copied "flat" to a USB stick (what Steve6375 was testing) then, once a solution to this has been found, let's tackle the next ordeal, the ubcd511.iso mapped to (0xff) or (hd32).

 

:cheers:

Wonko



#17 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,340 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 20 December 2012 - 07:21 PM

 

title test
map --mem (bd)/ubcd/images/fdubcd.iso (0xff)
map --hook
root (0xff)
map --mem /fdubcd.img (fd0)
map --hook
root (fd0)
chainloader /kernel.sys
This also fails (flat boot from USB) and there is no memdisk or syslinux involved.
 


#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,845 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 December 2012 - 07:42 PM

QEMU.

ubcd511.iso mounted as CD

booted from floppy disk loading grub4dos

MANUAL COMMANDS on command line:

 



root (cd)

chainloader

boot

 

in "main" Isolinux menu choose "grub4dos menu"

in grub4dos menu choose UBCD FreeDOs ...

text menu choose 7 Boot No UMB (ultradefensive)

 

The detection of CDROM fails and you have drive letters A: and Q:

"Exit" and type cdrom

Choose config, set "Fixed" and then "ATA", save, OK.

The CDROM is now detected and mapped as T:, it is accessible, you can list files on it, etc. etc.

Type ubcd

Then "Launch"

Error saying that there is NO cdrom (while there is one, and you can access it allright).

 

Preliminary conclusion:

the CDROM detection routine is flawed (TWICE), first one because it cannot find the CDROM and load it's driver, the second because after having loaded the driver and mounted the cd-rom to drive letter T: the CDROM is still not detected by the "Launch".

 

If booted directly to CD the first autodetection works, but the second still fails (but not always, in a few tests it "went through", meaning that possibly there is additionally a timing problem of some sort :w00t:

 

I take back last sentence, mistake on my part, sorry.

 

 

:cheers:

Wonko



#19 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 20 December 2012 - 07:53 PM

Yes, but if you try (and other people try in the attempt to help you) n different settings approaches and what not, there will not be n solution but either one or a few solutions for "unidentified" environment or no solutions at all.
I would propose a "plan". :unsure:
Let's see what happens ONLY with the ubcd511.iso mounted as CD in a VM. (and solve *somehow* this).
Then (and only after a solution for this environment, replicable by everyone, has been found) go to next step, contents of the ubcd511.iso copied "flat" to a USB stick (what Steve6375 was testing) then, once a solution to this has been found, let's tackle the next ordeal, the ubcd511.iso mapped to (0xff) or (hd32).

@Wonko, I apologize if I wasn't clear enough. I am indeed following one path / proposal / workaround / attempt at a time. I am not mixing them. Each suggestion and attempt started from the same point, the original UBCD 5.1.1.

For example, when I said I was successful when adding the expanded content of the images in addition to the images themselves, that was using the original grub4dos entries already used in ubcd511. For each suggestion from Steve or from Sha0, I started again from the same point, UBCD 5.1.1 "as-is", and I made only that suggested change, I generated a _new_ ubcd.iso and used that new ubcd.iso as a booting optical drive for the same VM. The purpose of my posts was to answer the questions or provide feedback about each suggestion, hoping it will gave enough input so to come up with a new grub4dos entry that could solve the problem.

BTW, having the images and the content simultaneously also expanded is not an adequate solution for this issue. If that's the best we can do with grub4dos + fdubcd.iso, then "sadly" there might be other (most probably better) alternatives (that involve more work than correcting grub4dos boot entries, like getting rid of fdubcd.iso, so that's out of the goal of this topic).

 
 
title test
map --mem (bd)/ubcd/images/fdubcd.iso (0xff)
map --hook
root (0xff)
map --mem /fdubcd.img (fd0)
map --hook
root (fd0)
chainloader /kernel.sys
This also fails and there is no memdisk or syslinux involved.

@Steve, I am used to syslinux directives, but not to grub4dos commands. If I understand correctly, you copied fdubcd.img from fdubcd.iso and pasted it to the root of the resulting main media (your UFD I guess). Am I correct? Was this failing in the exact same way as before? Was fdubcd.img "copied", or "moved" out of the fdubcd.iso image? Is there any equivalent to the "raw" memdisk parameter for grub4dos?

TIA,
Ady.

#20 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 20 December 2012 - 08:00 PM

Indeed the syslinux/isolinux -> memdisk method successfully uses "iso raw" for fdubcd.iso. I don't know if grub4dos has some similar or equivalent command or parameter, or if it is even necessary for grub4dos and fdubcd.iso. If such command exists, I'll appreciate someone suggesting it here.
...
And what about a grub4dos equivalent to the "append raw" used with "isolinux -> memdisk -> fdubcd.iso"? Again, when I say "grub4dos", I mean without using memdisk.
Please re-read my quote from the README_GRUB4DOS.txt file. But it's the default mode in GRUB4DOS anyway, so it won't help here, unless disabling it makes a difference. (Worth a try.)


title test
map --mem (bd)/ubcd/images/fdubcd.iso (0xff)
map --hook
root (0xff)
map --mem /fdubcd.img (fd0)
map --hook
root (fd0)
chainloader /kernel.sys
This also fails and there is no memdisk or syslinux involved.


I think perhaps you might've meant --rehook in there:
title test
# Might as well use the same drive number as MEMDISK
map --mem (bd)/ubcd/images/fdubcd.iso (0xE0)
map --hook
root (0xE0)
map --mem /fdubcd.img (fd0)
map --rehook
# Should be two entries
map --status
root (fd0)
# Let it boot itself as MEMDISK would
chainloader +1


#21 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 20 December 2012 - 08:01 PM

The detection of CDROM fails and you have drive letters A: and Q:
"Exit" and type cdrom
Choose config, set "Fixed" and then "ATA", save, OK.
The CDROM is now detected and mapped as T:, it is accessible, you can list files on it, etc. etc.

@Wonko, Is that "T:" showing the content of fdubcd.iso? Or is it the content of ubcd511.iso?

In my tests with grub4dos, that "T:" is ubcd511.iso; and when using memdisk for fdubcd.iso, that "T:" shows the content of fdubcd.iso. The "Launch" command expects that "T:" to be the content of fdubcd.iso, and that's why with grub4dos, the "launch" fails.

#22 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1,676 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 20 December 2012 - 08:16 PM

Regarding testing eltorito.sys, I am not sure what or how to test (advice?). The dosutils are already used in fdubcd.
I apologize. I thought we had incorporated some of Bart Lagerweij's tools into Syslinux. I was thinking of ETTool and ETDump and FindCD.

#23 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 20 December 2012 - 08:23 PM

Please re-read my quote from the README_GRUB4DOS.txt file. But it's the default mode in GRUB4DOS anyway, so it won't help here, unless disabling it makes a difference. (Worth a try.)

As I said, I am not used to grub4dos commands. I indeed read the "memdisk_raw" you mentioned, but I have no idea how exactly to test it. I don't really know what each grub4dos command means, or where to add them, if there is a specific order... With Syslinux I am fine most of the time, but I have no idea about grub4dos commands. That's why I am kindly asking for the commands, as specifically as possible. I mostly copy-paste them from the suggestions here.
 


 I think perhaps you might've meant --rehook in there:

title test
# Might as well use the same drive number as MEMDISK
map --mem (bd)/ubcd/images/fdubcd.iso (0xE0)
map --hook
root (0xE0)
map --mem /fdubcd.img (fd0)
map --rehook
# Should be two entries
map --status
root (fd0)
chainloader /kernel.sys
 

Sha0, I guess with "you", you meant Steve, right? Should I copy fdubcd.img and kernel.sys to the root of the boot media (ubcd.iso to be used as cd drive to boot a VM)? Or instead of "copy", should I "move" them out of the fdubcd.iso image? Or maybe Steve is ready with an answer while I am still trying to read, understand, and write back?

#24 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 20 December 2012 - 08:38 PM

I was thinking of ETTool and ETDump and FindCD.

I could add them and test them in ubcd511 (I know they are going to be included in the next stable release of ubcd anyway). Any specific steps or arguments (I need to learn about them)? Since we want info when booting with grub4dos, I will add them outside fdubcd.iso (to have access in the current state / behavior) and inside fdubcd.img (which is seen and accessed in any case).

It will take me some time to complete it all and report back (I am not as fast as I wish). In the meantime, if there are other tests or grub4dos commands or any other advice, I'll be happy to read them and try them (please, if you are so kind, post not just the command by itself but the complete grub4dos code so to be copied into the main.lst file).

TIA,
Ady.

#25 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,340 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 20 December 2012 - 10:09 PM

Please re-read my quote from the README_GRUB4DOS.txt file. But it's the default mode in GRUB4DOS anyway, so it won't help here, unless disabling it makes a difference. (Worth a try.)

I think perhaps you might've meant --rehook in there:

title test
# Might as well use the same drive number as MEMDISK
map --mem (bd)/ubcd/images/fdubcd.iso (0xE0)
map --hook
root (0xE0)
map --mem /fdubcd.img (fd0)
map --rehook
# Should be two entries
map --status
root (fd0)
# Let it boot itself as MEMDISK would
chainloader +1

Tried this and a few variations - none worked. :white_flag:

You can use hook twice (or more than twice). A map --status showed me that both hook and rehook work. 

Rehook does not have to be used after one hook has been done, I think rehook just sorts out the hook map and gets rid of unnecessary mapping (e.g. a-b-c after a rehook becomes a - c) :dubbio: .

 

I also tried mapping to (rd) as this is supposed to be equivalent to memdisk, but that doesn't seem to work either...