Announcement

**vinnywright** · May 23, 2019, 04:05 PM

OK so Qqmike has some tuts around hear on this I think ,,,,, hears one on changing the boot order https://www.lifewire.com/change-the-...ootmgr-4028027 ,,,,,,,,O and hears some of Qqmikes stuff https://www.kubuntuforums.net/showth...-fixing-things

VINNY

**claydoh** · May 23, 2019, 04:26 PM

On my Lenovo Ideapad, I am doing the same thing, keeping windows an the HDD and have Neon on an added SSD. But I have not mucked about with other OSs, as why mess with things, lol. Actually, it is my main rig, so I don't really experiment on it. But.........Manjaro

?

jest kiddin'

I have Secure boot on, I think. Possibly. I think the only things I changed in bios is the efi boot order, the Fn key options, and disabling Intel RST. If you have not come across this yet, but on my Lenovo, i have to re-set the bios adjustments after every bios update - except for the boot order, as far as I recall. Every time it re-enables RST and switches the Fn key option.

On my laptop, I set the boot OS in the Bios, which of course is simple as I only have 2 ---- make that three, as I somehow have an Ubuntu entry, must have been a holdover from when I installed Noen when it was 16.04?-----. I imagine that OS's grub loads up, and you go from there. It technically should not matter if you have other, broken installs left over, I think. But I 'd want to lose the useless ones myself. I had EFI on my older Latitude that I did experiment with, but can't remember how I cleared it up, unless I just reformatted it. (No windows on that one)

efibootmgr will be your friend
you can change things without having to go to the bios

Code:

claydoh@claydoh-ideapad:~$ sudo efibootmgr BootOrder
[sudo] password for claydoh: 
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,0000,2001,2002,2003
Boot0000* ubuntu
Boot0001* neon
Boot0002* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
claydoh@claydoh-ideapad:~$ sudo efibootmgr BootCurrent
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,0000,2001,2002,2003
Boot0000* ubuntu
Boot0001* neon
Boot0002* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network

Why do I even have a DVD/CDROM option, lololol (yeah, USB drives, I know...)
I wanna remove the Ubuntu entry, but not sure if it is tied to the Neon one.

Code:

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,0000,2001,2002,2003
Boot0000* ubuntu        HD(1,GPT,5b7846f3-0672-42fd-8577-ea389c50746f,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0001* neon  HD(1,GPT,5b7846f3-0672-42fd-8577-ea389c50746f,0x800,0x100000)/File(\EFI\neon\shimx64.efi)
Boot0002* Windows Boot Manager  HD(1,GPT,8b8ce93a-22a2-440b-844f-8d2b2ce4736d,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...m................
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

Technically, I think you could set a EFI timeout set to a few seconds to show the system's EFI boot menu and choose the OS there.

**claydoh** · May 23, 2019, 04:54 PM

....and setting a timeout does nothing on my lappy, and the Ubuntu entry is the same as Neon's custom grub menu, so I think they may be linked.

Now to answer some Q's as asked by the OP

1) either in your Bios or via efibootmgr

2) irrelevant, as the grub loaded is the one from the OS chosen via EFI

3) efibootmgr, and maybe reinstall grub from the main OS to the drive (not the partition) just like an install. ie /dev/sdx, using the standard grub recovery steps from a live disk and using a chroot, if you can't boot to the chosen OS.

4) It won't, as the choice set in the EFI takes care of that.

grub is still the boot loader, but on EFI/GPT there is no MBR to be taken over if I am reading this correctly. ie the efi entry loads the grub/boot loader from the OS chosen, Windows boot loader is not replaced or chain loaded as it is/was on an MBR disk.

My EFI experimentation was a long time back now, on an older machine that supported both, so I may be rusty here.

**Qqmike** · May 23, 2019, 05:23 PM

Vinny's got the links posted.

I try to keep things as simple as possible! As one writer has said (about UEFI): Want more than one OS? Then get more computers.

On (4):

Dual-Booting with Kubuntu and GRUB2-EFI
The summary is simple: Upon installing a second OS, GRUB from the second OS takes over the booting. You can still boot into all your OSs. The only thing that changes is which GRUB installation is controlling the main, first booting. You can fix things the way you want. Three things to know: . . .

From:
https://www.kubuntuforums.net/showth...l=1#post379977

That Manjaro folder in /boot/efi? AFAIK, you can just delete that whole folder (if you are done with that OS). You can also delete boot entries in UEFI using efibootmgr, as Claydoh has said.

**jglen490** · May 23, 2019, 09:37 PM

