<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    ARGH!!!<br>
    <br>
    Look at your sample .repo that I just copied and pasted.  <br>
    <br>
    For kernels, you have enabled=0<br>
    <br>
    I colored the line red below.<br>
    <br>
    !!!!<br>
    <br>
    I just did not look at it.<br>
    <br>
    <div class="moz-cite-prefix">On 03/01/2017 11:00 AM, Fabian Arrotin
      wrote:<br>
    </div>
    <blockquote
      cite="mid:c3c4ffb6-d562-2e4d-7165-61e04606d3fc@centos.org"
      type="cite">
      <pre wrap="">On 01/03/17 14:21, Robert Moskowitz wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">

On 02/28/2017 04:28 AM, Fabian Arrotin wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Hi guys,

As mentioned in the other thread about new kernel (basically to fix the
dccp cve issue), I had a look at the 4.4.x branch, but thought also
about a rebase to 4.9.x (also upstream LTS at kernel.org)

For AltArch (centos 7 i386), Johnny built a 4.9.13 kernel and so I
reused it for armhfp
It also makes sense to rebase to 4.9.x for rpi2/rpi3 as the rpi
foundation also rebased to 4.9 and so confirmed to me that they don't
maintain 4.4.x (even if they still accept Pull Requests).

So we have now 4.9.13 available for both rpi and generic.

The following /etc/yum.repos.d/testing-kernel.repo would do it :

[kernel-testing]
name=CentOS Kernels for armhfp testing
baseurl=<a class="moz-txt-link-freetext" href="https://buildlogs.centos.org/centos/7/kernel/$basearch/kernel-$kvariant/">https://buildlogs.centos.org/centos/7/kernel/$basearch/kernel-$kvariant/</a>

<font color="#ff0000">enabled=0</font>
gpgcheck=0

[firmware]
name=firmware
baseurl=<a class="moz-txt-link-freetext" href="https://armv7.dev.centos.org/repodir/arm-kernels/linux-firmware-20170213/">https://armv7.dev.centos.org/repodir/arm-kernels/linux-firmware-20170213/</a>

enabled=1
gpgcheck=0


After that a simple yum update --enablerepo=kernel-testing would bring
it to the node

For rpi, nothing to be done
For the other boards, I've added an update-boot tool to automatically
modify extlinux.conf. but you need the updated centos-userland-release
pkg :
<a class="moz-txt-link-freetext" href="https://armv7.dev.centos.org/repodir/c71611-updates-1/centos-userland-release/7-3.1611.el7.centos.0.2/armv7hl/centos-userland-release-7-3.1611.el7.centos.0.2.armv7hl.rpm">https://armv7.dev.centos.org/repodir/c71611-updates-1/centos-userland-release/7-3.1611.el7.centos.0.2/armv7hl/centos-userland-release-7-3.1611.el7.centos.0.2.armv7hl.rpm</a>


Worth noting that the actual 4.9.13 will *not* call it in the %post rpm
transaction (yet) but if that tool works for everybody, we'll add it for
newer kernels.

Any feedback is welcome, but for the kernel I'd like to push that asap
to signing/release (so the more feedback, the faster we'll have it
released) ;-)
</pre>
        </blockquote>
        <pre wrap="">
I just tried to install this on a server that is running with 4.4.42-202.

No update to the kernel.  Only proposes the 17 firmware files.

So I suspect there is some problem with the date of this update, making
it earlier than even 4.4.42-202.

Separate question about kernels.

When I *DO* update to a new kernel, do I have to reboot to be using the
new kernel.  Or are the new modules/libraries just called in while
running?  I never did figure this out...

thanks

</pre>
      </blockquote>
      <pre wrap="">
You should verify your yum local metadata/cache, as I confirm that pkgs
are there
(<a class="moz-txt-link-freetext" href="https://buildlogs.centos.org/centos/7/kernel/armhfp/kernel-generic/Packages/">https://buildlogs.centos.org/centos/7/kernel/armhfp/kernel-generic/Packages/</a>)
, and in repodata/metadata. (I updated a cubietruck through that method)
</pre>
    </blockquote>
    <br>
    <br>
  </body>
</html>