@jra you don’t
no longer needed. it wasn’t very good encryption when we did use it either.
@jra you don’t
no longer needed. it wasn’t very good encryption when we did use it either.
personally, i’d like a way to disable the mobile interface (other than deleting the mobile directory from the server, like i do now). i use the “Mobile/Quick Image Access Only” user type as a limited permissions account that can only do things from the pxe menu. i don’t want my student workers to be able to use the mobile interface.
using the method wayne posted would give you the complete database, including the hosts and image info. if you didn’t want to do a complete database restore, you could pull the data you wanted from it anyway.
for what it’s worth, i’m testing a few things with this new compression method. i’ll share my results.
does the powershell script file end on a space, newline, or a character?
legacy client or new?
if the purpose of the script is to restart the computer, why not have the restart command in the powershell script?
[quote=“Tom Elliott, post: 39160, member: 7271”]It’s alright, you can blame me.[/quote]
Improving the core functionality of fog is more important then retaining compatibility with a new experimental feature. So, ok, i blame you for improving the core functionality of fog.
i have not been able to get “ultra” levels (>=20) tasks to work without crashing. anyone else seeing the same?
@Wayne-Workman well, if it’s the legacy client, i probably know what the issue is. more knowledgeable devs can correct me if i’m wrong here, but the way the client checks to see if the task has completed is by waiting for the exit code of the program it launches. for an .msi install, this is msiexec.exe for powershell, this is powershell.exe, for a bat file, that’s cmd.exe ( i think). the issue is that msiexec.exe and powershell.exe may exit before the script they’re running (as a subprocess) is finished, providing an exit code and making the client think that it’s finished. this only really seems to be an issue when there’s a reboot involved, because then it doesn’t get the time to actually finish. (or when the running of a snapin relies on the previous snapin having completed, since it can run prematurely)
edit: this may also be an issue with the new client. i don’t know. ask jbob on that one. i don’t know as much about the new client. i hope to start using it more soon
for those interested, torrent-casting is not functional in the current SVN
changes have been made to the way that fog handles partition structure and other elements of imaging. these changes will be transparent to the end user, but greatly increase the overall capabilities and compatibility of fog. these changes did, however, undo much of the work done toward torrent-casting. while i plan on working to re-implement torrent-casting, i felt i should inform everyone that it could be a while before this feature is brought back.
@VincentJ “/tmp/pigz1” is just the name of the fifo that the data is being piped into to be sent to compression. maybe we should rename it for purely aesthetic reasons, but that’s working as it should. was the previous image also Multiple Partition Single Disk (non re-sizeable)?
typing “fog” after it has finished it’s task will make it try to do the task again, only this time the server will say that the task isn’t valid (because it’s already finished).
if you’re having trouble sharing images on the forum, you can post your images to an image hosting site like imgur and share the links.
i would guess that the first image on your server is a non-re-sizable image based on it’s size.
it’s possible that the other two have been uploaded with images that don’t contain any data.
for anyone interested, torrent-casting is now functional in the current svn, but it does require a few steps to be done manually at the moment. if anyone is interested in trying it out, i can walk them through it.
@george1421 i actually don’t think this is as massive of a rewrite/change as you imagine. Tom put a lot of flexibility in the code. I honestly think this could probably all be done with a plugin.
i mean, it’s beyond MY skill level. but someone could do it.
@yochaigal u.kpxe still has 4 characters after the period, that may be causing issues if it’s trying to adhere strictly to 8.3 format (disclaimer: i haven’t looked at the pcap file)
i didn’t realize this thread existed, but i’ve been working on this feature.
[quote=“Bjorn Jentoft, post: 35888, member: 587”]
I have actually done bittorrent downloading for imaging for a few years. However, I have been downloading the image file the normal bittorrent way. to a temporary partition, without piping it, and then running the actual imaging process and cleaning up the partitions afterwards. This is a delay in the process I would like to get rid of.[/quote]
if you had shared this, you could have saved me some work. lol
@Tom-Elliott i’m going to disagree with tom on the speed sacrifice with -19 setting. deploy speed, you won’t sacrifice much, and maybe even gain, but on capture it’s going to take quite a while longer. for me, i use -11.
could you try renaming the file to undionly.0 ?
how about this:
have your people
doing it this way, you have a hardware inventory of each computer, and a log of them getting the “!KilldiskTask!” deployment
you could try this http://ipxe.org/download
burn to cd or make a usb boot drive. this will load an ipxe network boot rom into memory and boot to it, instead of the network card’s onboard boot rom