[syslinux] MEMDISK issue with OptiPlex GX280,620

Jason Vasquez jvasquez at kennesaw.edu
Tue Dec 7 06:35:21 PST 2010


A kind request for help please.

MEMDISK is causing an issue with the Dell OptiPlex GX280 and GX620 platforms. Booting a PC-DOS/Ghost, disk image is successful (and proper) when using version 3.83. See results below:

MEMDISK 3.83:

Ramdisk at 0x07eeaa00, length 0x007bc000
command line: initrd=images/ghostclient/280_620/osbootc.img BOOT_IMAGE=memdisk
MEMDISK: Image seems to have fractional end cylinder
Disk is hd0, 7920 K, C/H/S = 0/255/63 (MBR/MBR), EDD on, rw
Using safe INT 15h access to high memory
Code 1656, meminfo 276, cmdline 66, stack 512
Total size needed = 2510 bytes, allocating 3K
Old dos memory at 0x9f800 (map says 0xa0000), loading at 0x9ec00
1588: 0xffff  15E801: 0x3c00 0x07dea
INT 13 08: Success, count = 1, BPT = 0000:0000
old: int13 = f0005c6f  int15 = f000f859  int1e = f000efc7
new: int13 = 9ec0000a  int15 = 9ec0038c  int1e = f000efc7
Loading boot sector... booting...
Starting PC DOS...

Though, when using any post-3.83 version of MEMDISK, the same disk image results in an unfavorable state. Notably, after booting the image, the system's SATA drive is not visible to the PC-DOS/Ghost environment. MEMDISK is likely the apparent culprit as indicated from the "We lost the last drive in our class of drives" notice during MEMDISK processing. Results below:

MEMDISK 4.03:

Ramdisk at 0x07eeaa00, length 0x007bc000
command line: initrd=images/ghostclient/280_620/osbootc.img BOOT_IMAGE=memdisk
MEMDISK: Image seems to have fractional end cylinder
Disk is hd0, 7920 K, C/H/S = 0/255/63 (MBR/MBR), EDD on, rw
Using safe INT 15h access to high memory
Code 1744, meminfo 276, cmdline 48, stack 512
Total size needed = 2580 bytes, allocating 3K
Old dos memory at 0x9fc00 (map says 0xa0000), loading at 0x9f000
1588: 0xffff  15E801: 0x3c00 0x07dea
INT 13 08: Success, count = 1, BPT = 0000:0000
We lost the last drive in our class of drives.
Drive probing gives drive shift limit: 0x01
old: int13 = f00042e4  int15 = f000f859  int1e = f000efc7
new: int13 = 9f00000a  int15 = 9f0003ba  int1e = f000efc7
Loading boot sector... booting...
Starting PC DOS...

Any insight to be had? Setting different MEMDISK memory access methods (raw, bigraw, int, safeint) offered no changes. Equally, changing the OptiPlex BIOS 'SATA Operation' configuration from Normal to Combination yielded no difference. And for what it is worth, the OptiPlex 755, 780, and 980 are not affected by this "bug". Please tell me there's hope.

Regards.




More information about the Syslinux mailing list