@wayne-workman Thank you Wayne, the resources you provided were quite extensive.

@Sebastian-Roth So far I’ve tried a fresh Ubuntu 16.04 install, and I’ve even used LVM and just captured as non-resizable with 0 issues. Now while this wasn’t Ubuntu 18, I did notice the machine I had the issue on originally is unable to install this OS due to something being wrong with the “file system” on the disk which for some odd reason it couldn’t format, delete, or write to. It is an SSD, and I couldn’t recreate this issue on any other box. I ran various SSD diagnostics with no errors being found so I’m stumped. I haven’t gotten to try with the exact iso posted above just yet - doing production stuff lately since I’m alone in IT currently.

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

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