[Edit- Although there might be some info in this post that may, or may not, be of use, the post is all over the place. I wasn't thinking clearly. It might be best to skip this post and avoid some suffering.]
Hi. I don't want to sound like Chicken Little, but it seems best to mention that there may be boot and partition access issues in some situations, or for some users, with the upcoming (?) e2fsprogs (?), with respect to ext4 filesystems.
As you can tell by the uncertainty, and the question marks, I don't really know what I am writing about. Further, although a rough scan of posts was done, a search was not undertaken, so I don't know if I am trying to post about something that is old news and already well discussed ( if so, I apologise).
However, it seems best to mention it, so users who might be affected can be prepared.
What does this post stem from? You may be aware that Fatdog64-814 and 900Alpha have recently been released. The ext4 filesystems created using the GParted provided in these releases will have the metadata_csum and metadata_csum_seed attributes (together with others, of course). Naturally, these changes will not be limited to just Fatdog64. They are, or will be, increasingly more wide spread. I don't know if this might already be the case with some Pups, Dogs, KLVs, etc..
Where kernel support is not available, the new ext4 filesystems will not be able to be mounted. Which is good for data protection, of course. This could, however, impact things for example, if a new partition were to be created, with a new ext4 filesystem, that was intended to be used as a shared data, or boot partition.
Kernel support for these attributes has been in place for a long time. However, this is a Puppy forum, and a long time has a different meaning here, or so I think 
.
To give a very rough idea of the bounds, a test was undertaken using an ext4 partition that was created using the default GParted in FD900alpha, and a "multiboot" USB drive based on one of the USB-Boot images in the Fatdog64 ISO.
The partition could be mounted by Slacko32-7.0, Slacko64-7.0, BionicPup32-8.0, BionicPup64-8.0 and, of course, later Pups.
Slacko32-6.9.9.9 could not mount the partition.
It follows that Slacko64-6.3.2 and Tahr32-605CE also could not, they were too early.
I apologise for being so long winded, but there might also be considerations with respect to using older bootloaders to boot Pups etc. on the new ext4 filesystems. For example, an attempt to boot FD900Alpha on a new ext4 partition using MX21.3 failed. Although the kernel in MX 21.3 supported the attributes, Grub2 could not boot it whilst the metadata_csum_seed was present. When this result was posted Jamesbond suggested that this was likely to affect the bootloaders in FD813 as well, and that those in Fatdog64-814 had been updated to accommodate this. I would imagine that the same has happened, or would also be happening, in the wider spheres of the Pups, Dogs, KLV etc..
If, like myself, you are sometimes using larger distros as your "boot lead", so to speak, then it could be helpful to check and plan, maybe. I guess I should also mention here that the Grub2 Os-Prober is also, apparently, being disabled. It already is in Debian 12.0.0. [EDIT-or so I had thought].
Ext3, f2fs etc. filesystems are, of course, not affected by this.
It is not the end of the world. I guess if you are not mixing things you may not even be affected by it. However, it seems best to have warning so that you can plan if you need to.
Apologies for yet another waffling tome. Doubly so if I have just been wasting your time. Thanks.
[Edited to correct a misinterpretation that I had, amongst many]
