Any way to edit the pacman upgrades to exclude grub packages?

Relative newbie to the world of Arch . . . ran a pacman a few minutes back and it shows a large number of upgrades available . . . . In that list were a couple of grub packages that I would prefer to not run through, because I’m in a multi-boot situation and another OS is handling grub affairs . . . . I tried to check “add/remove software” to see if I could lock grub, but doesn’t seem to have that capacity???

Is there a way to edit the pacman list of packages to simply remove them from the proposed list? Or, what would the suggested commands be to lock or prevent “grub-2.12-3” and “update-grub-2.12-3” ???

Or, simplest method is to run the pacman through and then remove them via GUI???

Partial upgrades are not supported.

When multi-booting, Manjaro’s GRUB needs to be the one in control.

1 Like

Well, I could understand that Manjaro would wish to be in control, but as a relative latecomer into the mix, grub was not installed when I installed manjaro . . . and it has been fine all around.

You can in theory add grub to ignored pkg list in pacman.conf, but it is a bad, BAD idea. Note that the software package that update automatically, the first stage of the bootloader and the generation of boot menu work and update somewhat independantly, or at least is one updates the other 2 does not always update automatically.

If you configured your other linux properly, it would not matter. Otherwise, at some point it will become a mess. For me, the only sensible way too boot such a setup will be to have completely different grubs on the efi, and always boot with the UEFI menu. Or use something else than grub.

2 Likes

Well, that is the question, whether it has been “configured properly” on the other system, or just “configured” . . . ?? Since there aren’t a whole huge number of multi-booters out there it took me many years to figure out that just installing grub on one system was better than using it in every system, which would, change handling of grub based upon when, like today, a system would upgrade grub . . . .

This is running on a Mac, and that has added another “element” into the handling of efi/bootloader . . . and then grub itself also seems to have “issues” that transpond into the mix. But, things have been OK as of late . . . Manjaro is overall a very good system, but for now grub is handled elsewhere.

Seems like, easiest would be run the upgrades through and then remove grub from Manjaro . . . as it hasn’t been there for at least a year and it’s been “happy.”

If another OS is used to create GRUB menu user could either boot to the other OS and update GRUB after updating Manjaro, or use chroot to access other OS and update GRUB
Any changes to GRUB from Manjaro update will be overwritten when GRUB is updated on other OS
Uninstalling packages or ignoring updates is not worthwhile

Then user has a backup GRUB if other OS GRUB has any issues

Thanks for the followup . . . “ideally” that would be correct, that running grub-update on the other system would overwrite what was done in Manjaro . . . but, not always actually so when rubber meets the road . . . .

There is a guy on one of the forums who is very computer savy, always runs multi-boot, and also installs grub on each of his systems, and he “doesn’t care” who has control of bootloader . . . one grub system being the same as the next, etc. But, it does add complication, and some of choices have very basic B&W grub menu, and others have a nice GUI looking grub page . . . .

And, in the present iteration of my installs, I am not using “sda1” for my bootloader, because OSX occupies that one, so in these “retro-installs” of grub, historically the updater seems to select sda1 or the first partition . . . rather than, for less problems with OSX wanting to “be the controller of all that goes on in a Mac,” . . . I have linux grub in sda5 . . . .

I believe I have already removed grub from Manjaro one time, all seemed to survive in doing that, if I do that again and it blows up, I’ll post back and . . . whine about it, just for the kicks. : - )))

[Edit] Ran the upgrades through, then did try to remove the two packages via “Add/Remove” and it “failed to execute my commands,” . . . each of them had some dependency that needed those packages . . . . Always something that drops a hiccup into the mix . . . . [/Edit]

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.