Manjaro-chroot or chroot manually because btrfs

Hiding the menu does not affect the timeout — as you have experienced. :wink:

That suggests that the live session is reading a different /etc/default/grub, which in turn suggests that you’re not doing it from within the chroot environment.

The chroot should really only pick up what is on your installed system, with the exception of one thing, i.e. the running kernel. So if you want to rebuild your initramfs from within the chroot, then you have to tell it to rebuild the initramfs for your installed kernels, as opposed to the running kernel. But that’s about the only difference.

But of course, if you’re going to run update-grub from within the live session but outside of the chroot, then it’s not going to pick up your on-disk configuration.

At this point I’m only guessing, because I am not at your system and I have no idea what you are or have been doing. :man_shrugging:

Also, check the OS_PROBER setting in /etc/default/grub.

I thought so too for a while, until I left a commented out line in the file from here, and that comment was showing in the file while accessing it in chroot as well.

Ofc, I only do this from within a chroot.

My brain feels like mush so I will put this on hold until tomorrow (I say that, and then in 6hrs I will be back at it, fkn add… xD), and keep this thread open unless you as a mod object to it?

I will even analyze the os_prober script and see if I can understand anything from that.

Thank you both for the AMAZING support! :hearts: :hearts:

1 Like

Hello bedna, glad that you enjoy the community here at Manjaruminati.

If you want to show a little extra appreciation please consider donating to us to keep the constant stream of ILUMINAA!!!“%¤#¤%#”" *ERROR, BOT MALFUNCTION; all_your_base_are_belong_to_us

File:Guru meditation.gif

1 Like

I FIGURED IT OUT!!!

I don’t mount my /home as a subvol, so if someone else uses this, you have to keep into consideration how YOUR /home is mounted in /etc/fstab
This is what I did in my case to make it work:

Boot into live env and open a console and type: (got lazy, did not continue testing when I got it working, but not all dirs might have to be mounted, like above mentioned /home f ex, I MIGHT do some more testing and find out)

edit yepp, I did some testing today and the only mounts needed is root, boot and the “hack” below for update-grub to work but saving all in the post for my own reference and mark this as the solution.

sudo mount -t btrfs -o subvol=@ /dev/sda7 /mnt
sudo mount -t vfat /dev/sda5 /mnt/boot/efi
sudo mount -t btrfs -o subvol=@cache /dev/sda7 /mnt/var/cache
sudo mount -t btrfs /dev/sda8 /mnt/home
sudo mount -t btrfs -o subvol=@log /dev/sda7 /mnt/var/log

Then comes the “hack” that makes it work, found sollution by reading this:

I found this question with a similar issue that said there was a known problem with the grub-mkconfig helper script.

So I:

sudo mkdir /mnt/hostrun
sudo mount --bind /run /mnt/hostrun

If I mount it directly to /run, all that folder will contain is a folder called “mount”. By mounting it to a directory I created first it somehow shows all directories correctly in /hostrun. I then mount THAT directory to /run within chroot:

sudo manjaro-chroot /mnt /bin/bash
mount --bind /hostrun /run

I can now use update-grub and it detects windows and my configured menus in 40_custom also works perfectly.

Now, can someone explain WHY this works I would be greateful.

Maybe even do a change to manjaro-chroot so if it detects a btrfs system it changes how it mounts? Or at least add some info in the Manjaro Wiki?

Is it just MY computer that does this? Call for testers. xD

On a side note, I find the absolute last comment from 2017 here pretty interesting.

Issue effects only installations on removable usb keys. Not a major problem then. Maybe we could add a information window that says: “Grub is now installed. If your other systems do not show in the grub menu, do not panic. Just boot and run ‘sudo update-grub’ in your manjaro installation.”

Edit
Just in case someone wants to really look deep into this, this might be helpful.
I did do some other tests before figuring this out. F ex I disabled os-prober in /etc/default/grub. That obviously fixed the error but made my win11 disappear.
Changing back to GRUB_DISABLE_OS_PROBER=false and running update-grub now produced NO ERRORS, but it also still did not detect my win11. But the error was gone for some reason.

Edit 2
I will mark this as a solution in a while, but I would REALLY appreciate some feedback, if possible. :hearts:

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.