How to keep Updater from reinstalling GRUB2?

[YesNoMaybe]

Hi,

recently I'm getting completely bugged off by Kubuntu up to the point of wanting to uninstall it. I hope somebody here can help me, please.

First, I'm experiencing this bug where Discover just hangs when I click on "Update", but won't let me close it nor let me shut down the system because there are tasks to do. To make things worse, it's not showing any progress bar, no status bar, or anything else which would let me guess what it's doing, or if it's doing anything at all. There isn't even any easy way to find out which program is actually running (Discover), so as a Kubuntu newbie I had to waste lots of time on this.

On top of the program window it says something like "80 Updates" and on the bottom it says "Installing 63 updates". When I repeatedly click on this "Installing 63 Updates", it goes from blue color to orange color and back, without letting me know what the colors mean. Regardless of color, the program does not install anything and just hangs. My user friendliness rating for the whole program on a scale from 1 to 10 is a clear zero.

Every time I have finally done the update manually, I need to close Discover with a kill -9.

Now as a new "feature", the Kubuntu update system seems to dislike my multi-boot installation and reinstalls GRUB2, without even asking me!!

How can I make the damn Kubuntu Updater stop touching my GRUB2 installation, never ever??


Many thanks for reading this rant!

[v7peer]

I never use discover for updating, only for notifying me that there are updates available.

Then I just do in the terminla:

sudo apt update && sudo apt full-upgrade

[jglen490]

I think a little research would have yielded the same info, as in the replies above.

But, I get it. So sometimes Discover works well for some things, but not others. No excuses, just reality.

When Discover pops a notice that updates are available, ignore it. The simplest solution for dealing with any update notice is the command line, as v7peer showed in the reply above. The next proper solution is to use a GUI such as Synaptic or Muon, to collect the updates and then apply them. The only use I've ever seen for Discover is using it as a "store front" when you know the kind of software you want but don't have a specific, named product in mind. Maybe someday, the devs will fix Discover, but it isn't ready right now.

[chimak111]

Now as a new "feature", the Kubuntu update system seems to dislike my multi-boot installation and reinstalls GRUB2, without even asking me!!

How can I make the damn Kubuntu Updater stop touching my GRUB2 installation, never ever??

There isn't anything, AFAIK, to avoid that. Kubuntu Updater, damned or not, has nothing to do with it.

/var/log/dpkg.log:     2018-11-23 06:30:23 status installed grub-common:amd64 2.02-2ubuntu8.9
/var/log/dpkg.log.1:   2018-10-26 07:26:01 status installed grub-common:amd64 2.02-2ubuntu8.7
/var/log/dpkg.log.1:   2018-10-11 18:52:52 status installed grub-common:amd64 2.02-2ubuntu8.6
/var/log/dpkg.log.2.gz:2018-09-06 07:26:29 status installed grub-common:amd64 2.02-2ubuntu8.4
/var/log/dpkg.log.3.gz:2018-08-23 16:08:15 status installed grub-common:amd64 2.02-2ubuntu8.3
/var/log/dpkg.log.4.gz:2018-07-24 08:00:50 status installed grub-common:amd64 2.02-2ubuntu8.2
/var/log/dpkg.log.4.gz:2018-07-12 15:44:00 status installed grub-common:amd64 2.02-2ubuntu8.1
/var/log/dpkg.log.6.gz:2018-04-26 18:24:09 status installed grub-common:amd64 2.02-2ubuntu8

[YesNoMaybe]

I think a little research would have yielded the same info, as in the replies above.

I've been doing exactly that for quite a while, now:

Every time I have finally done the update manually, I need to close Discover with a kill -9.

Meaning to say, I've been using sudo apt update && sudo apt full-upgrade manually. Nevertheless, even then my GRUB2 install is gone, every time after doing so.

There isn't anything, AFAIK, to avoid that. Kubuntu Updater, damned or not, has nothing to do with it.

/var/log/dpkg.log:     2018-11-23 06:30:23 status installed grub-common:amd64 2.02-2ubuntu8.9
/var/log/dpkg.log.1:   2018-10-26 07:26:01 status installed grub-common:amd64 2.02-2ubuntu8.7
/var/log/dpkg.log.1:   2018-10-11 18:52:52 status installed grub-common:amd64 2.02-2ubuntu8.6
/var/log/dpkg.log.2.gz:2018-09-06 07:26:29 status installed grub-common:amd64 2.02-2ubuntu8.4
/var/log/dpkg.log.3.gz:2018-08-23 16:08:15 status installed grub-common:amd64 2.02-2ubuntu8.3
/var/log/dpkg.log.4.gz:2018-07-24 08:00:50 status installed grub-common:amd64 2.02-2ubuntu8.2
/var/log/dpkg.log.4.gz:2018-07-12 15:44:00 status installed grub-common:amd64 2.02-2ubuntu8.1
/var/log/dpkg.log.6.gz:2018-04-26 18:24:09 status installed grub-common:amd64 2.02-2ubuntu8

Where does it come from, then? What would be the best solution, except for using another distribution?

[jglen490]

You have a multi-boot system. Is your PC UEFI? If so, where is the /boot/EFI partition?

In a konsole, enter

lsblk -af

Then post the output in a CODE box.

[claydoh]

Why do you not want to get bug/security fixes for grub? Is there a problem with updates?




Any ubuntu based distro is going to see this, as will many Debian ones, as most of these patches to grub come from there.
http://changelogs.ubuntu.com/changel...u8.9/changelog

Fedora seems to have a similar update pace

I can't tell what OpenSuse does with theirs

Arch//etc may see more updates or not, not sure if they patch (unlikely) or only do official releases from GNU.

[jlittle]

How can I make the damn Kubuntu Updater stop touching my GRUB2 installation, never ever??

(I've shared your frustration, several times.)
That depends on whether the computer boots using UEFI, or the legacy BIOS.

With UEFI, a simple method is to not mount the EFI partition at boot time, except maybe in the install you want to control grub. But also, copying the ubuntu directory, to, say, "mine", then using efibootmgr to have "mine" first in the boot order puts you in control, too. (Debian debconf has a setting called grub2/update_nvram which is meant to avoid this trouble if set to false, but if a new version of grub2 arrives, it gets ignored; found that the hard way. Maybe that'll be fixed one day...). If "secure boot" is enabled, IIUC needed for new Windows installs, it might be different.

With a BIOS multiple booting, the standard way to achieve this was to "install" grub to the partition rather than the device at install time. F.ex., to /dev/sda1 instead of /dev/sda. After install time, which would be usually be the case with multiple boots, I can't remember, sorry, other than using a separate small partition just for grub, and maintaining that manually. I settled on that approach long ago, maybe Kubuntu Hardy, and left grub problems behind.

[jglen490]

Well, I guess we won't know until YesNoMaybe replies with requested info ...

[YesNoMaybe]

You have a multi-boot system. Is your PC UEFI?

No, it's not UEFI unfortunately.

Why do you not want to get bug/security fixes for grub? Is there a problem with updates?

Bug/Security fixes for grub are fine, but I have more than one linux running, and I am used to maintenancing my grub installation from one of them ("master"), not from all of them. Actually I'd expect Kubuntu to download and install the fixes, but not to reinstall grub.

If that is really necessary, I'd like to be asked before doing it, since Kubuntu cannot possibly know if it's master or not. In fact, I've never had this problem before going from Kubuntu 16.something to 18.04.

With a BIOS multiple booting, the standard way to achieve this was to "install" grub to the partition rather than the device at install time. F.ex., to /dev/sda1 instead of /dev/sda.

That sounds like a great idea, I will check where Kubuntu installs grub into and try that, many thanks, also to everyone else!

[wartnose]

Hi,
...

First, I'm experiencing this bug where Discover just hangs when I click on "Update", but won't let me close it nor let me shut down the system because there are tasks to do. To make things worse, it's not showing any progress bar, no status bar, or anything else which would let me guess what it's doing, or if it's doing anything at all. There isn't even any easy way to find out which program is actually running (Discover), so as a Kubuntu newbie I had to waste lots of time on this.

...
Many thanks for reading this rant!

This has been addressed in several threads. Someone smarter than me suggested waiting for the "updates selected" to go from 0 MiB to however many MiBs there are to be updated BEFORE clicking "Update All". This works for me. If that doesn't for you someone else suggested Ctrl + Alt + Esc that gives you a little Skull and crossbones you can move to the X and kill the window. I'd be careful with that one. Might kill your session if you click in the wrong place. Been there. Done that. Using the Konsole works but I keep having to refer back to my cheat sheet to remember the alt-get vs alt commands. I probably need a tutorial on the difference.

[claydoh]

Where is it showing that grub is being reinstalled?
Grub needs to be reconfigured after a new kernel is installed/removed, settings have been changed in the configs, and the like, but not reinstalled.

I will admit I may be confused or missing something, but I don't see where this is happening. I am not even sure a package can be reinstalled without user interaction, no matter what method is used.

If this is the usual grub re-configuration, well that will happen with every distro that uses grub, and efi or bios does not have anything to do with it.

It is odd, I will admit that grub is seeing quite a few updates in a short period of time. This does not seem to be the norm, so perhaps it is a transient issue, and once they have fixed the things needed to be fixed, updates settle back down to a slower pace. Comparing the changelog for 18.04 's dates, is well as to other Ubuntu releases, the update rate is definitely very high at the moment.

[YesNoMaybe]

This has been addressed in several threads. Someone smarter than me suggested waiting for the "updates selected" to go from 0 MiB to however many MiBs there are to be updated BEFORE clicking "Update All". This works for me. If that doesn't for you someone else suggested Ctrl + Alt + Esc that gives you a little Skull and crossbones you can move to the X and kill the window. I'd be careful with that one. Might kill your session if you click in the wrong place. Been there. Done that. Using the Konsole works but I keep having to refer back to my cheat sheet to remember the alt-get vs alt commands. I probably need a tutorial on the difference.

I also noticed that waiting seems to make things better than worse. However, this time it was clearly showing the complete amount of disk space about to be updated, yet it still got stuck. The skull and crossbones is new to me, but I'm guessing it's one of the kill commands, e.g. kill -15 (send a SIGTERM = "clean up first and then terminate" signal), or a kill -9 (send a SIGKILL = "terminate immediately").

Where is it showing that grub is being reinstalled?
Grub needs to be reconfigured after a new kernel is installed/removed, settings have been changed in the configs, and the like, but not reinstalled.

I will admit I may be confused or missing something, but I don't see where this is happening. I am not even sure a package can be reinstalled without user interaction, no matter what method is used.

Well, I'm not sure what exactly it is doing, but fact is that it's destroying my own, highly customized grub installation. My own one has a background image, different font and font colors, own names for each OS to boot, more boot options, a graphical timer etc., whereas the one which I get after every Kubuntu update is just the plain, black and white standard os_prober version. Somehow this reminds me of Microsoft behavior: Kill everything foreign or that you don't know what it is, and make sure you're the only one around, no matter if you destroy all customization, data and whatever else the user owns. This is one of the reasons why I find it so annoying.

I would think that it's a complete reinstall though, because in order to fix it, I need to boot into my master linux system, and reinstall grub from there. That's without needing to reconfigure it of course, since luckily the configuration on the master system stands untouched (it's not Microsoft after all!).

The point seems to be that the update mechanism doesn't consider the possibility that the current OS might not be the grub configuration OS.

[claydoh]

Do you have grub for all your secondary installs placed on the MBR, or installed to the partition it resides on?
https://help.ubuntu.com/community/Ma...ll_of_your_OSs
Also, I don't think you even need more than one grub installed, you can install a *bunbtu without grub by booting to a live session, and running ubiquity -b,
rEFIND may also be a useful option
https://askubuntu.com/questions/7050...f-all-the-oses

[vinnywright]

Well, I'm not sure what exactly it is doing, but fact is that it's destroying my own, highly customized grub installation. My own one has a background image, different font and font colors, own names for each OS to boot, more boot options, a graphical timer etc., whereas the one which I get after every Kubuntu update is just the plain, black and white standard os_prober version. Somehow this reminds me of Microsoft behavior: Kill everything foreign or that you don't know what it is, and make sure you're the only one around, no matter if you destroy all customization, data and whatever else the user owns. This is one of the reasons why I find it so annoying.

I would think that it's a complete reinstall though, because in order to fix it, I need to boot into my master linux system, and reinstall grub from there. That's without needing to reconfigure it of course, since luckily the configuration on the master system stands untouched (it's not Microsoft after all!).

The point seems to be that the update mechanism doesn't consider the possibility that the current OS might not be the grub configuration OS.

this dose seem strange to me .

I to have a highly customized main grub install and like you it has it's own background and custom entry's , the system that controls it is 1 of 6 systems on this box .

the main grub is in the MBR of /dev/sda and the 4 systems that use their own grub have grub installed to the partition they reside on , for the 2 that do not have grub installed thay get booted with custom entry's in the main grub .

none of them have ever been changed by a grub update except 2 of the partition installed ones that were running stock (no customizing) and that was just their stock theme changing ?

VINNY