Jump to content











Photo
- - - - -

access fdubcd.iso content from grub4dos


  • Please log in to reply
179 replies to this topic

#26 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 20 December 2012 - 10:11 PM

I shall apologize for a previous report of mine, that now I know was incorrect.

I was having some problems with VBox 4.2.x (including VBox crashes), so I decided it was not worth going on in those conditions; I cleaned up and started over with VBox 4.1.22.

With this new VM, I tested again UBCD 5.1.1 with "hd96" as Sha0 suggested. Although it doesn't solve _all_ the problems found in fdubcd 1.44 (ubcd 5.1.1), the suggested change indeed makes the behavior of fdubcd equivalent for both boot methods, grub4dos and memdisk.

Since I was testing by booting from a (virtual) optical drive, now I have the doubt whether this change should also work when booting from UFD with the same grub4dos menu, specially since Steve reported a failure with this "hd96".

Should this "hd96" be adapted to something else when the main media (UBCD, not fdubcd) is not an optical drive?

If anyone else could confirm this report and also test a UFD (since Steve's first test failed), that would be helpful.

TIA,
Ady.

 



#27 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,050 posts
  •  
    Belgium

Posted 20 December 2012 - 11:53 PM

The grub4dos menu works for me in qemu (when booting from the ISO):
qemu -boot d -cdrom ubcd51.iso
 when changing the grub4dos line to:
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 (hd96)
map --hook
root (hd96)
chainloader (hd96)

and when I select not the default boot entry in FreeDOS, but choose to use an option that allows to configure the cdrom settings.

e.g:

 

2 Boot UMBPCI (optimal)

In the config settings for cdrom, choose:

 

Fixed, always load:
 [x] Eltorito


#28 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 21 December 2012 - 12:17 AM

@Icecube,

 

I've been testing all those options in UBCD 5.1.1. with no success. After reading your post I just tested it again and I can't reproduce your result. As I said before, in UBCD 5.1.1 you _can_ access a "T:" drive when fdubcd.iso is booted with grub4dos, but its content is not the needed by the scripts. To test it, try "launch" so to select some DOS program included in fdubcd.iso. In my tests, the DOS menu (very similar to the initial boot menu of UBCD) won't show up. The content of fdubcd.iso can't be found. Instead, "T:" represents the content of the main boot media, which is different from the content of fdubcd.iso.

 

Now, with "hd96" I can access the DOS programs, but not when UBCD is booted from UFD (installed by means of the ubcd2iso script). So, I am still searching for more advice.

 

TIA,

Ady.

 

EDIT: With Icecube's update of the above post, his results are now in line with my tests.


Edited by ady, 21 December 2012 - 12:48 AM.


#29 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,050 posts
  •  
    Belgium

Posted 21 December 2012 - 12:33 AM

@ ady

Updated previous post (works at least when booting from UBCD CDROM).



#30 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 21 December 2012 - 12:51 AM

@ ady

Updated previous post (works at least when booting from UBCD CDROM).

That's in line with what I reported. But it seems it can't be done just with "hd96" when booting from UFD. More tests and advice needed.



#31 tinybit

tinybit

    Silver Member

  • Developer
  • 914 posts
  •  
    China

Posted 21 December 2012 - 02:47 AM

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:

 

 

I can imagine it should be a problem with the ELTORITO DOS driver. The driver cannot successfully "drive" the eltorito cdrom drives created by grub4dos.

 

In my humble opinion it is in the wrong direction to seek for solution in other ways. The only (correct) solution is to fix the eltorito DOS driver.



#32 Victor Chew

Victor Chew
  • Members
  • 5 posts
  •  
    Singapore

Posted 21 December 2012 - 05:04 AM

The original topic that started this discussion can be found here. It contains more information regarding etdump info etc.

 

The bug report I filed on grub4dos can be found here.

 

Under VMPlayer V5.0.1, using (hd96) doesn't work. T: maps to the content of UBCD, not FDUBCD. Yes, (hd96) maps to the drive table entry (0xE0) used by memdisk, but the drive table issue remains.

 

Basically, you only get this problem when you are booting UBCD from a CD, which then creates an emulated CDROM drive to boot FDUBCD. The new eltorito drive should be the emulated CDROM drive and mounted by eltorito.sys, while UBCD is mounted by a installable device driver (PATA or SATA).

 

As far as I can tell, you _don't_ get this problem when you are booting UBCD from USB. eltorito.sys mounts the emulated CDROM drive as expected. This has been tested on physical machines (eg. HP D630)

 

Any insight into this behaviour will be much appreciated.


Edited by Victor Chew, 21 December 2012 - 05:16 AM.


#33 Victor Chew

Victor Chew
  • Members
  • 5 posts
  •  
    Singapore

Posted 21 December 2012 - 05:20 AM

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

 

Just to address this point, if we chainload memdisk via grub4dos, then it defeats the purpose of using grub4dos in the first place. The reason why grub4dos was added to UBCD was because its disk emulation logic have been reported to work on some systems where memdisk have failed.


Edited by Victor Chew, 21 December 2012 - 05:23 AM.


#34 Sha0

Sha0

    WinVBlock Dev

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

Posted 21 December 2012 - 07:40 AM

Tell me where to download stuff. I will attempt to reproduce the issue and fix the problem.

#35 steve6375

steve6375

    Platinum Member

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

Posted 21 December 2012 - 09:14 AM

To reproduce this issue when booting from a grub4dos USB flash drive - see http://www.rmprepusb.../tutorials/ubcd   (but install grub4dos not syslinux). Then (in my case) boot the USB drive using QEMU.

 

NOTE: If I boot from a REAL computer - e.g EeePC 904HA Intel atom netbook,  there is NO PROBLEM with any menu entry (the CDROM T: is found and the CD Applications are listed and run) - it is only under QEMU that there is a problem.

 

 

The point is that if you use memdisk in grub4dos then the FreeDOS CD driver works OK, but if you use map --mem then the FreeDos driver does not work.

 

So whatever map --mem is doing, it is not equivalent to memdisk.

 

I have tried various things including (rd) and lots of different mapping numbers and even tried  to avoid using the syslinux that is inside the DOS floppy image by using the following entry in \ubcd\menus\grub4dos\main.lst

title test
map --mem (bd)/ubcd/images/fdubcd.iso.gz (0xe0)
map --hook
root (0xe0)
map --mem /fdubcd.img (fd0)
map --rehook
root (fd0)
chainloader +1

 

Nothing seems to work except using

 

kernel /boot/syslinux/memdisk iso
initrd (bd)/ubcd/images/fdubcd.iso.gz 

 

 


#36 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 December 2012 - 09:41 AM

I can imagine it should be a problem with the ELTORITO DOS driver. The driver cannot successfully "drive" the eltorito cdrom drives created by grub4dos.
 
In my humble opinion it is in the wrong direction to seek for solution in other ways. The only (correct) solution is to fix the eltorito DOS driver.

It sounds to me exactly the same "right" approach, this is what I meant when I talked of issues with the CD-ROM detection.
 
Maybe this could be an occasion (besides finding a workaround provisional fix for UBCD 5.11) to find a good solution for 5.12. :)
 
