[Buildroot] [PATCH] package/e2fsprogs: fix build with headers >= 5.10 and < 5.12

[Buildroot] [PATCH] package/e2fsprogs: fix build with headers >= 5.10 and < 5.12

[Thomas Petazzoni via buildroot]

The bump of e2fsprogs to 1.47.3 in Buildroot commit
bb004ddba26ea86687d917fa16d313ea92aff41c causes the package to fail
building when the kernel headers are >= 5.10 but < 5.12.

Indeed the new version of e2fsprogs detects the presence of
<linux/fsverity.h> (which occurred in 5.10), and when it's available,
enables some fsverity functionality, which uses an ioctl() that was
only introduced in 5.12. This causes some build breakage if the
headers used are 5.10 or 5.11.

We fix this by introducing a patch, submitted upstream, that not only
verifies the availability of the header file, but also the
availability of the ioctl().

Fixes:

  https://autobuild.buildroot.net/results/c573233b1f871c61f916eda9c402c84070902432/ (host-e2fsprogs)
  https://autobuild.buildroot.net/results/0ed16cad1d1f500d0e577d03166c06381be73ffc/ (e2fsprogs)

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 ...ck-for-FS_IOC_READ_VERITY_METADATA-a.patch | 103 ++++++++++++++++++
 package/e2fsprogs/e2fsprogs.mk                |   7 ++
 2 files changed, 110 insertions(+)
 create mode 100644 package/e2fsprogs/0001-configure.ac-check-for-FS_IOC_READ_VERITY_METADATA-a.patch

