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.).

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.

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).

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 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.

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.

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?

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.

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

Quote:

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.

Quote:

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.

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:

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?

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:

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.

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.

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum