update manager refuses to upgrade kernel to newer version

[Spyros Tsiolis]

Hi again Oliver,

--------------------------------------------
> On Sun, 14/2/16, Oliver Grawert <ogra at ubuntu.com> wrote:
> 
>  Subject: Re: update manager refuses to upgrade kernel to newer version
>  To: ubuntu-users at lists.ubuntu.com
>  Date: Sunday, 14 February, 2016, 22:51
>  
>  hi,
>  Am
>  Sonntag, den 14.02.2016, 20:05 +0000 schrieb Spyros
>  Tsiolis:
>  
>  > I think they
>  > are the *-46 kernel files , yes. I agree with you
>  > totally.
>  > What I
>  > can't stop my mind from thinking though, is why on
>  > one
>  > installation
>  >
>  > the kernels get updated and run the newest kernel version
>  > and on the
>  > other
>  >
>  > installation this no longer applies. . . . .
>  >  
>  if you say "one
>  installation" vs "other istallation" i assume
>  you refer
>  to the server vs the NFS root ?

There are two identical installations; One is running on top of the
hardware at one clients' site the other runs on top of VMware ESXi
on another clients' site.


PLEASE NOTE : I WAS WRONG ! Just checked today both installations.
Both of them run v3.13-46 if I recall the kernel versions correctly.
My mistake again. 
But to tell you the truth, now it makes sense. Since the initial systems
run off an NFS server and load the kernel to RAM and the Kernel
updates the system does (while it is running) is storing the newer kernel
versions under "/boot/" (again if recall correctly).
So the "vmlinuz" and "initrd.img" with the newer kernel version need to 
be created by hand.
 
 
>  the way you install an
>  ubuntu (or debian) system is pretty essential
>  for the initial configuration, so while you
>  likely used ubiquity or the

Sorry, could you mean "synaptic" instead of "ubiquity" ?

>  text based
>  installer for the server, how did you install the nfs
>  root,

NFS root is living on a totally different server running
Ubuntu server v12.04 at x86 instruction set.

>  this might explain different behavior
>  (i.e. if you use debootstrap to
>  create an
>  initial chroot that gets you a completely unconfigured
>  system
>  which will differ from what you get
>  using one of the installers that
>  apply a
>  debconf preseed by default ...)
 
>  and on a sidenote, as i mentioned before, you
>  should make sure that
>  /proc, /sys and /dev
>  are mounted when you are inside the chroot (and
>  also make sure to unmount these before (or even
>  after) leaving it). the
>  pre/postinst scripts
>  of packages often use info from these dirs to do
>  the pre/post configuration

The last part I pretty sure I havne't done it.

Here's the output of the "mount" command from a running
"thin-client" :

ip.add.re.ss:/var/tftpboot/ubu1204x86diskless on / type nfs (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /tmp type tmpfs (rw)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /var/tmp type tmpfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

 
>  for the PXE issue, i'd start with copying
>  the new vmlinuz and
>  initrd.img files into
>  the PXE dir, that should get you going with the
>  updated kernel ... once you have this fixed we
>  can move on and look at
>  the remaining
>  probs.
 
Yep, Tried it this morning. Couldn't find a machine with
ubuntu 12.04 x86 running on it, so I will have to do a virtual
installation on my MAC, then try to create the two files.


>  ...one thing at a
>  time ;)
>  
>  ciao
>     
>  oli

Best Regards,

spyros