Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.slackware > #25387 > unrolled thread

Kernel upgrade to 4.1.6 w/o recompiles

Back to article view | Back to alt.os.linux.slackware

Contents

  Kernel upgrade to 4.1.6 w/o recompiles JohnF <john@please.see.sig.for.email.com> - 2015-08-23 08:56 +0000
    Re: Kernel upgrade to 4.1.6 w/o recompiles Eef Hartman <E.J.M.Hartman@gmail.com> - 2015-08-23 22:28 +0000
      Re: Kernel upgrade to 4.1.6 w/o recompiles JohnF <john@please.see.sig.for.email.com> - 2015-08-24 04:40 +0000
        Re: Kernel upgrade to 4.1.6 w/o recompiles Eef Hartman <E.J.M.Hartman@gmail.com> - 2015-08-24 05:38 +0000
          Re: Kernel upgrade to 4.1.6 w/o recompiles JohnF <john@please.see.sig.for.email.com> - 2015-08-24 06:36 +0000
            Re: Kernel upgrade to 4.1.6 w/o recompiles Eef Hartman <E.J.M.Hartman@gmail.com> - 2015-08-24 11:07 +0000
              Re: Kernel upgrade to 4.1.6 w/o recompiles JohnF <john@please.see.sig.for.email.com> - 2015-08-24 12:20 +0000
    Re: Kernel upgrade to 4.1.6 w/o recompiles JohnF <john@please.see.sig.for.email.com> - 2015-08-24 10:43 +0000

#25387 — Kernel upgrade to 4.1.6 w/o recompiles

(a) On one pc, I want to upgrade 14.1x32 to kernel 4.1.6, so I can
    use a logitech wireless kbd/mouse without needing ltunify --
    now I have to boot with wired kbd, ltunify unpair/pair both
    wireless devices, and then put the wired kbd away.
(b) I also want to upgrade 14.1x64 running on another pc,
    an asus vivo pc, e.g.,
       http://www.bhphotovideo.com/c/product/1131163-REG/
       asus_vivopc_vm62n_g050r_mini_desktop.html
    because its wifi chipset isn't supported by stock 3.10.17 kernel.

But I don't want to bother with recompiles. Looking at
   http://mirrors.slackware.com/slackware/slackware-current/slackware/a/
it seems to me that maybe I only need
   kernel-huge-smp-4.1.6_smp-i686-1.txz
   kernel-modules-smp-4.1.6_smp-i686-1.txz
Is that right, or do I need to install additional packages like
   /k/kernel-source-4.1.6_smp-noarch-1.txz

The doinst.sh for /a/kernel-huge-smp-4.1.6_smp-i686-1.txz
seems trivial -- just change the existing symlinks in /boot/
from 3.10.17 to 4.1.6. But it's the modules doinst.sh that seems
to suggest I may need those sources. The 4.1.6 /etc/rc.d/rc.modules
diffs exactly with the 3.10.17 version, so no change needed there.
But those symlinks
  ln -s /usr/src/linux-4.1.6 source
  ln -s /usr/src/linux-4.1.6 build
suggest maybe the sources are actually needed. Is that right?
Or, more comprehensively, what's everything I need to do to run
the current/4.1.6 kernel without recompile? Basically, I just want
to install the needed packages, change a couple of symlinks,
maybe do some simple editing, rerun lilo, and reboot. But the
kernel upgrade instructions I'm googling all involve recompiles.
Thanks,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [next] | [standalone]

#25391

JohnF <john@please.see.sig.for.email.com> wrote:
> Is that right, or do I need to install additional packages like
>   /k/kernel-source-4.1.6_smp-noarch-1.txz

Only if you got packages with kernel modules (like NVidia, VirtualBox
or such) that need to be recompiled against the new kernel.
Otherwise you will _not_ need the kernel source package.

But I would recommend you DO get
kernel-firmware-20150820git-noarch-1.txz
(or a newer replacement) as the new kernel may need newer firmware
to support certain hardware.

> The doinst.sh for /a/kernel-huge-smp-4.1.6_smp-i686-1.txz
> seems trivial -- just change the existing symlinks in /boot/
> from 3.10.17 to 4.1.6.

I wouldn't upgrade the kernel, but use installpkg for it,
after first renaming the "old" links in /boot.
I.e.:
vmlinux.old -> vmlinuz-3.10.17 
vmlinux.new -> vmlinux-4.1.6
(and the same for the System.map and the config file ones)
and then change lilo.conf to recognize both kernels, like:
# Linux bootable partition config begins
image=/boot/vmlinuz.new
  root=/dev/sda1
  label=linux
  read-only    # Partitions should be mounted read-only for checking
image=/boot/vmlinuz.old
  root=/dev/sda1
  label=backup
  read-only
# Linux bootable partition config ends

After running lilo you then always can get back to the distributed
kernel, if you get any problems with the newer one.
I always got at least two kernels on my systems, often three
(old as backup, plain "linux" as the default and maybe a "new"
one I'm testing).

PS: the firmware _should_ be upgraded as it will replace files that
are already there, so the older package won't be available anymore,
but that shouldn't matter, the firmware is _hardware_ related, not
kernel-version specific, that's why it doesn't have a kernel version
number but a date.

> to suggest I may need those sources.
> But those symlinks
>  ln -s /usr/src/linux-4.1.6 source
>  ln -s /usr/src/linux-4.1.6 build

These links are created so that a kernel module that has to be
re-compiled can find the _right_ version OF the sources.
So, as I said, the sources are needed for kernel MODULE recompiles,
as long as you don't need any of those you won't need sources.
But then again, as long as you "installpg" them they don't do any
harm either, just take up space on your disk.

[toc] | [prev] | [next] | [standalone]

#25392

Eef Hartman <E.J.M.Hartman@gmail.com> wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
>> Is that right, or do I need to install additional packages like
>>   /k/kernel-source-4.1.6_smp-noarch-1.txz
> 
> Only if you got packages with kernel modules (like NVidia, VirtualBox
> or such) that need to be recompiled against the new kernel.
> Otherwise you will _not_ need the kernel source package.

Thanks, Eef. Yup, installed 14.1x32 on a spare partition and tested
4.1.6 kernel upgrade there. Seems fine w/o new sources, though I guess
I'll download and install them at my leisure, eventually, as you
suggest at the very end.

> But I would recommend you DO get
> kernel-firmware-20150820git-noarch-1.txz
> (or a newer replacement) as the new kernel may need newer firmware
> to support certain hardware.

Okay, installed that, too. I first tried w/o new firmware, and that
seemed fine. New /lib/firmware/ seems fine, too. Like you say,
guess it can't hurt.

>> The doinst.sh for /a/kernel-huge-smp-4.1.6_smp-i686-1.txz
>> seems trivial -- just change the existing symlinks in /boot/
>> from 3.10.17 to 4.1.6.
> 
> I wouldn't upgrade the kernel, but use installpkg for it,

Nah, I prefer doing small upgrades "manually", i.e.,
  cd / ; tar -xv --xz -f filename.txz > /var/log/packages/filename
and then carefully execute the doinst.sh stuff myself.
Just makes me feel more comfortable that nothing's going to happen
that I'm not okay with. Of course, if there's too much doinst.sh
stuff, I just check it first and then use installpkg. But these
were pretty trivial. The firmware was hardest, but still easy --
just a dozen or so symlinks.

> after first renaming the "old" links in /boot.
> I.e.:
> vmlinux.old -> vmlinuz-3.10.17 
> vmlinux.new -> vmlinux-4.1.6
> (and the same for the System.map and the config file ones)

Yeah, the System.map and config symlinks are the ones that have
confused me about that. Each stanza can indeed contain
   image=/boot/vmlinuz.new
   image=/boot/vmlinuz.old
   etc,
but there's nothing I'm aware of in the stanzas that lets you
associate a System.map.new and config.new with vmlinuz.new, etc.
As far as I can tell, there's just one "global" System.map and
config, and they're going to be associated with all the stanzas.
How do you get around that?

> and then change lilo.conf to recognize both kernels, like:
> # Linux bootable partition config begins
> image=/boot/vmlinuz.new
>   root=/dev/sda1
>   label=linux
>   read-only    # Partitions should be mounted read-only for checking
> image=/boot/vmlinuz.old
>   root=/dev/sda1
>   label=backup
>   read-only
> # Linux bootable partition config ends
> 
> After running lilo you then always can get back to the distributed
> kernel, if you get any problems with the newer one.
> I always got at least two kernels on my systems, often three
> (old as backup, plain "linux" as the default and maybe a "new"
> one I'm testing).
> 
> PS: the firmware _should_ be upgraded as it will replace files that
> are already there, so the older package won't be available anymore,

I just mv'ed 14.1's /lib/firmware directory and just extracted a whole
new firmware directory from the tarball (and kept my fingers crossed
linux wouldn't hang in the meantime -- it didn't, everything worked fine).
But it's a little unexpected that for the old one (dated 20131008)
   du -sc firmware-slack14.1/
   59412 total
but for the new one (dated 20150820)
   du -sc firmware/
   109424 total
That looks like an awful lot of new stuff.

> but that shouldn't matter, the firmware is _hardware_ related, not
> kernel-version specific, that's why it doesn't have a kernel version
> number but a date.
> 
>> to suggest I may need those sources.
>> But those symlinks
>>  ln -s /usr/src/linux-4.1.6 source
>>  ln -s /usr/src/linux-4.1.6 build
> 
> These links are created so that a kernel module that has to be
> re-compiled can find the _right_ version OF the sources.
> So, as I said, the sources are needed for kernel MODULE recompiles,
> as long as you don't need any of those you won't need sources.
> But then again, as long as you "installpkg" them they don't do any
> harm either, just take up space on your disk.

Yeah, no problem with diskspace anymore. My first slackware install
was from floppies. Nowadays a stack of floppies from here to the Moon
wouldn't fill up my hard drive (actually, a stack of 10 is ~1.5" thick
and stores ~15MB formatted, so my 2TB hard drive is ~equivalent to
a 200,000" stack of floppies, which would be ~3.15 miles high).
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#25393

JohnF <john@please.see.sig.for.email.com> wrote:
> Okay, installed that, too. I first tried w/o new firmware, and that
> seemed fine. New /lib/firmware/ seems fine, too. Like you say,
> guess it can't hurt.

Certain hardware may need them. If you haven't got the hardware
you won't notice any differences.

> but there's nothing I'm aware of in the stanzas that lets you
> associate a System.map.new and config.new with vmlinuz.new, etc.

Neither the kernel nor lilo need those files/links, they're mostly for
human usage and _some_ apps may use them to get info about the running
kernel. Then, when you do wnat to modify the kernel, the config helps
to give you a base to start from.

> How do you get around that?

Just for convenience I create every reboot a new set of sym-links to
the running kernel's version of those files:
echo "Set correct version for System.map and kernel src link ...."
KERNEL=`uname -r`

cd /boot && ln -sf System.map*-$KERNEL System.map && \
ln -sf config*-$KERNEL config
cd /usr/src && test -d linux-$KERNEL && rm -f linux && \
ln -s linux-$KERNEL linux

You see that the last command allows for "no sources present".

> That looks like an awful lot of new stuff.

There's an awful lot of newer hardware that the kernel has to
support. Thta is the reason _why_ you wanted a newer kernel...

> a 200,000" stack of floppies, which would be ~3.15 miles high).

Cq. about 5 km (I cannot really think in those archaic units like
miles and feet etc. - in science only the SI is used).
BTW: I'm an ex-physics student and retired university mathematics and
electric engineering staff member (department Electrical Engineering,
Mathematics and Computer Science of the Delft University of
Technolofy).

[toc] | [prev] | [next] | [standalone]

#25394

Eef Hartman <E.J.M.Hartman@gmail.com> wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
>> Okay, installed that, too. I first tried w/o new firmware, and that
>> seemed fine. New /lib/firmware/ seems fine, too. Like you say,
>> guess it can't hurt.
> 
> Certain hardware may need them. If you haven't got the hardware
> you won't notice any differences.
> 
>> but there's nothing I'm aware of in the stanzas that lets you
>> associate a System.map.new and config.new with vmlinuz.new, etc.
> 
> Neither the kernel nor lilo need those files/links, they're mostly for
> human usage and _some_ apps may use them to get info about the running
> kernel. Then, when you do want to modify the kernel, the config helps
> to give you a base to start from.

Thanks for the additional info, Eef. Somewhere around slack 8 or 10,
I'd tried booting one install with several kernels, one per lilo stanza,
as per your (now snipped) suggestion. But it somehow failed, and
I somehow determined the single System.map and config were the problem.
So I never tried that again, instead using several partitions for
different kernel versions, on the sporadic occasions when I wanted
a newer kernel but not a whole new slackware version. But I guess that
was wrong -- the System.map and config weren't the problem, and I must
have messed up something else. Next time I need this, I'll try your
way again. Lots simpler than what I've been doing.

>> How do you get around that?
> 
> Just for convenience I create every reboot a new set of sym-links to
> the running kernel's version of those files:
> echo "Set correct version for System.map and kernel src link ...."
> KERNEL=`uname -r`
> 
> cd /boot && ln -sf System.map*-$KERNEL System.map && \
> ln -sf config*-$KERNEL config
> cd /usr/src && test -d linux-$KERNEL && rm -f linux && \
> ln -s linux-$KERNEL linux
> 
> You see that the last command allows for "no sources present".

Thanks, again. I'll put that stuff in /etc/rc.d/rc.local (or maybe
create a separate 755 rc.symlinks file).
   Off-topic, re uname -r : I'd noticed the default /etc/issue
has \s \r \l, which I'd guessed were uname -switches, except
that uname -l doesn't work. Where does it get that info from?

>> That looks like an awful lot of new stuff.
> 
> There's an awful lot of newer hardware that the kernel has to
> support. That is the reason _why_ you wanted a newer kernel...
> 
>> a 200,000" stack of floppies, which would be ~3.15 miles high).
> 
> Cq. about 5 km (I cannot really think in those archaic units like
> miles and feet etc. - in science only the SI is used).
> BTW: I'm an ex-physics student and retired university mathematics and
> electric engineering staff member (department Electrical Engineering,
> Mathematics and Computer Science of the Delft University of
> Technology).

Well, units/shmunits, miles/shmiles. Dimensionless constants are
invariant regardless. I have an ms in physics from ccny (city college
of new york), and did some adjunct teaching at queens college and
baruch (new york city schools) back in the 1970's. Mostly computer
consulting since, as per s-corp's homepage at the obvious url from
my sig below. ( By the way, I sail as a hobby, and there ain't
no such thing as nautical kilometers :)
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#25396

JohnF <john@please.see.sig.for.email.com> wrote:
>   Off-topic, re uname -r : I'd noticed the default /etc/issue
> has \s \r \l, which I'd guessed were uname -switches, except
> that uname -l doesn't work. Where does it get that info from?

See "man agetty" or likewise, the issue file is used by the getty
text-mode login process and IT interpretes the \<letter> stuff..

> ( By the way, I sail as a hobby, and there ain't
> no such thing as nautical kilometers :)

But there are "normal" ones (like: this lake is 10 km across).

BTW you've shown one problem with "miles" as there are at least two
different ones of them....
Not even staring on knots, fathoms and likewise.

[toc] | [prev] | [next] | [standalone]

#25397

Eef Hartman <E.J.M.Hartman@gmail.com> wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
>>   Off-topic, re uname -r : I'd noticed the default /etc/issue
>> has \s \r \l, which I'd guessed were uname -switches, except
>> that uname -l doesn't work. Where does it get that info from?
> 
> See "man agetty" or likewise, the issue file is used by the getty
> text-mode login process and IT interprets the \<letter> stuff..

Thanks for the additional info, Eef. And sorry for off-topic question.
I probably should have researched it myself first, but I just
recalled it when seeing your uname -r, and asked without thinking.

>> ( By the way, I sail as a hobby, and there ain't
>> no such thing as nautical kilometers :)
> 
> But there are "normal" ones (like: this lake is 10 km across).
> BTW you've shown one problem with "miles" as there are at least two
> different ones of them....
> Not even staring on knots, fathoms and likewise.

Aw, c'mon Eef, just kidding around. (Besides, "nautical km" would've
probably been more sensible if the English hadn't named it, since by
def it's the distance equivalent of one minute of latitude. And since
the original meter def was 10^7meters = equator-to-pole distance along
the Paris meridian, a "nautical mile"=10^7/90/60meters naturally,
as long as you don't insist on radians in preference to degrees.
By the way, google show's earth's polar circumference as 40,008km, so
their meter determination, wrt its 10^7 def, was excellent for the time.)
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#25395

JohnF <john@please.see.sig.for.email.com> wrote:
> <snip>... what's everything I need to do to run
> the current/4.1.6 kernel without recompile?

Update: Just in case anybody else is considering kernel upgrade,
everything worked as per Eef's suggestions in preceding posts.
That's on a 14.1x32 install on bios/mbr. Then I also did the same thing
on a 14.1x64 uefi/gpt install (dual-booting with a pre-installed win 8.1),
following the additional instructions at (long url split over two lines)
   http://docs.slackware.com/howtos:slackware_admin:
   linux_kernel_options_for_uefi_and_elilo
And that surprised the heck out of me when it "just worked".
No problems whatsoever. And iwconfig and lspci now show the
wifi chipset that 3.10.17 wasn't supporting, so complete success.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux.slackware

csiph-web