Since Victor Chew :worship: came in, I will dare :ph34r: to ask him a question:
Why the actual *need* of putting the fdubcd.img inside a .iso at all?
 
Unless there are some valid reasons (which at first sight I am completely missing :ph34r:), the current setup seems to me a lot like a matrioschka :w00t: with compressed images expanded to memory to load images of compressed files that are expanded to memory again (ramdisk).
 
@ady +@Steve6375
Besides the "right" way with (hd96) (which still uses however the memdisk inside fdubcd.iso.gz)
this works alright for me in Qemu:

 






map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook
map --mem (hd32)/fdubcd.img (fd0)
map (hd32) (cd)
map --hook
root (fd0)
chainloader +1
boot

and should be more or less the answer to the first question, i.e. how to boot from CD bypassing completely the memdisk.
 
Seemingly if the .iso image is mapped to (cd) the driver "catches it", while it doesn't until it is mapped to (hd32) or similar. :dubbio:
 
 
:cheers:
Wonko



#37 tinybit

tinybit

    Silver Member

  • Developer
  • 914 posts
  •  
    China

Posted 21 December 2012 - 09:43 AM

ScanDrives:	push	ax		; at df3 in 1.4
		push	si
		mov dl, 7fh		;Start at Drive 0x80
NextDrv:	inc	dl
		clc
		mov	ax,4B01h	;Get Bootable CD-ROM Status
		mov	BYTE [SpecPkt],0	;Clear 1st byte of SpecPkt
		call	SpecGo
