The return of the son of the Big Clone Mess

[Don B. Cilly]

About a week ago I messed up my boot configuration. It was promptly (it only took two days :·) solved and allowed me to use my beloved Neon from the new SSD again.

It left sequels, but those were solved too.
I still have two minor issues though, which are not actual problems, in the sense that they don't (seem to) impair functionality, but they worry me.
They may or may not be related:

1) I had two cloned Neons, one on sda2 (the original) and one on sdb1 (the copy).
With the messed up fstabs, if I ran the one on sdb, and proceeded to mount sda - to get some things from it, it treated both partitions as the same one, showed sda2 as mounted, and well... not nice. That was solved.
But the thing is, I (repeatedly) installed and updated grub from the "new" neon.
I also removed the EFI partition on the "old" disk.
Now, the grub menu at boot should show my new neon as default, and add an entry for neon on sda2... right?
Wrong. It adds an entry for the one on sdb1 and if I boot the "default"... it's still the old one on sda.
So I'm slightly worried that if I eventually want to use sda2 for something else, my boot will turn into a shoe again.

Note: Of course, I could physically disconnect the old disk and "see what happens". But, this motherboard is really finicky, if I touch the SATAs it tends to die - I did try after cloning and it took me an hour of fiddling before it revived - so I'd rather avoid it.

2) in order to fix the sequels, we had to play with initramfs.
And I noticed that that updated a kernel called 4.18.0-22-generic. My running kernel is reported (by inxi) as 4.18.0-21.
Now, update-grub says:

Found linux image: /boot/vmlinuz-4.18.0-22-generic
Found initrd image: /boot/initrd.img-4.18.0-22-generic
Found linux image: /boot/vmlinuz-4.18.0-21-generic
Found initrd image: /boot/initrd.img-4.18.0-21-generic
Found linux image: /boot/vmlinuz-4.15.0-52-generic
Found initrd image: /boot/initrd.img-4.15.0-52-generic

The 4.18.0-22 entry is not present in the boot dir on the old partition. Only the new one. Must have updated a kernel in the meantime...
They smell to me as still being cloning mishaps.
Any suggestions on how to proceed to sniff (and snuff) them out?

[Don B. Cilly]

Oh, I don't know.
It seems that nobody on Earth actually understands grub.
I've asked elsewhere, investigated, tried and retried.

In the end, I changed MBR to gpt on all disks, re-created the EFI/ESP partition on sda, installed grub to sda, and, no change.
It still sets the wrong entry as default and boots an older kernel (two versions older now - in the sense that I have a newer newer one and it ignores that as well).

And sda is definitely failing, gparted gave more errors and I had to fix them.

The latest boot-repair report is here.

[Snowhog]

Personally, and please don't take this as a criticism or a bashing, but I think everything you are reporting here about your system is entirely due to the initial changes you did that messed things up in the first place, complicated by the attempts to fix the mess which further complicated things. IMO, you would be better served if you simply re-installed 'from scratch', formatting the drive completely. I'd use GParted (Live CD/USB) to prepare the HDD first. Just my opinion, and what I'd do if I were in your position and faced with what you are now dealing with.

[Don B. Cilly]

Oh, I agree. it is entirely due to the initial changes I did that messed things up in the first place, complicated by the attempts to fix the mess which further complicated things.
And entirely my fault. And thanks to you guys, I managed to turn some major problems into minor annoyances.

Now, if it can't be fixed it without re-installing from scratch, I will.
Which means backing up /home (it's on the same partition) but that's easy.
And re-installing all the packages, libraries and silly stuff, and that's more of a bother, but yes, I can do it.
So, I'll give it a few more tries - as both issues are not critical - and then... "redo from start".

[oshunluvr]

Piling on - blaming grub may not be accurate and clearly isn't the answer. Any time one does something non-standard to their system, one cannot expect all the tools to innately "know" what you've done nor for developers to predict every possible permutation that a user might get themselves into.

If I have to guess - and I do because I've never seen this and you haven't supplied much in the way of evidence - you got something cross-wired due to using clonezilla and other things. Either UUIDs or grub or fstab or a combination of all of them. If you add to that that you have a failing drive, IMO it's time for a clean slate. You'll spend less time starting over and doing to correctly than trying to fix what you don't know is broken - just my opinion. Good luck with whatever path you travel.

For the record, I use GRUB in a very non-standard and sort of complicated way, but I do that to avoid these sort of issues because I got tired of managing GRUB during multiple installs, re-installs, removals of installs, changing drives, etc. I've been using a stand-alone GRUB installation (not part of any particular install) for 7 or so years now and don't regret it.

[oshunluvr]

Oh, I agree. it is entirely due to the initial changes I did that messed things up in the first place, complicated by the attempts to fix the mess which further complicated things.
And entirely my fault. And thanks to you guys, I managed to turn some major problems into minor annoyances.

Now, if it can't be fixed it without re-installing from scratch, I will.
Which means backing up /home (it's on the same partition) but that's easy.
And re-installing all the packages, libraries and silly stuff, and that's more of a bother, but yes, I can do it.
So, I'll give it a few more tries - as both issues are not critical - and then... "redo from start".

If you really want to fix it, start by verifying all your fstab mounts and UUIDs. This would include going through your grub.cfg files and making sure they are correct also.

It seems like you might have a wonky grub installation that's reading from cross-attached locations. You might just pull the second drive and reboot to see what fails. Also, which install grub was last installed from is needed information. Boot to the main installation, unmount all extra partitions, re-install grub, run grub update, then examine grub.cfg.

[Don B. Cilly]

You might just pull the second drive and reboot to see what fails.

Er... what will fail will be the whole motherboard. It's really touchy... I tried that just after I made the big clone mess, it took me half an hour of fiddling the SATA cables. :·//
Or maybe it's because it's actually the first dive (sda)? Still, it is really touchy, that one.

Also, which install grub was last installed from is needed information.

I installed it from the currrent running Neon on sdb1. To sda, the last time, as installing it to sdb wasn't working.

Boot to the main installation, unmount all extra partitions, re-install grub, run grub update, then examine grub.cfg.

I have no other partitions mounted except the boot/efi one. Should I unmount that?
My grub.cfg is more than 800 lines long :·/
Now, of course, that boot-report I mentioned above is 5760 lines long, so I understand you (or anybody else) don't really want to see it.
Can I pastebin just the grub.cfg? If you know what to look at (I don't, really)...

[Don B. Cilly]

One thing I notice, though:
in my grub.cfg, the "default" menuentry has "set root='hd1,gpt1'", which is correct. It's sdb1.

If I press 'e' at the boot menu on the default one (which boots to sda) it has "set root='hd0,msdos1'.
Now, "msdos" does not appear anywhere in my grub.cfg. I converted all disks to gpt.
Also, my grub.cfg has the neon on sdb1 (correctly) as the default and a separate entry for a neon on sda2.

My grub boot menu has the reverse - with a "non-existent" msdos-type entry.
So, I install and update grub (to both sda and sdb) and what gets written is not my actual grub.cfg.

[Don B. Cilly]

So, you see, it looks likely that even if I do re-install neon, it won't make any difference.
As the alien clone ghost zombie- grub has taken over the world... well, mine anyway, and... maybe I could try moving to Tasmania... or something

[jlittle]

About the "set root" statements in grub. They're normally redundant and have no effect, as they're followed by "search" statements whose purpose is to set the root. I presume they're there as a fallback if the search fails. (The device names grub sees can change from boot to boot.) Maybe there's an optimization to search first at the current root, which would conceivably be significant if searching for a file.

But most of the time the search succeeds and the "set" is ignored.

[Don B. Cilly]

Yes, but the problem is not that.
It is that grub-install does not write the grub.cfg contents to the actual boot menu.
The entries there do not match my config file.

I even tried
apt-get install --reinstall grub-efi-amd64
and that doesn't work either.

[Don B. Cilly]

You know what?
I just installed rEFInd and ditched grub.
Everything is fine and I have 4.18.0-25 as kernel.

[oshunluvr]

Bravo!