Add support for FSCK before Image Creation / Image Management(web UI)

[alv000h]

Hi all,

I was using Clonezilla/DRBL for some time and it have an option very interesting for FS imaging.
They call it fsck-src-part-y, basically it FSCK the FS before image creation.
(src: http://drbl.org/faq/fine-print.php?path=./2_System/108_bitmap_free_count_err.faq )

NOTE Adding a Warning for this option will be nice, something like this: FSCK FS from non-native OS may CAUSE DATA CORRUPTION!!!

UNIX / FAT FS may be something like:
fsck -f -y /dev/sda1

NTFS FS may be something like:
ntfsfix /dev/sda1

Maybe could be good idea add clear dirty flag (Dangerous!):
ntfsfix -d /dev/sda1

This is interesting because sometimes you have to image a far far away server that not umount FS cleanly or there is a version difference between Kernel/FS utilities from SO (older) and FOG (newer)

For example in ext3 is typical to have this partclone error when FS was not cleanly umounted:

 calculating bitmap..please wait..extfsclone.c:bitmap free count err, free:25457320 ?

The solution is reboot and FSCKd affected FS, then reboot and PXE boot again.

Imagine you have to do this for 10 or 100 PC with this issue…

I propose add this option in Image Management or in Create Capture task,.

Why in Create Capture task? Figure you try to Image capture a server and it fails, after that, you can create another capture task with auto FSCK option active and send it only to affected servers without change image definition…

[Quazz]

Making sure the file system is in a correct state is not really the responsibility of FOG. Invariably this will cause issues if implemented because of the myriad of use case scenarios.

[Tom Elliott]

To add on, however, we already check the filesystem during imaging.

[alv000h]

Hi all,

Thank you @Tom-Elliott

@Quazz
IMHO, This option is not intended for default use case.

This sholud be optional and maybe discouraged/Expert feature (Maybe showing a warning about posible issues, data loss or image corruption…)

Typical Scenario:
In the past if you fsck ext2 or ext3 with different kernel or fsprogs versions, this tends to fix existent issues in older versions but inexistent in new ones or viceversa. (call it bug, call it new feature)

Real Case scenario: https://bugzilla.redhat.com/show_bug.cgi?id=491385

This FR is intended to make life easier, because yesterday I shutdown a older linux (it shutdown Ok) for capturing Image with Fog and I had had to reboot it in rescue mode and fsck / FS because of partclone: “extfsclone.c:bitmap free count err” error.

If fog could this for us, and it have a relative recent kernel and e2fsprogs version(the newer, the better…), whats the problem?

I always can automatize fsck all FS outside fog, but i thought this could be a feature useful to share with others…

[Wayne Workman]

@alv000h I think the feature would cause more problems than it would solve. People would post here complaining that fog broke their golden/reference machine. FOG should make as little changes as possible to the golden/reference machine. Partitions get resized because the operation is very safe and has tremendous benefits - but clearing a dirty flag is a different story - it has very few benefits and a lot of risk. In my opinion, if you are skilled enough to do it already outside of fog, it’s probably best (for fogproject & community) if you keep doing it that way.

[Tom Elliott]

Mind you all, now with the postinitscripts feature, you could code this your self in its entirety. Any init related feature requests can now be done by the average admin/user as they see fit.

Should they like to see the feature for “everybody” post the script and description of what it’s doing and why you feel it’s useful.

FOG takes a few liberties in regards to guess work, but we cannot account for EVERY possibility. This, I think, is where the FOG Community could/should thrive.

[Tom Elliott]

@alv000h We do perform filesystem checks, but only before resize operations occur. (Or after if expanding back)

They are located in the inits: (/usr/share/fog/lib/funcs.sh)
expandPartition lines 212 and 232
shrinkPartition lines 539 and 584
Partclone also uses this to ensure all is capturing the image:
savePartition line 2004

If you had to stop the imaging process for whatever reason, it’s not going to run the checks because you caused it to do something to begin with.

[Wayne Workman]

@Tom-Elliott said in Add support for FSCK before Image Creation / Image Management(web UI):

Should they like to see the feature for “everybody” post the script and description of what it’s doing and why you feel it’s useful.

This is what fog-community-scripts is for.