; Carry is not cleared in buggy Dell BIOSes,
; so I'm checking packet size byte
; some bogus bioses (Dell Inspiron 2500) returns packet size 0xff when failed
; Dell Dimension XPsT returns packet size 0x14 when OK

		cmp	BYTE [SpecPkt], 13h	; anything between 13h and 20h should be OK
		jb	FindFail
		cmp	BYTE [SpecPkt], 20h
		ja	FindFail	; in 1.4 at e16
		jmp	short SendFound	; in 1.4 at e26

FindFail:	cmp	dl, 0ffh
		je	SendFail		; Check from 80h..ffh
		jmp	short NextDrv		;Next drive
SendFail:	xor	dl,dl
		stc
		jmp	short ThingDone
SendFound:	mov	dl, [SpecPkt+2]
		clc
ThingDone:	pop	si
		pop	ax
		retn
		; *** end 1.4 changes ***

Look at the above source code for eltorito.sys. It scans the CDROMs from 0x80 upward. I think it would be better to scan from 0xFF downward. Grub4dos users tend to use 0xFF for the virtual CDROM, at least the README_GRUB4DOS.txt has suggested the use of 0xFF for DOS, for historical reasons.

 

If the scan is from 0xFF downward, then the first drive 0xFF is encountered and should succeed immediately. No problem would occur.

 

The above code has another issue. Look at this:

 

SendFound:	mov	dl, [SpecPkt+2]
		clc
ThingDone:	pop	si
		pop	ax
		retn

It should firstly compare [SpecPkt+2] with DL, if not equal, it should fail out. At least one BIOS has etdump output as follows:

 

FF: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
FE: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
..
9F: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
..
81: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
80: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7

 

In the above output, only the line for drive 9F is correct. All the others are meaningless.



#38 steve6375

steve6375

    Platinum Member

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

Posted 21 December 2012 - 10:01 AM

Unfortunately, mapping to cd on my setup (booting QEMU from physical USB grub4dos boot flash drive) gives me a grub4dos error 'Error 23: Error while parsing number'  :dubbio:



#39 tinybit

tinybit

    Silver Member

  • Developer
  • 914 posts
  •  
    China

Posted 21 December 2012 - 10:09 AM

Unfortunately, mapping to cd on my setup gives me a grub4dos error 'Error 23: Error while parsing number'

 

If the eltorito cdrom is "active"(meaning you had booted the machine in no-emulation mode), then you can use the (cd) for it.

 

If not, you cannot use the "(cd)", because it is invalid, or say, not present.



#40 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 December 2012 - 10:11 AM

Unfortunately, mapping to cd on my setup gives me a grub4dos error 'Error 23: Error while parsing number'  :dubbio:

But you are seemingly using a completely different setup with image on a USB stick, and most probably a newer (different) version of grub4dos :unsure: then the one in UBCD5.11.
 

and should be more or less the answer to the first question, i.e. how to boot from CD bypassing completely the memdisk.

 


The above tests works in Qemu, let's see what happens to ady in virtualbox and then on the actual hardware he uses.
 
 
:cheers:
Wonko



#41 steve6375

steve6375

    Platinum Member

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

Posted 21 December 2012 - 10:21 AM

On a real machine, booting from USB works, but under QEMU, Oracle VM and VMware Player booting from the same \\physicaldrivex USB drive gives the 'no cd' symptom. So I think it is important to test any changes/modifications on real h/w  as well as test the same change under a VM, as it seems to me that VMs and QEMU behave differently from real systems. :dubbio:



#42 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 December 2012 - 10:39 AM

On a real machine, booting from USB works, but under QEMU, Oracle VM and VMware Player booting from the same \\physicaldrivex USB drive gives the 'no cd' symptom. So I think it is important to test any changes/modifications on real h/w  as well as test the same change under a VM, as it seems to me that VMs and QEMU behave differently from real systems. :dubbio:

Yes, and you should also test UBCD511.ISO:

  • from internal ATA (PATA) disk
  • from internal SATA disk
  • from internal SATA CD
  • from CF-CARD USB connected
  • from CF-CARD PATA connected
  • from CF-CARD SATA connected
  • from any device SCSI connected
  • from any device FireWire connected
  • and don't forget ZIP and JAZZ disks through parallel port

I proposed to check one thing at the time, to avoid mixing reports and issues, I perfectly know (and tinybit just explained WHY) the given working solution - actually a workaround - ONLY applies when booting from CD (which actually was the first  question), of course you are perfectly free :) to take a completely different approach and mix together every possible setup and the related successes and failures.

 

:cheers:

Wonko



#43 Sha0

Sha0

    WinVBlock Dev

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

Posted 21 December 2012 - 10:46 AM

ScanDrives:    push    ax        ; at df3 in 1.4
        push    si
        mov dl, 7fh        ;Start at Drive 0x80
NextDrv:    inc    dl
        clc
        mov    ax,4B01h    ;Get Bootable CD-ROM Status
        mov    BYTE [SpecPkt],0    ;Clear 1st byte of SpecPkt
        call    SpecGo
; Carry is not cleared in buggy Dell BIOSes,
; so I'm checking packet size byte
; some bogus bioses (Dell Inspiron 2500) returns packet size 0xff when failed
; Dell Dimension XPsT returns packet size 0x14 when OK
        cmp    BYTE [SpecPkt], 13h    ; anything between 13h and 20h should be OK
        jb    FindFail
        cmp    BYTE [SpecPkt], 20h
        ja    FindFail    ; in 1.4 at e16
        jmp    short SendFound    ; in 1.4 at e26
FindFail:    cmp    dl, 0ffh
        je    SendFail        ; Check from 80h..ffh
        jmp    short NextDrv        ;Next drive
SendFail:    xor    dl,dl
        stc
        jmp    short ThingDone
SendFound:    mov    dl, [SpecPkt+2]
        clc
ThingDone:    pop    si
        pop    ax
        retn
        ; *** end 1.4 changes ***


Look at the above source code for eltorito.sys. It scans the CDROMs from 0x80 upward. I think it would be better to scan from 0xFF downward. Grub4dos users tend to use 0xFF for the virtual CDROM, at least the README_GRUB4DOS.txt has suggested the use of 0xFF for DOS, for historical reasons.
 
If the scan is from 0xFF downward, then the first drive 0xFF is encountered and should succeed immediately. No problem would occur.


Please review the rationale.


The above code has another issue. Look at this:

SendFound:    mov    dl, [SpecPkt+2]
        clc
ThingDone:    pop    si
        pop    ax
        retn

It should firstly compare [SpecPkt+2] with DL, if not equal, it should fail out. At least one BIOS has etdump output as follows:
FF: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
FE: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
..
9F: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
..
81: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
80: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7

In the above output, only the line for drive 9F is correct. All the others are meaningless.


I'll review that.  After downloading the subject matter, I'll find out if they're even using this version of ElTorito.sys.



#44 tinybit

