Okay. CZ did not work “device to device.” So I used GParted to copy the working EFI from external SSD to internal FAT Partition and it worked.
But how do we get the BIOS to recognize it? I rebooted and went back into BIOS to choose boot device and all entries have been removed except USB and the ext SSD.
If I go back into live MX session from USB and choose Boot Rescue, will one of those options scan the internal drive to find that newly created EFI on it? I am going to see what I can try from there.
Oh, I thought CZ was your backup.
If you have a backup copy on external disk, yes, of course, use that.
There is nothing magic about it… it is just a partition with a filesystem on it… copy it any way you feel comfortable with.
You could make a new ESP partition, say 700Mb, then put a fat32 filesystem on it, and copy the backup filesystem with cp -rp onto it.
I do have CZ backups. And I could use any of them to only restore parts. I was just trying to use the complete image of both the new EFI & MX partitions that I just copied to the ext SSD last night. That has all of my recent changes in getting Garuda onto the MX grub.
The problem I thought of with that though is that I made that 500 gb copy of the internal MX partition onto a larger partition on the other drive. So now I am having to use my ext HDD to make another CZ image of that before shrinking the new MX partition down to match the one originally used so that I can copy it back onto the internal drive. Can’t copy a 900 gb part onto a 500 gb part.
I can also then make a partition for Garuda and put it on the ext SSD as well. Then I can just use CZ to make the entire SSD image and lay it on the internal drive. BUT, without installing, I am unsure how BIOS gets the info that these OS’s exist. Is that taken care of in Clonezilla? Even with the change in UUIDs?
I have to work today, so will be later when I have a chance to test these things out. Obviously, I can always use CZ to put everything back the way it was before making the changes to EFI and symlinks to get Garuda onto the MX grub, but I wanted to first try to find a way I can avoid having to redo all that work.
It would definitely not be easier. I have a lot of apps/games that would have to be reinstalled/set up, bluetooth devices, etc.
As I told @nevj, before reinstalling, I would just use Clonezilla to lay my most recent disk image back on the disk and then go about the work of modifying EFI and using symlinks to have Garuda OS appear on the MX Linux grub menu.
I do not easily admit defeat I will get everything back at least as close to present by using my CZ image from earleir in Oct if needed. I do have Timeshift copies as well, but not sure that is going to help with the other issues outside of getting MX install back on internal drive.
Yes @callpaul.eu I do. I like confronting a technical challenge, working through the steps to resolve and coming out on the other side the “victor” LOL. I have all the pieces to accomplish what I set out to do in this thread, and have succeeded along the way in getting Garuda (a btrfs OS) into the MX grub menu. So now it is just a matter of analyzing all of the pieces and deciding which strategy to employ to put the puzzle together as it should be.
I am blessed to have multiple working computers so it is not a big deal to have this one not booting both OS’s as I intend for them to, and I can take the time needed to resolve this issue.
Sorry, @nevj and I use CloneZilla a lot so we abbreviated the name to CZ. It is what we use to make the images of our entire drives where we can restore the entire drive or just parts (partitions) of it as needed.
So I wanted to update my current order of operations in getting all of this working. I have been too busy at work this week to start on it till now.
Using Gparted:
Ext HDD - shrunk NTFS partition and gave the extra 1.5 TB space to the ext4 partition
Created 2 new ext4 partitions on this drive:
1st new part (P3) to use for CZ image of the current laptop internal M.2 drive (that no longer has MX on it-empty partition now)
2nd new part (P4) to use for CZ image of the ext SSD drive (has the working MX OS and EFI that incorporates Garuda in its grub menu).
Now that backups are done:
Remove the internal drive partition that has the original Garuda OS on it (I had already copied Garuda to the next partition to the right that was larger)
Use that unallocated space to grow the original MX partition (to the left) so it is large enough to place the MX copy from ext SSD back onto it.
THEN comes the hard part (I think) and that is getting fstab edited with new UUIDs and updating grub so that my internal drive will boot to MX grub menu that has Garuda on it.
It is taking quite some time to shrink the ext HDD partition from 2.62 TB to 1.25 TB with gparted.
I will update once the above steps are completed as I am sure I will need assistance in modifying the fstab.
I waffled back and forth on using CZ or Gparted as the restore solution for internal/external drives involved, as I was not sure if using GParted to copy/move partitions would have the same effect as using CZ.
My main question now is: since current BIOS does not show any Linux to boot to, only USB flash drive and my ext SSD with MX on it, how does BIOS find the installed OS once everything is laid back onto the internal drive?
An install of an OS always updates BIOS with that install. But does simply putting the OS/EFI partitions back on the internal drive update BIOS after reboot?
I will try that first and see. I was actually just reading about “UEFI Bootloader” last night and was a bit confused as to what that was. Someone was trying to sell the idea that “grub” was not necessary. Most responded with disagreement. But it made me think about my mini PC that had an unusal menu besides BIOS and if that was UEFI Bootloader.
If not, at least I can chroot into live MX session and install grub.
Thanks for that, I kept thinking that BIOS cannot just find bootable partitions laid on the drive without some method (besides install) of adding them.
You will have to isolate MX and chroot is the only way I know of, that much I have learned from playing with Linux From Scratch. Just a copy of MX from one drive to a partition, means nothing, unless the update-grub command is issued in chroot. and I would think this would set /etc/default/grub to GRUB_DEFAULT=0???
Now that everything has been resolved on the internal drive, I used the MX live session to find the blkid’s of each partition. I do not understand how these IDs are assigned, but I left both EFIs on the drive (MX & Garuda’s original EFI) and each of those have the UUID=XXXX-XXXX.
But the MX and Garuda partitions have a long alpha/numeric UUID. Do I need to chroot into my MX boot partition and run update-grub FIRST? I am not sure how those get shortened to 8 digit UUIDs.
I had planned on fixing fstab first, then updating grub. But have never done this before, so need to ensure the correct order of steps while rooted into my OS.
Okay. So I used “chroot” and looked at fstab, then ran os-prober. It found the internal SSD partitions with both MX and Garuda as well as the EFIs.
Then I ran update-grub. From there I used the live MX session to scan for grub menus and it found mine and I booted into it. Of course, it is still not in the BIOS. So now that I am in my own OS, I am going to install grub and see if that resolves the BIOS boot I had before.
I will get everything back at least as close to present by using my CZ image from earleir in Oct if needed. I do have Timeshift copies as well, but not sure that is going to help with the other issues outside of getting MX install back on internal drive.