Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-23 Thread Neil Bothwick
On Fri, 22 May 2015 20:55:39 -0400, Tom H wrote:

  I've never understood the approach of trusting the makefile to
  configure your kernel, compile it, compile any number of modules and
  install all those modules, but when it comes to copying one file
  to /boot, that has to be done manually because the makefile can't be
  trusted to get things right.  
 
 /sbin/installkernel renames the already-installed vmlinuz and
 System.map if it's installing the same version of the kernel.

Not if you set LOCALVERSION or LOCALVERSION_AUTO in the kernel config,
then you never get two kernels with the same name.


-- 
Neil Bothwick

Keyboard: (n.) a device used by programmers to write software for a mouse
or joystick and by operators for playing games such as 'word processing.'


pgpbfBNxizZHx.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-22 Thread Neil Bothwick
On Fri, 22 May 2015 23:29:40 +0100, Mick wrote:

  make install does it exactly the way you are doing it, but faster and
  less prone to error.  
 
 Hmm ... I may have used it the wrong way quite a few years ago, but it
 would only keep two kernels at a time or something like that.  That
 made me carry on copying kernel files into boot manually.  In this way
 at least I know where I put them and what options I pass on to them.

make install installs the kernel it just made. It doesn't, and can't,
touch other kernels. The only change it makes to /boot beyond copying
three files there is to adjust the symlinks if they are already present.

I've never understood the approach of trusting the makefile to configure
your kernel, compile it, compile any number of modules and install all
those modules, but when it comes to copying one file to /boot, that has
to be done manually because the makefile can't be trusted to get things
right.


-- 
Neil Bothwick

Microbiology: staph only.


pgpxFQRpHwpm_.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-22 Thread Neil Bothwick
On Fri, 22 May 2015 17:04:49 -0500, Dale wrote:

 I also save the config with the same version part as the kernel, that
 way I know which config goes with which kernel.  Everyone has their own
 way of doing what works for them.  I just prefer to copy my own manually
 with a name that makes sense to me.  I don't think make install will do
 this the way I do it.

make install does it exactly the way you are doing it, but faster and
less prone to error.


-- 
Neil Bothwick

They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety.
Benjamin Franklin


pgp0lvsAcW6Lb.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-22 Thread Neil Bothwick
On Fri, 22 May 2015 12:21:15 -0500, Dale wrote:

  I didn't even know about make install until I read this thread, I
  always manually copied kernels over.

 I have always copied mine over manually too.  I keep quite a few spares
 laying around, just in case.

Make install only copies the new kernel, it doesn't touch your existing
ones. However, if you use symlinks in /boot, it links the new
kernel to vmlinuz and the previous one to vmlinuz.old, which removes the
need to alter your grub config.


-- 
Neil Bothwick

Ifyoucanreadthis,youspendtoomuchtimefiguringouttaglines.


pgpalAChjPAg8.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-22 Thread Tom H
On Fri, May 22, 2015 at 6:29 PM, Mick michaelkintz...@gmail.com wrote:
 On Friday 22 May 2015 23:13:06 Neil Bothwick wrote:
 On Fri, 22 May 2015 17:04:49 -0500, Dale wrote:

 I also save the config with the same version part as the kernel, that
 way I know which config goes with which kernel. Everyone has their own
 way of doing what works for them. I just prefer to copy my own manually
 with a name that makes sense to me. I don't think make install will do
 this the way I do it.

 make install does it exactly the way you are doing it, but faster and
 less prone to error.

 Hmm ... I may have used it the wrong way quite a few years ago, but it would
 only keep two kernels at a time or something like that. That made me carry on
 copying kernel files into boot manually. In this way at least I know where I
 put them and what options I pass on to them.

Two same-version kernels at a time? That's true because of
/sbin/installkernel.



Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-22 Thread Tom H
On Fri, May 22, 2015 at 6:58 PM, Neil Bothwick n...@digimed.co.uk wrote:
 On Fri, 22 May 2015 23:29:40 +0100, Mick wrote:

 make install does it exactly the way you are doing it, but faster and
 less prone to error.

 Hmm ... I may have used it the wrong way quite a few years ago, but it
 would only keep two kernels at a time or something like that. That
 made me carry on copying kernel files into boot manually. In this way
 at least I know where I put them and what options I pass on to them.

 make install installs the kernel it just made. It doesn't, and can't,
 touch other kernels. The only change it makes to /boot beyond copying
 three files there is to adjust the symlinks if they are already present.

 I've never understood the approach of trusting the makefile to configure
 your kernel, compile it, compile any number of modules and install all
 those modules, but when it comes to copying one file to /boot, that has
 to be done manually because the makefile can't be trusted to get things
 right.

/sbin/installkernel renames the already-installed vmlinuz and
System.map if it's installing the same version of the kernel.



Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-22 Thread Dale
Neil Bothwick wrote:
 On Fri, 22 May 2015 17:04:49 -0500, Dale wrote:

 I also save the config with the same version part as the kernel, that
 way I know which config goes with which kernel.  Everyone has their own
 way of doing what works for them.  I just prefer to copy my own manually
 with a name that makes sense to me.  I don't think make install will do
 this the way I do it.
 make install does it exactly the way you are doing it, but faster and
 less prone to error.




