Problems with UBCD since 5.2.x

[ctschantz]

Hello,

I was using 5.1.1 with a bunch of custom BIOS update utilities that I integrated into UBCD without issue for quite some time.

Ever since 5.2 was released this doesn't appear to work any longer and I was hoping for some insight. I have even tried with 5.2.4 (released today) with the same problem.

What happens is that the image just stops and freezes the computer. Here is a screenshot of where it freezes:



Here is how I have it setup and working in 5.1.1:

LABEL -
MENU LABEL SOME BIOS
TEXT HELP
VERSION
ENDTEXT
LINUX /boot/syslinux/memdisk
INITRD /ubcd/biosupdates/laptops/SOMEBIOS.ima
APPEND raw

I noticed things have changed around with 5.2, so I tried what appears to be the way to use memdisk now:

LABEL -
MENU LABEL SOME BIOS
TEXT HELP
VERSION
ENDTEXT
COM32 linux.c32 memdisk
INITRD /ubcd/biosupdates/laptops/SOMEBIOS.ima
APPEND raw

(I have also tried "APPEND floppy raw" as well as "APPEND floppy raw c=XX h=X s=XX"

Here is a copy of one if the IMA's that I have created:

http://depositfiles.com/files/czi6y4pxs

Its basically just a freedos floppy image which launch an HP BIOS update (ROMPAQ).

Doing it either way in 5.2 results in the problem with it freezing. Again there were no problems with 5.1.1 (and im pretty sure with other revisions of 5.1)

Could this be an issue with the included memdisk version or syslinux \ isolinux? It seems very strange that this worked fine in the older version but now does not.

Thanks for the help and assistance.

[ady]

Have you tried using the same entry as before, but in UBCD 5.2.x?

Code: Select all

LABEL -
MENU LABEL SOME BIOS
TEXT HELP
 VERSION
ENDTEXT
LINUX /boot/syslinux/memdisk
INITRD /ubcd/biosupdates/laptops/SOMEBIOS.ima
APPEND raw

If this boot entry worked before, it should work now too.

Please report your results.

[ctschantz]

Have you tried using the same entry as before, but in UBCD 5.2.x?

Code: Select all

LABEL -
MENU LABEL SOME BIOS
TEXT HELP
 VERSION
ENDTEXT
LINUX /boot/syslinux/memdisk
INITRD /ubcd/biosupdates/laptops/SOMEBIOS.ima
APPEND raw

If this boot entry worked before, it should work now too.

Please report your results.

Yes, as indicated in the original post (albeit not very well) I have tried both ways. The way it works with 5.1.1 as well as what looked to me the new way to use memdisk.

LINUX /boot/syslinux/memdisk

and

COM32 linux.c32 memdisk

Both methods result in the freezing.

[ady]

I tested you image in VBox with UBCD 5.2.x, and I see no problem to boot it. I can see some similar messages as you posted in your screenshot, but the boot procedure goes on (perhaps you should wait?). It eventually displays a message about the specified command shell (erompaq...) requiring a newer system (the specific shell can be executed only on specific systems).

Although the image you posted has its issues (like using an old kernel, in a 2880KiB floppy, with kernel.sys not having the "system" attribute and not being the first file), my test shows that memdisk is working correctly in UBCD 5.2.x (I used the same type of boot entry as in UBCD 5.1.1.).

[ctschantz]

I noticed if I use the floppy image on a system that it wasn't designed to work on it would boot but give me the same error message as you found.

For example, lets say I had two systems. An HP 6550b and a HP 2570p. If I boot to the 2570p image on the 6550b or vice versa, it would not freeze but it would error out mentioning a newer system just as you experienced.

When it freezes, I can wait all day and it wont move past the point where I posted the SS.

Do you have by chance any HP laptops? If so what model?

Maybe its just the image I am using.... I don't know.. its just crazy strange that it worked before 5.2.

[ady]

I would tend to think these images are not "official, as-is", but I don't really know.

FWIW, when the shell defined in config.sys is not working, and you get the relevant message, you could type in "command.com" and press "enter" to get a generic FreeDOS prompt.

The most important thing here (because it would mean that there is some regression in memdisk) is to test twice the same exact machine with the same exact floppy image: once with the memdisk included in UBCD 5.1.1, and one with the memdisk included in UBCD 5.2.x.

If you have the old UBCD 5.1.1, extract memdisk from it and copy it to the new UBCD 5.2.x, for example as "/boot/syslinux/memdisk511" (so not to overwrite the current memdisk file, as we want both).

Then use 2 entries:

Code: Select all

LABEL somebios
LINUX /boot/syslinux/memdisk
INITRD /ubcd/biosupdates/laptops/SOMEBIOS.ima
APPEND floppy raw

LABEL somebios_old
LINUX /boot/syslinux/memdisk511
INITRD /ubcd/biosupdates/laptops/SOMEBIOS.ima
APPEND floppy raw

(I intentionally used "floppy raw" in both).

Then boot with one entry and take note of what happens. Reboot and select this time the second entry.

Are there any cases (hardware with respective relevant image) where the behavior between the 2 attempts is different in any way?

TIA,
Ady.

[ctschantz]

I am back in the office today so I will give this a shot ASAP and report the results.

Thanks

[ctschantz]

I would tend to think these images are not "official, as-is", but I don't really know.

FWIW, when the shell defined in config.sys is not working, and you get the relevant message, you could type in "command.com" and press "enter" to get a generic FreeDOS prompt.

The most important thing here (because it would mean that there is some regression in memdisk) is to test twice the same exact machine with the same exact floppy image: once with the memdisk included in UBCD 5.1.1, and one with the memdisk included in UBCD 5.2.x.

If you have the old UBCD 5.1.1, extract memdisk from it and copy it to the new UBCD 5.2.x, for example as "/boot/syslinux/memdisk511" (so not to overwrite the current memdisk file, as we want both).

Then use 2 entries:

Code: Select all

LABEL somebios
LINUX /boot/syslinux/memdisk
INITRD /ubcd/biosupdates/laptops/SOMEBIOS.ima
APPEND floppy raw

LABEL somebios_old
LINUX /boot/syslinux/memdisk511
INITRD /ubcd/biosupdates/laptops/SOMEBIOS.ima
APPEND floppy raw

(I intentionally used "floppy raw" in both).

Then boot with one entry and take note of what happens. Reboot and select this time the second entry.

Are there any cases (hardware with respective relevant image) where the behavior between the 2 attempts is different in any way?

TIA,
Ady.

I tried this today with the same results. That would lead me to believe that it has to be something else within the latest UBCD that could potentially be causing the problem. I tried this using the latest 5.2.4 ISO. I create the USB's using UBCD2USB in the tools folder. This is how I have always done it.
Would it be beneficial to test by creating the USB using 5.1 ISO and then doing the above with the latest memdisk from 5.2 vice the way I just tried?

I did find that right before it freezes the computer I can press F8 to have it present me with Y\N prompts on what I want to execute within config.sys. If I say yes to ROMPAQ that's where it freezes. If I say no, I can get to command line and do normal commands like "dir" et cetera but as soon as I execute ROMPAQ I get the freeze.

I know that ROMPAQ isn't something that is necessarily supported by UBCD (at least not integrated) I am just at a loss as to why I can manage to make it work just fine in the older versions. I wish I could narrow it down to something specific so I could potentially find a work around and still take advantage of the newer things in 5.2. At least now it seems memdisk is not the issue.

Thanks for all the help. I am always open to more suggestions.

[Victor Chew]

The version history should give you an idea of what has changed since V5.1.1 so that you can try to isolate the problem. First suspect is probably syslinux/memdisk. Try to revert to an older version and see if that helps.

[ady]

At least now it seems memdisk is not the issue.

Maybe I am misunderstanding something but, from your report, it would seem that the version of memdisk is the only thing that changes.

From what I understood:

Syslinux v4.06 (in UBCD 5.2.x) + memdisk (from the same UBCD 5.2.x) + floppy image X in hardware_X ==>> something FAILS.
But
Syslinux v4.06 (in UBCD 5.2.x) + memdisk (from the old UBCD 5.1.1) + same floppy image X in same hardware_X ==>> boots OK and all works.

Am I understanding your tests and your report correctly?

Now, I indeed recognize that using an older memdisk with a newer Syslinux is not the best combination, yet my understanding from your report is that it worked correctly. Then, it would seem that with the newer memdisk the floppy image can't complete the boot process "correctly" in the "expected hardware" (and these last 2 words are very relevant).

When I say "something fails", indeed the FREEDOS image initially boots (using command.com as shell), so the question is, what in that specific shell in that specific hardware, when combined with memdisk (from the Syslinux 4.06 package), generates the failure. Why the same shell would be accepted in the same hardware when the image is booted with an older memdisk?

What if you use an updated FREEDOS kernel, with a "correctly built" floppy image?

Best Regards,
Ady.

[ctschantz]

At least now it seems memdisk is not the issue.

Maybe I am misunderstanding something but, from your report, it would seem that the version of memdisk is the only thing that changes.

From what I understood:

Syslinux v4.06 (in UBCD 5.2.x) + memdisk (from the same UBCD 5.2.x) + floppy image X in hardware_X ==>> something FAILS.
But
Syslinux v4.06 (in UBCD 5.2.x) + memdisk (from the old UBCD 5.1.1) + same floppy image X in same hardware_X ==>> boots OK and all works.

Am I understanding your tests and your report correctly?

Now, I indeed recognize that using an older memdisk with a newer Syslinux is not the best combination, yet my understanding from your report is that it worked correctly. Then, it would seem that with the newer memdisk the floppy image can't complete the boot process "correctly" in the "expected hardware" (and these last 2 words are very relevant).

When I say "something fails", indeed the FREEDOS image initially boots (using command.com as shell), so the question is, what in that specific shell in that specific hardware, when combined with memdisk (from the Syslinux 4.06 package), generates the failure. Why the same shell would be accepted in the same hardware when the image is booted with an older memdisk?

What if you use an updated FREEDOS kernel, with a "correctly built" floppy image?

Best Regards,
Ady.

Something must have gotten lost in translation (that never happens)

The test that I completed failed on both accounts. Using the latest 5.2.4 ISO and the included memdisk as well as memdisk from 5.1.1.

For giggles, I tried the same test in reverse where I created the USB using the 5.1.1 ISO and the included memdisk as well as memdisk from 5.2.4. Both tests passed and worked as expected.

I am going to do some additional testing trying to mix and match different things and see if I can narrow it down that way. I will keep this thread updated with my findings.

[ady]

The test that I completed failed on both accounts. Using the latest 5.2.4 ISO and the included memdisk as well as memdisk from 5.1.1.

Got it now

For giggles, I tried the same test in reverse where I created the USB using the 5.1.1 ISO and the included memdisk as well as memdisk from 5.2.4. Both tests passed and worked as expected.

So, it seems the conflict is between Syslinux 4.06 and the specific DOS shell from HP, eRompaq.exe, at least as it is configured in your 2880KiB floppy image.

I will keep this thread updated with my findings.

Feedback is very appreciated.

Is there any official web page from where we could download some tool or package or archive or "something" that would already contain, in some form or another, this eRompaq.exe from HP? Is there any official documentation about how the BIOS of this particular hardware is supposed to be updated (or about whichever goal the eRompaq.exe shell is useful for)? It could be useful so to eliminate the possibility that the floppy image, or the (old) FREEDOS kernel in it, could be the source of the conflict.

TIA,
Ady.

[ctschantz]

Feedback is very appreciated.

Is there any official web page from where we could download some tool or package or archive or "something" that would already contain, in some form or another, this eRompaq.exe from HP? Is there any official documentation about how the BIOS of this particular hardware is supposed to be updated (or about whichever goal the eRompaq.exe shell is useful for)? It could be useful so to eliminate the possibility that the floppy image, or the (old) FREEDOS kernel in it, could be the source of the conflict.

TIA,
Ady.

These dang floppy images were created by me. IIRC, some of the BIOS updates for HP's came with a freedos image you could use on a floppy disk. What I believe I did (back when I originally created the floppy images) is modified the image contents to include the proper update files for the different models that we support. This included on some accounts expanding the size of the floppy image to accommodate larger BIOS update files. Since it worked with the current UBCD at the time, I didn't think twice about my method of doing it. Its very possible that its just a poorly build image file.

For the particular model I have been testing on HP does provide a download that will allow you to either update the BIOS on the machine you run it on, or create a standalone USB to update the BIOS; Here is an overview and direct download link:

http://h20000.www2.hp.com/bizsupport/Te ... b-116685-1
ftp://ftp.hp.com/pub/softpaq/sp61001-61500/sp61139.exe

[ady]

The necessary files to build an adequate floppy image from the sp61139.exe are bigger than 2880KiB (68SSU.BIN is 3072KiB already).

A possible alternative would be to build a bigger ("superfloppy") image (as the current fdubcd.img, for example), and boot it with memdisk. But since the specific erompaq.exe shell seems to detect whether the hardware is adequate, then the specific format of the image (including its geometry, and whether it is a superfloppy or otherwise it has a MBR) might be part of the conflict. But if that's the case, then why your image works (including the DOS shell) when booted with older Syslinux versions and not with version 4.06?

Unfortunately, I have no relevant hardware so to test this by myself (to try to reproduce the behavior with different Syslinux versions).

I am starting to think that this case needs to be presented to the Syslinux mailing list, including info about the specific hardware (model, links, etc.).

@ctschantz, would you be willing to send the relevant info to the Syslinux Mailing List?

[Icecube]

Try with different memdisk parameters to see if that solves the problem:

Code: Select all

   raw		Use raw access to protected mode memory.

   bigraw	Use raw access to protected mode memory, and leave the
		CPU in "big real" mode afterwards.

   int		Use plain INT 15h access to protected memory.  This assumes
   		that anything which hooks INT 15h knows what it is doing.

   safeint	Use INT 15h access to protected memory, but invoke
		INT 15h the way it was *before* MEMDISK was loaded.
		This is the default since version 3.73.

http://www.syslinux.org/wiki/index.php/ ... safeint.29

Because you made the original image yourself, try to update FreddDOS (kernel and related files) in your image.

Here is a link to a wiki where they explain how to make FreeDOS images for HP BIOS updates (They don't use 'raw' but the default 'safeint' for MEMDISK):
http://www.richud.com/wiki/BIOS_HP_Romp ... E_USB_Boot

[ady]

I don't think it is about the specific floppy image nor about memdisk. The same floppy image and the same memdisk version (from Syslinux v.4.06) work as expected when using SYSLINUX v.4.04.

The problem appears when booting with

SYSLINUX (4.06) -> memdisk (whichever version) -> same floppy image -> erompaq.exe (HP's DOS shell)

while works as expected when

SYSLINUX (4.04) -> memdisk (whichever version) -> same floppy image -> erompaq.exe (HP's DOS shell)

and it also works as expected when

SYSLINUX ((whichever version)) -> memdisk (whichever version) -> same floppy image -> FREEDOS' command.com

So, the problem appears when combining SYSLINUX 4.06 with erompaq.exe.

I even wonder if the problem could be "erompaq.exe" vs "eRompaq.exe".

The question would be "what's different between SYSLINUX 4.04 and 4.06 that makes erompaq.exe fail when booted with the later".

It could also be interesting testing with Syslinux 5.xx, but that needs a little more initial work.

We need to wait for someone with the relevant hardware to test and provide feedback. ctschantz ?

PS: Regarding the link that Icecube posted... FWIW, fdubcd.img v1.48 (UBCD v5.2.x) is a superfloppy image, and it doesn't need hex-editing CHS values to work correctly.

[Icecube]

The version of syslinux shouldn't matter as MEMDISK is not really related to the syslinux version.
MEMDISK doesn't depend on Syslinux (any bootlaoder that supports loading linux kernel images works fine with MEMDISK).

The difference between MEMDISK 4.04 and 4.06 could just be that is it compiled with a different compiler version.
Testing with the different MEMDISK parameters would still be nice to do.

To remove the Syslinux version from the equasion, run the 2 versions of MEMDISK from grub4dos.
Load the grub4dos menu from Syslinux (try with 4.04 first, then 4.06 ==> normally shouldn't matter) after adding this to the grub4dos menu file:

Code: Select all

title somebios MEMDISK 4.04 (UBCD 5.1.1)
kernel /boot/syslinux/memdisk511
initrd /ubcd/biosupdates/laptops/SOMEBIOS.ima

title somebios MEMDISK 4.04 (UBCD 5.1.1) with raw
kernel /boot/syslinux/memdisk511 raw
initrd /ubcd/biosupdates/laptops/SOMEBIOS.ima

title somebios MEMDISK 4.04 (UBCD 5.1.1) with bigraw
kernel /boot/syslinux/memdisk511 bigraw
initrd /ubcd/biosupdates/laptops/SOMEBIOS.ima

title somebios MEMDISK 4.04 (UBCD 5.1.1) with int
kernel /boot/syslinux/memdisk511 int
initrd /ubcd/biosupdates/laptops/SOMEBIOS.ima

title somebios MEMDISK 4.06 (UBCD 5.2.x)
kernel /boot/syslinux/memdisk52x
initrd /ubcd/biosupdates/laptops/SOMEBIOS.ima

title somebios MEMDISK 4.06 (UBCD 5.2.x) with raw
kernel /boot/syslinux/memdisk52x raw
initrd /ubcd/biosupdates/laptops/SOMEBIOS.ima

title somebios MEMDISK 4.06 (UBCD 5.2.x) with bigraw
kernel /boot/syslinux/memdisk52x bigraw
initrd /ubcd/biosupdates/laptops/SOMEBIOS.ima

title somebios MEMDISK 4.06 (UBCD 5.2.x) with int
kernel /boot/syslinux/memdisk52x int
initrd /ubcd/biosupdates/laptops/SOMEBIOS.ima

[ctschantz]

Hey guys sorry for the delay.

I had totally forgotten that I already had grub4dos setup and working correctly on 5.1.1.. I just never use it so out of sight out of mind.

I booted the 5.2.4 USB I created with all the bios updates and then launched the grub4dos menu. Navigated to the proper BIOS update and executed. It froze at the same point that SYSLINUX \ MEMDISK did.

Here is how I have grub4dos setup from 5.1.1:

Code: Select all

title SOME BIOS\n SOME VERSION
map (hd0,0)/ubcd/biosupdates/laptops/2560p.ima (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
map --floppies=1

Again the above failed at the same point in 5.2.4.

SOOOO I tried modifying the MEMDISK parameters and found that I got the same result with all methods mentioned (raw, bigraw, int and safeint).

Ill read through those threads that you posted links too and see what else I can find.

[ctschantz]

Quick update.

I finished creating a new image file using the instructions on the website posted above:

http://www.richud.com/wiki/BIOS_HP_Romp ... E_USB_Boot

I used the win98 boot files and ROMPAQ did not freeze with 2.5.4. However, I tried it with grub4dos and it froze.

So in summary, initial tests are good and I will continue to test (freedos is next) and report back. Its most likely a problem with the images I created and I got lucky with the previous versions of UBCD.

[ctschantz]

Ok, I got the gurb4dos problem sorted. It appears my old method doesn't work with 5.2.4:

Code: Select all

title SOME BIOS\n SOME VERSION
map (hd0,0)/ubcd/biosupdates/laptops/2560p.ima (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
map --floppies=1

This is what does work:

Code: Select all

title SOME BIOS\n SOME VERSION
kernel /boot/syslinux/memdisk
initrd /ubcd/biosupdates/laptops/SOMEBIOS.ima

Im going to modify a few more images for a few more models and see if I can get the same result. I will report back with my findings.

So far it appears that the problem was with the images I originally created.