Grub mystery

[Don B. Cilly]

This is what blkid is reporting as of now:

/dev/sdb1: LABEL="SSD_Neon" UUID="[B]3331581b-e3a3-4976-86a3-bbfc025262be[/B]" TYPE="ext4" PARTUUID="6e09a355-01"
/dev/sdb2: LABEL="SSD2" UUID="5c3af4ec-b016-4eea-accd-23d517b87248" TYPE="ext4" PARTUUID="6e09a355-02"
/dev/sdb4: UUID="754B-22C4" TYPE="vfat" PARTUUID="6e09a355-04"
/dev/sdb5: UUID="bbb7dbfc-e767-43c9-8b99-614bbaab2cc5" TYPE="swap" PARTUUID="6e09a355-05"
/dev/sda1: LABEL="K14" UUID="4d8f0727-3f74-46ca-9b8f-bb6aa04ac6f8" TYPE="ext4" PARTUUID="000aef22-01"
/dev/sda2: LABEL="NEON" UUID="[B]879b2424-5b36-49b4-a53b-f51dbde63b30[/B]" TYPE="ext4" PARTUUID="000aef22-02"
/dev/sda3: UUID="d697a1d9-5452-4aba-bb15-0c3103238c71" TYPE="swap" PARTUUID="000aef22-03"
/dev/sda4: UUID="8EF0-A702" TYPE="vfat" PARTUUID="000aef22-04"
/dev/sdc1: LABEL="K18" UUID="3733e2b4-b159-434d-a4d2-ab4cb0cfa031" TYPE="ext4" PARTUUID="85e3aaee-01"
/dev/sdc2: LABEL="joey" UUID="13a64598-bbd5-489d-a193-4ebc1cad8072" TYPE="ext4" PARTUUID="85e3aaee-02"
/dev/sdc3: UUID="239B-2FC4" TYPE="vfat" PARTUUID="85e3aaee-03"
/dev/sdc4: LABEL="joey-gnome" UUID="66336795-cced-40b0-93aa-0845872860fc" TYPE="ext4" PARTUUID="85e3aaee-04"

I've highlighted the two partitions (old and new NEONs) that cause problems.
As you can see, I do use labels - well, except for the efi and swap partitions.
The UUIDs, they are unique. If they are messed up, I wouldn't know.
Manually editing the grub.cfg... as you can see I have quite a few OSs on the machine - and each of those comes with quite a few kernel sub-entries. So you can imagine...

Do you think it would be a good idea to delete all efi partitions and just keep one?
I mean if I lose it, I can restore it from a live medium, right?

[jlittle]

...
It still had the "HDD" one as default. It didn't change...

I'm not sure grub and the computer is doing exactly what you think it is. I've been quite confused on this sometimes.

Which is a bit funny, isn't it,.. the fact that before writing to sdb it reported sdb4 as /boot/efi and after, sda4?

There are no guarantees that the device names in Linux remain the same between boots. On some systems they change depending on what you've got plugged in (not just drives), and on others on timing. So the installers set things up using UUIDs, and grub uses them (by default) too.

I suggest:

• 
  Checking all the UUIDs of your drives and partitions using gparted. If they're not unique or messed up you can set new ones, though running update-grub would become necessary. This might clean up those partition header warnings.
• UUIDs are user unfriendly IMO; labels are much easier to remember and to use generally. Start by setting labels you like on each device and partition; even if you don't get the OS's and grub to use them dolphin will.
• Consider ditching the debian grub script machinery, and using a grub.cfg you edit manually. There's a learning curve, but the If your installs are dynamic, by which I mean some may come and go, you'll save a lot of time and effort and failed boots in the not very long run. With device and partition labels things become straightforward. (Keeping the debian grub stuff out of it needs a couple of tricks.) Some of us here have done this for many years.
• Consider using btrfs, using btrfs subvolumes rather than partitions for different installs. Free space is shared, and managing partitions only needed for OS's that don't support btrfs. This practice might allow you to have them all on the same SSD. As well as booting faster, installing can be faster too.
  
  (I can install a *buntu release in 7 minutes, from download complete to install complete, booting from the iso on the SSD.)

Sent from my VFD 822 using Tapatalk

[Don B. Cilly]

Addendum:
Now I remember, I tried writing grub to sdb not just as a redundancy measure, but because, well, it was booting the SSD, but not as the default entry.
It still had the "HDD" one as default. It didn't change.
Which is a bit funny, isn't it, if I install and update from the SDD version, shouldn't it set that as default?
And the fact that before writing to sdb it reported sdb4 as /boot/efi and after, sda4?

