@Sheila_Flanagan
Here is a different approach using chainloader in grub
https://forums.debian.net/viewtopic.php?t=159094
https://forums.linuxmint.com/viewtopic.php?t=411902
I think finding a version of os-prober that can deal with btrfs is simpler.
1 Like
After reading the links, I agree. I will see what I can do and report back.
Thanks,
Sheila
2 Likes
Okay. I have been analyzing partitions, space, etc. In gparted, the EFI of size 256 MiB shows only 4.22 used; 251.xx unused.
The EFI-2 (Garuda’s EFI) is size 512 MiB and has only 1.59 MiB in use; 510.xx unused.
I got ready to do the cp from EFI-2 to EFI-1, but since I cannot see the actual contents (file names, etc.) of these EFI partitions, do I need to be concerned about overwriting one?
I know Garuda and MX are very different, but would not want to over write *.cfg or “config” in MX EFI with same file in Garuda.
Thanks,
Sheila
1 Like
One other thing that occurred to me is I have CZ images of the entire drive as well as the Garuda partition (and MX separately as well). But Garuda is 08.30.24–2 months old. And it does include the EFI partition.
Not worried about updates (that can be done after booting solved) and I can copy the home folders from within MX for any personal stuff that “might” be there. I don’t use it for anything other than gaming really as it is great for that. So I will need to copy those folders as well.
And I have the timeshift snapshots of MX current as of today. All backups are on the external HDD, not on this drive.
So considering I am backed up, once I confirm “cp” is okay, I assume I will still need to modify that grub-btrfs to the new UUID on EFI-1, and then try os-prober, etc. just to see if it finds it. A reboot to grub might show it, but if not, I will need to tackle that os-prober-btrfs option. Not looking forward to “making” a pkg, but I read the instructions and will see if I can do it.
Thanks,
Sheila
2 Likes
Hey call a halt.
You need to be able to see the contents to use cp.
Do you have the EFI’s mounted?
They are FAT filesystems… you might have to install something to deal with FAT in MX
I can see mine… I just cd to /boot/efi where it is mounted and can see the files!
Obvoiusly you cant mount both EFI’s on /boot/efi
I would do temporary mounts elsewhere ( eg in /mnt) to do the cp.
Agree
1 Like
Yes.
You will need a new CZ when you finish.
Using the old one would obviously restore the two EFI’s
At the moment that may be a lifesaver
That is in Garuda? Yes
2 Likes
It seems evey linux supports fat32.
You dont need to worry about that.
but you can check as shown in the link, if you want to.
1 Like
Okay, I have mounted the Garuda EFI to see the files in Thunar. Not sure if uppercase/lowercase matters in file naming, but both EFIs have an EFI/BOOT folder that each contain “bootx64.efi.” The Garuda file name is lowercase while MX is uppercase. So right off, I cannot just cp, even with -i, I would end up saying “n” do not overwrite. Even the folder names are the same.
So I do not think cp or “merging” the two is going to work. I am going to give it more thought on how I can restructure the drive partitions and I may just have to reinstall Garuda and ensure both boot. Am just not sure how I would lay the CZ image on that partition without messing up the EFI part.
Sheesh, this is a pain having btrfs. Didn’t Fedora use that? Think that is why I tossed it in the first place…LOL.
More thinking…
Sheila
1 Like
Mine looks like this
root@trinity:/boot/efi# tree
.
└── EFI
├── BOOT
│ └── BOOTX64.EFI
├── MX
│ └── grubx64.efi
└── void
└── grubx64.efi
The uppercase/lowercase matters… same as with all Unix filesystems
The EFI/BOOT/boot64.efi is the default uefi bootloader
There should be in addition one directory for each OS… but my Devuan is missing , so it must use the default loader or maybe it is missing because Devuan has never been in control of grub.
You need to copy the Garuda directory, and everything in it ( cp -r) into
/boot/efi/EFI of the first ESP partition. Leave the rest alone
1 Like
I have had issues with failure on large disks (1 tb and plus) using fat 32 on mint. Ended up reformatting as a linux format and re installing. Did not understand why as these articles suggest its fine. If i did it as a partitioned drive 2 x ok.
Was it MBR or GPT?
I can imagine more than 1Tb with MBR may have issues.
Yes, each has their own Garuda/MX folder. Makes sense about the default UEFI OS being uppercase. But regardless of case, if I had copied EFI/BOOT folder from Garuda into the 1st partition it would have overwritten my MX folder.
I will copy only the Garuda folder over to the 1st partition and see what happens.
Thanks,
Sheila
1 Like
So I did the above changes of copying Garuda folder to my EFI and changed the UUID to partition 1 EFI. Of course nothing has changed because I have to do the other os-prober from Github.
Following instructions on how to clone a git repository, I succeeded in that part, although I was told to cd to the working directory where I wanted the clone. I created one (maybe that is the issue below). Did that:
git clone https://github.com/boretom/os-prober.git
Cloning into 'os-prober'...
remote: Enumerating objects: 3020, done.
remote: Counting objects: 100% (3020/3020), done.
remote: Compressing objects: 100% (1066/1066), done.
remote: Total 3020 (delta 1825), reused 3002 (delta 1809), pack-reused 0 (from 0)
Receiving objects: 100% (3020/3020), 329.25 KiB | 2.39 MiB/s, done.
Resolving deltas: 100% (1825/1825), done.
But the next step says to apply the patches:
for p in ./debian/patches/*.patch; do patch -p1 < $p; done
That returned:
bash: ./debian/patches/*.patch: No such file or directory
So of course I cannot continue to create/install the package with that error. This is a first for me (creating pkgs) so I am unsure what the bash error refers to or how to resolve. I assumed when I installed the deb helper tools, any and all files/directories were either already there or created. But I also wonder if staying in that “working directory” is an issue. I did not find ./debian under root or in my dot files directory.
Should I have not used a working directory? Should I have done this from my normal /home/myviolinsings/ directory so it could add the folder “debian”
UPDATE: I tried to apply the patches from home directory and stil got same error message.
Thanks,
Sheila
In trying to find the earlier solution on symlinks, I ran across the following at:
The GRUB os-prober has problems detecting btrfs @subvolumes, the easiest answer from "rick3332" from ubuntu-forums made it work for me on both dual-boot btrfs based OS installs(ubuntu16&18) each with their own grub. There is no need for comprehensive hack os-prober code or do non-persistent manual grub.cfg edits. Just create symlinks in each btrfs volume roots for @/boot and @/etc and run "sudo update-grub2" afterwards in each OS.
#navigate to root of your current booted brtfs based OS
cd /
#create symlink for boot
ln -s @/boot boot
#create symlink for etc
ln -s @/etc etc
#mount the other btrfs volume with OS-install and navigate to its root
cd /mnt/exampleotherbtrfsvolume
#create symlink for boot
ln -s @/boot boot
#create symlink for etc
ln -s @/etc etc
NB: GRUB 2.06 and consequently Ubuntu 22.04+ disabled use of os-prober by update-grub by default. You can enable os-prober in /etc/default/grub by adding GRUB_DISABLE_OS_PROBER=false and the subsequent steps will work. If you do not wish to permanently enable os-prober, run sudo os-prober && update-grub.
#let grub detect btrfs based install volume
sudo update-grub2
#reboot to the other btrfs based OS (probably listed this time in grubmenu)
#let this grub detect the previously booted btrfs volume
sudo update-grub2
I did uncomment the “disable os-prober” in my /etc/default/grub on MX. What I am not clear about is including the correct location of the Garuda subvolumes in the symlink.
The Garuda is mounted, but how would I use terminal to create these symlinks for /@/boot which has everything we need for grub? And where am I putting these symlinks–in MX /boot/ folder? That is where the efi, grub and menu entries are. Would I need to be in a live Garuda session to make changes to the current Garuda OS as previously discussed with “chroot”
Thanks,
Sheila
Yes mbr.
I dont know why I chose Fat on a linux machine, think it was a error on my part without thinking more about it at installation stage.
Well, were you in the working directory when you did that?
Have a look
ls ./debian/patches
is anything there?
Maybe the github clone did not have any patches
I have never seen a github clone with patches?
I checked on github… debian/patches is there… so did it download with the cloning?
I aso saw there is a pre-made .deb file available… on tbe ‘release page’ … but I could not find any release page?
1 Like
I dont understand @/boot
@ in bash stands for the positional parameters
so it must transfer any argument to the head of the path?
but there is no argument?1
Does anyone know?
1 Like
There is no. /debian.
If it did, I didn’t see it. I thought that part in the instructions about deb helper utilities might have added the debian folder, but apparently not.
1 Like
Remember when I showed you the kernel files we needed? That is in @/boot. The structure in Garuda is as follows:
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@cache
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@home
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@log
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@root
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@srv
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@tmp
the “@” has several files/folders:
\/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/.snapshots
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/bin
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/boot
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/dev
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/etc
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/home
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/lib
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/lib64
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/media
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/mnt
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/opt
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/proc
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/root
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/run
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/sbin
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/srv
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/sys
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/tmp
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/usr
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/var
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/.garuda-tools
And the /boot folder has:
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/boot/efi
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/boot/grub
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/boot/memtest86+
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/boot/initramfs-linux-zen.img
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/boot/initramfs-linux-zen-fallback.img
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/boot/intel-ucode.img
/media/myviolinsings/406d8c92-eb3f-4642-8532-fe14c97261cd/@/boot/vmlinuz-linux-zen
So I assume the subvolumes these instructions refer to (the ones os-prober cannot find by such locations/names) are what we need to point to.
One forum the person had MX installed and added OpenSUSE (btrfs) and this was stated:
OK, so it seems that the solution layed out in https://askubuntu.com/questions/967172/grub2-does-not-detect-btrfs-partition/1032354#1032354 also works if "your currently booted OS" is NOT btrfs (but ext4 in my case).
Just do the following:
- mount the btrfs volume locally (eg in Dolphin, click on the respective partition)
- navigate to the mountpoint
- do
Code: Select all
sudo ln -s @/boot boot
sudo ln -s @/etc etc
And further explanation:
How to enable os-prober to detect btrfs installs with "/"-root on subvolumes...
For BTRFS installtions, where system root "/" files system is located on a btrfs-subvolume,
GRUB through update-grub ( => grub-mkconfig ) does have difficulties to generate
a GRUB menu entry for those other installations found on another partition.
update-grub is using os-prober. And os-prober does not have an indication
what subvolume "/"-root filesystem is located on.
In order to "help" os-prober to detect the GRUB-installtion on such btrfs-install
with subvolumes, some symlinks needs to be added to the "top id=5" subvolume.
The person decided to just go with chainloading as he did not want to run the script the helper created for him.
I am still not sure I understand where these symlinks are to be created, and if I can create them while I have MX booted.
Thanks,
Sheila
1 Like
You need to be where you can see ‘@’ in an ls
You can do that from MX, as long as you have the ESP mounted
You dont have to be in Garuda to do it… you are making the link in the ESP partition , not in the root filesystem.
Thanks, I missed the meaning of @ . I get it now… it is a directory name… how confusing is that.
1 Like