[SOLVED] GRUB woes -- can't alter boot menu?

[chconnor]

Hi!

sda1 is a windows install
sda2 is my main linux install

I have several other disks on the machine. I recently did an additional 20.04 install on sdc1 (for occasional development). All works fine, I can boot to main linux, development linux, or windows just fine.

The problem is the GRUB menu now puts the new development linux install at the top of the list, and boots it as the default.

I tried update-grub from the main linux install: no change. I tried editing /etc/default/grub to set GRUB_DEFAULT to an entry besides the first line: no change. I tried that from both the development linux install and the main one; didn't make a difference.

What is the magic trick to actually affecting the grub menu?

I haven't confirmed yet whether the boot options from the main linux install are actually propagating to the grub menu -- will do that next. [edit: yes, they are; presumably they'd be wiped if I did update-grub from the development linux again.]

Thanks for any tips,
-c

[chconnor]

I also noticed that boot screen, that is, the black screen that appears while the machine has just gone past GRUB, now has a blinking cursor in the top left, whereas before it was all black, IIRC. Not sure if this is a clue of anything.

[Don B. Cilly]

Probably the simplestt solution would be:
Edit /etc/default/grub
Change GRUB_DEFAULT=0 (or whatever you have there) to:
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
then update grub.

This will make grub boot (as default choice) the last OS you used.

[Schwarzer Kater]

The thing with multiple Linux installations is: the last one you installed normally also did install the grub that is used now and has set itself as default (top of the list in grub boot menu).

You can either do as Mr. Cilly said and edit /etc/default/grub (in the Linux you installed last and now boots as default) and sudo update-grub afterwards or, e.g. if you don't want to touch /etc/default/grub at all:

• boot the Linux you want to be your default (and you want to handle grub)
• sudo update-grub (especially if you did edit this Linux's /etc/default/grub now)
• sudo grub-install /dev/[PATH TO YOUR BOOT-DRIVE, NOT PARTITION, LIKE "sda"]

Any changes to /etc/default/grub only work, if you do them in the Linux that boots as default (or as the case may be, the first one of the list in grub boot menu, if you have changed certain things in this Linux's /etc/default/grub before) or if you reinstall grub from the Linux you have booted to the boot drive afterwards.

I think it is a good idea for everyday use to do as Mr. Cilly said, of course.

[oshunluvr]

Both answers above are correct. IMO the second response - re-installing GRUB from your primary OS - is the superior choice for these reasons:

1. Last I checked, changing grub default to "saved" does not work if you're using BTRFS as your file system.
2. The continuous rotating default boot choice can be irritating unless you will always remember which install you booted to last.
3. Re-installing GRUB from your primary install will help insure you don't accidentally leave your system unbootable by deleting the one that GRUB was installed from. If you decided to delete your Development install, you would have to either know to re-install GRUB from another install first or you'd be doing GRUB recovery.

This illustrates one of the default behaviors and a minor pitfall to the way GRUB is installed by Kubuntu. The installer does not by default offer you the option to NOT install GRUB even from the "Manual" partitioning setup. You have to know to boot choose "Try Kubuntu" then launch the installer (ubiquity) with the "--no-bootloader" option. This is a bug IMO.

One thing you can easily do is, when installing a second Kubuntu or other OS, is install GRUB to a partition instead of the boot drive. Then after rebooting, simply running update-grub on your main install will detect the second installation and add it to the GRUB menu (usually).

[oshunluvr]

Also, since you apparently have three drives, an excellent method to insure you remain bootable is to:

• Set your BIOS to boot your primary Linux drive (sdb based on your description)
• Leave the Windows boot loader on sda
  
• On every subsequent Linux install, select sdc for GRUB

Then you will have three bootable drives, all relying on a different OS install and all you have to do in the event of a problem is to change the boot order in BIOS and reboot.

[chconnor]

Thank you all for the tips. grub-install was the missing piece for me -- didn't realize that the installed grub was not agnostic to where it came from. I figured since both linuxes were 20.04 and the grub version was identical, I could update-grub from either.

oshunlovr -- so you're saying that by totally separating the OS's across drives, you have fully independent disks that can be booted on their own without grub being involved, should it come to that? I like that idea. (When I finally get dragged to windows 10 maybe I'll make that happen.) In that scenario, booting to the sdb (in your example) would still get to a grub screen that would allow me to choose which OS to boot, right, since os-prober would have found all the OS's? (Meaning, BIOS wouldn't be the only way to choose which drive to boot, it's just there as a backup method...)

Agreed that the default installer's choice to install grub without asking is a bad idea -- I was surprised when it happened. It used to ask at the end if you wanted to do that, didn't it?

[oshunluvr]

Agreed that the default installer's choice to install grub without asking is a bad idea -- I was surprised when it happened. It used to ask at the end if you wanted to do that, didn't it?

The old installer did ask that question. IDK when it disappeared, but it's been a while, like years.

Thank you all for the tips. grub-install was the missing piece for me -- didn't realize that the installed grub was not agnostic to where it came from. I figured since both linuxes were 20.04 and the grub version was identical, I could update-grub from either.

Running grub-install "tells" the boot loader where to look for GRUB files. So whichever OS did the last grub-install "owns" the ability to boot. A manual run of grub-install pointing it to whichever GRUB you want will change that.

oshunlovr -- so you're saying that by totally separating the OS's across drives, you have fully independent disks that can be booted on their own without grub being involved, should it come to that? I like that idea. (When I finally get dragged to windows 10 maybe I'll make that happen.) In that scenario, booting to the sdb (in your example) would still get to a grub screen that would allow me to choose which OS to boot, right, since os-prober would have found all the OS's? (Meaning, BIOS wouldn't be the only way to choose which drive to boot, it's just there as a backup method...)

Actually, you wouldn't matter which drive the OS's are on at all, just use different OS's to install GRUB to SDB and SDC. GRUB or some boot manager is always required to begin the boot process so you have to have some boot loader. What I'm suggesting is Let Windows boot SDA, Install GRUB on SDB from your main Kubuntu, then install GRUB on SDC from your Development Kubuntu. Then you have three bootable disks, each requiring their own install. Both installations of GRUB would be able to boot any of the other OS's. I believe Windows can be made to to that also, but not my area of knowledge.

[Qqmike]

@chconnor, I'm guessing you are using a PC that boots by UEFI? (Most PCs after about 2011 do so.) Let me drop this link to my how-to's on UEFI booting which covers many idea on dual-booting using your ESP(s). No one mentioned using efibootmgr. Maybe you do not have UEFI ...

UEFI, GPT, ESP, GRUB2-EFI, (dual)-booting, fixing things

https://www.kubuntuforums.net/showth...-fixing-things

(btw, I agree with oshunluvr, "IMO the second response - re-installing GRUB from your primary OS - is the superior choice ...")

[chconnor]

Thanks Qqmike -- I don't honestly know anymore. I have had all kinds of intractable bugs from UEFI vs non-UEFI... I have to boot flash drives non-UEFI when installing the OS. But I've also had e.g. network cards not work when booting non-UEFI, etc.

I tried setting up GPT partitions once and my sense memory of that experience is very negative, but I can't now remember why. :-) My mobo is a little flakey, I think; I've had some issues now and then.

I believe I've seen your helpful post -- I will give it a read and consider it for next time.

To be honest, it's kind of unbelievable how complicated the booting stuff is. I would never have predicted it if coming to the problem naively. Feels heavily over-engineered, but I admit ignorance.

And yeah, I have fixed my issue by grub-install via the main linux partition.

Thanks!

[jlittle]

Feels heavily over-engineered, but I admit ignorance.

I agree (but make the same admission).

I cut down the engineering by avoiding all the scripting machinery that's behind update-grub, and maintain my own much simplified grub.cfg by hand (well, it started simple). I've set up grub in its own subvolume (before btrfs I had a separate small partition). The hardest part has been stopping the grub scripts from messing it up.

[Qqmike]

chconnor: Feels heavily over-engineered, but I admit ignorance.

We must all suffer from that same ignorant feeling! Your perceptions are not off base.

With the old original GRUB 0.97 whatever, it was fairly simple, at least the basic rules were simple. But it had limitations. It was fun, though, and anyone could play. We all learned tricks to make complicated things happen. It was a boom for how-to writers like myself, Herman at Big Pond, et. al. Your GRUB config file might look sort of disorganized and difficult to read.

Then came GRUB 2. Definitely an improvement, you could boot iso's with loopbacks and such. BUT, it wasn't so much fun! How-to writers fell by the way side. Everything was turned over to scripts. You really need to understand scripts and be a script writer to play, or know how to copy others' scripts. (Having been a programmer of Pascal, LISP, Fortran IV, Basic, etc. doesn't count on the capability statement--you need Linux scripts.) But, with GRUB 2, you could say that everything is automated by the scripts -- BUT your ability to customize is more complicated; you can often do it, but you have to then manually maintain your custom setup, like dedicated GRUB partitions and such. The GRUB config file now looks "cleaner"--each bootable thing having its own menuentry stanza, neatly organized, and "automated."

Now with GPT and UEFI, it's all different, again. I'll make a statement that at least half the members will disagree with: With GRUB-EFI (UEFI ), things CAN BE simple! Thanks to the GPT setup and the ESP machinery. Everything is right there in your ESP. Extreme customizations are a different matter, again. My how-to's attempt to show you various ways to do almost anything and keep things as simple as possible. You are still having to "maintain," but what you are maintaining is all located in your ESP[s]. The real complicating factor now is the motherboard maker--HOW they CHOSE to set up their firmware and implement the UEFI standard, and that can be a game-changer. I use ASUS boards, and ASUS is an industry leader in providing really nice, easy, clean, approachable, user-friendly UEFI implementation. IMO, the ESP is a clean way to handle the GRUB config-ing, with pointers (set in a simple top-level grub.cfg file) to wherever it needs to go.

As you go from GRUB Legacy to GRUB 2 to GRUB-EFI/ESP, your ability to get a conceptual handle on your booting setup increases, at least that's how I see it.

It does seem like there's a lot of over-engineering with Linux booting. You just have to get your preferred point of view on it all, ignore the rest of it, and then simplify your own system as much as possible. Fact is, with UEFI, you can dual boot very simply by accepting the default setup in your one, single ESP, and don't mess with it. Learn just the one trick of booting into your preferred OS to issue grub-install and update-grub, and leave it be like that. And learn to use the UEFI command efibootmgr so you can communicate with your UEFI firmware, if and as needed.

[chconnor]

Good perspectives, thanks.

I will say that the middle period seemed like the worst (late GRUB, early GRUB2, perhaps?)... seemed like every time I installed anything I'd fall in to GRUB hell and spend two days dealing with things not seeing other things, burning rescue CDs, dorking around in the grub shell, trying to understand chainloading, following outdated how-to's, etc. That boot-repair utility helped a lot later on, and now it seems like things truly are pretty easy to deal with (e.g. my current problem, which was pretty trivial to fix), if a little less flexible for the non-expert. So I don't mean to complain too much. :-)