[SOLVED] Boot repair for ESP doesn’t change my Root location

[Moderator BobC]

I have an EFI Windows dual boot system that was once booting from sda4. I now need to boot from sda6 instead, so I would like that to be my default.

At this point I need to clear and resize sda4 and sda5, and copy my sda6 to the new sda4 and change its UUID so that I can use it for testing the kernels in my latest attempt to get my bluetooth headset to work. I am afraid to do that if the system thinks sda4 controls the boot. Gparted is telling me that if I change those partition sizes I might not be able to boot.

When I run boot repair and select ESP and sda1 for location, and sda6 for root location, then apply, it says it was successful.

But if I go back in and look again, it wants to use MBR again, and thinks sda4 should be the root location.

Does anyone have any helpful ideas, comments or suggestions?

• This topic was modified 5 months, 3 weeks ago by BobC.

[Moderator caprea]

Helpful

Up

0

::

Maybe it’s helpful.Unfortunately I don’t really understand the whole complex situation. One reason is perhaps that I am not dual booting with windows here.(AFAIK gparted always gives this warning if you rezise or otherwise change used partitions)
But maybe a tip.It is very easy to let grub take control from another system on another partition.You only need to boot into the other system and then execute there

sudo grub-install /dev/sda

of course if the system where you booted in is located on sda,otherwise sdb or whatever.The partition should not be labeled.

[Moderator Brian Masinick]

Helpful

Up

0

::

I don’t know if this will be helpful or a confusing hindrance, but here’s what I do:

First, I almost always multiboot; in the past I’ve had as many as 12-13 distinct systems; these days it’s usually 4-5, but the ideas are the same:

1) I always have more than one system that has SOME form of booting, either from their own root partition, the MBR, or the EFI boot loader. Recent versions of antiX, after I’m actually logged into antiX, I go into the section where I can repair or alter the boot loader, and I do exactly that: I put the capability to manage the boot loader THREE different ways: boot from root, boot from MBR, AND boot from EFI; since the third method is the default or de-facto way I prefer it to work, I do that one last.

With several other distributions on my system, every once in a while, one of the other distributions will get frisky and want to take over the boot loader. It hasn’t proven to be a problem because to date, all of the distributions have been successful in recognizing one another, so I simply go through the other systems and update them, and when I’m done, I’ll select antiX from whatever boot loader has assumed control, and then I can change it by loading antiX into all three of the boot loader options mentioned above. This ensures that I can boot all of the systems and it’s worked every time.

Suppose one day it DOESN’T work? Got that covered too because I have many USB drives and I can install or reinstall if anything REALLY goes off the rails; since I’ve received the HP-14 I have not had any boot loader issues resulting in failure, but I have had instances where another system will attempt to assume control; fortunately they’ve otherwise behaved well; still, I have alternatives in the backup drives and also in other physical hardware in the event of hardware issues. Between backups, copies, and multiple approaches, this has worked for me personally for a couple of decades.

The most exasperating system for me was my Acer Aspire 5 A515-55. In terms of performance and features, it was faster and had things like backlit keyboard and I also liked the touch of the keyboard better than this HP-14; the problem was boot management. It was all over the place; their mechanism on that system was unusual to me compared to the many Dell and HP systems I’ve used, and even the Lenovo and Gateway systems before that.

What led to me dumping the Acer and getting the HP was that one day I reset the entire boot management scheme and it went back to ALMOST what it was in the beginning, EXCEPT that I had a password defined or redefined and I couldn’t locate either the default password or the one I set, and I also couldn’t figure out how to correct it; I may have eventually got it, but after hours of effort and multiple days trying things, I cut my losses and moved on; I just did a reinit on the whole thing and donated it to a local recycle place; they usually do their own refresh on equipment too; I didn’t think I left anything on it and certainly not anything terribly sensitive.

Anyway, extra USB removable drives with versions of software, if available, extra desktop or laptop systems, copies, backups, and multiple boot loaders, plus boot loader repair programs, all coupled together, lead to the ability to correct most accidents or physical problems.

That has held true over 20-25 years; I don’t beat on my systems too much, but at times I’ve deliberately tried to mess things up; this background has also been helpful in recognizing common issues and resolving them.

--
Brian Masinick

[Moderator BobC]

Helpful

Up

0

::

I installed efibootmgr and deleted the older items. I couldn’t really tell which is which, so I did it based on the date stamp of the file in the folder for each.

I think the boot repair must be defaulting to the first likely partition. Maybe that isn’t bad, just scary for me in this case.

[Moderator Brian Masinick]

Helpful

Up

0

::

If you have more than one system, or your one system has more than one bootable kernel, at startup time you can (of course) use your boot loader to select the appropriate system and kernel choice; since I multi-boot, I have to do this on every boot except when I want to boot the default.

--
Brian Masinick

[Author]

Posts