- Update to linux-7.0.7 (Security Update)
- Update to tcl-8.6.18
- Update to expat-2.8.1 (Security Update)
- Update to vim-9.2.0481 (Security Update)
- Fix CVE-2026-7210 and CVE-2026-8328 in Python
- Update chapter01/whatsnew.xml with a current list of added patches
Updating a couple of days before the normal mid-month commit.
This is to establish the initial baseline for fixing numerous
packages in BLFS that will need to updated for linux-7 and
openssl-4.
Update to vim-9.2.0461 (Security Update).
Update to sqlite-3.53.2.
Update to Python-3.14.5.
Update to openssl-4.0.0.
Update to linux-7.0.5.
Update to iana-etc-20260604.
Add Python-3.14.5 linux7 build patch.
Add glibc linux7 fixes patch (Security Fix).
Add systemd openssl4 build patch.
The original warning is inaccurate/misleading in many aspects.
The critical thing is GCC version. There's nothing to do with the
OpenSSL version (as nothing in ch5 or 6 ever uses OpenSSL). There's
also nothing to do with the kernel "major" version as the "major"
version is just an arbitary choice to make the minor version not greater
than 19 by Linus. It does not imply any aspect of the ABI, unlike the
"major" version in a SONAME or something. The inablility to build Glibc
with Linux 7.0 API headers is simply a coincidence. If another API
header change happens in Linux 7.6, it may break Glibc build as well.
And I cannot see how the Linux API header version of the host distro can
ever affect LFS. LFS builds ch05 Glibc with its own Linux API header
installed just before Glibc, not the installation from the host distro.
So Glibc should just build fine with the 6.19 API header just installed
into $LFS/usr/include. I know it would fail to build with Linux 7.0 API
headers but why it can ever find one - if it really finds the host
distro's API header instead of the one in $LFS/usr/include we have a
serious bug and it will have to be fixed instead of papered over by
limiting the host distro.
I also know the req test will fail if the host distro has Linux 7.0 but
I've no idea if the test failure is really related to the "massive
breakage of rseq" (I assume it refers to the jemalloc breakage? But
AFAIK nothing in LFS uses jemalloc). And the glibc upstream has just
fixed the test file simply. We always treat test-file-only fixes as
"known failures" instead of "bugs requiring a fix" unless it aborts the
entire test suite too early. Add a note in the glibc page to note there
can be additional failures with Linux >= the version we use for LFS.
And there's also nothing to do with the "rolling release." For example,
you cannot build LFS 12.0 on LFS 12.4 because ch06 bash uses the host
compiler to build some code generators, and those generators are not
compatible with C23 (the default of GCC 15.2 shipped by LFS 12.4). LFS
12.4 is definitely not a rolling release...
A rolling release just catches the breakage earlier and we shouldn't
blame it to do so. IMO we should avoid the unfair accusion on rolling
distros as the same unfair accusion is often towards LFS (notably the
way we develop BLFS is very similar to a rolling release distro).
In the hostreqs page we already states building with a GCC newer than
the version specified for LFS in the book is "not tested and not
recommended." I don't know why people must ignore it (AFAIU "not
recommended" in LFS means "not supported; don't report any bug" already:
for example those "recommended" dependencies in BLFS). Make it more
explicit with assertive language and <warning>.
Twice in the past span of a year, Arch Linux has updates to new versions
of software rather quickly that causes LFS to be impossible without
modifications. The first instance was updating to GCC-15.1, of which
that disaster may be repeated with GCC-16.1. The second, most recent,
instance is that they updated to Linux-7. This changed behavior of
rseq, tables, and the ABI feature from 32 to 33, which messes with
Glibc, meaning users will need to use a host that has Linux <= 6.19.x
for now.
This distructive nature needs to be explained to the users to help to
prevent them from using broken hosts.
So many issues have popped up over on Discord and Reddit, and as an
aside and personal vent, I've been getting pretty tired of it each time
Arch pulls off something like this when it clearly isn't time yet.
The Gentoo GUI LiveCD (and Gentoo itself in general) is a good example
of how to treat the software set, and too not update too early.
Fix the explanation for CSM (here M stands for Module, not Mode).
Keep the terminology "BIOS" soly for "booting via MBR" and use
"firmware" instead for other purposes.
"UEFI bootloaders" normally stands for things like GRUB or systemd-boot,
instead of firmware. And it seems we are using "standard" location
instead of "hardcoded" location elsewhere.
- Use "firmware setup" instead of "BIOS": in the context of the grub
page "BIOS" almost always means "MBR boot," but here it means the
firmware setup interface.
- We may manipulate any EFI variable (unless the firmware makes it read
only) by directly writing the efivarfs, but GRUB needs efibootmgr.
- We don't necessarily install LFS into the same disk where ESP exists.
Update to wheel-0.47.0 (Python module).
Update to tzdata2026b.
Update to sed-4.10.
Update to packaging-26.2 (Python module).
Update to mpc-1.4.1.
Update to meson-1.11.1.
Update to vim-9.2.0421 (Security Update).
Update to man-pages-6.18.
Update to iproute2-7.0.0.
Update to inetutils-2.8.
Update to expat-2.8.0 (Security Update).
Update to elfutils-0.195 (libelf).
Update to coreutils-9.11.
Update to iana-etc-20260424.
Technically the swap partition does not contain a file system, thus
"formatting" seems puzzling. And the next section is using a better
terminology "initialized" (copied from the man page of mkswap).
The bug only affects BIOS. So if the user has not built grub for BIOS,
(s)he won't use BIOS and the sed is not needed; if the user has built
grub for BIOS, the sed should have been already executed when (s)he was
building grub for BIOS.
So in either case, we don't need to repeat the sed in the EFI sections.
Update to meson-1.11.0.
Move intltool and XML-Parser to BLFS.
Update to vim-9.1.0340 (Security Update).
Update to util-linux-2.42 (Security Update).
Update to sqlite-3.53.0.
Update to Python3-3.14.4 (Security Update).
Update to openssl-3.6.2 (Security Update).
Update to linux-6.19.12.
Update to libcap-2.78 (Security Update).
Update to iana-etc-20260409.
The iocharset option has nothing to do with what the firmware will see.
It only changes the way the kernel reports the file names to the
user-space. So techincally it should match the locale, we're lucky here
because most common locales treat 7-bit ASCII in the same way.
P.S. the UEFI spec says the file names stored onto the ESP (controlled
by codepage instead of iocharset) must be either (7-bit) ASCII or UCS-2.
CP437 actually has more characters than ASCII (it's "DOS extended 8-bit
ASCII") so if you create a file with 8-bit name in ESP you may wreck
havoc. UCS-2 is a subset of UTF-16 which is CP1200, but Linux does not
support CP1200 (yet) and even if we can use CP1200 it still contains
more characters than UCS-2 so the issue will still exist. We can only
trust the boot loader installers (like grub-install) and the user for
avoiding 8-bit file names.
Add a note to say UEFI partition only needs to be mounted when running
grub-install or to inspect the partition. It may be needed in BLFS when using
efibootmgr. It is definitly not needed to be in fstab for the boot process
to work.
I also needed to remove several unneeded options in the example fstab
line because it ran off the right side of the page. It's a bit
unfortunate that fstab does not have the capability of understanding
backslash-newline.
