[SOLVED] Serious boot mess

[Don B. Cilly]

Following up from here.
I got a little impatient and totally "cilly" and turned a minor annoyance into a serious problem.

I tried removing the sda efi partition and re-re-re-installing grub on sdb as I thought it might... er... solve the glitches.
Instead, I now cannot boot any Neon. I mean, I can boot the entries, but they crash. I'm back to Kubuntu 18, on sdc.
Any help would be much appreciated.

[Qqmike]

I didn't really follow the other thread on a detailed level, only conceptually, and I know nothing about Neon. Just this comment: Are you trying to use another ESP, and not use the ESP on sda1? Are you trying to use more than one ESP?

In general, the ESP has a boot flag on it -- the ESP is a FAT32 partition, usually sda1 (but can be any partition), the size is usually 100 MB-500MB (but can be anything), and in GParted (or other partition manager), you set the boot flag on the ESP. If you do NOT want an ESP to be seen/recognized (permanently or temporarily), you can simply use your partition manager (GParted) to turn off the boot flag on it (permanently or just temporarily).

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

Seems like you just need to establish an ESP partition and then re-install GRUB to it?

[Don B. Cilly]

My Neon is basically Kubuntu 18.04 with faster-updating repositories (and Plasma 5.16 because it's the "unstable· edition). So treat it as Cosmic.
I had three esp/efi partitions: sda4, sdb4, and sdc3.
sda4 was used to boot Neon, even though it was on sdb1 and I repeatedly tried to tell it to use the sdb one.
I removed the sda1 and installed grub to sdb.
Now I have to boot Kubuntu which is on sdc1 and shows sdc3 as /boot/efi.
As you can see from the post referenced above, I get "GUID Partition Table Header signature is wrong:" warnings when installing grub. To sda, sdb and sdc.
Probably due to the fact that I had to change the UUID of sdb because cloningthe partition cloned the UUID as well.

[claydoh]

Did you ever set the Neon drive to be the first one in your bios boot order, as I suggested? Have you tried selecting different drives in your computer's built-in boot menu (NOT grub)?

[Don B. Cilly]

I (think) I did.
I mean, the BIOS gave me three choices: neon, "opensuse secure boot", and the SSD drive ID.
Now, after re-installing grub from the Kubuntu, it gives me ubuntu as well.
Whether I select neon or ubuntu in the bios as boot, it won't boot to either neon.
If I select hard disk or opensuse, I don't get a grub menu at all (well, opensuse is not there - I'd like to get rid of that entry too, btw).

I'm not sure what "my computer's built-in boot menu (NOT grub)" is... not the BIOS either?

efibootmgr:

BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0002,0000,0001
Boot0000* opensuse-secureboot
Boot0001* Hard Drive 
Boot0002* neon
Boot0003* ubuntu

[Don B. Cilly]

Just for additional info on drives and distros:
This is what update-grub says (on Kubuntu 18 on sdc):

Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.0-20-generic
Found initrd image: /boot/initrd.img-4.18.0-20-generic
Found linux image: /boot/vmlinuz-4.18.0-18-generic
Found initrd image: /boot/initrd.img-4.18.0-18-generic
Found linux image: /boot/vmlinuz-4.18.0-17-generic
Found initrd image: /boot/initrd.img-4.18.0-17-generic
Found Ubuntu 14.04.6 LTS (14.04) on /dev/sda1
Found KDE neon Unstable Edition (18.04) on /dev/sda2
Found KDE neon Unstable Edition (18.04) on /dev/sdb1
Found Ubuntu 13.04 (13.04) on /dev/sdc2
Found Ubuntu 10.04.4 LTS (10.04) on /dev/sdc4
Adding boot menu entry for EFI firmware configuration
done

[Don B. Cilly]

Update:
I installed boot-repair. It said "I have repaired your boot". (sounds like Mister Minit ;·) The pastebin is here.
What it did, it added a lot of "EFI" entries to grub, none of which seems to boot anything, just allows me do do some "key management" before returning to grub.

