Moving/Copying EFI partition to end of disk

Sheila_Flanagan · October 25, 2024, 9:00pm

I have recently seen I am running out of space on my MX Linux partition. On this 1 TB disk I have
P1 EFI-SYSTEM 256 MiB
P2 MX Linux 311.53 GiB
P3 EFI-SYSTEM2 512 MiB (this is the larger EFI needed for Garuda OS)
P4 Unused 150.41 GiB
P5 Garuda OS 151.22 GiB
P6 Unused (ext4) 280.84 GiB

I iwanted to see if I could make a new partition at the end of the disk (512 MiB) and move/copy the EFI 2 parition to it as it is in between my MX install and the unused 150 GB partition I want to append to MX.

What is the best way in GParted to do this?

Thanks,
Sheila

UPDATE:

So I used Gparted to copy the Garuda EFI partition to a new partition at the end of the disk. Then I deleted that EFI partition for Garuda. Of course, now I need to point Garuda to that new EFI in order to boot into it.

Previously, Garuda controlled grub. But I rebooted and now MX-Linux boots from its original EFI (first partition on disk). I was also able to grow the MX partition to 526 GB so that I now have plenty of space there.

So I guess I need to know the commands for changing the EFI partition # (UUID?) in order to make Garuda boot again?

I have looked at a few forums, but most of them are either discussing Windows dual boot (and how both OS share an EFI) which is not my case or they are talking about having to chroot and mount the EFI from a live session.

I was thinking there is surely a boot file that points to the EFI and that I can edit that file to point to the new location.

Thanks,
Sheila

nevj · October 25, 2024, 11:05pm

Hi Sheila,
I think you can mount the EFI partition in /etc/fstab. Mount it to the mount point /boot/efi.
If it is already there in /etc/fstab just change the UUID.
You can get a list of UUID’s with blkid command. You may need to install blkid.

but
That is not the whole story…
To get garuda in control of grub you need to go into garuda and do
grub-install --efi-directory=/boot/efi
and the EFI partition needs to be mounted on /boot/efi when you do it.
So, if it is not moubted by /etc/fstab , mount it temporarily with a mount command before you do the grub-install.
then
Before you leave Garuda, do
update-grub

and
I am concerned that you have two EFI partitions on one disk
After you get the problem sorted , I would be looking into whether you could merge the contents of the smaller partition into the larger one, and then discard the smaller partition.

https://www.gnu.org/software/grub/manual/grub/html_node/Installing-GRUB-using-grub_002dinstall.html

Regards
Neville

nevj · October 25, 2024, 11:13pm

That is tricky.
It is the grub-install command that , apart from putting a copy of grub in the EFI partition, also puts a little entry in the BIOS telling it where the EFI partition is, so it can find grub.

Sheila_Flanagan · October 25, 2024, 11:13pm

I don’t need Garuda in control of grub. It was only because I installed it after MX that I let that be. But at install, it required a bigger EFI than MX Linux did, so I had it create a new one. And that, of course, put it right there after my MX install and followed it with the Garuda partition. I still have another unused partition after Garuda, but do not need it yet.

But I don’t see how I could 'merge" the 2 EFIs. I thought you could only copy/paste or move partitions in Gparted, anyway. Is it possible to install grub for MX Linux into the larger Garuda EFI?

Sheila_Flanagan · October 25, 2024, 11:26pm

Most of the conversations I found on getting Garuda back to booting involved using chroot from a live session.
https://forum.garudalinux.org/t/how-to-chroot-garuda-linux/4004

I guess I thought there had to be an easier way as you said by changing the UUID in /etc/fstab. But if there are two EFIs, one for Garuda and one for MX, I’m not seeing how that would work. One OS has to be the controlling grub, right? and If I use a live Garuda session, it would then be in control again.

Control is not a real issue for me as long as I can get MX Linux from whichever grub, as it is my daily driver. I only installed Garuda as an intro to Arch. In fact, I found Endeavour to be pretty user friendly Arch distro.

Point is, I could always reinstall Garuda, but the issue remains it requires a bigger EFI than my current MX EFI, which sits at the front of the disk as 1st partition. I can’t enlarge that as MX follows.

