Page 1 of 1

Booting Unix: "Bad decode table"

Posted: Thu Jun 19, 2008 4:51 am
by graham
Hi!

I'm trying to use UBCD to boot SCO OpenServer in VMware. The version of OpenServer I have does not boot from CD, and must boot from floppy. Unfortunately, a problem with the SCO floppy driver in this version renders it compatible with VMware (boot prompt appears, loads kernel and ramdisk image, then complains about device initialization). But that's another problem...

I'm trying to boot it from an ISO image of UBCD, with the boot.img file of the boot floppy. I've put the boot.img file in the /custom folder of the UBCD image, using MagicISO. Then I tell VMware that the ISO image is a CD drive.

Starting VMware, UBCD boots correctly, and I select the "user installed" options. The SCO OpenServer 5 boot prompt appears correctly (so, it's picking up the correct image, and the image is not complete garbage).

On booting (hit return), the boot string appears, it performs it's usual "sizing memory", then "loading kernel fd(64)unix .text". At this step, it fails, stating "Bad decode table". It then goes on to complain it cannot load it's ramdisk image ("Bad magic").

Any clues?

Cheers,
Graham.

Posted: Thu Jun 19, 2008 8:56 am
by Icecube
See if you can boot the floppy image directly in VMware. If not, check it the image file isn't corrupted.

After some googling I found that "Bad decode table" means that your kernel is corrupted, so probably the image file is corrupted also.

Posted: Thu Jun 19, 2008 3:14 pm
by graham
Hi!

Thanks, but yes, the image does read the kernel and rootFS images in VMware. But as I say, I hit the problems with the floppy driver in the kernel being incompatible with the floppy drive emulation in VMware.

So, the image is fine. It appears that UBCD is not delivering the SCO boot-loader with the correct data. But it's not complete rubbish either (the boot-loader itself *does* load).

Is there some gotcha I look for? The image is a raw disk image, and is the same as I have been using in VMware as a floppy image.

Cheers,
Graham.

Posted: Thu Jun 19, 2008 5:07 pm
by The Piney
What are the lines in the cfg file that you've added? Have you tried any of the switches like raw, bigraw, etc? Have you updated the isolinux/syslinux files per Icecubes post here -> viewtopic.php?t=901

Here it is to make it easier...
Download syslinux from http://www.kernel.org/pub/linux/utils/boot/syslinux/.

Extract the syslinux archive to "c:\syslinux\".

To update isolinux for the CD version
- Copy "c:\syslinux\isolinux.bin" to "c:\ubcd\isolinux\".
- Copy "c:\syslinux\com32\menu\menu.c32" to "c:\ubcd\isolinux\".
- Copy "c:\syslinux\com32\modules\chain.c32" to "c:\ubcd\isolinux\" (not necessary)
- Copy "c:\syslinux\com32\memdisk\memdisk" to "c:\ubcd\isolinux\" (not necessary)

To update syslinux for the bootable USB key
- Copy "c:\syslinux\ldlinux.sys" to "c:\ubcd\syslinux\".
- Copy "c:\syslinux\mbr\mbr.bin" and "c:\syslinux\ldloader.bss" to "c:\ubcd\tools\ubcd2usb\".
- Copy "c:\syslinux\com32\menu\menu.c32" to "c:\ubcd\syslinux\"
- Copy "c:\syslinux\com32\modules\chain.c32" to "c:\ubcd\syslinux\" (not necessary)
- Copy "c:\syslinux\com32\memdisk\memdisk" to "c:\ubcd\syslinux\" (not necessary)

Delete unnecessary files:
You can delete the following files in "c:\ubcd\rescuecd\isolinux\"
Code:
boot.cat (boot catalog file needed for the iso image, but when you remaster the iso an updated boot catalog will be formed.)
isolinux.bin (already included in ubcd)
isolinux.cfg (replaced by rescuecd.cfg)
memdisk (already in "c:\ubcd\isolinux\")


Remaster the iso:
If you don't know how to do it, see viewtopic.php?t=1343.

Posted: Fri Jun 20, 2008 4:13 am
by Icecube
Try to boot the image in another virutal machine like qemu or VirtualBox to see if you can boot the SCO OpenServer completely. If not, I think that you have an partly corrupted image, so you have to download it again or try to do a md5 check on the image file.

Can you give a link to the image file or give the name of the files that are in the image?

Posted: Fri Jun 20, 2008 4:39 am
by graham
Hi Piney,

I just followed the instructions. I copied boot.img into /custom; custom.cfg was already there, already set to load an image from that location, so I didn't change custom.cfg at all.

I didn't know there were switches. Where are they documented? After you mentioned these two, I found them in some of the existing .cfg files, so I've tried adding "raw" and "bigraw" in the same way to my .cfg file. They make no difference whatsoever, neither better nor worse. What do they do?

No, I hadn't followed those instructions. I've updated the files as instructed (though, there is no /com32/memdisk/memdisk, just /memdisk/memdisk, so I used that, it appears identical to the file I already had). This also makes no difference.

The diskette image I have is a straight sector-for-sector copy of the original diskette, 1,474,560 bytes long. Do I need something different?

There are obviously options for configuring this that you know and I don't... where are they documented? I can't find any documentation other than the "Customizing UBCD" page.

Cheers,
Graham.

Posted: Fri Jun 20, 2008 5:08 am
by Icecube
Info about memdisk options.
http://syslinux.zytor.com/wiki/index.php/MEMDISK

Add something similar to your custom.cfg file:

Code: Select all

LABEL sco1
	MENU LABEL SCO Openserver 5
	KERNEL memdisk
	APPEND initrd=/icustom/boot.img
LABEL sco2
	MENU LABEL SCO Openserver 5 (raw access to protected mode memory)
	KERNEL memdisk raw
	APPEND initrd=/icustom/boot.img
LABEL sco3
	MENU LABEL SCO Openserver 5 (raw access to protected mode memory, return to big real mode)
	KERNEL memdisk bigraw
	APPEND initrd=/icustom/boot.img
and test those options.

Posted: Fri Jun 20, 2008 5:25 am
by Victor Chew
AFAIK, using a memdisk-emulated floppy to load a protected-mode OS is an uncertain proposition.

Remember, memdisk loads the floppy in memory and hooks the BIOS to intercept the floppy interrupts.

However, once the protected-mode OS takes over, it's almost certain to overwrite the memory used by memdisk to store the floppy image. Once that happens, we enter unknown territory...

It may work, but the protected-mode OS must not read/write from the emulated floppy after its memory has been overwritten.

Posted: Fri Jun 20, 2008 1:11 pm
by The Piney
Maybe the ro switch could help in this situation? I haven't tried that switch on anything yet but worth a try if nothing else works..

Posted: Fri Jun 20, 2008 1:51 pm
by graham
Hi Victor!

Ahhh! This makes sense. It explains completely why the image appears to be corrupt. As soon as the kernel begins to load, it is perhaps being loaded *over* the image of the diskette.

I had a try with BCDW... this gets much further before failing. (Loads the entire kernel, but can't start the install process.)

I can prevent the Unix kernel from using certain parts of memory, but I'm thinking that won't help... the problem with BCDW starts as soon as the SCO drivers take over from the boot process, and presumably is bypassing the int13h handler.

Thanks, that's helpful. Now I just need to find a way for it to get the next lot of files from somewhere else... :)

Cheers,
Graham.