So things change. When I did some research on UEFI and Linux a couple of years ago, the prevailing advice was turn Secure Boot off. Which I did and mine works just fine. But mine is only single boot machine, the presence of Secure Boot or not is very likely irrelevant. Kubuntu boots.

So there's this https://wiki.ubuntu.com/UEFI/SecureBoot which talks extensively about the details of Ubuntu and Secure Boot. It would seem the prevailing advice is now moving towards leaving Secure Boot on, because Canonical provides a security certificate that Secure Boot will use. The action takes place within /boot/efi which becomes the traffic cop especially when multiple OSes are involved.

I'm going to re-jigger my Kubuntu 18.04 desktop machine, probably this long weekend, as I have bolted in an SSD for the / partition, to take the place of the current spinner as OS drive. That is, right after I take multiple backups to each of my three external backup drives. And I'm going to turn Secure Boot back on ...

**jlittle** · May 24, 2019, 12:30 AM

The summary is simple: Upon installing a second OS, GRUB from the second OS takes over the booting.

This can be a nuisance, f.ex. if you are doing test installs. If the second OS's installer is ubiquity, one can run it with the -b switch which tells it not to install a boot loader. (Some subsequent upgrade actions will still screw up things.)

As well, Qqmike's guide suggests ensuring that each install uses a different directory in the ESP, by making a copy if necessary. (I just copy the .efi file to another name.) Then efibootmgr can reset things quickly, assuming you can get to it.

Running several installs that you keep updated, even fixing things with efibootmgr gets old, because the installs mess with the boot order somewhat unpredictably. A simple expedient is to comment out the line in /etc/fstab that mounts the ESP (or give it the noauto option, though I haven't tried that) in the installs that shouldn't touch the booting.*

If you don't follow that suggestion, and a subsequent install uses the same ESP directory as the install you want to keep control, it overwrites the .efi (if it installs a boot loader). If that happens, it's fixed by re-running grub-install back in the OS you want to be in control.

* There is a debconf setting that's supposed to fix this interference; you might have seen

Update NVRAM variables to automatically boot into Debian?
GRUB can configure your platform's NVRAM variables so that it boots into
Debian automatically when powered on. However, you may prefer to disable
this behavior and avoid changes to your boot configuration...

In debconf it sets

Code:

grub-efi-amd64	grub2/update_nvram	boolean	false

but I've found that it has been ignored in several circumstances. The web will told me to run "sudo dpkg-reconfigure grub-efi-amd64" in order to get the dialogue I've quoted, but it reruns update-grub and gives the message "Adding boot menu entry for EFI firmware configuration" which is exactly what I just told it not to do. One could use debconf-get-selections, grep, and debconf-set-selections to set it manually.

**Qqmike** · May 24, 2019, 06:14 AM

This can be a nuisance ...

Yeah, I agree. But, as you say,

If that happens, it's fixed by re-running grub-install back in the OS you want to be in control.

and that's what I have done. Lately, I'm simplifying greatly: I current run only one OS! I have run as many as 8 and using both labels and 3 separate ESPs. Gosh that's fun. And unnecessary and also a maintenance PITA. Face it: run more than one OS, and you must then maintain the booting, which generally is not difficult, just a PITA each time. My guidance, as you say, does suggest two tools to play with: Using "labels" and using more than one ESP. I've experimented with both, and there's some creative options one might glean. Also, there is rEFInd, Rod Smith's boot manager, which I have found to be great. Of course, upon installing something new, or getting an update to a GRUB, rEFInd will also get bumped down one position in the BootOrder, and so, again, you must reset it to be first (using efibootmgr).

**oshunluvr** · May 24, 2019, 02:26 PM

Thanks for the replies all, I just haven't had time to get back to it yet. I'll report when I do.

**deanr** · Jun 06, 2019, 10:58 PM

Just to add my experience - Manjaro doesn't really allow dual-booting of mulitple Linux distros. It's possible if it's the last of the installs I think but if you attempt to dual-boot something after Manjaro it'll screw up.

The people at Manjaro know this is the case and claim it's because their grub is superior - so why wouldn't you want to use their boot loader?

Have you tried MX Linux 18 on a USB? Their live image has a boot repair tool which apparently works well. Never tried it or seen it in action but that's the word around town.

**oshunluvr** · Jun 09, 2019, 01:27 PM

Originally posted by deanr View Post

Just to add my experience - Manjaro doesn't really allow dual-booting of mulitple Linux distros.

Odd , because I've been doing just that for more than a year on my desktop, and without using their (not really "theirs" as it's open source) boot loader. In fact, I have both Manjaro Free and Non-Free on my desktop. I was also multi-booting KDEneon and Kubuntu along with Manjaro non-free on this laptop from the Manjaro grub install without any problems until Manjaro froze during a kernel update (grub still works, but Manjaro is borked). I suspect the people that report they can't dual boot using Manjaro are simply not experienced enough to do it. I've had zero trouble doing so, possibly since I don't rely on a distro's "out-of-the-box" solutions to control my abilities to boot. My typical installation of a new distro does not include re-installing GRUB. There's just no reason to, and there's more than one way around it.
I appreciate the MX Linux suggestion (a new distro to my ear), but I prefer not to (ever) rely on a third-party tool like a boot repair. It simply isn't needed or wanted in my world. GRUB offers all the needed boot repair tools. My attitude usually is "if a can break it, I can fix it."

