On 1/30/20 12:42 PM, Alan Feuerbacher via blfs-support wrote:
On 1/30/2020 9:57 AM, Bruce Dubbs via blfs-support wrote:
On 1/30/20 10:19 AM, Alan Feuerbacher via blfs-support wrote:
On 1/29/2020 8:52 PM, Ken Moffat via blfs-support wrote:
If I've parsed your mail correctly, you are updating glibc on a
completed system.
Right. Completed, at least, to the point where KDE etc. can be
installed.
If I've misparsed that, I'm sure I'll find out
when I start my next test build.
Very few people here update glibc in a running LFS system. Unlike
binary distros, we don't ship a new build of glibc when the kernel
headers change (or, indeed, at all - we don't ship any binaries).
That makes sense to me for the stable versions of LFS, but I thought
the purpose of the development versions was for someone like me to
install new packages as they come along.
For the mot part, yes. glibc is probably the biggest exception
because everything relies on it.
Ok. But I'm not clear about what to do with kernel updates. Should I do
as I did?: Do the "make headers" thing for each new kernel version, then
recompile glibc against that? And then compile the new kernel? That
seemed to work ok as I updated from linux-5.4.6 to 5.4.8 to 5.4.13. Or
should I refrain from doing the "make headers" thing for the new kernel,
leave glbic alone, and just compile the new kernel?
Just do the instructions in LFS Section 8.3.
make mrproper
make menuconfig
make
make modules_install
cp files to /boot
edit/update /boot/grub/grub.cfg
reboot
If you need an initrd that depends on the kernel, you will need to
rebuild that. I have an initrd that only updates the cpu microcode, but
that does not depend on the kernel and can be used for multiple kernels.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
