Posts made by salted_cashews

@Sebastian-Roth Yeah, it was honestly my fault. Normally I’d capture and deploy immediately after to test, but these past few weeks have been ridiculously insane for me and my machine to image allocations haven’t been as up to date as they normally would’ve been.

I noticed this happened once before with a Windows image, but it was related to the dirty bit and another issue I found here. All in all I wanted to at least report and give this a go, I apologize for taking your time but as always appreciate the help. If this does happen again, I’ll be sure to give those kernels a go and report back here the results.

@Junkhacker Ah, that makes sense now that I think about it.

@Sebastian-Roth Haha, no worries. Unfortunately it didn’t work but this certainly was an interesting learning experience. This has made me curious: Does the task via the GUI and task on the client both have to be restarted (i.e. the computer rebooted and the old task killed, new task created) in order for an image to be deployed? I only ask because I’ve been using debug mode quite a bit but noticed I couldn’t start a new task without rebooting the client first. I would try to schedule a new task via the GUI but it would only take the old one when I ran “fog” at the CLI. From my perspective this makes sense as the FOS is deployed after PXE boot and that FOS contains only the information it was given from that correct?

@Sebastian-Roth True, I’ve elected to at least give it a go. I did notice the image progress screen was a bit off, is this the init/kernel?

@Sebastian-Roth Unfortunately the machine in question has been imaged over, so the original image that is now broken no longer exists aside from the copy on the FOG server. Should I still try using those Kernels on deployment? I know you said the capture might’ve been the problem though.

@Sebastian-Roth Certainly so! I won’t have to worry about these new kernels breaking any working images would I? Would making a backup beforehand be a wise choice?

Also, I appreciate the work you guys do here very much. I understand you’re all doing this in your own time and that changes might come sooner or later. I’ve learned quite a lot from using FOG as a whole and speaking with you and everyone on the forums. Anything I can do to help I’m willing to jump in.

@Sebastian-Roth Interesting, so a simple update to the latest build seems to be a solution? I remember you saying (about a month ago no less) that you guys were releasing a new version. Interesting, I really need to keep hounding my superiors lol.

@Sebastian-Roth

Before:

administrator@FOG-DHCP:/images/PPS_v9.0R2_dev_CentOS$ cat d1.fixed_size_partitions
:4:5

After:

administrator@FOG-DHCP:/images/PPS_v9.0R2_dev_CentOS$ cat d1.fixed_size_partitions
:3:4:5

administrator@FOG-DHCP:/images/PPS_v9.0R2_dev_CentOS$ cat d1.partitions
label: dos
label-id: 0x000b34c0
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     2097152, type=83, bootable
/dev/sda2 : start=     2099200, size=   262144000, type=83
/dev/sda3 : start=   264243200, size=   104857600, type=83
/dev/sda4 : start=   369100800, size=   568602112, type=5
/dev/sda5 : start=   369108992, size=    20971520, type=82

administrator@FOG-DHCP:/images/PPS_v9.0R2_dev_CentOS$ cat d1.minimum.partitions
label: dos
label-id: 0x000b34c0
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=      531963, type=83, bootable
/dev/sda2 : start=     2099200, size=    95734010, type=83
/dev/sda3 : start=   264243200, size=    13453641, type=83
/dev/sda4 : start=   369100800, size=   568602112, type=5
/dev/sda5 : start=   369108992, size=    20971520, type=82

administrator@FOG-DHCP:/images/PPS_v9.0R2_dev_CentOS$ cat d1.original.fstypes
/dev/sda1 extfs
/dev/sda2 extfs
/dev/sda3 extfs

@Tom-Elliott

:3:4:5

Like so?

@Tom-Elliott
No problem, here’s the output:

administrator@FOG-DHCP:/images$ ls -lhart /images/PPS_v9.0R2_dev_CentOS/
total 30G
-rwxrwxrwx  1 root          root             5 May  2 07:27 d1.fixed_size_partitions
-rwxrwxrwx  1 root          root           368 May  2 07:27 d1.partitions
-rwxrwxrwx  1 root          root            48 May  2 07:29 d1.original.fstypes
-rwxrwxrwx  1 root          root             0 May  2 07:29 d1.has_grub
-rwxrwxrwx  1 root          root          1.0M May  2 07:29 d1.mbr
-rwxrwxrwx  1 root          root           368 May  2 07:29 d1.minimum.partitions
-rwxrwxrwx  1 root          root           512 May  2 07:29 d1p5.ebr
-rwxrwxrwx  1 root          root          173M May  2 07:29 d1p1.img
-rwxrwxrwx  1 root          root           29G May  2 08:12 d1p2.img
-rwxrwxrwx  1 root          root           512 May  2 08:16 d1p4.ebr
-rwxrwxrwx  1 root          root            47 May  2 08:16 d1.original.swapuuids
-rwxrwxrwx  1 root          root          1.1G May  2 08:16 d1p3.img
drwxrwxrwx  2 root          root          4.0K May 13 12:29 .
-rw-rw-r--  1 administrator administrator  90M May 13 12:29 d1p1_extracted.dat
drwxrwxrwx 40 fog           root          4.0K May 13 13:32 ..

This certainly is a weird occurrence, I’ve captured and deployed a few images since then so I know nothing has been permanently botched. I know getting that fsck error usually means a corrupt file system correct?

@Tom-Elliott
Here’s the result after renaming using a “_”. We have other images using “-” and “.”, would this be best practice to avoid even if they still work fine (haven’t had this issue until now)?

Image failed to restore and exited with exit code 1 (writeImage)
   Info: 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
   Args Passed: /images/PPS_v9.0R2_dev_CentOS/d1p3.img* /dev/sda3

#                          Will continue in 1 minute                         #


 * Press [Enter] key to continue

 * Resizing extfs volume (/dev/sda3).................Failed
 * Press [Enter] key to continue

#                         An error has been detected!                        #
Could not check before resize (expandPartition)
   Info: /dev/sda3: Inode 393217 has an invalid extent
        (logical block 0, invalid physical block 1609504, len 26)


/dev/sda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
   Args Passed: /dev/sda3 :4:5

Kernel variables and settings:
loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 web=10.10.100.252/fog/ consoleblank=0 rootfstype=ext4 mac=60:45:cb:a2:86:eb ftp=10.10.100.252 storage=10.10.100.252:/images/ storageip=10.10.100.252 osid=50 irqpoll hostname=Kaibab-20 chkdsk=0 img=PPS_v9.0R2_dev_CentOS imgType=n imgPartitionType=all imgid=333 imgFormat=5 PIGZ_COMP=-19 hostearly=1 isdebug=yes type=down```

@Tom-Elliott Renamed, giving it another shot.

@Tom-Elliott Interesting catch, would just renaming and re-associating via the Web GUI work to fix this?

@Sebastian-Roth

zstdmt -d /images/Ciara_CentOS-BASEmk3/d1p1.img -o /images/Ciara_CentOS-BASEmk3/d1p1_extracted.dat
/images/Ciara_CentOS-BASEmk3/d1p1.img: 241217197 bytes

No error this time, the error I received running it manually is the same error that displays during the task as well (on the partclone progress screen).

df -h

Filesystem                      Size  Used Avail Use% Mounted on
udev                            2.9G     0  2.9G   0% /dev
tmpfs                           597M   61M  537M  11% /run
/dev/mapper/FOG--DHCP--vg-root   24G  7.7G   15G  36% /
tmpfs                           3.0G     0  3.0G   0% /dev/shm
tmpfs                           5.0M     0  5.0M   0% /run/lock
tmpfs                           3.0G     0  3.0G   0% /sys/fs/cgroup
/dev/sdb1                       1.8T  1.4T  334G  81% /images
/dev/sda1                       472M  108M  341M  24% /boot
tmpfs                           597M     0  597M   0% /run/user/1000

@Sebastian-Roth

-dev_CentOS/d1p3.img : 4201 MB...     -dev_CentOS/d1p3.img : Read error (39) : premature end

@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

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

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