@Mr_Matten Is the VM hard disk “dynamic” in size or fixed? (if it’s dynamic, try making it fixed instead, large enough to deploy the image of course)
Might also be worth going over the settings, especially CPU, since during deploy the client (the device you’re deploying to) will uncompress the image and then write which is CPU intensive.
It also needs enough RAM ofc.
Might be worthwhile to show us the VM settings altogether
@Hanz You probably have to kill the udpsender process as well?
I created a PR to fix some stuff and to hopefully handle errors better/more reliably.
I don’t think it will fix this problem necessarily, but it should should hopefully throw errors when we expect it to.
https://github.com/FOGProject/fos/pull/26
You can download the inits of it here: https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/PR-26/2/artifacts
if you’re interested in testing it out.
@Arrowhead-IT That’s because Audit mode is triggered by sysprep which only runs if the apps make it past the checks, it’s stupid, but hey.
@Mr_Matten Ah, glad you figured it out!
@Wayne-Workman Yes.
I did notice that in the prep stages of the capture it sets permissions for /images/macaddress rather than /images/nameofimage ,not sure if that’s relevant or not though.
On latest trunk I get the same error as https://forums.fogproject.org/topic/7153/unable-to-upload-image-error-returned-type-2-file-var-www-fog-lib-fog-fogftp-class-php/2
Obviously, deleting the folders prior to capture each time would get tedious after a while, so I’m hoping for a better solution.
@Eric-Johnson Very interesting, here’s what sfdisk man page has to say about it.
sfdisk uses BLKRRPART (reread partition table) ioctl to make sure
that the device is not used by system or another tools (see also
--no-reread). It's possible that this feature or another sfdisk
activity races with udevd. The recommended way how to avoid possible
collisions is to use exclusive flock for the whole-disk device to
serialize device access. The exclusive lock will cause udevd to skip
the event handling on the device. For example:
flock /dev/sdc sfdisk /dev/sdc
Note, this semantic is not currently supported by udevd for MD and DM
devices.
So perhaps adding flock $disk before sfdisk $disk < $file will resolve it
Making the line read as flock $disk sfdisk $disk < $file
@fry_p Some options to try out here in this thread:
http://superuser.com/questions/747830/file-name-warning-for-c-program
https://github.com/FOGProject/fogproject/blob/master/packages/web/lib/fog/user.class.php#L214
This function is where it validates the username.
It uses the same regex as the javascript that checks when you try and manually create an account.
@kek can you share some examples that failed so we could potentially modify it?
It doesn’t seem difficult, but we need to know if it’s valid for your case.
@goempie Upgrading the kernel is unrelated to the ipxe binaries, don’t worry.
Try pointing your DHCP server to the realtek.kpxe binary instead of undionly.kpxe like George suggested.
Don’t worry about wireless for now, wireless cards rarely ever support PXE, same goes for the BIOS supporting wireless PXE booting. So, it is most likely already trying to boot of the wired connection.
@JJ-Fullmer Thanks for the instructions; that worked!
Also, it will tell you that your password is blank when you do these steps, because when you set both a password and authentication plugin, the password gets ignored by mysql.
I skipped the step to set password in mysql console itself to test the installer handling itself.
Some notes on the situation for me:
Root password was set BUT only for ‘localhost’, but the host localhost did not have any type set (whereas the others had mysql_native_password)
Running the installer a second time, after successfully setting root password in previous installer run, ends in the same error. (due to line 1201 expecting a root password it no longer has access to)
@zpoling That makes a driver issue unlikely, so most likely it’s an issue with an unattend.xml file, at least in my experience.
@Jbob said:
@Rusty This is the best guide that has been written so far. It does include some text on fog server setup, so skip to the “WORKSTATION IMAGE CREATION” section
https://forums.fogproject.org/uploads/files/1443813159297-imaging-server.pdf
I second this. Although if you’re not using AD you need to change a few things.
@jmeyer It’s fixed in https://github.com/FOGProject/fogproject/commit/e0449fa268df2d10e3ea66cf78d4bc76da015afb dev-branch, but hasn’t been ported to working-1.6 it seems.
@zpoling For a test, you could try to remove the file before sysprep and capture and see if that resolves the problem.
@atarone I don’t know if ntfsfix is included in debug mode (guessing not), so assuming it’s not, boot up a linux distribution livecd, install ntfs-3g if it isn’t included yet and then try:
sudo ntfsfix /dev/sda4
And try again. If it still happens, then you can manually force the dirty bit to go away with
sudo ntfsfix -d /dev/sda4
It’s also possible that you simply have a checkdisk scheduled at some point.
You might also before doing all the above check the following registery key:
HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute
@boeleke You will need to go into the WebUI settings and change storage node IP as well as a few other things
Source: https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address
@RipAU You can set those variables manually by for example creating something like:
:variables
set fog-ip youriphere
set fog-webroot /var/www/html
:start
To my knowledge, you can’t just copy profiles from one account to another as it causes issue.
I think the better path to walk is to manipulate the registry entries for the default user profile and save those keys in a reg file to be applied at any time (or alternatively simply collect the registry manipulation in a batch file, same result really).
I use a combination of registry manipualtion and regular file adding/removing to customize the default user. It’s not perfect, but it doesn’t cause issues and has saved us a lot of time.
This part copies the theme from our local NAS and then manipulates the registry entries for default users so it becomes the default theme for any new user.
copy /y "\\path\to\theme\theme.themepack" %SYSTEMROOT%\Resources\Themes\
cmd /c reg load HKU\TempHive "%SystemDrive%\Users\Default\NTUSER.DAT"
cmd /c reg add HKU\TempHive\Software\Microsoft\Windows\CurrentVersion\Themes /v CurrentTheme /t REG_SZ /d "%SYSTEMROOT%\Resources\Themes\theme.themepack" /f
cmd /c reg unload HKU\TempHive