Deployment stuck in a loop, never finishes imaging?

[salted_cashews]

@Junkhacker Oh I see, is FOS the preboot environment?

[Junkhacker]

@salted_cashews yes. it’s the minimal Linux OS that loads over the network to do the imaging tasks

[salted_cashews]

@Junkhacker Thanks for the info!

[george1421]

@salted_cashews FOS is the Fog Operating System that runs on the target computer. It is linux based and is built from bzImage (kernel) and init.xz (virtual HD) .

If you run a debug capture/deployment you can access this log file. It only exists on the virtual ram drive that FOS uses.

[salted_cashews]

@george1421 This is really interesting, is this why I’m able to almost-ssh into the box during an image/network boot?

[george1421]

@salted_cashews Yes. It IS an operating linux OS. If you boot into debug mode and then give root a password you can ssh into the box as root and run the debug deployment/capture remotely. I use this method when debugging/developing post install scripts.

[Sebastian Roth]

@salted_cashews Are you sure the image was captured with Zstd as well? If you change that option in the image setting you need to re-capture it!

Running a debug deploy task and ssh into it (you need to set a root password within the booted FOS environment on your client machine using passwd command) to look at the partclone.log is definitely a good idea.

[salted_cashews]

@Sebastian-Roth I’m 100% positive it was captured using Zstd, the only thing I can think of is something we did on the image before capture or a network issue during.

[Sebastian Roth]

@salted_cashews See if you can grad the partclone.log file and hope we get some more information from that.

[Sebastian Roth]

@salted_cashews I find it really strange that the filesystem does not seem to be clean. Are you sure the filesystem was clean when you initially captured the image? Sure the machine was not in some kind of hibernation when it was PXE booted to be captured?

[salted_cashews]

@Sebastian-Roth Indeed, the image was a CentOS 7 image that had been rebooted (hibernation on the OS is disabled via the GUI). This had happened with one other image as well, and I remember us running some basic “clean up” tasks beforehand. It’s possible these mucked up the file system or something. Let me see if I can trace back exactly what we did.

[Sebastian Roth]

@salted_cashews said in Deployment stuck in a loop, never finishes imaging?:

Let me see if I can trace back exactly what we did.

Maybe .bash_history…?

[salted_cashews]

@Sebastian-Roth To my dismay the host was just “nuked” this morning. On the bright side I’m testing another deploy debug and I’m SSHd into the guy. Is it possible to have the root password set via passwd by default on a deploy/capture? I’d love to just be able to jump in like this at-will.

[Sebastian Roth]

@salted_cashews Take a look at Tom’s post here: https://forums.fogproject.org/post/88286

Though I have not tested this myself lately it should still work I reckon.

[salted_cashews]

@Sebastian-Roth Thank you sir, as far as the logs are concerned this is what they report:

Partclone v0.2.89 http://partclone.org
Starting to restore image (-) to device (/dev/sda3)
note: Storage Location 10.10.100.252:/images/, Image name PPS_v9.0R2-dev_CentOS
we need memory: 208468 bytes
image head 4160, bitmap 200208, crc 4100 bytes
Calculating bitmap... Please wait... get device size 53687091200 by ioctl BLKGETSIZE64,
done!
File system:  EXTFS
Device size:    6.6 GB = 1601624 Blocks
Space in use:   4.5 GB = 1097323 Blocks
Free Space:     2.1 GB = 504301 Blocks
Block size:   4096 Byte
read ERROR:No such file or directory

Following this I get a bunch of errors about “inode” something or other, and then the eventual reboot.

[Sebastian Roth]

@salted_cashews Please run the following command on your FOG server: file /images/PPS_v9.0R2-dev_CentOS/d1p3.img

Post output here.

[salted_cashews]

@Sebastian-Roth

/images/PPS_v9.0R2-dev_CentOS/d1p3.img: data

[Sebastian Roth]

@salted_cashews Please run the same for all image files in that directory: file /images/PPS_v9.0R2-dev_CentOS/d1p*

[salted_cashews]

@Sebastian-Roth said in Deployment stuck in a loop, never finishes imaging?:

file /images/PPS_v9.0R2-dev_CentOS/d1p*

/images/PPS_v9.0R2-dev_CentOS/d1p1.img: data
/images/PPS_v9.0R2-dev_CentOS/d1p2.img: data
/images/PPS_v9.0R2-dev_CentOS/d1p3.img: data
/images/PPS_v9.0R2-dev_CentOS/d1p4.ebr: DOS/MBR boot sector; partition 1 : ID=0x82, start-CHS (0x1bf,247,57), end-CHS (0x2d9,99,10), startsector 8192, 20971520 sectors, extended partition table (last)
/images/PPS_v9.0R2-dev_CentOS/d1p5.ebr: data

[Sebastian Roth]

@salted_cashews Possibly this version of file does not detect Zstd compressed files. Please try to manually extract the image to see if that works properly:

zstdmt -d /images/PPS_v9.0R2-dev_CentOS/d1p3.img -o /images/PPS_v9.0R2-dev_CentOS/d1p3_extracted.dat

See if that triggers an error or not.

Hint: You might need to install package zsdt on your FOG server.