tinybit

    Silver Member

  • Developer
  • 914 posts
  •  
    China

Posted 21 December 2012 - 10:57 AM

Please review the rationale.

 

 

I prefer the old eltorito.sys version of scanning downward,  because it should work ok with the virtual drive 0xFF of grub4dos.



#45 steve6375

steve6375

    Platinum Member

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

Posted 21 December 2012 - 11:16 AM

@wonko

Ady said:

Now, with "hd96" I can access the DOS programs, but not when UBCD is booted from UFD (installed by means of the ubcd2iso script). So, I am still searching for more advice.

TIA,

Ady.

 

 

This sounds to me as if the OP ady is looking for a CD and UFD (real h/w) solution? (can ady confirm?)

I presume that ady is making an ISO because he wants to eventually make a CD and boot from many different systems (which is why he does not want to use the memdisk solution because of suspected compatibility issues). He also seems to want to make a bootable grub4dos USB - again presumably to boot on a wide variety of physical systems.

So testing a real CD and real UFD on a real system seems like a sensible thing to do and it is easier to work on a flat file system on USB...



#46 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 December 2012 - 12:04 PM

So testing a real CD and real UFD on a real system seems like a sensible thing to do and it is easier to work on a flat file system on USB...

Yes ;), and all the other variations I listed and a few more.


The whole point I tried vainly to make was that I found advisable to do this in a given order, one at the time, as opposed to what was started (everyone testing a different setup/environment and mixing each and every report in such a way that it is difficult to understand to which setup/environment it refers to).

 

In any case the "real issue" remains the detection of the CDROM (and possibly the El-torito .sys driver).

 

:cheers:

Wonko



#47 steve6375

steve6375

    Platinum Member

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

Posted 21 December 2012 - 01:04 PM

If you boot the whole ubcd511 ISO from a USB stick under QEMU (booting with grub4dos) then it works if you use the syslinux menu (FreeDOS does find the CD) - but not if you use the grub4dos menu, as expected.

title UBCD 511
find --set-root /ubcd511.iso
map /ubcd511.iso (hd32)
map --hook
root (hd32)
chainloader (hd32)

Both syslinux and grub4dos menus do work on real h/w however.

 
 


#48 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 21 December 2012 - 01:45 PM

Why the actual *need* of putting the fdubcd.img inside a .iso at all?
 
Unless there are some valid reasons (which at first sight I am completely missing :ph34r:), the current setup seems to me a lot like a matrioschka :w00t: with compressed images expanded to memory to load images of compressed files that are expanded to memory again (ramdisk).

@Wonko, you are actually looking at this the "right" way, but I separated the "real" problem into pieces, because presenting all the story in just one topic seemed "too much", specially with so much different software involved (grub4dos, syslinux, memdisk, DOS, different booting media...).

A little bit of history, so to put things in context. In UBCD 5.0.3, fdubcd was booting a ram floppy disk, "A:". To access the DOS programs (inside cab files), fdubcd needs access to the booting media where the cabinet files were located. This access was not achieved in certain systems, so the DOS programs in cab files were not available.

In UBCD 5.1, the floppy image was inserted into a new fdubcd.iso, which now contains all the files that need to be accessed by fdubcd DOS. By using these 2 images, fdubcd was still booting to "A:" (fdubcd.img) and memdisk could still access the content of fdubcd.iso as an additional ramdrive. The only purpose of "booting" this fdubcd.iso was to provide (assure) access to the DOS programs, while still booting fdubcd using "A:".

The purpose of having grub4dos is to give more chances to boot into fdubcd, when memdisk fails for whichever reason. In UBCD 5.0.3, the entry for grub4dos was working as expected, because the cab files were located directly in the booting media. Once memdisk was working as needed in UBCD 5.1 (by DOS now being able to find the cab files in the ramdrive originated by fdubcd.iso), the entry in grub4dos needs a correction. As in UBCD 5.0.3, grub4dos is able to find the original boot media, but now the cab files are inside the new ramdrive based on fdubcd.iso; hence the current topic.