Funny, I've yet to screw up copying and naming a kernel.  Also, I get to
name it the way I want to name it not the way someone else wants to name
it.  I sort of doubt that make install will repeat the same naming
scheme I use.  Of course, I haven't tried it in a long time either.  It
wouldn't do what I wanted the last time I read about it so I never used
it.  I haven't seen any need to since I don't update my kernels that
often.  I'm going on two months since my last reboot. 

Dale

:-)  :-) 



Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-22 Thread Walter Dnes
On Fri, May 22, 2015 at 11:29:40PM +0100, Mick wrote
 On Friday 22 May 2015 23:13:06 Neil Bothwick wrote:
  
  make install does it exactly the way you are doing it, but faster and
  less prone to error.
 
 Hmm ... I may have used it the wrong way quite a few years ago, but
 it would only keep two kernels at a time or something like that.
 That made me carry on copying kernel files into boot manually.
 In this way at least I know where I put them and what options I pass
 on to them.

  I've automated that process.  I have 2 kernels, experimental and
production.  I use 2 scripts makeover and promote.  When I first
build a new kernel, I run the the makeover script, which does make and
overwrites the previous experimental kernel.  Note that this script
*MUST* be executed from the /usr/src/linux/ directory.

#!/bin/bash
make  \
make modules_install  \
cp  arch/x86_64/boot/bzImage /boot/kernel.experimental  \
cp System.map /boot/System.map.experimental  \
cp .config /boot/config.experimental  \
lilo

  When the experimental kernel has been running OK for a couple of
weeks, I promote it to production with the promote script...

#!/bin/bash
cp /boot/System.map.experimental /boot/System.map.production
cp /boot/config.experimental /boot/config.production
cp /boot/kernel.experimental /boot/kernel.production
lilo

  This hooks into my /etc/lilo.conf menu, shown here with comment lines
removed...

###
lba32

boot = /dev/sda
map = /boot/.map

install = /boot/boot-menu.b

menu-scheme=Wb
prompt
timeout=150
delay = 50

image = /boot/kernel.production
root = /dev/sda5
label = Production
read-only # read-only for checking
append = noexec=on net.ifnames=0

image = /boot/kernel.experimental
root = /dev/sda5
label = Experimental
read-only # read-only for checking
append = noexec=on net.ifnames=0
###

  This has saved me on occasion, allowing me to fall back to a working
production kernel when things go badly with experimental.  I then
run my demote script.

#!/bin/bash
cp /boot/System.map.production /boot/System.map.experimental
cp /boot/config.production /boot/config.experimental
cp /boot/kernel.production /boot/kernel.experimental
lilo

  I also have my kernels set up so that I can...

zcat /proc/config.gz  /usr/src/linux/.config

...to retrieve a known working .config file from the currently running
kernel.  This puts me back to square 1 with the experimental kernel.

-- 
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications



Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-22 Thread Dale
Neil Bothwick wrote:
 On Fri, 22 May 2015 12:21:15 -0500, Dale wrote:

 I didn't even know about make install until I read this thread, I
 always manually copied kernels over.

 I have always copied mine over manually too.  I keep quite a few spares
 laying around, just in case.

 Make install only copies the new kernel, it doesn't touch your existing
 ones. However, if you use symlinks in /boot, it links the new
 kernel to vmlinuz and the previous one to vmlinuz.old, which removes the
 need to alter your grub config.



I'm sure that works but I've been doing the way I do it because that
works for me.  This is what I end up with:

-rw-r--r-- 1 root root 5148896 Dec  6  2013 /boot/kernel-3.11.6-1
-rw-r--r-- 1 root root 5269728 Mar 23  2014 /boot/kernel-3.13.6-1
-rw-r--r-- 1 root root 5309456 Apr  6  2014 /boot/kernel-3.14.0-1
-rw-r--r-- 1 root root 5370192 Aug 10  2014 /boot/kernel-3.16.0-1
-rw-r--r-- 1 root root 5371280 Oct  6  2014 /boot/kernel-3.16.3-1
-rw-r--r-- 1 root root 5316576 Oct 25  2014 /boot/kernel-3.16.3-2
-rw-r--r-- 1 root root 5388960 May  1 00:53 /boot/kernel-3.18.12-1
-rw-r--r-- 1 root root 5387488 Feb  8 13:10 /boot/kernel-3.18.5-1
-rw-r--r-- 1 root root 5387680 Feb 27 18:03 /boot/kernel-3.18.7-1
-rw-r--r-- 1 root root 5387584 Mar 14 16:56 /boot/kernel-3.18.9-1
 

I also save the config with the same version part as the kernel, that
way I know which config goes with which kernel.  Everyone has their own
way of doing what works for them.  I just prefer to copy my own manually
with a name that makes sense to me.  I don't think make install will do
this the way I do it.

To each his own.

Dale

:-)  :-)



Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users

2015-05-22 Thread Mick
On Friday 22 May 2015 23:13:06 Neil Bothwick wrote:
 On Fri, 22 May 2015 17:04:49 -0500, Dale wrote:
  I also save the config with the same version part as the kernel, that
  way I know which config goes with which kernel.  Everyone has their own
  way of doing what works for them.  I just prefer to copy my own manually
  with a name that makes sense to me.  I don't think make install will do
  this the way I do it.
 
 make install does it exactly the way you are doing it, but faster and
 less prone to error.

Hmm ... I may have used it the wrong way quite a few years ago, but it would 
only keep two kernels at a time or something like that.  That made me carry on 
copying kernel files into boot manually.  In this way at least I know where I 
put them and what options I pass on to them.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.