[Don B. Cilly]

The mystery deepens. The plot thickens. Global annoyance levels rise... ;·)
Mind you. The problem is solved. I have neon running on the SSD. And a good thing it is, because it boots a lot faster.

There are glitches though.
The SSD neon was all of two days outdated. The other day I mounted the old neon to recover some minor stuff that was not in the new one.
I start with a text file, copy it to my Documents (on the new one). Dolphin says, are you stupid or what, you're trying to copy a file onto itself.
So I think, is Dolphin stupid or what, I'm doing no such thing... then I notice that Conky reports the mounted partition as /dev/sda2. It should be (and was a moment before) /dev/sdb1.
Funny thing 2, the disk usage bar (reads sdb1) is empty. But the lua bar graph which also reads sdb1 is showing disk activity.
Nothing else untoward is apparent.

So I reboot. Back to normal. I re-mount sda2, back to impossible.
Reboot, and - even though I do remember the "Do not meddle in the affairs of wizards" quote - I play the dunce and install grub to sdb. Because, I say, if the older disk fails, I have an EFI on the SSD...
Nothing bad happens, except the efi partition used to show as sdb4, now it's sda4.
Oh well. Irrelevant... or is it.

The thing that slightly worries me is: if I decide to use that sda partition for something else, like trying out a distro, is it going to completely mess up all of my disk tables?
Because - also - grub-install tells me:

Installing for x86_64-efi platform.
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
Installation finished. [B]No error reported[/B].

Which seems a funny way of reporting no errors.
So, even though everything works (except mounting sda2 - I tried copying stuff from sdc and it was fine) I'm a little uneasy as to future developments.

[Don B. Cilly]

Nice. Thanks.

[Snowhog]

I hashtagged your first post. The option to create hashtags is in the editor, but you have to click on the Go Advanced button to see it. It's the # icon on the bottom row at the right.

[Don B. Cilly]