In theory, there are _other_ alternatives, without fdubcd.iso. Using a superfloppy image for fdubcd.img is one, and using a hdd image for fdubcd.img is another. Both options have their own negative effects.

The alternative I presented in this topic keeps both fdubcd.img and fdubcd.iso as in UBCD 5.1.1, by trying to find an adequate grub4dos entry.

But the ideal alternative would be to find the "real" problem: how to get access to the booting media (CD media or UFD) once the floppy image, fdubcd.img, boots (by means of memdisk) into fdubcd DOS. Solving _this_ problem would solve all the questions: we can get fdubcd.iso out of the equation, we don't need to find other alternatives with their own negative effects, the boot process would be faster and even more advantages that I'd rather avoid mixing in this topic.

In UBCD 5.1.1, we can still reproduce the original "real" problem. By using the method Icecube described above ("dynamically" change the config for cd-roms while booting fdubcd, which I also do in my tests), we can see in Volkov Commander that all the CD-ROM drive letters are available for DOS, but when we try to display the content of those CD drives, it can't be shown and fdubcd DOS might hang. This behavior suggests that maybe something in the DOS scripts is not quite right, as DOS recognizes the drives, assigns them drive letters, but can't access their contents. Solving _this_ problem is the "real" solution for UBCD.
 


@ady +@Steve6375
Besides the "right" way with (hd96) (which still uses however the memdisk inside fdubcd.iso.gz)
this works alright for me in Qemu:

map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook
map --mem (hd32)/fdubcd.img (fd0)
map (hd32) (cd)
map --hook
root (fd0)
chainloader +1
boot
and should be more or less the answer to the first question, i.e. how to boot from CD bypassing completely the memdisk.
 
Seemingly if the .iso image is mapped to (cd) the driver "catches it", while it doesn't until it is mapped to (hd32) or similar. :dubbio:

@Wonko, is that code working without having the content of fdubcd.iso (and maybe also the content of fdubcd.img) also available directly in the boot media? As I said before, when the content of fdubcd.iso and fdubcd.img is also available in the boot media, the grub4dos entry in UBCD 5.1.1 indeed works correctly and all the DOS programs are available. But having the same information 2 and 3 times in UBCD seems an expensive workaround. Please confirm if in the above test the content of fdubcd.iso is also copied into the booting media, or if instead you are using UBCD 5.1.1 "as-is" with the only exception of that grub4dos entry.

TIA,
Ady.

Edited by ady, 21 December 2012 - 01:47 PM.


#49 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 December 2012 - 02:59 PM

@Wonko, is that code working without having the content of fdubcd.iso (and maybe also the content of fdubcd.img) also available directly in the boot media? As I said before, when the content of fdubcd.iso and fdubcd.img is also available in the boot media, the grub4dos entry in UBCD 5.1.1 indeed works correctly and all the DOS programs are available. But having the same information 2 and 3 times in UBCD seems an expensive workaround. Please confirm if in the above test the content of fdubcd.iso is also copied into the booting media, or if instead you are using UBCD 5.1.1 "as-is" with the only exception of that grub4dos entry.

:frusty:

The posted works ONLY with an UNTOUCHED ubcd511.iso given as CDROM to a QEMU virtual machine.

As said, by now for the nth time that was (in my perverted mind) the first question, and as said I was answering ONLY to that (AND it is a workaround, ONLY valid in that particular setup/environment).

No USB, no "\\.\Physicaldrive", no expansion of anything, no nothing BUT ONLY an UNTOUCHED ubcd511.iso given as CDROM to a QEMU virtual machine.

 

However, and to confirm my first impression that what is actually IMHO unneededly complex is the cd-rom detection and mounting routine, I propose a radical alternative :w00t:.

 

Add to a \\.\physicaldrive root an UNTOUCHED fdubcd.iso (extracted from the fdubcd.iso.gz inside the ubcd511.iso)

