1 |
On Tuesday, 9 February 2021 13:25:01 GMT n952162 wrote: |
2 |
> On 2/9/21 12:57 PM, Michael wrote: |
3 |
> > On Tuesday, 9 February 2021 10:01:04 GMT n952162 wrote: |
4 |
> >> On 2/9/21 10:05 AM, Dale wrote: |
5 |
> >>> n952162 wrote: |
6 |
> >>>> Are extra administrative steps necessary when --sync brings in a new |
7 |
> >>>> |
8 |
> >>>> kernel, as in: |
9 |
> >>>> https://wiki.gentoo.org/wiki/Kernel/Upgrade |
10 |
> >>>> |
11 |
> >>>> I currently have this situation: |
12 |
> >>>> |
13 |
> >>>> $ uname -a |
14 |
> >>>> Linux host *4.19.72-gentoo* #7 SMP Tue Jun 9 19:51:52 CEST 2020 x86_64 |
15 |
> >>>> GNU/Linux |
16 |
> >>>> |
17 |
> >>>> $ eselect kernel list |
18 |
> >>>> |
19 |
> >>>> Available kernel symlink targets: |
20 |
> >>>> [1] linux-5.4.72-gentoo |
21 |
> >>>> [2] linux-5.4.80-gentoo-r1 |
22 |
> >>>> [3] linux-5.4.92-gentoo |
23 |
> >>>> |
24 |
> >>>> If an update requires additional steps, shouldn't that have appeared |
25 |
> >>>> in the news? |
26 |
> >>> |
27 |
> >>> It depends I think. I say think because there may be a binary kernel |
28 |
> >>> available which will upgrade itself. I seem to recall reading about it |
29 |
> >>> on a mailing list somewhere. I have no experience with it tho. That |
30 |
> >>> said, if you use the old method, you have to upgrade the kernel |
31 |
> >>> yourself. There are scripts you can use to help automate it a good bit |
32 |
> >>> but some of us still do it the manual way. When you do updates, emerge |
33 |
> >>> will pull in the new sources but the rest is up to you. I suspect most |
34 |
> >>> that do it the old way, copy .config over to the new kernel directory, |
35 |
> >>> run make oldconfig and answer the questions, compile the new kernel, |
36 |
> >>> copy it to /boot using the right method which there is a few of and then |
37 |
> >>> configure your bootloader if needed. The link you posted explains this |
38 |
> >>> in more detail, and may be more complete too. |
39 |
> >>> |
40 |
> >>> I'm trying to remember what that binary kernel thing is called. I just |
41 |
> >>> skimmed the messages so it could be something else or not even in the |
42 |
> >>> tree yet. |
43 |
> >>> |
44 |
> >>> Dale |
45 |
> >>> |
46 |
> >>> :-) :-) |
47 |
> >> |
48 |
> >> Ah, maybe I have a theory what's going on ... maybe there's no news that |
49 |
> >> it's time to upgrade the kernel, because it's not meant that the kernel |
50 |
> >> necessarily needs to be upgraded ... except that it seems that the |
51 |
> >> virtualbox-modules package might have a (unfortunate) dependency on |
52 |
> >> that... |
53 |
> > |
54 |
> > I'm not sure I understand completely why there should be a news item from |
55 |
> > portage whenever new kernel sources are updated and downloaded. It is up |
56 |
> > the system administrator to configure and build the new sources if |
57 |
> > desired. |
58 |
> gentoo policy is that administrators need to keep their systems |
59 |
> up-to-date. The promise is, if they do so, the dependency system will |
60 |
> be reliable. |
61 |
> |
62 |
> The kernel version is apparently an exception to this. The updating |
63 |
> mechanism does not require that this track the synchronization of the |
64 |
> portage tree. Administrators are free to decide what kernel they want |
65 |
> to use. This works - except for virtualbox-modules. |
66 |
> |
67 |
> > Each time you upgrade your kernel on the host, external modules will |
68 |
> > require updating/rebuilding. The set '@module-rebuild' does that instead |
69 |
> > of having to re-emerge manually each external module. |
70 |
> |
71 |
> Yes, in another context, your tip about this helped me to solve a |
72 |
> separate problem with vbox. A quick survey didn't find mention of this |
73 |
> facility in the handbook. Perhaps I missed it. |
74 |
|
75 |
Yes, I just found it in the Handbook here: |
76 |
|
77 |
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Post-install. |
78 |
2Fupgrade_tasks |
79 |
|
80 |
|
81 |
and in the wiki here: |
82 |
|
83 |
https://wiki.gentoo.org/wiki/Kernel/ |
84 |
Upgrade#Reinstalling_external_kernel_modules |
85 |
|
86 |
|
87 |
> > You seem to be running an old kernel. VBox and its modules changed |
88 |
> > recently so these will need to be updated - there may be a conflict with |
89 |
> > older host kernels and as you report you've come across it. |
90 |
> |
91 |
> what is the most efficient way for an administrator to known when a new |
92 |
> kernel is available and advisable? |
93 |
|
94 |
I don't know of a generic recommended way to go about this, but I have 'sys- |
95 |
kernel/gentoo-sources' in my world file, so the latest stable version is |
96 |
downloaded once available. Then I build the kernel when convenient and run |
97 |
'@module-rebuild' to update any external module packages. |
98 |
|
99 |
The problem could arise when some package, in this case VBox, requires a later |
100 |
kernel than the one you've been running. I guess things will break and upon |
101 |
investigating the kernel version issue will come up in troubleshooting. |
102 |
|
103 |
For major breakages of the core system I'd expect the devs would have spotted |
104 |
it and highlighted it with a news item. |
105 |
|
106 |
|
107 |
> > The eselect list you showed does not have a selected kernel source. What |
108 |
> > is linked to /usr/src/linux on your system? |
109 |
> > |
110 |
> > $ ls -l /usr/src/ |
111 |
> |
112 |
> It is properly linked considering the configuration: |
113 |
> |
114 |
> $ ll /usr/src/linux |
115 |
> lrwxrwxrwx 1 root root 20 Nov 8 2019 /usr/src/linux -> |
116 |
> linux-4.19.72-gentoo |
117 |
|
118 |
Right, this particular kernel version is no longer in the tree. The two |
119 |
versions closest to it are 'gentoo-sources-4.14.217' and 'gentoo- |
120 |
sources-4.19.160'. Or you could shoot for the latest stable 5.4.92, which |
121 |
works fine here, also on a host which runs VBox. |