Not sure of the best solution, as I don’t see anyway to enlarge that 1st EFI with the current partition order.

Thanks,
Sheila

nevj · October 25, 2024, 11:40pm

You can… you have to move partitions with gparted.
Dont try to move MX while you are in it… used a gparted usb drive so everything is unmounted.

What you have works , but is messy.
I think I would be having MX in control of grub because it is more stable.

I think those conversations are not mult-boot oriented.
You should be able to get garuda to boot by having MX controlling grub, and having os-prober find garuda when you do update-grub in MX.
Then on reboot you should get a grub menu showing both MX and garuda.

Sheila_Flanagan · October 25, 2024, 11:54pm

So then it doesn’t matter about the other EFI, as we are not using it as grub, right? Means, I could get rid of it once Garuda boots from MX Grub.

But then I would still have that Garuda EFI partition between Garuda and the empty large partition at the end of the drive. So would I need to copy the MX partition to another one, then delete the old MX partition in order to leave some of the first part before it (that I can later use to enlarge the MX EFI), and then move the MX partition back?

I don’t think that would work unless I get rid of Garuda since it is between MX and the last unused 280 GB partition. Plus, I think that MX is too big to copy to that unused one, so the only fix is to delete all partitions except the first two, create a big enough one to copy MX over to, then use a small part of the current MX partition to add to the EFI. From there, I would then move MX back to 2nd partition and add what I need from that last partition.

I always like to have partitions to test out other distros as that works better than a VM to really see how it works on the hardware.

I’ll see what I can do.

Thanks,
Sheila

nevj · October 26, 2024, 12:08am

Not sure.
I think there might be stuff in that larger EFI that helps garuda to boot… maybe not… I dont know

So as a strategy how about this

move partitions and make first EFI larger
copy contents of second EFI into the first… just use cp. Dont overwriite anything. There may be duplicated files.
boot MX and do grub install --efi..... to make sure MX is in control, again with the first EFI mounted, then do update-grub
on reboot your grub menu should contain MX and Garuda
if all looks OK, delete the second EFI partition… maybe copy it to usb first for safety
test booting again after delete

Think about is first. It is a big reshuffle. You need a backup before start.

Afterthought:
Maybe you could test if os-prober can find garuda first.
Go into MX and type os-prober
What does it find?

Second afterthought:
If garuda has the second EFI partition mounted in /etc/fstab, you will, of course, have to change it to mount the first EFI partition , before you delete the second.

nevj · October 26, 2024, 12:50am

@Sheila_Flanagan
Did you catch the afterthoughts on precious reply?
Sorry, it is complicated, I keep thinking of possible traps.

callpaul.eu · October 26, 2024, 4:43am

Would it be easier to buy a new disk ?
Either to run along side existing one or replace with bigger than 1 tb ?

So system disk and data disk. Ok if its a laptop no space in box but a replacement may fit.

So set up new disk with areas for each system then copy to that disk the data files

Just an idea

Sheila_Flanagan · October 26, 2024, 10:00am

That was my first thought: why not test os-prober before doing anything else? I did and it did not find Garuda. It paused and then went back to a prompt. Then I ran update-grub and it only found MX.

Second:
I cannot boot into Garuda from BIOS (there used to be an entry for it) nor disk as it is no longer found. So this is all to be done once I get it booted. I do not see a way to do it from a live session other than to do the fix in /etc/fstab and how would I do that on the installed system from live session?

I do not even know how to do it from MX. It’s one thing to see the files on the other partitions from MX, but modify them?

I cannot say for sure what I am looking at in live session:
Devices:
/
root (this is Garuda install?)
rootMX23
280.3 GiB internal drive (partition5)
GARUDA_DR460IONIZEDGAMING_BIRDOFPREY (live session?)

So I looked at Garuda fstab from MX session:

<file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=E857-3ED4                            /boot/efi      vfat    defaults,umask=0077 0 2
UUID=406d8c92-eb3f-4642-8532-fe14c97261cd /              btrfs   subvol=/@,defaults,noatime,compress=zstd 0 0
UUID=406d8c92-eb3f-4642-8532-fe14c97261cd /home          btrfs   subvol=/@home,defaults,noatime,compress=zstd 0 0
UUID=406d8c92-eb3f-4642-8532-fe14c97261cd /root          btrfs   subvol=/@root,defaults,noatime,compress=zstd 0 0
UUID=406d8c92-eb3f-4642-8532-fe14c97261cd /srv           btrfs   subvol=/@srv,defaults,noatime,compress=zstd 0 0
UUID=406d8c92-eb3f-4642-8532-fe14c97261cd /var/cache     btrfs   subvol=/@cache,defaults,noatime,compress=zstd 0 0
UUID=406d8c92-eb3f-4642-8532-fe14c97261cd /var/log       btrfs   subvol=/@log,defaults,noatime,compress=zstd 0 0
UUID=406d8c92-eb3f-4642-8532-fe14c97261cd /var/tmp       btrfs   subvol=/@tmp,defaults,noatime,compress=zstd 0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

And from terminal:

blkid
/dev/nvme0n1p5: UUID="67a12008-f15b-4e49-ae37-84edbf35a878" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a7ac825b-dfc3-4d58-bae9-a7fbb8ee2a07"
/dev/nvme0n1p3: LABEL_FATBOOT="EFI-SYSTEM2" LABEL="EFI-SYSTEM2" UUID="E857-3ED4" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI-SYSTEM2" PARTUUID="7a2ef150-919b-4cd5-8928-4d9f0c7d1f00"
/dev/nvme0n1p1: LABEL_FATBOOT="EFI-SYSTEM" LABEL="EFI-SYSTEM" UUID="8C3B-BE28" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="f637a525-4b4d-4d41-8629-442ab14a1385"
/dev/nvme0n1p4: UUID="406d8c92-eb3f-4642-8532-fe14c97261cd" UUID_SUB="1fb52a33-a158-47ae-aaf1-bf0dab2e7cbf" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="root" PARTUUID="85f8d72d-f95a-478f-a240-041f629e73c9"
/dev/nvme0n1p2: LABEL="rootMX23" UUID="2779c5bc-45ad-4909-bd7c-de1dcd54dafd" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="311afcbb-6686-4882-9438-820dfe00628e"

What happens if I edit the Garuda fstab first line from:
UUID=E857-3ED4

to:
UUID=8C3B-BE28

Can I even do that from MX session?

Thanks,
Sheila

nevj · October 26, 2024, 11:52am

I think that may be because Garuda keeps the vmlinux and init.rd images in a strange place. I had that issue with Solus once.
How about you go into the garuda root directory, find where the kernel images are, and put some pointers to them in ‘/’.
eg
ln -s somewhere /vmlinuz
ln -s anotherplace /init.rd
grub will always find things in ‘/’

Then try os-prober again.

nevj · October 26, 2024, 12:01pm

Yes, you can edit anything from MX.
Just mount it with the needed permissions.
Be careful, mounts of another / can be confusing… make sure you are in the garuda /etc directory, before you edit anything. I once edited the MX fstab by mistake…
made a real mess.

Yes, you can make garuda mount the other EFI directory. … it may not find the files it needs there… yiu may hzve to copy them across.
That will not solve the os-prober problem… os-prober looks for directories containing linux images… it does not use the EFI directory, it searches every partition on every disk and decides if each is bootable.

Sheila_Flanagan · October 26, 2024, 12:04pm

I am wondering if Garuda uses “snapshots” for these. I found grub.cfg but also grub-btrfs.cfg. Opening that last one, trying to find location of the kernels, I see:

menuentry '|         Date        |          Snapshot         | Type |                                Description                               |' { echo }
submenu '| 2024-10-15 20:59:14 | @/.snapshots/142/snapshot | post | adwaita-cursors adwaita-icon-theme adwaita-icon-theme-legacy alsa-card-p |' {
    submenu '| 2024-10-15 20:59:14 | @/.snapshots/142/snapshot | post | adwaita-cursors adwaita-icon-theme adwaita-icon-theme-legacy alsa-card-p |' { echo }

    menuentry '  vmlinuz-linux-zen & initramfs-linux-zen-fallback.img & intel-ucode.img' --class snapshots --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-snapshots-406d8c92-eb3f-4642-8532-fe14c97261cd' {
        if [ x$feature_all_video_module = xy ]; then
        insmod all_video
        fi
        set gfxpayload=keep
        insmod btrfs
        if [ x$feature_platform_search_hint = xy ]; then
            search --no-floppy --fs-uuid  --set=root  406d8c92-eb3f-4642-8532-fe14c97261cd
        else
            search --no-floppy --fs-uuid  --set=root 406d8c92-eb3f-4642-8532-fe14c97261cd
        fi
        echo 'Loading Snapshot: 2024-10-15 20:59:14 @/.snapshots/142/snapshot'
        echo 'Loading Kernel: vmlinuz-linux-zen ...'
        linux "/@/.snapshots/142/snapshot/boot/vmlinuz-linux-zen" root=UUID=406d8c92-eb3f-4642-8532-fe14c97261cd  quiet loglevel=3 ibt=off  rootflags=defaults,noatime,compress=zstd,subvol="@/.snapshots/142/snapshot"
        echo 'Loading Microcode & Initramfs: intel-ucode.img initramfs-linux-zen-fallback.img ...'
        initrd "/@/.snapshots/142/snapshot/boot/intel-ucode.img" "/@/.snapshots/142/snapshot/boot/initramfs-linux-zen-fallback.img"
    }

    menuentry '  vmlinuz-linux-zen & initramfs-linux-zen.img & intel-ucode.img' --class snapshots --class gnu-linux --class gnu

I did find in the /boot directory:

Not sure if that is what we are looking for.

Thanks,
Sheila

Sheila_Flanagan · October 26, 2024, 12:15pm

If it searches every partition then why would it not find that partition with Garuda to be bootable? Maybe this is one of the downsides of either Garuda or btrfs? It does not put things in a normal place or in normal format for os-prober to find?

I am going to do the cp from EFI-SYSTEM2 to EFI-SYSTEM after I backup both and see if that fixes the booting to Garuda issue. I will need to update-grub and run os-prober from MX and then try rebooting and see what happens.

Thanks,
Sheila

nevj · October 26, 2024, 12:21pm

That is it
Now you have me guessing… if they are in /boot grub would normally find them ?
Maybe the names are strange or the content is different?

The ones it needs are
vmlinuz-linux-zen
initramfs-linux-zen.img
I would still try the links, but I am not certain it will help
You can make the links from MX

I think snapshot just means it is an on the fly take of some development stage… nothing to do with snaps.

Sheila_Flanagan · October 26, 2024, 12:27pm

Oh, I know it has nothing to do with snaps, but I have seen Garuda discussion on using “snapshots” to restore their system, so I assumed it is an up to date image of the system. Since snapshots may contain the actual linux images, just did not know if that prevented the usual tools like os-prober, etc. from finding a bootable Linux install.

Sheila

nevj · October 26, 2024, 12:38pm

@Sheila_Flanagan ,
Hold on, I found this

" To detect Garuda Linux you will need to install os-prober-btrfs .

yay -S os-prober-btrfs

"
That was coming from Arch.
Not sure if MX has os-prober-btrfs

It is the btrfs filesystem that is foiling os-prober.

Sheila_Flanagan · October 26, 2024, 12:48pm

And that was my thinking. It had something to do with btrfs. But searching packages, and trying sudo apt install os-prober-btrfs, nothing is found on MX Linux packages, probably because it is an Arch tool.

Cannot use yay on MX Linux. Looking for a debian pkg, I found this:

Does that sound like it will work?

Sheila

nevj · October 26, 2024, 1:05pm

Sounds like it may work.
At least now we know what the problem is.
If that is not the solution, we can get the source code of os-prober-btrfs fron Arch… it will only be a shell script… the stabpndard os-prober is just a shell script, nothing
fancy.

What you would need to do is replace the os-prober in MX with this new script. You can use a symlink to trick it into that replacement too. You want grub to find the new os-prober when it initiates os-prober… so just use a name change or a link to trick it.