Re: Weird yum/kernel problem

--===============7231093069060865703==
Content-Type: multipart/alternative; boundary="Apple-Mail=_D628B7CE-A43E-4979-AF81-A88996B91F4B"


--Apple-Mail=_D628B7CE-A43E-4979-AF81-A88996B91F4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

The weirdness continues. I never got 3.17.3 working, but a week or so =
ago, after 3.17.7 had been out for a while, I tried again, and the build =
worked flawlessly. So I was feeling reasonably confident to try 3.17.8 =
last week. But it failed. So I rebooted to 3.17.7 and used rpm to remove =
3.17.8 (maybe I should have used yum, but I don=92t know how to do that =
for a kernel). I then tried to build the module again. But although I =
was in kernel 3.17.7, and 3.17.8 had been removed, it believed it built =
a kernel for 3.17.8! i.e. the reverse of my previous problem. A bit =
confusing - it couldn=92t have actually built a kernel for 3.17.8, =
because all the relevant headers and libraries no longer existed - but =
somehow it thought it had, and this seem to relate to another issue. It =
turned out that an rpm uninstall didn=92t remove the boot files for =
3.17.8; removing those by hand allowed me to build a module for 3.17.7. =
So it looked like the build system decided what kernel it had built for =
by checking what was the latest in /boot??? But this can=92t explain the =
whole problem, because we can be absolutely certain that when I was =
building for the 3.17.8 kernel, the boot files were available (after =
all, I was booted into it).=20

So basing on Anders=92 comment, it raises another possibility. When a =
new kernel arrives, I always delay installing it until the corresponding =
devel and header files are available in my local mirrors. But if I build =
soon after a new kernel turns up, it still always seems to fail. Waiting =
for a week or so often seems to do the trick (but difficult to =
experiment with, so I=92m not certain). Does this ring any bells for =
anyone? Is there something else that the module build process could be =
relying on to determine what kernel it has built for - something that =
might not get updated for a few days in remote mirrors, after the =
kernel, headers and devel have arrived?=20

    Thanks for any suggestions
    Bob


On 12 Dec 2014, at 13:03, Bob McKay <[email protected]> wrote:

> I=92m not sure whether the problem I=92m about to describe is a yum =
problem, or a problem with the way the kernel packages are set up in our =
Fedora 20 server. If this is the wrong place to ask, I=92d really =
appreciate a pointer to the right one (the Fedora mechanism for yum =
kernel updates seems to be particularly complex, and I haven=92t =
properly understood it yet, which is why I=92m not sure where the real =
problem lies).=20
>=20
> I have some RAID hardware that requires a driver module to be built =
after every kernel update (all updates are performed with yum, not =
package-manager). My process is to disable the hardware, boot to the =
newly-updated kernel, build and install the module, then re-enable the =
harware and reboot. Since about mid year, I have been having repeated =
problems building the module. When I build it, the build appears to =
succeed, but install fails, saying that the module wasn=92t built =
against the running kernel. This seems to be correct - when I manually =
check the magic of the built module, it shows the preceding kernel (i.e. =
at the moment, 3.17.2), although it  was built under a running 3.17.3 =
kernel, and is installed in the correct location for 3.17.3 modules.
>=20
> By the way, I have no clear idea how I got to a working 3.17.2 kernel =
- the problem originally occurred at 3.16.3, and I was stuck in that =
kernel for a long while. Fortunately I had some free time on the server =
a few weeks ago. Somehow something in a complex sequence of =
grub2-install, grub2-mkconfig , removals and reinstallations of the =
corresponding kernel and kernel-devel, and module rebuilds changed =
something, and I managed to get the 3.17.2 update working. But I haven=92t=
 been able to figure out what it was, or to reproduce it since.
>=20
> Why it looks like it should build correctly: at the time of building, =
all kernel components have been fully updated. For example, at the =
moment, I have kernel, kernel-devel, kernel-modules-extra and kernel =
devel all at 3.17.3 (but of course, I also have earlier versions of =
kernel, kernel-headers and kernel-modules-extra installed as well - in =
this case, including 3.17.2). When I try to do the build and install, it =
is booted in 3.17.3. So I don=92t understand why it builds a 3.17.2 =
module.
>=20
> It seems that at the time it is building the module, the system is =
somehow defaulting to building for 3.17.2. That suggests that a =
necessary flag recording the current kernel version isn=92t being =
updated when the kernel is updated or booted - I haven=92t been able to =
figure out how the system decides what the current kernel is, so I don=92t=
 know where this flag might be. Any suggestions on how this is done (and =
why it might be failing, or how to check it) would be really =
appreciated.
>=20
> There is more detail on the problem at:
> http://forums.fedoraforum.org/showthread.php?t=3D300863
> https://bugzilla.redhat.com/show_bug.cgi?id=3D1167222
> but unfortunately no responses in either place yet (possibly because =
there isn=92t sufficient detail - but I have no idea what else to =
supply).=20
>=20
> The system is a production server; it=92s currently running stably =
with 3.17.2, and I can=92t reboot very often, so any suggestions that =
would help me to diagnose this problem without rebooting would be =
particularly appreciated.


--Apple-Mail=_D628B7CE-A43E-4979-AF81-A88996B91F4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">The =
weirdness continues. I never got 3.17.3 working, but a week or so ago, =
after 3.17.7 had been out for a while, I tried again, and the build =
worked flawlessly. So I was feeling reasonably confident to try 3.17.8 =
last week. But it failed. So I rebooted to 3.17.7 and used rpm to remove =
3.17.8 (maybe I should have used yum, but I don=92t know how to do that =
for a kernel). I then tried to build the module again. But although I =
was in kernel 3.17.7, and 3.17.8 had been removed, it believed it built =
a kernel for 3.17.8! i.e. the reverse of my previous problem. A bit =
confusing - it couldn=92t have actually built a kernel for 3.17.8, =
because all the relevant headers and libraries no longer existed - but =
somehow it thought it had, and this seem to relate to another issue. It =
turned out that an rpm uninstall didn=92t remove the boot files for =
3.17.8; removing those by hand allowed me to build a module for 3.17.7. =
So it looked like the build system decided what kernel it had built for =
by checking what was the latest in /boot??? But this can=92t explain the =
whole problem, because we can be absolutely certain that when I was =
building for the 3.17.8 kernel, the boot files were available (after =
all, I was booted into it).&nbsp;<div><br></div><div>So basing on =
Anders=92 comment, it raises another possibility. When a new kernel =
arrives, I always delay installing it until the corresponding devel and =
header files are available in my local mirrors. But if I build soon =
after a new kernel turns up, it still always seems to fail. Waiting for =
a week or so often seems to do the trick (but difficult to experiment =
with, so I=92m not certain). Does this ring any bells for anyone? Is =
there something else that the module build process could be relying on =
to determine what kernel it has built for - something that might not get =
updated for a few days in remote mirrors, after the kernel, headers and =
devel have arrived?&nbsp;</div><div><br></div><div>&nbsp; &nbsp; Thanks =
for any suggestions</div><div>&nbsp; &nbsp; =
Bob<br><div><br></div><div><br><div><div>On 12 Dec 2014, at 13:03, Bob =
McKay &lt;<a =
href=3D"mailto:[email protected]">[email protected]</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"><div style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I=92m =
not sure whether the problem I=92m about to describe is a yum problem, =
or a problem with the way the kernel packages are set up in our Fedora =
20 server. If this is the wrong place to ask, I=92d really appreciate a =
pointer to the right one (the Fedora mechanism for yum kernel updates =
seems to be particularly complex, and I haven=92t properly understood it =
yet, which is why I=92m not sure where the real problem =
lies).&nbsp;<div><br></div><div>I have some RAID hardware that requires =
a driver module to be built after every kernel update (all updates are =
performed with yum, not package-manager). My process is to disable the =
hardware, boot to the newly-updated kernel, build and install the =
module, then re-enable the harware and reboot. Since about mid year, I =
have been having repeated problems building the module. When I build it, =
the build appears to succeed, but install fails, saying that the module =
wasn=92t built against the running kernel. This seems to be correct - =
when I manually check the magic of the built module, it shows the =
preceding kernel (i.e. at the moment, 3.17.2), although it &nbsp;was =
built under a running 3.17.3 kernel, and is installed in the correct =
location for 3.17.3 modules.</div><div><br></div><div>By the way, I have =
no clear idea how I got to a working 3.17.2&nbsp;kernel&nbsp;- the =
problem originally occurred at 3.16.3, and I was stuck in that kernel =
for a long while. Fortunately I had some free time on the server a few =
weeks ago. Somehow something in a complex sequence of grub2-install, =
grub2-mkconfig , removals and reinstallations of the corresponding =
kernel and kernel-devel, and module rebuilds changed something, and I =
managed to get the 3.17.2 update working. But I haven=92t been able to =
figure out what it was, or to reproduce it =
since.</div><div><div><br></div><div>Why it looks like it should build =
correctly: at the time of building, all kernel components have been =
fully updated. For example, at the moment, I have kernel, kernel-devel, =
kernel-modules-extra and kernel devel all at 3.17.3 (but of course, I =
also have earlier versions of kernel, kernel-headers and =
kernel-modules-extra installed as well - in this case, including =
3.17.2). When I try to do the build and install, it is booted in 3.17.3. =
So I don=92t understand why it builds a 3.17.2 =
module.</div><div><br></div><div>It seems that at the time it is =
building the module, the system is somehow defaulting to building for =
3.17.2. That suggests that a necessary flag recording the current kernel =
version isn=92t being updated when the kernel is updated or booted - I =
haven=92t been able to figure out how the system decides what the =
current kernel is, so I don=92t know where this flag might be. Any =
suggestions on how this is done (and why it might be failing, or how to =
check it) would be really =
appreciated.</div></div><div><br></div><div>There is more detail on the =
problem at:</div><div><a =
href=3D"http://forums.fedoraforum.org/showthread.php?t=3D300863">http://fo=
rums.fedoraforum.org/showthread.php?t=3D300863</a></div><div><a =
href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1167222">https://bug=
zilla.redhat.com/show_bug.cgi?id=3D1167222</a></div><div>but =
unfortunately no responses in either place yet (possibly because there =
isn=92t sufficient detail - but I have no idea what else to =
supply).&nbsp;</div><div><br></div><div>The system is a production =
server; it=92s currently running stably with 3.17.2, and I can=92t =
reboot very often, so any suggestions that would help me to diagnose =
this problem without rebooting would be particularly =
appreciated.</div></div></blockquote></div><br></div></div></body></html>=

--Apple-Mail=_D628B7CE-A43E-4979-AF81-A88996B91F4B--

--===============7231093069060865703==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Yum mailing list
[email protected]
http://lists.baseurl.org/mailman/listinfo/yum

--===============7231093069060865703==--