My issue here really revolves around a total lack of understanding EFI and how it works. "Works" being code for me breaking and learning to fix it. It figures now that I really have GRUB nailed down, they go an throw something new in there.

Hopefully, I will have time this week to dig back into it and fix the mess I've made.

**Nasty7** · Jun 09, 2019, 01:44 PM

Originally posted by oshunluvr View Post

I suspect the people that report they can't dual boot using Manjaro are simply not experienced enough to do it. I've had zero trouble doing so, possibly since I don't rely on a distro's "out-of-the-box" solutions to control my abilities to boot. My typical installation of a new distro does not include re-installing GRUB. There's just no reason to, and there's more than one way around it.

My issue here really revolves around a total lack of understanding EFI and how it works.

1. Maybe one day you will explain your technique to the rest of us LOL. I haven't really learned how to manipulate grub often. When I need to look for the info and usually end up asking for help. I usually just let the next distro take over and all is good. If I need to fix it or mbr I just to "boot-repair".

2. You and me both. I have read many Tutorials on how to dual boot with EFI but haven't done it yet as most my pc's are too old and don't use it. I feel so behind the times

**oshunluvr** · Jun 09, 2019, 02:07 PM

Originally posted by Nasty7 View Post

1. Maybe one day you will explain your technique to the rest of us LOL. I haven't really learned how to manipulate grub often. When I need to look for the info and usually end up asking for help. I usually just let the next distro take over and all is good. If I need to fix it or mbr I just to "boot-repair".

2. You and me both. I have read many Tutorials on how to dual boot with EFI but haven't done it yet as most my pc's are too old and don't use it. I feel so behind the times

LOL, right? EFI has been unnecessary for me until this laptop. I wanted to keep the factory Win install around for awhile so EFI became needed. As far as my mad-grub-skills (forever to be known as "MGS" from now on - ROFL!) I've posted extensively here for years about how I've done things with grub.

In a nut shell:

Install grub as a stand-alone (formerly in a partition, currently in a btrfs subvolume).
Use a manually created grub.cfg featuring nested grub menus.
At each new installation, install grub to the partition rather than the root of the drive (or to a secondary drive).
Edit the stand-alone grub menu to include the new install.

This has the effect of leaving the main bootable GRUB untouched while allowing each distro to have it's own grub. Kernel updates (and thus changes to grub.cfg) occur as normal. The main grub simply reads the grub.cfg from the selected install and never touches the "home" or main grub install. I even have a backup grub on a different drive that's also bootable in case of a drive failure. Removing or "breaking" any one install never stops my ability to boot.

The only downside to do this is grub packages aren't updated by any particular install. I supposed you could chroot into it and update it, but I never bother. I just re-create the grub install from a new distro every couple of years. GRUB isn't really all that critical to running a distro once you've booted so this has never created a problem.

