Re: [lfs-dev] Potential problems with the LFS and BLFS 12.3 release

Am 27.02.25 um 10:26 schrieb Thomas Trepl ([email protected]
via lfs-dev Mailing List):
> Am Mittwoch, dem 26.02.2025 um 13:19 -0600 schrieb Bruce Dubbs:
>> We have a potential problem with LFS and BLFS that I am asking for feedback on how to 
>> proceed.
>>
>> CURRENT
>>    We have LFS and BLFS almost ready to go with a few packages (3) that still need 
>> testing on specialized hardware. There are also a few tweaks needed to some 
>> instructions, but there are no show stoppers.
>>
>> PROBLEM
>>    I was testing some LFS packages that have come in during the package freeze and 
>> ran into a problem with udev/systemd. This problem is caused by a change in the 
>> kernel headers for linux-6.13.4 that cause udev/systemd to fail. This problem can be 
>> fixed with two seds or by upgrading to systemd-257.3 but we cannot be sure that the
>> rest of the many applications and libraries that depend on systemd/udev will work
>> properly unless we go through extensive testing. The changes are not needed for
>> what we have now using the linux-6.13.2 kernel.
>>
>>   The problem now occurs if a user upgrades the kernel when building LFS.  We say:
>> "The Linux kernel is updated quite frequently, many times due to discoveries of 
>> security vulnerabilities. The latest available stable kernel version may be used, 
>> unless the errata page says otherwise."
>>
>> Here are our options:
>>
>> 1. Continue with the 12.3 release.  We can add to the errata to tell users NOT to
>>     use the latest kernel or we can remove that quote above.
>>
>> 2. We can release a new lfs-12.3-rc2 and restart the testing process. This
>>     will delay the release schedule by one to two weeks but will make upgrades
>>     easier for users. It will also allow us to incorporate newer package versions
>>     that have published security issues.
>>
>>     I'll note here that there is no guarantee that during the delay that new
>>     packages with security issues will not be released. Sometimes a new package
>>     is not an issue, but the current problem is that udev/systemd touches a huge
>>     number of packages and we don't have a good way to ensure everything is
>>     consistent without re-testing everything.
>>
>> I am asking for community feedback about how we should proceed.
> 
> I'd suggest to add (and finally choose) a third option:
> 
> 3. Change the note to "The Linux kernel is updated quite frequently, many
> times due to discoveries of security vulnerabilities. The book has been
> tested on the documented kernel version of &kernel-version;. If there are
> newer versions, those version might be used if there are urgent reasons,
> but there is no guarantee that newer kernel version can be just dropped in
> without impact on user land programs."  (or so)
> 
> So we can stay on 6.13.2 and release it as is. Kernel upgrades do occur
> very often and when we tell the user to always use the latest, it would
> mean the user has to redo LFS every some days and our "release" is rendered
> invalid.
> We know that 12.3 works pretty fine on 6.13.2. Thats good and it is a
> pretty good starting point for a user looking for a stable system.
OK, but no user would expect a _minor_ point-release of the _kernel_ to
break the build.  Linux-6.13.5 is out already.  Does anybody really
expect a user not to take that version if he can?  With the latest fixes
or drivers?  And who would want to explain that 6.13.2 is good but
6.13.5 is "no-no"?

Update the udev/systemd-stuff, take the time needed for testing and
simply postpone the release accordingly.  The "schedule" mentioned in
this thread is just an internal thing.  Completely unimportant for the
users.

Rainer


> 
> Why not -rc2?  If we coordinate testing somehow (who compiles/tests what)
> we avoid double-work and will be pretty quick. We do not need to check
> details like SBU and sizes again.  Just  CMMI, worked? Yes. Next one ...
> 
>

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page