update manager refuses to upgrade kernel to newer version

[Ralf Mardorf]

On Sun, 14 Feb 2016 01:26:40 +0100, Oliver Grawert wrote:
>hi,
>Am Samstag, den 13.02.2016, 23:59 +0100 schrieb Ralf Mardorf:
>
>> 1. I'm not using a bootloader package:
>> 
>> [root at moonstudio weremouse]# dpkg -l grub-pc | grep ii
>> ii  grub-pc        2015:09-06-moonstudio all          Dummy package  
>
>any reason why you use a dummy package ? grub-pc is at best a
>recommends which will not get re-installed once you removed it manually
>(unless you make the mistake to manually install the most bottom layer
>linux-image package by hand (which you should not do if you want
>functioning upgrades), then you would need to use --no-install
>-recommends to prevent it from coming back)

I already explained it, even in this thread, but you are focused on
incomplete sentences.

>> 2. Even if I would use a bootloader package, then I wouldn't  
>experience
>> the bug, since I wouldn't use grub in such an environment as the OP
>> does.  
>
>well, you claim it is a bug that grub cant work if it does not know
>about attached hardware due to missing /dev when the probe and search
>tool runs. how would grub install to its target device without any info
>about the existing hardware ? 

Even this was explained. The GRUB2 bootloader works, what doesn't work
is the fine auto-config-thingy and while it claims /dev isn't
mounted, /dev actually is (could be) mounted.

>> 3. I expect that somebody maintaining GRUB2 or making GRUB2 a
>> dependency for a kernel package is aware about well known issues.
>>   
>see 1) ... it is no dependency, it is a recommends that you can remove
>at any time.

And it could come back any time a user needs to install something
including recommended dependencies and including a kernel image package,
so making it a suggested dependency or much better, no dependency at
all would be the better approach. Inexperienced users who really need
a bootloader anyway would get it, when they install Ubuntu, so later
when they upgrade a kernel or install another kernel, the bootloader
already is installed.

However, for most inexperienced users GRUB doesn't cause issues when
upgrading a kernel image, but the Ubuntu "novice installer mode" seems
to recommend to use a separated /boot partition and makes this partition
seemingly too small since a long time ago. Ubuntu devs are aware of
this issue. My point is, that maintaining such automated things is much
more work, than to explain users to set up things by manually editing,
e.g. a bootloader config or selecting sizes of partitions and to chose
if there is any need at all, to split an install into several
partitions.

Overdone user-friendliness often comes with the expense of
intransparency and less choice and makes users dependent to out of the
box provided solutions, but any solution could fail.

Too much automation asks to fail on different fronts. For maintainers
it's hard to keep up with upgrades, to ensure that the automation will
work for most, let alone all use cases. For users self-reliance and
knowledge gets lost.

That's all behind calling auto-thingies "crappy", the context of my
complete claims. Less is more. It provides more choice and it's easier
to maintain for developers and easier to use for users.

Regards,
Ralf