Bingo!
You da mon. You da wizard.
I could see it immediately, as I have xplanetFX as wallpaper, and it was morning. (it's 7PM here now).
And then conky shows sdb1 as / and sdb4 as /boot/efi.
I'll see if I can add some tags (in case someone has a similar problem) and mark it Solved.

[EDIT] Couldn't find a "tagging" tool, I just added them to the top of the first post, hope it's OK.

[claydoh]

So, I'll happily try all that, just... when you say
sudo mount /dev/sdb4 /mnt/boot/efi <<<<<<substitute the correct drive here if necessary
you mean the EFI partition on the SSD, right?

yes, that's correct

[Don B. Cilly]

OK. Because I tried re-installing grub to sda - after changing the sdb UUID.
It said:

Installing for x86_64-efi platform.
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
Installation finished. No error reported.

So, lots of errors but no errors. Oh Well. Anyway, it didn't work because it still boots the sda Neon (when I tell it to boot the other one).

So, I'll happily try all that, just... when you say
sudo mount /dev/sdb4 /mnt/boot/efi <<<<<<substitute the correct drive here if necessary
you mean the EFI partition on the SSD, right?

[claydoh]

We will need to know which partition is /EFI on the sdb drive

sudo mount /dev/sdb1 /mnt
sudo mount /dev/[B]sdb4[/B] /mnt/boot/efi <<<<<<substitute the correct drive here if necessary
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo cp /etc/resolv.conf /mnt/etc/
sudo chroot /mnt
apt-get install --reinstall grub-efi-amd64

Now, exit out of this, and run sudo update-grub on your running system.

Reboot and try booting to the new Neon via the computer's boot menu (not via the grub menu). If it does not show, you may have to go into the bios and turn off fast-boot, and look at the boot settings to see if it shows there.
There should be a grub menu, but do realize that this is the Grub for the SDB Neon. Each Linux will have its own grub.


Now boot normally, and see if the original, SDA Grub boots the new Neon.


Now, if things are working fine all around, and all Grubs are booting all the OSs you want them to, you are good to go.

Now, if SDB Neon is going to be your main OS, then you will want to make that disk the first boot disk, so if you decide to format the other drive for storage, or something, your normal OS is not touched.
if you decide to dual boot, just remember that each one has its own grub. If you install say, Arch, Neon's grub won't know about it until you manually update grub there.

[Qqmike]

Yep, I've always noticed such entries in the UEFI boot list. Like right now, though I have only one hard drive and one OS, efibootmgr included this strange entry:

Boot0008* Hard Drive    BBS(HD,,0x0)..GO..NO........O.W.D.C. .W.D.5.0.0.3.A.Z.E.X.-.0.0.M.K.2.A.0.................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.3.C.5.F.F.X.2.6.F.K........BO

I always ignore these things, instead focusing on what I do recognize and need.

[jlittle]

... this looks OK, except for the "hard Drive"...

Something adds a "Hard Drive" boot entry to the EFI boot list on my system. If I delete it with efibootmgr it reappears later, maybe after the next boot. I presume it's the UEFI on the motherboard, a Gigabyte. It's a nuisance because it shows several lines of junk with efibootmgr -v.

Sent from my VFD 822 using Tapatalk

[Don B. Cilly]

not@all:~$ efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0001
Boot0000* opensuse-secureboot   HD(3,MBR,0x85e3aaee,0x12c1a000,0x9ff800)/File(\EFI\opensuse\shim.efi)
Boot0001* Hard Drive    BBS(HD,,0x0)..GO..NO...o.C.T.5.0.0.M.X.5.0.0.S.S.D.1...A...>..Gd-.;.A..MQ..L.9.1.3.1.1.E.6.F.3.C.5.4. . . . . . . . ...BO..NO...u.W.D.C. .W.D.3.2.0.0.A.A.J.S.-.0.0.L.7.A.0...A...>..Gd-.;.A..MQ..L.

. . . .W. .-.D.C.W.V.A.J.2.9.2.7.2.9.4...BO..NO...o.W.D.C. .W.D.1.0.E.Z.E.X.-.2.2.M.F.C.A.0...A...>..Gd-.;.A..MQ..L. . . . .W.

.-.D.C.W.6.C.5.Y.N.X.J.V.F.A...BO
Boot0003* neon  HD(4,MBR,0xaef22,0x7369b000,0x6b800)/File(\EFI\neon\shimx64.efi)

Ugly, eh? ;·)
The opensuse entry is still there (somewhere in the EFI, but it's not in use as the opensuse system is not anywhere anymore.
The "hard drive" is the oldest of the tree drives and is seen "as that" by the BIOS.
Still, I think I have three EFI partitions, sda4, sdb4 and sdc3...

[claydoh]

Cool. The disk layout would be shown, mounted or not.
Only one efi partition, that's good.

Now, I messed up a little, I should have had you run the efi manager command with the -v option, to see more info

efibootmgr -v

Now:

not@all:~$ efibootmgr
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0001
Boot0000* opensuse-secureboot
Boot0001* Hard Drive 
Boot0003* neon

So far, this looks OK, except for the "hard Drive", the extra info requested will help figure that out.
Is the opensuse entry still still in use?


What the plan is, we will delete any useless entries, if any.
Then we will mount some directories from the 'missing' Neon in a chroot so we can run commands on them like it was a running OS. We'll then run some commands to rebuild the missing Neon boot stuff.


One thing we didn't check, as this is a uefi system is to see if the missing Neon could be booted from your computer's built in efi boot selection menu. I doubt it would, without seeing more info. Grub only comes into play *after* the bios/efi loads the boot info from the /EFI partition and loads info from its nvram. So , it is often possible to boot an OS even if another OS's grub doesn't know about it.

[Don B. Cilly]

dh -f basically returns "huh?" so, assuming you meant:

not@all:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           795M  1.4M  793M   1% /run
/dev/sda2       178G   39G  131G  23% /
tmpfs           3.9G   48M  3.9G   2% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/loop1       89M   89M     0 100% /snap/core/6964
/dev/loop0      128K  128K     0 100% /snap/cnctsun/58
/dev/loop2       54M   54M     0 100% /snap/core18/970
/dev/loop4       36M   36M     0 100% /snap/gtk-common-themes/1198
/dev/loop5      457M  457M     0 100% /snap/wine-platform/128
/dev/loop7       90M   90M     0 100% /snap/core/6818
/dev/loop6       74M   74M     0 100% /snap/wine-platform-3-stable/6
/dev/loop8      128K  128K     0 100% /snap/cnctsun/59
/dev/loop3      217M  217M     0 100% /snap/wine-platform-runtime/6
/dev/sda4       212M  6.0M  206M   3% /boot/efi
tmpfs           795M   12K  795M   1% /run/user/1000
/dev/sdb1       252G   39G  201G  16% /media/not/SSD_Neon

(yes, I mounted /dev/sdb1 to check things, usually it's not).
and

not@all:~$ efibootmgr
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0001
Boot0000* opensuse-secureboot
Boot0001* Hard Drive 
Boot0003* neon