@sebastian-roth I have not, it seems to have just been that one time.

@epsilon52 First let me say that I 100% agree with Sebastian, but I also know a secret for the Dells.

Using the Dell CCTK (Command and configure tool) you can instruct the bios to pxe boot on the next boot up. This is totally outside the scope of FOG and not something that FOG is capable of, but the cctk tool has the ability to update/change bios settings from inside windows. So using that thought one could create a snapin (FOG deployable program) to run the preinstalled cctk command with the proper parameters to pxe boot on the next reboot only then instruct the computer to reboot. You would deploy that task after you have created an imaging task. I have not personally do this on my campus because I have other rules, but it should be totally possible with snapins and the fog client (I don’t use either in my environment).

As I said before I require the Imaging Tech to sit in front of the computer being imaged so they are 100% certain on what computer they are imaging. Because once in the past with the fully automated process we had an Imaging Tech pick the wrong computer and reimaged (i.e. erased) a VIP’s computer.

@sebastian-roth great, thank you!

@george1421 Oh, thanks for the info. Is there a way to use an AntiVirus to check the HDD?

@TimBr Please explain more presicely where you get the login failure and where it does work. Best if you take a picture or video. As well let us know about customizations on your FOG server and the version you run.

I am asking because neither a normal deploy nor debug need a login in general. So we need to know more to be able to help.

@sebastian-roth oh, ok 🙂 Thank you!

@Jim-Holcomb What do you mean by “manually” - through the FOG PXE boot menu?

@george1421 said in Need new kernel for Intel I225-V network card:

@will Lets try this kernel.

https://drive.google.com/file/d/1blQf70N3um0bXmr1wjzQbQk47TA97gpW/view?usp=sharing

its bzImage593RT2 the only changes is enabling that specific intel network adapter driver.

I have tested this new kernel. It is working with Intel I225-V NIC now. Thank you for your help.

Turns out the install was corrupted with TFTP files in /srv/tftp (as for ARCH installs. Re-running the installer fixed it all up.

@tom-elliott Thanks Tom!

@sebastian-roth thx for the support!

@LittleTux Thanks for the feedback on this!

@ihcrcdan We eventually got it resolved. We had to remove 3 columns from the mysql.user table. Once that was done, I was able to update the password and the installer was able to complete. Just took us a while to find that information.

@george1421 Thank you again, that fixed it.

@sebastian-roth
It’s still working for me.

@george1421 I’ve actually managed to deploy this image to a range of different hardware without doing the sysprep, although I guess the fact that this thread exists might indicate that’s not the best idea… I would very much be interested in the guide you mentioned, I think next time I’m in the office I’ll have to seriously look into doing it through vmware/vbox.

Figured it out. The old database was using the wrong bzImage file. Thank you again for all the help.

@cedre2 said in Network Printer:

Fog client can’t read on a network share from a domain and install printers

Can’t you create a network share specific for these printer stuff that is free to access without username/password?! That way the SYSTEM account used by the fog-client run as a service will be able to access the files.

@sebastian-roth Thank you for your help. I just saw from a recent post exactly that, here.

@george1421 said in Make room on fog server's storage:

@sjensen If you delete the image from the image list (not from within the image definition) the deletion action will only remove the list entry and leave the raw files behind. If you go into the image record and delete the image from there, there is a checkbox to also remove the raw files (or something named similar). This will purge the files from the disk.

@JDnoble18 As George said, permissions look fine. Now that I think of it again I can imagine you ran into an issue where the installer would mess up with a link to the web root directory. Please run the following commands and post output here:

grep FOG_VERSION /var/www/html/fog/lib/fog/system.class.php grep FOG_VERSION /var/www/fog/lib/fog/system.class.php ls -al /var/www

I just tested kernel update on FOG 1.5.9.49 and it works as expected. So it does not seem to be a general issue.