@Lee-Rowlett Any news on this yet?

@agray there are muc more uptodate versions of this done by @george1421 collaberating his version and mine which i’d suggest looking over but for just osid replace if statement with this:

case $osid in 5) osn="Win7" ;; 6) osn="Win8" ;; 7) osn="Win8.1" ;; 9) osn="Win10" ;; esac

Tutorial By George

Your findings, Lee, is about what I’d expect. This, of course, if the deploy is done (well maybe not now) from a unicast stand point rather than a Multicast.

Compression is a fickle thing. Uploading anything and compressing before doing so always take far more time than re-obtaining the data even if the re-obtaining is highly compressed. This is because the CPU is actually doing much more work finding what can and how much it can be compressed.

On a download, the less data you have to transfer, the faster it transfers.

Don’t think there’s a way to do it with “chain.32”. I found other references to “pxechain.com” from the linux utilities.
I added the following and it seemed to start booting but unfortunately didn’t boot WDS:

LABEL Windows Deployment Services
kernel pxechain.com
append IPADDRESSGOESHERE::boot\x64\pxeboot.n12
MENU LABEL Windows Deployment Services
TEXT HELP
Loads the Windows Deployment Services Imaging Environment.
ENDTEXT

So I’m going to give up on this one and do what everyone else seems to have done.
Which is to put the linux boot files onto the WDS location and modify from there instead.
Reference: [url]http://www.syslinux.org/wiki/index.php/WDSLINUX[/url]

Actually, someone found this as well (multi-PXE boot) which I might try out first:
[url]http://www.vcritical.com/2011/06/peaceful-coexistence-wds-and-linux-pxe-servers/[/url]

Hi,

i don’t understand the hole thread also the title!
I just can a little foresee what u may ment.

Greetz X23

I’d suggest adding in the following lines right after “ntfs-3g -o force,rw $part /ntfs”:

[CODE]printf “Error Message: $?\n”;
sleep 10;[/CODE]

Or use echo instead of printf. Just to see if there’s anything useful in there.

Tried finding the exit codes online, but it looks like the fastest way to find them would be to pull up the ntfs-3g man page from the console to see what the exit codes are (here’s the reference page which suggests doing that):
[url]http://www.tuxera.com/community/ntfs-3g-manual/#9[/url]

sysfs,

You also have to mount it.

The gzip is ext2 formatted file/filesystem.

The way you edit is to perform these tasks:

First unzip, as you already know how but just for clarity sake:
[code]cd /tftpboot/fog/images
gunzip init.gz[/code]

Then make another directory and mount it like a filesystem:
[code]mkdir tmp
mount -o loop init tmp
[/code]

Then cd into the tmp folder and you’ll see all the scripts and the “Root” filesystem fog uses. Most of the scripts are in the bin folder so:
[code]
cd tmp/bin
[/code]

Then you can edit all the scripts you need to.

When you’re all complete perform these tasks:

[code]
cd /tftpboot/fog/images
umount tmp
gzip -9 init
[/code]

You should, then, have successfully customized your init.gz file.

Do you see any errors in your apache log files when mail is being sent? I guess you need to configure smart host with sendmail… [url]https://www.dnsexit.com/support/mailrelay/sendmail.html[/url]

I glad 🙂
We use a fog 0.30 customized version :oops: But the LDAP validation, I think that is easy to migrate to a new version of FOG.
The “site” layer and technician rol, is much more difficult. Sorry.
I just started the migration of code from the old version to the new FOG version.

I would really like to implement this solution as well, any chance of getting a complete tut?

Added this to quick inventory screen as it was very simple. Thanks Lee!

one is based off of rhel the other ubuntu so it won’t be as easy as getting those images into the init/bzimage as both os’s handle splash/init a bit differently but I’ve taken apart init enough times and am fairly familiar with ubuntu so I think I should be able to marry the two without too much of a headache and in the end we can/will have a usb/cd bootable image that can come in handy aside from loading via pxe.

this was indeed the culprit! thank you very very much, saved me a big headache! 😄

This is a change from 0.31 to 0.32 you have to use 0.31 for this patch to work. It work great on a 0.31 system for me along with some other modifications we can image machines all on the remote network with very little WAN traffic.