Use a grub4dos floppy to boot (fd0).

Use the attached floppy image as second floppy (fd1).

In the grub4dos command line:

 

 

 

 





map --mem (hd0,0)/fdubcd.iso (hd32)
map --hook
map --mem (hd32)/fdubcd.img (fd0)
map -hook
root (fd0)
chainloader +1
boot

(you can in the above replace the chainlaoder +1 with chainloader /kernel.sys to bypass the memdisk)



choose 7
Abort CD-rom mounting and go to Freedos command line, then:

 

 





b:
shsucdrd /F:C:\fdubcd.iso
shsucdx /D:SHSU-CDR,T
Q:
ubcd

 

:cheers:

Wonko

Attached Files



#50 ady

ady

    Frequent Member

  • Advanced user
  • 119 posts

Posted 21 December 2012 - 04:05 PM

:frusty:
The posted works ONLY with an UNTOUCHED ubcd511.iso given as CDROM to a QEMU virtual machine.
As said, by now for the nth time that was (in my perverted mind) the first question, and as said I was answering ONLY to that (AND it is a workaround, ONLY valid in that particular setup/environment).
No USB, no "\\.\Physicaldrive", no expansion of anything, no nothing BUT ONLY an UNTOUCHED ubcd511.iso given as CDROM to a QEMU virtual machine.
 
However, and to confirm my first impression that what is actually IMHO unneededly complex is the cd-rom detection and mounting routine, I propose a radical alternative :w00t:.
 
Add to a \\.\physicaldrive root an UNTOUCHED fdubcd.iso (extracted from the fdubcd.iso.gz inside the ubcd511.iso)
Use a grub4dos floppy to boot (fd0).
Use the attached floppy image as second floppy (fd1).
In the grub4dos command line:

map --mem (hd0,0)/fdubcd.iso (hd32)
map --hook
map --mem (hd32)/fdubcd.img (fd0)
map -hook
root (fd0)
chainloader +1
boot
(you can in the above replace the chainlaoder +1 with chainloader /kernel.sys to bypass the memdisk)

choose 7
Abort CD-rom mounting and go to Freedos command line, then:
 
b:
shsucdrd /F:C:\fdubcd.iso
shsucdx /D:SHSU-CDR,T
Q:
ubcd
 

@Wonko, I'm sorry but I am not used to nor understand grub4dos. For example, I don't know what you mean with "Use a grub4dos floppy", and I have no idea what each grub4dos command you posted does or means. I do understand the ones you posted related to fdubcd DOS and UBCD, but that's not enough for me to be able to replicate all the above by myself, specially when I am not sure what is the expected result. Maybe Victor can try it and if he finds it satisfactory then he may implement that method in next testing versions of UBCD.

Since I don't understand grub4dos commands, but I can understand (more or less) the commands in fdubcd, for my personal needs, I'd rather adapt the cd-rom config, which allows launching the DOS programs even when booting with grub4dos. But the whole point of this topic was for sure not _my_ particular needs, but finding adequate grub4dos entries without changing fdubcd.iso nor fdubcd.img (which are already working with memdisk), so it could be used in the next UBCD version.

Now, about your
what is actually IMHO unneededly complex is the cd-rom detection and mounting routine
, it brings me to my previous post regarding the _real_ problem: finding a way for fdubcd DOS to access the content of additional cd drives, which immediately would also solve this topic (it would be obsolete) and we would get rid of fdubcd.iso too. But that seems to be, IMHO, a DOS-related issue, thus a new topic is needed.

If someone that understands grub4dos and knows by himself how to proceed with Wonko's suggestion so to test it and report back the results (about launching DOS programs from fdubcd and about access to additional cd drives), it would be really appreciated. (That is not to say that I am just waiting for someone else to test. I am also performing tests so to solve the _real_ problem, and reading about grub4dos; maybe by UBCD 7  :w00t: I'll be able to understand grub4dos commands).

TIA,
Ady




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users