The e2fsprogs contains a version 1.0.0 of `blkid`. This version does not support flags that the current kernel install scripts pass to `blkid`. By building and installing e2fsprogs I ended up replacing blkid 2.30.2 with 1.0.0, which broke kernel packaging. This is easily fixed by doing `yum reinstall util-linux`, which reinstalls the correct version blkid.
This mess could be avoided if e2fsprogs either included a more modern version of blkid, or perhaps did not include blkid at all, since a more current version of this utility is maintained and installed through other packages.
(Finding https://forums.centos.org/viewtopic.php?t=69655 helped a lot in figuring out why my kernel build started failing all of a sudden)
On Tue, Apr 05, 2022 at 11:15:22PM +0000, Kiselev, Oleg wrote:
> The e2fsprogs contains a version 1.0.0 of `blkid`. This version
> does not support flags that the current kernel install scripts pass
> to `blkid`. By building and installing e2fsprogs I ended up
> replacing blkid 2.30.2 with 1.0.0, which broke kernel packaging.
> This is easily fixed by doing `yum reinstall util-linux`, which
> reinstalls the correct version blkid.
>
> This mess could be avoided if e2fsprogs either included a more
> modern version of blkid, or perhaps did not include blkid at all,
> since a more current version of this utility is maintained and
> installed through other packages.
>
> (Finding https://forums.centos.org/viewtopic.php?t=69655 helped a lot in figuring out why my kernel build started failing all of a sudden)
The blkid and uuid libraries were moved from e2fsprogs from util-linux
on most Linux distributions. However, these libraries are still
needed to compile e2fsprogs, and they are needed for non-Linux
operating systems, including FreeBSD, Illumos, etc., and some Linux
systems, such as Android. That's why they haven't been removed.
If you install the RHEL/Fedora packages libblkid-devel and
libuuid-devel before you run run e2fsprogs's configure script, then it
will use the system versions of libblkid and libuuid, which will do
the right thing.
(For Debian / Ubuntu the packages names are libblkid-dev and uuid-dev,
but for these distributions it's better to just run
"dpkg-buildpackage" since that will automatically build the Debian
packages with all of the correct configure options via the
debian/rules file, and the Build-Depends: declaration in
debian/control will automatically enforce that you have all of the
correct build prerequites installed.)
If you hand done the simple thing that most novice users do, which is
to just run "./configure ; make", then the binaries will statically
link the old versions of blkid and uuid and that will work as well.
You just ran into the case where (a) you knew enough to enable ELF
share libraries, but (b) didn't know enough to install the system
libraries instead, and (c) then did a "make install" instead of using
a package manager to mediate installation of the programs.
I'm sorry that happened to you, but it's a relatively rare
combination, and the fact remains that there are other users of
e2fsprogs besides Linux, and unfortunately, many open source packages,
including util-linux and systemd, suffer from the "All The World Runs
Linux" disease, which seems to be an updated form of the disease, "All
the World's a Vax"[1]. (This is also why it would take more work than
it's worth to try to backport newer versions of blkid into e2fsprogs.)
Cheers,
- Ted
[1] From: https://www.lysator.liu.se/c/ten-commandments.html
Commandment #10:
Thou shalt foreswear, renounce, and abjure the vile heresy which
claimeth that ``All the world's a VAX'', and have no commerce with
the benighted heathens who cling to this barbarous belief, that
the days of thy program may be long even though the days of thy
current machine be short.
This particular heresy bids fair to be replaced by ``All the
world's a Sun'' or ``All the world's a 386'' (this latter being a
particularly revolting invention of Satan), but the words apply to
all such without limitation. Beware, in particular, of the subtle
and terrible ``All the world's a 32-bit machine'', which is almost
true today but shall cease to be so before thy resume grows too
much longer.
Got it. There was no mention of installing libblkid-devel and libuuid-devel in the INSTALL file. Now that I know what to look for, the ./configure actions with blkid make sense.
On 4/6/22, 5:49 AM, "Theodore Ts'o" <[email protected]> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
On Tue, Apr 05, 2022 at 11:15:22PM +0000, Kiselev, Oleg wrote:
> The e2fsprogs contains a version 1.0.0 of `blkid`. This version
> does not support flags that the current kernel install scripts pass
> to `blkid`. By building and installing e2fsprogs I ended up
> replacing blkid 2.30.2 with 1.0.0, which broke kernel packaging.
> This is easily fixed by doing `yum reinstall util-linux`, which
> reinstalls the correct version blkid.
>
> This mess could be avoided if e2fsprogs either included a more
> modern version of blkid, or perhaps did not include blkid at all,
> since a more current version of this utility is maintained and
> installed through other packages.
>
> (Finding https://forums.centos.org/viewtopic.php?t=69655 helped a lot in figuring out why my kernel build started failing all of a sudden)
The blkid and uuid libraries were moved from e2fsprogs from util-linux
on most Linux distributions. However, these libraries are still
needed to compile e2fsprogs, and they are needed for non-Linux
operating systems, including FreeBSD, Illumos, etc., and some Linux
systems, such as Android. That's why they haven't been removed.
If you install the RHEL/Fedora packages libblkid-devel and
libuuid-devel before you run run e2fsprogs's configure script, then it
will use the system versions of libblkid and libuuid, which will do
the right thing.
(For Debian / Ubuntu the packages names are libblkid-dev and uuid-dev,
but for these distributions it's better to just run
"dpkg-buildpackage" since that will automatically build the Debian
packages with all of the correct configure options via the
debian/rules file, and the Build-Depends: declaration in
debian/control will automatically enforce that you have all of the
correct build prerequites installed.)
If you hand done the simple thing that most novice users do, which is
to just run "./configure ; make", then the binaries will statically
link the old versions of blkid and uuid and that will work as well.
You just ran into the case where (a) you knew enough to enable ELF
share libraries, but (b) didn't know enough to install the system
libraries instead, and (c) then did a "make install" instead of using
a package manager to mediate installation of the programs.
I'm sorry that happened to you, but it's a relatively rare
combination, and the fact remains that there are other users of
e2fsprogs besides Linux, and unfortunately, many open source packages,
including util-linux and systemd, suffer from the "All The World Runs
Linux" disease, which seems to be an updated form of the disease, "All
the World's a Vax"[1]. (This is also why it would take more work than
it's worth to try to backport newer versions of blkid into e2fsprogs.)
Cheers,
- Ted
[1] From: https://www.lysator.liu.se/c/ten-commandments.html
Commandment #10:
Thou shalt foreswear, renounce, and abjure the vile heresy which
claimeth that ``All the world's a VAX'', and have no commerce with
the benighted heathens who cling to this barbarous belief, that
the days of thy program may be long even though the days of thy
current machine be short.
This particular heresy bids fair to be replaced by ``All the
world's a Sun'' or ``All the world's a 386'' (this latter being a
particularly revolting invention of Satan), but the words apply to
all such without limitation. Beware, in particular, of the subtle
and terrible ``All the world's a 32-bit machine'', which is almost
true today but shall cease to be so before thy resume grows too
much longer.