Posts made by Quazz

@scosta You can rearrange partitions. I would use something like macrium reflect to create a clone to an identical disk where I manually arrange the partitions, you can then use that disk for capture in FOG, once that is done, you can deploy it to the original disk and see if everything works.

There’s probably other ways or even faster ways, but messing with partition tables can be scary.

@shruggy Indeed, I didn’t catch that last time. Because we use square brackets now it needs to start the quote earlier. (though really it should always do that for clarity)

@Sebastian-Roth Thankfully, Mariadb has a list of possible issues: https://mariadb.com/kb/en/converting-tables-from-myisam-to-innodb/

We’d need to set some baseline settings in the mysql config, imo.

@banana123 I agree with George.

The type matches a normal Windows first partition, but it appears to have been heavily modified afterwards to be “recovery”.

And it seems your second partition is now getting resized for whatever reason…

If you don’t need the recovery partition it seems best to just start over.

@banana123 Looks like your first partition is incorrectly identified as being resizable, which is likely at the root of your problems.

Though, it looks like that partition has been altered in some way.

Currently, FOS uses partition flags to attempt to identify “non-resizable” partitions.

As far as I can tell, your first partition is missing essential flags (namely System and Active), causing FOS to misidentify the partition as a normal NTFS data partition that should be resized.

@Sebastian-Roth He’ll need newer inits that include the NVME package since it wasn’t included in the 1.5.7 package iirc.

@ProfDrSir Ideally you’d use both! Sysprep does more than what the cleaning tool can do.

We often see images failing to capture after installing certain updates. Though typically these are version point upgrades.

Do you use sysprep for your images?

Sometimes it can be resolved by cleaning up the system and such.

(eg dism /online /cleanup-image /startcomponentcleanup)

Is this a legacy Windows 10 install that has been converted? The partition layout is not standard.

@ty900000 That build does not yet include the partclone fixes, though. But we are getting close to that.

@explosivo98 Latest dev build is available here: https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/master/115/artifacts

I don’t believe we have actively tried to hunt this particular bug down, but changes have been made to kernel configs and inits, so worth a shot! (so get both the bzImage and init.xz)

Only use these for testing those devices for now. Still some bugs to kill, but you should be able to see if you can deploy at least.

@Middle That’s really unfortunate. We were hoping that would be sufficient for all usecases, but unfortunately it seems that in some cases that’s not true.

We also can’t disable it globally since that would hinder performance for a lot of users that don’t have this issue…

You can try setting the command in postinit scripts. (/images/dev/postinitscripts/fog.postinit)

The command should execute after the init has loaded and before FOG starts its magic.

@Middle Can you try the KERNEL ARGS George suggested?

nvme_core.default_ps_max_latency_us=0

@shruggy said in Development FOG not capturing image - PartClone update:

@Tom-Elliott said in Development FOG not capturing image - PartClone update:

I pushed another fix and believe the issue was as @Quazz noted is the -c argument was missing. Strange as that is, as the -c argument doesn’t appear to be a part of the spec list (unless somebody already added that to the patch for partclone and I didn’t know it?)

My understanding of it is this:

• images captured with partclone.imager -c need to be restored with partclone.restore, raw images captured with partclone.dd or with partclone.imager without -c need to be restored with partclone.dd
• the options for partclone.imager are basically the same as for any partclone.$ftype (including -c and -a), it’s partclone.dd that is a special case. The symbol DD only pertains to partclone.dd, the symbol IMG is specifically defined in Makefile for partclone.imager, but never gets used in upstream Partclone code.

Adding on to this, partclone.imager is generated using partclone.dd source files.

As per the makefile: https://github.com/Thomas-Tsai/partclone/blob/master/src/Makefile.am#L56

Making this commit: https://github.com/Thomas-Tsai/partclone/commit/2d1ee7c94139f390453ea8cb8675f67173bde33b problematic.

The special code for RAW is then locked to partclone.dd while partclone.imager is stuck using the “normal” code, which doesn’t work properly for its scenario.

Restoring the old code for partclone.imager should work. (there is no option to change the if condition main.c since there is no opt for imager…)

The stuff in https://forums.fogproject.org/topic/14078/1-5-7-89-partclone-doesn-t-capture-an-image-in-dd-mode-wrong-options-in-fog-upload/17 should work.

We just need to create a patch for it imo.

@Tom-Elliott I am fairly confident the -a0 is a bug, since it is listed in its options, but isn’t picked up for use.

-c was removed for dd (it’s implied I guess??)

Interesting you should mention it not occuring in debug. I have seen this problem before, but that was on… unreliable devices so didn’t think much of it when I couldn’t replicate it on other devices.

@Tom-Elliott I think it’s more likely to be caused by partclone.imager being broken in current 0.3.12

Note how the detected size of the partition is 0 by partclone.

@Sebastian-Roth @pete Tested a host with debug tasking. With the -A ""
argument it works fine, without it Cannot view from browser

I believe you have to modify the client OS to support being booted over iSCSI, though I have limited experience with it.

I could be wrong, but I think by default iSCSI isn’t included in the initramfs of Ubuntu.

Perhaps this https://apfelboymchen.net/gnu/notes/booting ubuntu iscsi.html could be helpful. (at least the client info)

All that said, NFS boot is likely to be a lot more straightforward to implement and I use that method quite often.

@Sebastian-Roth https://github.com/jkuchar/BigFileTools possibly.

@cmachado The integer is overflowing on the node because 32bit has a 2GB limit for integers, but the filesizes exceed that number.

If you get a 64 bit node your problems will disappear I reckon.