Posts made by explosivo98

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

@Quazz dang, no luck. This tablet is x64 so there shouldn’t be a need to try the 32bit kernel right? Or are there some cases where the x32 config worked when the x64 wouldn’t?

Hey all, I’m doing a bit of thread necromancy here to ask if there’s ever been any breakthroughs on solving this particular error. These tablets are really the only thing in our arsenal that we still need to manually image with a Clonezilla drive and, well, everyone here loves the way Fog works now that we deploy 99% of our systems using it. I did try one of the newer kernels (4.19.64) for the heck of it but didn’t notice a difference. I wasn’t sure if there were any new experimental kernels to try that might help with this or what so I figured I’d ask.

Same results (black screen, no text) with the 4136 kernel. I looked through the BIOS and there’s not a ton of options to change, but I did try flipping a few of them on/off with no luck. 32 bit kernel looped back around to a dark version of the main FOG menu when I tried to choose compatibility mode, which was strange, but then trying to deploy an image I got a “Could not boot: Error 0x71048283” message three times before sending me to the iPXE command line.

I’m not sure if it matters but poking around in the BIOS reminded me that these things do support Android. There’s three options in the bios for “Droid Mode” “Android Mode” and “Windows Mode”, all of which are set to be disabled on the stock tablet except the Windows option which says “Windows 8.x”. I don’t know if that means the drives are partitioned in such a way that it would cause issues like this but that was about the only thing I found looking around in the BIOS for settings to change.

@george1421 haha I got you. I went ahead and added that argument but no change

@george1421 okay, and to be sure this goes under “Host Kernel Arguments”, correct?

@george1421 Yeah I have a couple here and they all seem to be doing the same thing. I did find this post from a while ago about some new kernel inits that were manually created to resolve this in the past, but the links don’t seem to work anymore. Not sure if this is what you were referring to or not but in my time scrubbing the forums for the solution I did notice it but couldn’t proceed:
https://forums.fogproject.org/post/121137

@Sebastian-Roth ah okay, unfortunately after seeing that message it goes back to the same repeated error. I did attempt to run the debug kernel option in the FOS menu and it looked like it was about to do something but then started showing the rcu_sched error again with more bits of information in between, however there was a bit more info attached to this one regarding the system

@george1421 Hmm, if I can get this working that’d be an okay workaround provided they still can select the image being deployed without having to be registered first. I made a boot USB using the .img file you provided but when trying to go back into the compatibility menu I get a “db_root:cannot open: /etc/target” message, followed by the same cascading “rcu_sched” errors if left alone long enough.

@george1421 They are 64 bit devices (Atom x7-Z8750). We’ve supported some betas on these tablets before and we were able to boot to Clonezilla on USB to image them individually in the past.

@george1421 I finally had some time to test this out today and was able to successfully manually assign the new kernel to that device, but when booting into the compatibility mode option the screen goes black and nothing shows up. There’s no flashing cursor or anything, just a black screen.