On 2020-04-09 오전 10:05, Ken Moffat wrote:
On Thu, Apr 09, 2020 at 08:17:12AM +0900, WooHyung Jeon wrote:
On 2020-04-09 오전 3:30, Bruce Dubbs wrote:
On 4/8/20 1:21 PM, Furkan İnciroğlu wrote:
On 4/7/20 2:31 AM, Furkan İnciroğlu wrote:
Hi there,
When I compiled LFS 8.4 systemd Linux kernel version was 4.20.12. I
want to upgrade kernel version to 5.5 or else. I was wondering before
doing this job, is it possible to break something in the operating
system when this upgrade is done? Because now everything works
properly, I will upgrade just kernel.
Yes you can do this easily. Just build the new kernel with the
instructions in Chapter 8 and copy to /boot. Then update grub.cfg with
a new menuentry and reboot.
One technique though is to copy the current running configuration into
the kernel tree as .config and run 'make oldconfig'. It will ask
questions about new configuration items. I usually accept the default
for those questions except for drivers. Usually it will want to add new
drivers but if I haven't added any new HW, I answer No for those.
Thank you Bruce for you answer. I built new kernel and then copied
under boot directory and now everything works properly and I checked
cat /proc/version, it says my kernel has 5.5 version. That's perfect.
But I wonder, Why I do not need to Installation of Linux API Headers
again? Like section 5.6 and 6.7.1 in the LFS book? In my opinion, I
also need to run make headers command and copy this new kernel headers
to /usr/include directory. What would you say?
Don't do that. glibc depends on the kernel headers it was built with.
You could make changes that will create errors that are very hard to
find and fix.
-- Bruce
Sorry for the stupic question but how far can I update the kernel? I mean,
if I installed 5.5.x version headers, then I could update to the 5.5.y
kernels only? Is there any principle related to this?
--
Regards,
W. H. Jeon
In theory you can update "for ever" i.e. to any newer version. In
practice, you will _not_ be able to use new options which require
userspace to take advantage of additions to the kernel headers, and
at some point you will eventually need to update the toolchain (e.g.
ISTR last year gcc-4.7 was dropped for X86).
For desktops, my considered advice is that you should eventually
script the whole build (or use jhalfs if that suits) and upgrade
within a year (as well as upgrading vulnerable packages on a regular
basis).
You might also sometimes find that things break if something has
been removed from the newer kernel. I don't have any examples of
that, and it would only intentionally happen when the fix for a
problem (typically a CVE) removes something because it is "just
wrong". I suppose that is more likely to happen if you need to
enable something which is in 'staging' and then that drops out
because nobody made it good enough for the main kernel. That can
also happen on uncommon things which the kernel devs think ought to
be removed, and put into staging for a release or two to see if
anyone complains (that is, staging drivers need to be specifically
enabled, most individuals who build a kernel will not do that).
In practice, I try to keep my old 'released' desktop systems
minimally updated for vulnerabilities for up to 18 months (e.g.
firefox, qtwebengine, and sometimes openssl, ghostscript,
occasionally other packages). In those systems I update to a newer
'stable' kernel when the running kernel version is no-longer
maintained.
So, to take a hypothetical example - if I started with headers from
5.2 I would have moved to a 5.3 kernel at some point, then to 5.4.
Since 5.4 is a long-term stable kernel I will then only update to
later 5.4 point releases on that system if I become aware of bug
fixes which affect my hardware, or of serious CVE problems that
affect my usage (about 16 months ago we started to hit the spectre
and meltdown fixes, nowadays serious CVE problems typically only
affect modern intel CPUs used for shared hosting (KVM|QEMU|XEN) oe
only affect specific drivers and use-cases).
For my 9.1 desktop systems I will typically update to 5.6 in the
early 5.6 releases, after trying late 5.6-rc, and again for 5.7,
5.8, etc until the next LTS kernel is announced.
On test (or WIP) desktop builds from LFS-svn I will update to newer
releases and -rc kernels if I have the time and think the system is
still usable (e.g. for recovering other systems if I trash them).
So, those of my desktop and laptop systems which I think are still
usable (or maintainable) are either running 5.4.something (if old),
5.5.something, or 5.6.2 (my most recent updates this week).
Just for the record, on my laptop I don't expect to update old
systems (builds are so sloow, 5400rpm or slower HDD and only 6.7GB
RAM (from 8GB) left after the video takes some - with 8 cores that
is woefully inadequate, and even with 4 cores offline and using 3
inxtance of xfce term I was marginally into swap when updating
firefox to 68.7.0.
My maintained desktop systems are variously LFS-8.3 (one machines,
on another I couldn't update qtwebengine), 8.4 (two machines - the
third desktop/test machine is newer than this) 9.0, 9.1, and now two
or three newer svn builds (one of those used 5.6 or maybe 5.6-rc
headers, I'm sure Bruce will think that is 'bleeding edge', but then
I did participate on the old BeLFS list back in the days when I was
running a brain-damaged (incoherent caching) PPC machine.
For *test* server builds I go with what is in the book at the time,
and then probably throw them away. But for my home server I drop
back to the current LTS kernel and if that is older than what is in
the LFS release then I drop back to the matching version of
iproute2.
For a while, my current home server (athlon 200ge) was too new to
work with the LTS kernel (4.19, which insisted that I should be
using radeon isntead of amdgpu - but radeon doesn't support this
newer hardware - I need amdgpu to get a sensibly large framebuffer
console, 80x25 doesn't suit me). But now that 5.4 is LTS I'm using
a 5.4 kernel with iproute-5.4 on what is otherwise {,B}LFS-9.1.
Oh, maybe I should add that in the past I used to try to keep some
past desktop systems usable for a longer time. But there were two
problems with that: First, building new releases almost always takes
longer, whilst my old hardware was low-end so new builds were slow.
But the killer problem was that I moved to HDMI monitors and the
oldest machines had integrated graphics with D-SUB (vga) connectors.
But with usable hardware, updating a kernel should not be a big
deal. Whether it is safe or sensible to keep a very old system
running is a different question which each owner must answer for
himself or herself.
Sorry if that was rather more information than you wanted.
Fun, isn't it ;-)
ĸen
Wow, I appreciate this detailed answer! I think I should re-read a few
more times! :) Thanks again!
--
Regards,
W. H. Jeon
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
