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.
On 12/7/2010 09:35, Jason Vasquez wrote:> A kind request for help please. > > MEMDISK is causing an issue with the Dell OptiPlex GX280 and GX620 > platforms.I have access Dell Optiplex GX280 hardware.> 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 cylinderFractional end cylinder, you say? You appear to be using a 7.734375 MiB HDD image.> Disk is hd0, 7920 K, C/H/S = 0/255/63 (MBR/MBR), EDD on, rw0 cylinders, you say? What geometry did you use when creating the HDD image. Ghost typically produces a floppy image, so I gather that you created the HDD image yourself.> 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: > > ... ... ... > 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.Kindly use this MEMDISK and report its output: http://www.etherboot.org/share/sha0/memdisk_dskprobe It has DBG_DSKPROBE enabled for its build. - Shao Miller
Thank you for the response.
Below is an excerpt of memdisk_dskprobe's information (I was not able to
capture the full output):
probe_int13_ah(0xfb, 0x08) == 1
probe_int13_ah(0xfb, 0x15) == 1
probe_int13_ah(0xfb, 0x41) == 1
probe_bda_drive(0xfb) == 0 count: 1
probe_int13_ah(0xfc, 0x08) == 1
probe_int13_ah(0xfc, 0x15) == 1
probe_int13_ah(0xfc, 0x41) == 1
probe_bda_drive(0xfc) == 0 count: 1
probe_int13_ah(0xfd, 0x08) == 1
probe_int13_ah(0xfd, 0x15) == 1
probe_int13_ah(0xfd, 0x41) == 1
probe_bda_drive(0xfd) == 0 count: 1
probe_int13_ah(0xfe, 0x08) == 1
probe_int13_ah(0xfe, 0x15) == 1
probe_int13_ah(0xfe, 0x41) == 1
probe_bda_drive(0xfe) == 0 count: 1
probe_int13_ah(0xff, 0x08) == 1
probe_int13_ah(0xff, 0x15) == 1
probe_int13_ah(0xff, 0x41) == 1
probe_bda_drive(0xff) == 0 count: 1
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... press any key to boot...
Regarding the hdd image. You are correct in deducing that I created the image. I
originally started with a 16MB SD card and configured it as a Ghost client disk.
Then I copied its contents to a Sony 8MB Memory Stick. The 8MB image was a
product of this card with the interest of having a smaller boot load. Below are
the details involved configuring the hdd image source media. (Apologies for the
extra information.)
-------------------------------
#Sony Memory Stick 8MB (msa-8a)
#(note: created by 'dd'-ing 16MB Panasonic SD image to Sony 8MB media)
#fdisk -lu /dev/sda
Disk /dev/sda: 8 MB, 8110080 bytes
255 heads, 63 sectors/track, 0 cylinders, total 15840 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 63 16064 8001 4 FAT16 <32M
#disktype /dev/sda
--- /dev/sda
Block device, size 7.734 MiB (8110080 bytes)
DOS/MBR partition map
Partition 1: 7.813 MiB (8193024 bytes, 16002 sectors from 63, bootable)
Type 0x04 (FAT16 <32M)
FAT16 file system (hints score 5 of 5)
Volume size 7.737 MiB (8112640 bytes, 15845 clusters of 512 bytes)
#file -s /dev/sda1
/dev/sda1: x86 boot sector, code offset 0x58, OEM-ID "IBM 7.1", root
entries 512, sectors 16002 (volumes <=32 MB) , Media descriptor 0xf8,
sectors/FAT 62, heads 255, hidden sectors 63, serial number 0x434b15d8,
unlabeled, FAT (16 bit)
-------------------------------
#Panasonic SD 16MB (rp-sd016b)
#(note: as formatted by Ghost Boot Wizard)
#fdisk -lu /dev/sda
Disk /dev/sda: 14 MB, 14909440 bytes
255 heads, 63 sectors/track, 1 cylinders, total 29120 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 63 16064 8001 4 FAT16 <32M
#disktype /dev/sda
--- /dev/sda
Block device, size 14.22 MiB (14909440 bytes)
DOS/MBR partition map
Partition 1: 7.813 MiB (8193024 bytes, 16002 sectors from 63, bootable)
Type 0x04 (FAT16 <32M)
FAT16 file system (hints score 5 of 5)
Volume size 7.737 MiB (8112640 bytes, 15845 clusters of 512 bytes)
#file -s /dev/sda1
/dev/sda1: x86 boot sector, code offset 0x58, OEM-ID "IBM 7.1", root
entries 512, sectors 16002 (volumes <=32 MB) , Media descriptor 0xf8,
sectors/FAT 62, heads 255, hidden sectors 63, serial number 0x2e7717e0,
unlabeled, FAT (16 bit)
#parted /dev/sda print
Model: Generic STORAGE DEVICE (scsi)
Disk /dev/sda: 14.9MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 8225kB 8193kB primary fat16 boot
Using BIOS version A08 for the OptiPlex GX280, and A10 for the GX620. PXE booting is the basic practice here, but for testing I've resorted to ISOLINUX booting (with the same results). Interesting to know about the "superfloppy". Thanks for the link. When I have some extra time, I'll try to read more about that option. Helpful though. Get well, and I hope that you feel better.
Splendid trick using dd to help better compress an image. I did not know that was possible. Thank you for sharing. More information now to share about my MEMDISK issue for possible reference. I created an ISO image of my test disc that contains the PC-DOS/Ghost disk image. I then remastered the test CD to include the ISO image. Using SYSLINUX 4.03's MEMDISK to boot the ISO image file surprisingly allowed for the Ghost environment to see the GX280's SATA drive. That is, no "We lost the last drive in our class of drives" occurred using this approach -- booting an ISO containing the HDD image, unlike booting the HDD image directly. Doubly odd, no? Regards. ----- Original Message ----- From: "Shao Miller" <Shao.Miller at yrdsb.edu.on.ca> To: syslinux at zytor.com Sent: Tuesday, December 7, 2010 7:33:30 PM GMT -05:00 US/Canada Eastern Subject: Re: [syslinux] MEMDISK issue with OptiPlex GX280,620 Oh, I forgot to mention that MEMDISK can gunzip a gzipped initrd (the RAM disk image). Thus if you delete all unwanted files out of the disk (or attached/mounted disk image), then do something like: dd if=/dev/zero of=/mnt/ghost/0 ... No space left on device... rm /mnt/ghost/0 umount /mnt/ghost gzip -9 ~/ghost.hdd You will get a pretty nice size for the resulting file. :) Filling the filesystem's unused space with a 0 pattern should allow it to compress quite well. - Shao Miller _______________________________________________ Syslinux mailing list Submissions to Syslinux at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.
Pardon my delay in responding. The past day had me reviewing the disk image being used - specifically, its geometry and its history. Ghost imaging has long been an integral part of the environment here. With that said, relying on Symantec's Ghost Solution Suite's Ghost Boot Wizard to create a Network Boot Package in the form of an ISO and CD had been the way for years. Enter SYSLINUX and an available, local PXE server, and CD booting was migrated to a less-archaic method of imaging. The ISO produced from the Boot Wizard was not to be dismissed though. The ISO file contains a 24 MB disk image; one that is larger than I prefer and loading slower than desired. That image is, in effect, the source of my hacked/modded 8MB disk image. I need something larger than 4 MB but less than 24 MB. Upon Shao's splendid advice of gzipping initrd and seeing the results, I have elected to start anew. I returned to the ISO (and its embedded 24 MB disk image) produced from the Symantec GSS Boot Wizard. After gzipping the disk image, I now have a ~6 MB file. Nicely, it loads rather quickly - besting the 8 MB image. Additional to this clean approach, the disk image's geometry is explicit. Based on yours and Gene's comments about disk geometry, I feel much better now having a sound disk image. Progress, agree? Booting the new image though has changed little. Version 4.03 of MEMDISK (ISOLINUX and PXELINUX both invoked for testing), produced these results: MEMDISK 4.03: Ramdisk at 0x07f099000, length 0x005cc813 moving compressed data 0x07f099000 to 0x7d939a00 gzip image; decompressed addr 0x7df06400, len 0x01780800: ok command line: initrd=images/ghostclient/280_620/osbootc.img.gz BOOT_IMAGE=memdisk MEMDISK: Image seems to have fractional end cylinder Disk is hd0, 24066 K, C/H/S = 2/255/63 (MBR/MBR), EDD on, rw Using safe INT 15h access to high memory Code 1744, meminfo 264, cmdline 70, stack 512 Total size needed = 2590 bytes, allocating 3K Old dos memory at 0x9fc00 (map says 0xa0000), loading at 0x9f000 1588: 0xffff 15E801: 0x3c00 0x07cf0 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 = f0005c6f int15 = f000f859 int1e = f000efc7 new: int13 = 9f00000a int15 = 9f0003ba int1e = f000efc7 Loading boot sector... booting... Starting PC DOS... Again, Ghost is unable to see the internal SATA drive from this image's booted environment. Reverting back to MEMDISK 3.83, the 'lost last drive' message does not occur and Ghost can see the SATA drive. To reiterate, this image does not work on OptiPlex GX280s and GX620s via MEMDISK versions newer than 3.83. The image will work on the OptiPlex 755,780, and 980 systems via all MEMDISK versions post 3.83. And as much as a superfloppy might assist here, its 3840 KB capacity is generally inadequate. If it helps, I could provide a copy of my image for personal testing and examination. If you're interested, please let me know how it would be best to deliver the ~6 MB image. Thank you and Gene both for responding this week. Regards.
Happy New Year to all; and please do pardon my digging this topic back up. I attempted to send for testing my disk image via a private email to Gene, but did not have confirmation of it being delivered/received. Could the attachment have exceeded a mail server limit? That's my concern - call me paranoid. Given Gene's discovery of the BCM5751 [14e4:1677] being a common denominator to the GX280 and GX620 Dell systems, I am intrigued by what this might hold for any possible alterations to MEMDISK or workarounds. If there is some way that I might be able to help in testing, then I'm open. Thanks again for everyone offering their time and responses. Regards. ----- Original Message ----- From: "Gene Cumm" <gene.cumm at gmail.com> To: "For discussion of Syslinux and tftp-hpa" <syslinux at zytor.com> Sent: Friday, December 10, 2010 9:10:30 PM GMT -05:00 US/Canada Eastern Subject: Re: [syslinux] MEMDISK issue with OptiPlex GX280,620 On Fri, Dec 10, 2010 at 20:28, Jason Vasquez <jvasquez at kennesaw.edu> wrote:> Pardon my delay in responding. The past day had me reviewing the disk image being used - specifically, its geometry and its history. > > Ghost imaging has long been an integral part of the environment here. With that said, relying on Symantec's Ghost Solution Suite's Ghost Boot Wizard to create a Network Boot Package in the form of an ISO and CD had been the way for years. Enter SYSLINUX and an available, local PXE server, and CD booting was migrated to a less-archaic method of imaging. The ISO produced from the Boot Wizard was not to be dismissed though. The ISO file contains a 24 MB disk image; one that is larger than I prefer and loading slower than desired. That image is, in effect, the source of my hacked/modded 8MB disk image. I need something larger than 4 MB but less than 24 MB. > > Upon Shao's splendid advice of gzipping initrd and seeing the results, I have elected to start anew. I returned to the ISO (and its embedded 24 MB disk image) produced from the Symantec GSS Boot Wizard. After gzipping the disk image, I now have a ~6 MB file. Nicely, it loads rather quickly - ?besting the 8 MB image. > > Additional to this clean approach, the disk image's geometry is explicit. Based on yours and Gene's comments about disk geometry, I feel much better now having a sound disk image. Progress, agree? > > Booting the new image though has changed little. Version 4.03 of MEMDISK (ISOLINUX and PXELINUX both invoked for testing), produced these results: > > MEMDISK 4.03: > > Ramdisk at 0x07f099000, length 0x005cc813 > moving compressed data 0x07f099000 to 0x7d939a00 > gzip image; decompressed addr 0x7df06400, len 0x01780800: ok > command line: initrd=images/ghostclient/280_620/osbootc.img.gz BOOT_IMAGE=memdisk > MEMDISK: Image seems to have fractional end cylinder > Disk is hd0, 24066 K, C/H/S = 2/255/63 (MBR/MBR), EDD on, rw > Using safe INT 15h access to high memory > Code 1744, meminfo 264, cmdline 70, stack 512 > Total size needed = 2590 bytes, allocating 3K > Old dos memory at 0x9fc00 (map says 0xa0000), loading at 0x9f000 > 1588: 0xffff ?15E801: 0x3c00 0x07cf0 > 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 = f0005c6f ?int15 = f000f859 ?int1e = f000efc7 > new: int13 = 9f00000a ?int15 = 9f0003ba ?int1e = f000efc7 > Loading boot sector... booting... > Starting PC DOS... > > Again, Ghost is unable to see the internal SATA drive from this image's booted environment. > > Reverting back to MEMDISK 3.83, the 'lost last drive' message does not occur and Ghost can see the SATA drive. > > To reiterate, this image does not work on OptiPlex GX280s and GX620s via MEMDISK versions newer than 3.83. The image will work on the OptiPlex 755,780, and 980 systems via all MEMDISK versions post 3.83. And as much as a superfloppy might assist here, its 3840 KB capacity is generally inadequate.With regards to why those exact two models, I may have some insight (it just dawned on me). BCM5751 [14e4:1677] (rev 01). Models GX260 and GX270 used Intel chips and the models 740 and 745 used BCM5754 chips. Models 755, 760, 780 and 980 all use Intel chips. A Dell Latitude D610 also uses a BCM5751 and may experience the same behavior. Along the lines of superfloppies, I think the LS-120 drive _might_ have acted like a true superfloppy (big unpartitioned device). You can go bigger but you'll need to specify and track your geometry more carefully. The others are just standard sizes (even if rare like the 3840 kiB size).> If it helps, I could provide a copy of my image for personal testing and examination. If you're interested, please let me know how it would be best to deliver the ~6 MB image.I'd be interested in seeing it. Private email or a web link are the two quickest methods at least for me. I might even be able to make one like it.> Thank you and Gene both for responding this week. Regards.-- -Gene _______________________________________________ Syslinux mailing list Submissions to Syslinux at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.