If I try to boot neon, it hangs a while "searching for Btrfs", then proceeds to "Start job is running for dev-disk-by\longhexstring", takes a while, then "Times out waiting for device dev-disk-by\longhexstring", then panics and puts me into maintenance mode.

Just for the record, while it was "repairing", the disk section of conky looked like this:

[Qqmike]

Again, I won't address the general issue or the NEON - btrfs - etc. issues, but just to show an example of what I said above, looking at what you said here:

I had three esp/efi partitions: sda4, sdb4, and sdc3.
sda4 was used to boot Neon, even though it was on sdb1

My point exemplified: So, let's say you want to install Neon to sdb1 (or say you want to re-install GRUB in Neon while booted into Neon on sdb1). BEFORE you do any of that (install Neon or re-install its GRUB), if you want NEON to use the ESP sda4, you must do this:
Use, say, GParted to remove the boot flags on the other two ESPs sdb4 and sdc3.
Make sure the boot flag is on the ESP sda4.
So, one ESP is on, the other two are off.
Now go ahead and do your work--install Neon to sdb1 or re-install Neon's GRUB while booted into Neon on sdb1).
After that is done, go into GParted again and turn on the boot flags to the other two ESPs sdb4 and sdc3.
Done:
Your PC's UEFI firmware will now know to use the ESP sda4 for the NEON on sdb1.

[Don B. Cilly]

Well, I can't boot into either neon.
I've removed sda4 altogether. I could remove sdc3, or the flags for it, but...
... I'd rather not (if possible) re-install neon and start from scratch.
Even If I did that, I'm afraid the problem is the UUIDs of both sda and sdb. I changed the sdb one because clonezilla cloned it, and... boom.

I believe if I could fix just that, everything else would fix itself.
I have looked and searched, But I can't seem to find a solution.
If I have to re-install neon from scratch, well, I will, I was just hoping I didn't have to.

[EDIT] Mind you, I have a backup of /home (which is big because it has virtual machines in it) but to re-install all the libraries, python modules, and silly stuff in general...

[jlittle]

If you clone a drive or a partition, you must immediately give one of the clones a new UUID. I had to learn that the hard way; much confusion and breakage can follow otherwise. I imagine an OS might use both clones some of the time, and mess up both.

If you change the UUID on a partition you want to boot from, and the boot uses UUIDs, you have to edit the /etc/fstab in that boot, and any grub entry used for that boot, because they both have the UUID. The grub entry can be edited while booting by pressing "e" on the grub menu entry, but that doesn't stick.

(Since you have to make these edits, changing UUID= to LABEL= is easier IMO.)

[jlittle]

A couple of other points that are my opinions.

• The idea of seeing the boot loader as part of the OS, and so separate ESPs for each install is attractive, particularly from a resilience perspective. But boot loaders (especially grub as set up in debian, and the Windows one) and EFI partitions don't see it like that. Each instance thinks it owns the machine, and fights to centralize control. Having at most one ESP per device, and one grub avoids struggles.
• Keeping a log of every package installed, and every significant configuration change, is something I learned to do the hard way. If I forget, my logs of shell sessions are a backstop (if I use the command line).

[Don B. Cilly]

But I did change the UUID. See here. Not immediately though.
Now, I really wonder why clonezilla doesn't do it to start with, or at least warn you about it. Considering the real problems it causes...

But then. You say:

If you change the UUID on a partition you want to boot from, and the boot uses UUIDs, you have to edit the /etc/fstab in that boot, and any grub entry used for that boot

Now, the grub entries seem to have changed.
But. I checked the fstab on the partition. It still has a non-existent (the one I removed) as boot/efi.
So why did re-installing grub (to that disk) nor realise it... Ok, I changed it to a "proper" one. I'll try and see if it works and report back.

[Don B. Cilly]

Bingow. It was the fstab.
I am now using neon.
Thanks.