To get started, simply install your fav distro to a partition or btrfs subvolume, delete everything other than /boot/grub/*, shrink the partition to recover free space (not necessary with btrfs), then edit grub.cfg to look like this:

Code:

[FONT=monospace][COLOR=#000000]### END /etc/grub.d/05_debian_theme ###[/COLOR]

[/FONT][FONT=monospace][COLOR=#000000]### BEGIN Custom menu ###[/COLOR]
menuentry 'KDE Neon 18.04' --class neon {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 60834933-1e99-4d5c-922c-9abbc373e172
    configfile /@KDEneon1804/boot/grub/grub.cfg
}
menuentry 'Kubuntu 18.04' --class kubuntu {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 60834933-1e99-4d5c-922c-9abbc373e172
    configfile /@Kubuntu_1804/boot/grub/grub.cfg
}[/FONT]

etc., etc. The "configfile" points to the grub.cfg in each install. Since I use btrfs and everything is on the same file system, you can see my UUIDs are all the same. Yours would be different if you use something other than btrfs. Youc an even boot directly to ISOs for installation purposes with:

Code:

[FONT=monospace][COLOR=#000000]menuentry 'Kubuntu 18.04 ISO' --class iso {[/COLOR]
    set isofile="/@grub/disco-desktop-amd64.iso"
    loopback loop (hd0,3)$isofile
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
    initrd (loop)/casper/initrd
}[/FONT]

I can install a new distro by copying the ISO to my grub subvolume, editing the ISO name to match the menuentry or edit the menuentry to match the ISO name, and reboot. No USB stick necessary.

If you use custom fonts or themes for grub, they would need to be moved the the grub location.

**Nasty7** · Jun 09, 2019, 02:56 PM

Very cool, I'll refer to this when needed but I warn you now, you will be the one helping me LOL

Did you eveR look at this, one of the better Tutorials from an official source.
Ubuntu UEFI

**claydoh** · Jun 09, 2019, 03:19 PM

https://www.happyassassin.net/2014/0...lly-work-then/

This is a bit long,. but the important bits are in the upper third ot fourth of the page
A summary I found helpful:
(emphasis added by moi)

Your UEFI firmware contains something very like what you think of as a boot menu.
You can query its configuration with efibootmgr -v, from any UEFI-native boot of a Linux OS, and also change its configuration with efibootmgr (see the man page for details).
This ‘boot menu’ can contain entries that say ‘boot this disk in BIOS compatibility mode’, ‘boot this disk in UEFI native mode via the fallback path’ (which will use the ‘look for BOOT(something).EFI’ method described above), or ‘boot the specific EFI format executable at this specific location (almost always on an EFI system partition)’.
The nice, clean design that the UEFI spec is trying to imply is that all operating systems should install a bootloader of their own to an EFI system partition, add entries to this ‘boot menu’ that point to themselves, and butt out from trying to take control of booting anything else.
Your firmware UI has free rein to represent this mechanism to you in whatever way it wants, and it may do this well, or it may do this poorly.

This is written so that even I can understand it

And the most important quote from it that helps me the most:
Even if you don’t grasp the details of this post, grasp this: it is completely different. Completely and utterly different from how BIOS booting works. You cannot apply any of your understanding of BIOS booting to native UEFI booting. You cannot make a little tweak to a system designed for the world of BIOS booting and apply it to native UEFI booting. You need to understand that it is a completely different world.

That bit I bolded in the summary reminds me of an important thing I think may still happens in *buntu: Installing any official Flavour uses the exact same files in the EFI partition, so instead of having a Kubuntu entry, an Ubuntu one, and a Lubuntu one, you may only have one folder for Ubuntu in the EFI partition, and thus only the one *buntu entry in the firmware boot loader. When it passes things to Grub, then you get its menu for all the OSs

When I had my Latitude, and was still multi-booting, I tried an experiment where I wanted to use the laptop's EFI boot menu to select which OS to boot, and skip a grub menu altogether. I could not do this, as any of the *buntu flavours I installed all used the exact same 'ubuntu' EFI folder, so the last one installed would overwrite that, and become the only *buntu in the firmware's EFI boot menu. Of course, the grub menu for that last *buntu would boot all the OSs installed, no problemo. Any non-Ubuntu OS naturally had their own folder in the EFI partition. I don't know if this is still the case nowadays. It sure confused the heck out of me, as I knew that there was no MBR to overwrite any longer, and I could not initially figure out what was going on, until I actually looked at the contents of the EFI partition, and saw that there were no separate folders for the Flavours I had installed, and the grub.cfg in it had the root partition set to the last *buntu I had installed.

Now, without going back and fully re-reading this thread, the Grub you get while booting is the grub from whichever OS is set as the first one in the bios EFI settings. Changing the order there to to the one you prefer gets you to the grub menu from that OS.

On my Neon and WIndows laptop, with no other OS ever installed on it, I have these in my EFi:

Code:

BOOT  neon  ubuntu

I believe that Neon users some of Ubuntu's stock setup, but modified, it seems to be sharing some bits of Ubuntu's, likely in order to have it's own unique EFi entry and customized menu, but without actually modifying Ubuntu's , and thus keeping them from having to maintain and support their own grub implementation.

I get Neon's themed grub menu no matter which of these two EFI boot entries I choose.

Code:

$ sudo ls /boot/efi/EFI/ubuntu
BOOTX64.CSV  [B]fw  fwupx64.efi  [/B]grub.cfg  grubx64.efi  mmx64.efi  shimx64.efi
$ sudo ls /boot/efi/EFI/neon
BOOTX64.CSV  grub.cfg  grubx64.efi  mmx64.efi  shimx64.efi

Announcement

Schooling needed with UEFI nightmare - What have I done?

Schooling needed with UEFI nightmare - What have I done?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment