@Zerpie
I know it doesn’t directly address your issue; forgive me.
Hardware raid cards are pretty darn cheap (used server pulls etc). Have you ever tried to rebuild one of those fakie raids? I’ve seen really poor results when it actually comes down to rebuilding a mirror, and the performance of general use is garbage.
I agree. Fog should tell you “these images won’t really be deleted, I’m just going to pretend… you’ll need to ssh in and clean up”
I revived this thread, because I’m seeing this issue. I see other threads saying it works, but I am on
FOG 1.5.4 kernel 4.18.3 and have to ssh to actually delete the files.
I consider it resolved. Thanks for chiming in.
I feel like a bit of a dummy. It works now, and I suspect I just needed to run the “chkdsk /f” from prompt instead of what I figure is the less thorough one from disk properties. For completeness I’ve included what didn’t work.
Nice thought, but the thread you note doesn’t hold my solution.
https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/43
Bit locker is off as evidenced by the encryption control commands.
manage-bde -off C:
manage-bde -status C:
“Way 1” from the FOG wiki made no change either.
https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit
I believe command prompt “chkdsk /F” corrected the issue. I had previously just used disk check from disk properties, which doesn’t lock the drive. This was, however, in conjunction with a bios setting dealing with power saving that was causing hangs.
It sounds like your VM handler doesn’t know how to boot off PXE. I had to fiddle with VBox some to find the right NIC settings, but I was able to PXE boot VBox eventually. If your physical boxes can do it, FOG would seem to be up and functional.
I’ve captured most of the boxes around the house, but a couple of them don’t appear to resize. FOG tells me I’m capturing 232GB images.
During capture the bar says it is basically done at 122GB.
Image lists show it at 232GB
The folder shows something like 42GB
I’ve run cleanup, chkdsk, & defrags. These boxes aren’t encrypted.
Any tips to get these to behave/report properly?
Tried disabling Spanning tree with no effect.
It turned out to be a bios/UEFI setting “option rom launch policies.” New to me. In my defense, this box’s bios is pretty massive and clumsy to navigate through, but works now!
I feel stupid, but my issue appears resolved! Thank you very much George. I might not have ever stumbled through those screens again if it weren’t for you.
As an aside, the MAC address cloning is a little odd as fog find and tries to get an IP on the wrong NIC first, before it gives up and tries the next NIC.
@george1421
I hadn’t considered a MAC mismatch. This box has two NICs (one to control some equipment). They BOTH have the same MAC address… So maybe the box is trying to configure the first NIC that is only connected to a machine. Of course no IP will be given. Should I spoof a MAC for the “internet NIC” and enter taht in the host record? Will this method confuse FOG?
Details on this NIC say it supports pre-boot, but also speaks of available option ROMs. I’m not familiar with much of what I find in this document. Clueless here.
I might just swap out the NIC, but I don’t honestly know if it will make a bit of difference.
So this is an HP workstation with an I210-T1 NIC I’m trying to image. It is UEFI, and I don’t make it to the FOG boot menu. Instead I get this:
I added vendor codes to the DHCP / windows AD setup ages back, and all that is foggy. I can say that other UEFI boxes image ok.
Any advice on how to get PXE up on this one?
