You may want to mess up with SDI only when your image is ready for
deployment. That means you may now work only on your image and forget about
SDI until you are done with the image changes.
Sometimes (depends on how hard it is to copy an XPe image on a target
device) it might be useful to use Remote Boot Manager and SDI tools just to
deploy (should read - copy) your image to the target. In case of using hard
drive on the target it would potentially be more time-saving to just plug
the hard drive into your dev machine and copy the image on it. Then you plug
the drive back into your target machine and see how XPe image runs (FBA will
be preparing the image first).
And again, XPe/XP Pro is very different from linux so you may not want to
even try to compare their remote booting. XPe image does require some
pre-setup things on target (registry, PnP, drivers, etc.). It is
inconvenient for development phase but we all have to live with that until
Microsoft (with or without help of this NG) think of another approach.
I believe one of the good advantages of XPe is that it's based on XP Pro
binaries. That allows to run many applications written for XP Pro on XPe
images but it also applies many restrictions to building XPe images and
brings many problems and discomfort to the development process under XPe.
That can't be changed (at least in short time frames) unless you want to
have a new embedded OS with different structure than XP Pro.
I (and probably some other folks here) am realy wondering why you put so
many efforts getting into such a new area for you as XPe? You don't seem to
be very familiar with Windows (XP/XPe) and definitely prefer linux. You also
don't seem to like exploring of new software. Your posts are full of
complains about Microsoft product and that might stop many knowledgeable
people from helping you out. I would suggest you to either drop the
development under XPe or dig deeply into it and read as much XPe
documentation as you can before posting your questions.
If you have constractive questions, please try to asnwer them from reading
the docs first. If you can't find answers yourself, please compile your
questions and post it here without complains.
Thanks,
KM
PS. Personally, since I have gone through the remote boot process myself, I
believe that Saad's emails posted recently to this thread should certainly
answer almost all of questions. So, please read them carefully.
a> Ok. So how do you propose to do this copy of the image to the target
a> machine? Remove the target harddisk, insert the disk in the dev
a> computer, fdisk and format the target hard disk, and then copy the
a> contents of d:/windows embedded images/ to the drive, shutdown the
a> host computer, remove the target driver, insert the target drive in
a> the target machine, boot and then the target disk can be removed,
a> reinserted into the host machine again, then copied to a SDI disk...
a> Am I going to have to do this everytime I tweak the boot image?
a> JDa> etc.
a> confers no rights.
a> us/remboot/html/xpconpreparingremotebootimagefordeployment.
3.. Create an SDI disk of the appropriate size using
the SDI loader
utility.
Done.
4.. Format the SDI virtual drive using Disk a> Management
Console,
Diskmgmt.msc. When prompted, do not choose to create a> the
volume as a dynamic
disk.
Done.
5.. Copy your run-time image to the SDI volume. It is
not necessary to
copy the Ntdetect.com, Ntldr.exe, or Boot.ini files to
the SDI volume
because they are automatically downloaded from the a> server
during an early
phase of Remote Boot.
Ok.
6.. Create another SDI image that will contain the
partition for the SDI
disk created in Step 2.
In step 2 you told me to install the tool and not a> create a
disk. What are you talking about?
[Saad Syed] If you read below, I've explained the first a> SDI is created with
SDILoader to mount a DISK which you'll copy files into. a> The *SECOND* SDI is
created with SDIMGR.WSF to create an SDI file with a a> PARTITION or VOLUME. Do
not confuse the two SDIs. If you follow the steps a> correctly you'll figure
out what I'm talking about.
This will be the final SDI image that will reside on the Remote
Boot server. The following command line
example shows how to
create the new SDI image using the SDI manager command
line utility.
sdimgr /new c:\ramdisk.sdi sdimgr c:\ramdisk.sdi /readpart:f:
Your first command fails.
C:\tmp>c:\"program files"\"windows embedded"\utilities\sdimgr /new
ramdisk.sdi results in a dialog box which pops up and says:
This script must be run using the CSCRIPT WSH host.
Either explicaity invoke CSCRIPT or use "CSCRIPT //H:cscript: //S"
to select the host as the default.
the trailing .. on the second command look like you are trying to
guess a command or something. I didn't even a> try
that.
[Saad Syed] As the dialog indicates a> run "CSCRIPT //H:cscript" and retry.
This is what you should be running at the command prompt.
c:\tmp>cscript //h:cscript
c:\tmp>\Program Files\Windows
a> Embedded\Utilities\sdimgr /new ramdisk.sdi
c:\tmp>\Program Files\Windows Embedded\Utilities\sdimgr a> ramdisk.sdi
/readpart:F:
where 'F:' is the drive letter where the runtime was a> copied in steps 5. If
its G: use G:, etc.
This will give you ramdisk.sdi with just the volume, copy a> this to the
"\Program Files\Windows Embedded\Remote Boot a> Service\Downloads" folder. Use
Remote Boot Manager to specify this file in the image.
[Saad Syed] Step 7 was the one where you had to copy the a> ramdisk.sdi into
the downloads folder, it got messed up due to bad copy
a> pasting on my part.
a> this:
subnet 192.168.0.09 netmask 255.255.255.0 {
allow bootp;
<stuff deleted>
group {
host windev {
hardware ethernet 00:90:27:df:ca:48;
fixed-address 192.168.0.6;
option routers 192.168.0.1;
option domain-name-server 192.168.0.1;
# option domain-name-server 9.44.5.76; M$ can't handle a> DNS
outside subnet?
}
host wintarget {
hardware ethernet 00:90:27:31:95:9e;
fixed-address 192.168.0.7;
# what option goes here to tell target machine to use # the above
computer as its PXE boot server?
}
}
}
[Saad Syed] Unfortunately I'm not that familiar with a a> linux DHCP server.
But if I'm guessing correctly you'll need to remove a> the 'allow bootp;' line,
as this'll tell the PXE client that the PXE server is on a> the DHCP machine
which it is not. You can do a simple quick check to a> determine if the
configuration is working. Use reboot.com or abortpxe.com a> as the boot program
from Remote Boot Manager, yes don't need an image to test a> this. If the
client boots off pxe and reboots or aborts PXE, then the a> configuration
should work. If that doesn't work run a network sniffer a> or network monitor
to determine if the DHCP packet sent by the DHCP server a> to the client
contains an option tag '60' or not.
With best regards, KM. E-mail: (e-mail address removed)
