[syslinux] Debugging memdisk loaded via pxelinux

Michael T. Davis davism at ecr6.ohio-state.edu
Mon Oct 24 19:08:44 PDT 2011

At 01:11 PM 10/22/2011, Gene Cumm <gene.cumm at gmail.com> wrote:

>On Sat, Oct 22, 2011 at 12:59, Michael T. Davis
><DAVISM at ecr6.ohio-state.edu> wrote:
>> At 08:36:27.26 on 22-OCT-2011 in message
>> <CAD0RxenXopH-Bu_qjascNqYfMCFd=eEKQ_Y5z7U4k9830Pym4w at mail.gmail.com>, Gene
>> Cumm <gene.cumm at gmail.com> wrote:
>>>On Fri, Oct 21, 2011 at 23:10, Michael T. Davis
>>><DAVISM at ecr6.ohio-state.edu> wrote:
>>>>      I have a USB flash drive that I'd like to image, and then load that
>>>>image via pxelinux and memdisk.  The flash drive was formatted under
>>>>Windows 98 SE as FAT, and boots just fine on its own.  The PXE boot process
>>>>gets as far as loading the image via memdisk, but then when the boot process
>>>>switches over to the RAM disk, it fails:
>>>> [...PXE diagnostic information...]
>>>> Loading boot sector...booting...
>>>> Invalid system disk
>>>> Replace the disk, and then press any key
>>>>Aside from re-keying all the information I can see on the PXE client/target
>>>>identified as "[...PXE diagnostic information...]", is there some way to log
>>>>this data so that I can cite it here?
>>>>      My DHCP/tftpd server is tftpd32 from tftpd32.jounin.net, running under
>>>>Windows XP Pro SP3.  I'm using a distribution of syslinux v4.0.4 (from which
>>  I
>>>>obtained pxelinux.0 and memdisk) I found via Google (since the syslinux site
>>>>is down).
>>>Are your partition(s) aligned to cylinders on the UFD?  I'd consider
>>>using fdisk to see what geometry is being used on the UFD then feed
>>>that information to MEMDISK (see doc/memdisk.txt for the parameter
>>        You don't specify, but I suspect you're talking about fdisk from a
>> *ix distribution, right?  I have access to CYGWIN and Mac OS X.  Will fdisk
>> in either of those environments work?  If so, do I just invoke `fdisk <dev>'
>> for the necessary information, then use that for MEMDISK's {c|h|s}=n options?
>If fdisk in DOS bothers to show geometry, that's also suitable.  Yes,
>MEMDISK normally guesses the geometry and marginal devices cause
>failures in the guesses.
>>        FWIW, I haven't done any special partitioning on the UFD; I just
>> formatted it under Win98 SE and requested installation of system files, so it
>> would boot.  As such, I believe there's only one partition.  I understand,
>> however, that you're referring to alignment of the partition relative to the
>> cylinders, not the number of partitions.
>So it was probably partitioned by the manufacturer.  It'd still be
>good to check it out.  Yes, alignment of the partition relative to the
>cylinders and ensuring it's the normal fashion.  If it's not, that
>alone will cause MEMDISK to guess poorly.
>>        I'm at home without access to the UFD or my test environment over the
>> weekend.  I do remember seeing the following during the image load, though:
>>  Memdisk: Image seems to have fractional end cylinder
>Not unusual but a good reason to check things out.  You may also
>consider shrinking the partition to perfect standard alignment then
>taking an image so the image ends on a whole cylinder.
>> I hope to gather what information I can over the weekend and apply it when I
>> return to work on Monday.  I appreciate this as a starting point.

        OK, the only version of fdisk I have under Windows is Windows 98, and
as far as I can tell, that doesn't report geometry.  This is what fdisk under
Mac OS X (v10.6.8) reports (after using df to determine the device name):

$ df
Filesystem    512-blocks     Used Available Capacity  Mounted on
/dev/disk0s2   624470624 28319944 595638680     5%    /
devfs                221      221         0   100%    /dev
map -hosts             0        0         0   100%    /net
map auto_home          0        0         0   100%    /home
/dev/disk3s1      503248     9392    493856     2%    /Volumes/GHOSTCLIENT

$ fdisk /dev/rdisk3
Disk: /dev/rdisk3       geometry: 999/8/63 [503808 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
*1: 0E    0   1   1 -  983  15  32 [        32 -     503776] DOS FAT-16
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused

Either this isn't valid, or I'm not understanding what I need to enter for the
c/h/s options to MEMDISK (or both, I guess).  Please advise.

        You seemed to imply that the manufacturer's partitioning scheme might
be the problem, so I blew away the partition under Win98's fdisk, then
reformatted under Win7, and used Win7's diskpart to set the only partition
as active.  Then I used Win98 to write its system files to the drive.  This
broke the UFD's ability to boot entirely.  I have several identical UFDs, so I
just used "USB Image Tool" to pull the image from another UFD, then re-imaged
the "broken" one, and it's back to proper boot functionality, now.

        You suggested "shrinking the partition to perfect standard alignment."
How might I achieve this?



More information about the Syslinux mailing list