diff --git a/package/e2fsprogs/0001-configure.ac-check-for-FS_IOC_READ_VERITY_METADATA-a.patch b/package/e2fsprogs/0001-configure.ac-check-for-FS_IOC_READ_VERITY_METADATA-a.patch
new file mode 100644
index 0000000000..36442a53b8
--- /dev/null
+++ b/package/e2fsprogs/0001-configure.ac-check-for-FS_IOC_READ_VERITY_METADATA-a.patch
@@ -0,0 +1,103 @@
+From 1a2ce8cd956065106ae27a36a5000f00ebc4591f Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+Date: Sat, 22 Nov 2025 21:12:23 +0100
+Subject: [PATCH] configure.ac: check for FS_IOC_READ_VERITY_METADATA
+ availability
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Commit 6bfa843b4435334ac073e42950b48d8bacb54977 ("mke2fs: enable
+copying of fs-verity metadata") introduced support for reading
+fs-verity metadata, which requires using the
+FS_IOC_READ_VERITY_METADATA.
+
+The code is conditionally compiled when the kernel headers have
+<linux/fsverity.h> available. Unfortunately, this check is not
+sufficient: <linux/fsverity.h> was introduced in Linux 5.10, but the
+FS_IOC_READ_VERITY_METADATA was not introduced before 5.12, so if one
+is using 5.10 or 5.11 kernel headers, the build fails with:
+
+./../misc/create_inode.c: In function ‘copy_fs_verity_data’:
+./../misc/create_inode.c:589:10: error: variable ‘arg’ has initializer but incomplete type
+  589 |   struct fsverity_read_metadata_arg arg = {
+      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~
+[...]
+./../misc/create_inode.c:600:20: error: ‘FS_IOC_READ_VERITY_METADATA’ undeclared (first use in this function)
+  600 |   size = ioctl(fd, FS_IOC_READ_VERITY_METADATA, &arg);
+      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This commit therefore extends the configure.ac check to ensure that
+not only <linux/fsverity.h> exists but also that it defines the
+FS_IOC_READ_VERITY_METADATA ioctl.
+
+Upstream: https://github.com/tytso/e2fsprogs/pull/256
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+---
+ configure.ac        | 18 ++++++++++++++++++
+ misc/create_inode.c |  6 +++---
+ 2 files changed, 21 insertions(+), 3 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index a0171163..3e5586a3 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -1997,6 +1997,24 @@ OS_IO_FILE=""
+ esac]
+ AC_SUBST(OS_IO_FILE)
+ 
++dnl Check for fsverity ioctl
++if test "${ac_cv_header_linux_fsverity_h}" = "yes"; then
++   AC_MSG_CHECKING([for FS_IOC_READ_VERITY_METADATA ioctl])
++   AC_PREPROC_IFELSE(
++   [AC_LANG_PROGRAM([[
++#include <linux/fsverity.h>
++#ifndef FS_IOC_READ_VERITY_METADATA
++# error "FS_IOC_READ_VERITY_METADATA not available"
++#endif
++]], [])], [
++   AC_DEFINE([HAVE_FS_IOC_READ_VERITY_METADATA], [1], [Define to 1 if FS_IOC_READ_VERITY_METADATA ioctl is available])
++   AC_MSG_RESULT([yes])
++   ],
++   [
++   AC_MSG_RESULT([no])
++   ])
++fi
++
+ dnl
+ dnl Make our output files, being sure that we create the some miscellaneous 
+ dnl directories
+diff --git a/misc/create_inode.c b/misc/create_inode.c
+index 624efc03..a7918873 100644
+--- a/misc/create_inode.c
++++ b/misc/create_inode.c
+@@ -30,7 +30,7 @@
+ #ifdef HAVE_SYS_SYSMACROS_H
+ #include <sys/sysmacros.h>
+ #endif
+-#ifdef HAVE_LINUX_FSVERITY_H
++#if defined(HAVE_LINUX_FSVERITY_H) && defined(HAVE_FS_IOC_READ_VERITY_METADATA)
+ #include <linux/fsverity.h>
+ #include <linux/fs.h>
+ #endif
+@@ -569,7 +569,7 @@ out:
+ }
+ #endif /* FS_IOC_FIEMAP */
+ 
+-#ifdef HAVE_LINUX_FSVERITY_H
++#if defined(HAVE_LINUX_FSVERITY_H) && defined(HAVE_FS_IOC_READ_VERITY_METADATA)
+ static inline off_t round_up(off_t n, off_t blksz, off_t bias)
+ {
+   return ((n - bias + (blksz - 1)) & ~(blksz - 1)) + bias;
+@@ -738,7 +738,7 @@ static errcode_t copy_file(ext2_filsys fs, int fd, struct stat *statbuf,
+ 		err = copy_file_chunk(fs, fd, e2_file, 0, statbuf->st_size, buf,
+ 				      zerobuf);
+ 
+-#ifdef HAVE_LINUX_FSVERITY_H
++#if defined(HAVE_LINUX_FSVERITY_H) && defined(HAVE_FS_IOC_READ_VERITY_METADATA)
+ 	if (!err && (flags & EXT4_VERITY_FL))
+ 		err = copy_fs_verity(fs, fd, e2_file, statbuf->st_size);
+ #endif
+-- 
+2.51.1
+
diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk
index 27e5e37bca..ad3d1dbe75 100644
--- a/package/e2fsprogs/e2fsprogs.mk
+++ b/package/e2fsprogs/e2fsprogs.mk
@@ -18,6 +18,13 @@ E2FSPROGS_INSTALL_STAGING = YES
 E2FSPROGS_DEPENDENCIES = host-pkgconf util-linux
 HOST_E2FSPROGS_DEPENDENCIES = host-pkgconf host-util-linux
 
+# 0001-configure.ac-check-for-FS_IOC_READ_VERITY_METADATA-a.patch
+# the additional dependencies are only needed for autoreconf
+E2FSPROGS_AUTORECONF = YES
+E2FSPROGS_AUTORECONF_OPTS = --include=$(HOST_DIR)/share/autoconf-archive
+E2FSPROGS_DEPENDENCIES += host-gettext host-autoconf-archive
+HOST_E2FSPROGS_DEPENDENCIES += host-gettext host-autoconf-archive
+
 E2FSPROGS_SELINUX_MODULES = fstools
 
 # e4defrag doesn't build on older systems like RHEL5.x, and we don't
-- 
2.51.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/e2fsprogs: fix build with headers >= 5.10 and < 5.12

[Julien Olivain via buildroot]

On 23/11/2025 14:34, Thomas Petazzoni via buildroot wrote:
> The bump of e2fsprogs to 1.47.3 in Buildroot commit
> bb004ddba26ea86687d917fa16d313ea92aff41c causes the package to fail
> building when the kernel headers are >= 5.10 but < 5.12.
> 
> Indeed the new version of e2fsprogs detects the presence of
> <linux/fsverity.h> (which occurred in 5.10), and when it's available,
> enables some fsverity functionality, which uses an ioctl() that was
> only introduced in 5.12. This causes some build breakage if the
> headers used are 5.10 or 5.11.
> 
> We fix this by introducing a patch, submitted upstream, that not only
> verifies the availability of the header file, but also the
> availability of the ioctl().
> 
> Fixes:
> 
>   
> https://autobuild.buildroot.net/results/c573233b1f871c61f916eda9c402c84070902432/ 
> (host-e2fsprogs)
>   
> https://autobuild.buildroot.net/results/0ed16cad1d1f500d0e577d03166c06381be73ffc/ 
> (e2fsprogs)
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Applied to master, thanks.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/e2fsprogs: fix build with headers >= 5.10 and < 5.12

[Markus Mayer via buildroot]

Hi all,

I submitted a different patch for this to Ted T'so a week ago, on
November 21, to be exact. Unfortunately, there doesn't seem to be a
mailing list for e2fsprogs, so there is no way of quoting said email.
Unfortunately, I haven't heard back from Ted as of yet.

I think the easiest way of showing my patch set here at this point in
time is by providing a Github link.

https://github.com/tytso/e2fsprogs/compare/master...mmayer:e2fsprogs:kern-compat-master

This page should show the entirety of the diff, combining the two
commits in that tree (manual changes and derived autoconf changes).
The important changes are in the first commit (configure.ac and
kern_compat.h)[1].

The big difference between your patch and my patch is that my patch
doesn't disable functionality when the build environment is too old.
Instead, it provides the missing definitions of the data structures,
so the binaries can still be built with full functionality compiled
in. So, while your patch strips functionality out of e2fsprogs based
on the build environment, mine does not.

This makes a big difference, because "old" kernel headers at build
time don't necessarily equate to an "old" kernel at runtime. Here is
why. Our toolchain ships with a sys-root that contains the C runtime,
glibc and kernel headers. The toolchain is an external, pre-built
toolchain. For compatibility reasons, kernel headers in the toolchain
are from Linux 5.4. However, that toolchain is then used to build
entire root file systems (including the kernel) for 5.4, 5.15, 6.1 and
6.12. Just to stress this one more time, this means an entire
Buildroot build, including the kernel, is conducted with this
toolchain, but while using different kernel versions. We aren't doing
any funky business like copying binary files around and sharing them
between releases. It all gets built together as one would expect, and
users generally won't even notice the kernel headers in the sys-root
are from Linux 5.4, and they shouldn't have to care.

It is easy to see how stripping out functionality based on build time
headers will become an issue in this setting. Sure, with the 5.4-based
rootfs, the added functionality will not actually work at runtime
(ioctl not supported by the kernel), but in the other three
environments, it'll work perfectly (due to the data structure
definitions provided), despite having been built against 5.4 kernel
headers.

I held off submitting this to buildroot right away, because I was
hoping this would be accepted upstream quickly enough to not have to
clutter buildroot with patch commits. However, it being a week later,
I was about to submit my patches for inclusion into Buildroot, since
Ted hasn't responded and it is Thanksgiving in the US, which means
more delays.

However, then I noticed there was already a patch present in
Buildroot. So, I am reaching out first before submitting the series
for inclusion as it would conflict with the solution that is currently
present.

Please let me know what you think.

Regards,
-Markus

[1] https://github.com/tytso/e2fsprogs/commit/bbe1c7fb5abf7c41894616e5885ad78446dd5f3b






On Sun, 23 Nov 2025 at 06:16, Julien Olivain via buildroot
<buildroot@buildroot.org> wrote:
>
> On 23/11/2025 14:34, Thomas Petazzoni via buildroot wrote:
> > The bump of e2fsprogs to 1.47.3 in Buildroot commit
> > bb004ddba26ea86687d917fa16d313ea92aff41c causes the package to fail
> > building when the kernel headers are >= 5.10 but < 5.12.
> >
> > Indeed the new version of e2fsprogs detects the presence of
> > <linux/fsverity.h> (which occurred in 5.10), and when it's available,
> > enables some fsverity functionality, which uses an ioctl() that was
> > only introduced in 5.12. This causes some build breakage if the
> > headers used are 5.10 or 5.11.
> >
> > We fix this by introducing a patch, submitted upstream, that not only
> > verifies the availability of the header file, but also the
> > availability of the ioctl().
> >
> > Fixes:
> >
> >
> > https://autobuild.buildroot.net/results/c573233b1f871c61f916eda9c402c84070902432/
> > (host-e2fsprogs)
> >
> > https://autobuild.buildroot.net/results/0ed16cad1d1f500d0e577d03166c06381be73ffc/
> > (e2fsprogs)
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>
> Applied to master, thanks.
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/e2fsprogs: fix build with headers >= 5.10 and < 5.12

[Thomas Petazzoni via buildroot]

Hello Markus,

On Thu, 27 Nov 2025 11:53:36 -0800
Markus Mayer <mmayer@broadcom.com> wrote:

> I submitted a different patch for this to Ted T'so a week ago, on
> November 21, to be exact. Unfortunately, there doesn't seem to be a
> mailing list for e2fsprogs, so there is no way of quoting said email.
> Unfortunately, I haven't heard back from Ted as of yet.
> 
> I think the easiest way of showing my patch set here at this point in
> time is by providing a Github link.
> 
> https://github.com/tytso/e2fsprogs/compare/master...mmayer:e2fsprogs:kern-compat-master
> 
> This page should show the entirety of the diff, combining the two
> commits in that tree (manual changes and derived autoconf changes).
> The important changes are in the first commit (configure.ac and
> kern_compat.h)[1].
> 
> The big difference between your patch and my patch is that my patch
> doesn't disable functionality when the build environment is too old.
> Instead, it provides the missing definitions of the data structures,
> so the binaries can still be built with full functionality compiled
> in. So, while your patch strips functionality out of e2fsprogs based
> on the build environment, mine does not.

I don't really have a strong preference between the two solutions.

In your solution, what happens if the kernel is actually too old to
support the fsverity ioctl() ? Does e2fsprogs gracefully handles the
situation? That's a bit the problem with building code with "newer"
kernel headers than the running kernel: how is user-space going to be
have when the kernel features exposed in the kernel headers are
actually not implemented by the kernel.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/e2fsprogs: fix build with headers >= 5.10 and < 5.12

[Markus Mayer via buildroot]

Hi Thomas,

Thanks for checking out this patch series.

On Fri, 28 Nov 2025 at 01:21, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Markus,
>
> On Thu, 27 Nov 2025 11:53:36 -0800
> Markus Mayer <mmayer@broadcom.com> wrote:
>
> > I submitted a different patch for this to Ted T'so a week ago, on
> > November 21, to be exact. Unfortunately, there doesn't seem to be a
> > mailing list for e2fsprogs, so there is no way of quoting said email.
> > Unfortunately, I haven't heard back from Ted as of yet.
> >
> > I think the easiest way of showing my patch set here at this point in
> > time is by providing a Github link.
> >
> > https://github.com/tytso/e2fsprogs/compare/master...mmayer:e2fsprogs:kern-compat-master
> >
> > This page should show the entirety of the diff, combining the two
> > commits in that tree (manual changes and derived autoconf changes).
> > The important changes are in the first commit (configure.ac and
> > kern_compat.h)[1].
> >
> > The big difference between your patch and my patch is that my patch
> > doesn't disable functionality when the build environment is too old.
> > Instead, it provides the missing definitions of the data structures,
> > so the binaries can still be built with full functionality compiled
> > in. So, while your patch strips functionality out of e2fsprogs based
> > on the build environment, mine does not.
>
> I don't really have a strong preference between the two solutions.
>
> In your solution, what happens if the kernel is actually too old to
> support the fsverity ioctl() ? Does e2fsprogs gracefully handles the
> situation? That's a bit the problem with building code with "newer"
> kernel headers than the running kernel: how is user-space going to be
> have when the kernel features exposed in the kernel headers are
> actually not implemented by the kernel.

According to [1] and [2], e2fsprogs does the right thing and will
propagate the "not supported" error. I'll see if I can set up a test
case that will trigger this function call, so I can verify the actual
behaviour.

Regards,
-Markus

[1] https://github.com/tytso/e2fsprogs/blob/master/misc/create_inode.c#L599https://github.com/tytso/e2fsprogs/blob/master/misc/create_inode.c#L599
[2] https://github.com/tytso/e2fsprogs/blob/master/misc/create_inode.c#L599https://github.com/tytso/e2fsprogs/blob/master/misc/create_inode.c#L669

> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/e2fsprogs: fix build with headers >= 5.10 and < 5.12

[Thomas Petazzoni via buildroot]

On Fri, 28 Nov 2025 13:16:24 -0800
Markus Mayer <mmayer@broadcom.com> wrote:

> According to [1] and [2], e2fsprogs does the right thing and will
> propagate the "not supported" error. I'll see if I can set up a test
> case that will trigger this function call, so I can verify the actual
> behaviour.

Sounds good to me, you don't need to do a formal test to verify the
actual behavior.

How do we proceed? You send a follow-up patch that improves mine? I've
anyway had no feedback from upstream.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/e2fsprogs: fix build with headers >= 5.10 and < 5.12

[Markus Mayer via buildroot]

On Sat, 29 Nov 2025 at 13:17, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Fri, 28 Nov 2025 13:16:24 -0800
> Markus Mayer <mmayer@broadcom.com> wrote:
>
> > According to [1] and [2], e2fsprogs does the right thing and will
> > propagate the "not supported" error. I'll see if I can set up a test
> > case that will trigger this function call, so I can verify the actual
> > behaviour.
>
> Sounds good to me, you don't need to do a formal test to verify the
> actual behavior.
>
> How do we proceed? You send a follow-up patch that improves mine? I've
> anyway had no feedback from upstream.

Yes, that sounds like the best plan. I'll concoct something that
builds on top of your patch. I haven't had any feedback yet on my
series from Ted, either.

Regards,
-Markus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot