@Sebastian-Roth I need to do testing tomorrow but I was able to get this working at the very end of my day today. I’ll post the details tomorrow if it works but I did a fresh reinstall of Debian, set up the bonded interface first, and then did the Fog install, pointing it to bond0 during setup. I also had to remove a couple lines from the interface config. I was able to get an IP from each port so it’s looking real good but need to verify/test tomorrow to be sure.

Okay, so after some testing this morning I’m happy to report that I was able to get this working. I was going off the guide on the wiki which had it configured almost exactly like I pasted in the OP, but after some googling I saw people recommending NOT including the bond-primary lines for each of the bonded interfaces. I commented out those lines to test and sure enough it worked. Below is my current network interfaces config:

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet dhcp

auto bond0
iface bond0 inet static
   bond-slaves none
   bond-mode 2
   bond-miimon 100
   address 192.168.214.10
   netmask 255.255.255.0
   network 192.168.214.0
   broadcast 192.168.214.255
   gateway 192.168.214.1
   hwaddress ether 90:e2:ba:f5:58:ba

auto enp2s0f0
iface enp2s0f0 inet manual
   bond-master bond0
#   bond-primary enp2s0f0 enp2s0f1

auto enp2s0f1
iface enp2s0f1 inet manual
   bond-master bond0
#   bond-primary enp2s0f0 enp2s0f1

I think what also helped was a clean reinstall of Debian; when I posted this thread I was attempting to change existing settings from a pretty setup using only one of the network ports. I did a full reinstall and configured the interface bonding FIRST, then once I was confident that was working I ran the Fog installer and used bond0 as the interface. Installation completed without a hitch and I was online. I appreciate the assistance, I definitely learned a lot along the way, but the solution to this problem of mine with multiple network ports ended up being much easier than anticipated once I knew what to do. Now it’s time to image!

@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.

@sebastian-roth thank you, there’s a lot of helpful info here. I know details are light and I apologize, but working from home so I don’t have the exact error codes right now but have someone in our lab now so hopefully should get some info later. And to clarify i’ve only used FOG for imaging (I think that’s all we can use it for :p) but I meant that in general this is the first time I’ve been doing imaging so I don’t really know about standards and practices that might be normal for imaging (like sysprep etc)

@george1421 Windows 10, and yeah for the record I don’t think that FOG is doing anything wrong throughout the process, it seems to be working as it should be but I’m only now realizing that there’s likely issues with the hardware or images themselves that might’ve gotten passed down through multiple iterations of images. Developing on a VM sounds like a much better idea than what I’m doing and I may need to look into it, I basically have a rack of 10 or so systems that are supposed to only be used for imaging but hardware shortages mean sometimes we need them for other purposes so they get overwritten with images quite often. I always assumed there would be other issues related to not being created through a VM and not on the hardware it’s being deployed to but I guess not. No, I don’t do sysprep before capturing.

Hello, I’ve recently been having a lot of problems with systems being deployed with certain images on my server developing bluescreen issues either immediately after imaging, or anywhere from a week or more after deploying. I wasn’t initially thinking this was due to the image being used but it’s been happening pretty consistently with a few of our images and no others despite it all going on the same hardware. It’s actually become a pretty significant issue for us and I’ve been trying to chase down the cause of it but the ones that we get back are showing registry errors and I can’t even work with the drives, they’re totally shot.

I think right now my main theory is that since I’m updating and capturing the images on physical hardware that some of the systems I’m using for it are corrupt in some way, and those corrupt files are making their way onto the image which is killing some drives that are receiving it. On Friday I attempted to capture a new version of the image from an old backup I had of the problematic one and just found out this morning that it isn’t even able to be deployed right now with the <stdin> is not compressed error so I think that system I used to capture is completely gone and need to try again.

I did recently update to 1.5.9 in an effort to hopefully curb some of these problems but it doesn’t seem to have changed much. I have a few questions; I stumbled on a forum post from from 2016 from someone looking to develop a plugin that allows scanning of images for potential corruptions but all the links were dead and I haven’t been able to find anything out about this by searching around, is this something that can be done today? If there is a way to easily identify which images need to be re-done or uncover problems as they’re imaged that would be super helpful.

Secondly, I’ve been using FOG for a couple years now without too many problems but this is my first foray into imaging so I’ve sort of been doing all this on the fly. Is there a better way to be capturing these images to avoid these kinds of problems from happening? Like from a VM or something? I guess I should be doing SFC/DISM disk checks and all that before capturing images moving forward at least.

@george1421 okay, thought I’d check. This is an x64 device.

@george1421 would I need a new init file for this as well or no? I tried rebooting with the same debug task in queue from last time and it just froze after loading (successfully) the init file. I rebooted with the task canceled and selected the system compatibility check option and it just went to a black screen after that.

@george1421
hm, the hardware ID for this looks like it’s just a generic driver, it shows as SD\GenDisk in the device manager. I’m on the command prompt now but lsblk returns nothing and the grep commands returned “no such file” when ran.

Edit: Trying the kernel now!

@george1421 yeah I am, like I said I tried switching between some of the hard drive types but nothing made a difference, but I assume since running the compatibility test returns a similar error that it probably doesn’t have anything to do with that anyway.

@george1421 Looks like it was the ACPI toggle that did it, I switched back to the newest production kernel after getting it working on the newest dev build and it worked there so right now I’m using 4.19.64

@george1421 !! holy cow, that actually got me past the rcu_sched error! This is farther than I’ve ever gotten with this. Everything looked like it was going to work and I was ready to throw a party but it failed the getHardDisk check, it can’t detect the hard drive on here now for some reason. The storage on this is a Sandisk DF4064 which is an eMMC drive if that matters. I tried single disk resizable mode as well as multi partition non resizeable and neither worked. Running the compatibility test does show a Fail for the hard drive check as well. Are there special considerations I need to make when dealing with one of these drives?