update manager refuses to upgrade kernel to newer version

[Ralf Mardorf]

On Sun, 14 Feb 2016 13:40:31 +0100, Oliver Grawert wrote: 
>if /dev would be mounted and it doesnt work this would indeed be a bug

A link in German about a PXE nfs setup:

http://www.vdr-portal.de/board60-linux/board14-betriebssystem/board96-yavdr/99348-update-schl%C3%A4gt-fehl-grub-pc-error-bei-diskless-client-pxe/

The same issue, but related to a chroot and btrfs:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/591454

The Internet is full of descriptions of the same or similar issues.

And the link I already posted in my previous mails says:

"Mostly this is caused by some issues when running in a chroot. Before
switching to the chroot, it's necessary to mount at least the /dev
and /proc directories. However sometimes we've seen this issue even
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
with these mounts properly configured."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Sun, 14 Feb 2016 13:47:08 +0100, Oliver Grawert wrote:
>> This is REALLY weird; I have an identical installation running on top
>> of the hardware (no VMs /blades) and the system updates the kernel
>> successfully.  
>
>you did not show us the complete output log from such an upgrade, only
>the actual error message ... how exactly do you execute an upgrade of
>the chroot, many packages require /proc, /sys (and sometimes /dev/pts)
>to be mounted in their post-installation scripts, if you use the chroot
>command, did you make sure to mount these three before running the
>upgrade ?

How much identically is the "identical installation"? The above Ubuntu
bug report, as several different sources, mentions "replacing
the /dev/mapper symlinks with the device nodes".

The issue might just happen with some versions of grub, perhaps it was
fixed, but OTOH something that once was fixed could get broken again
(short blanket syndrome).

Regards,
Ralf