After installing Manjaro XFCE, there are two options for boot in my UEFi. One is UEFI OS and another one is my SSD. Which one should I choose?

Support
23

Ok, next chapter in the mystery novel :smile: . The problem seems to come just from the line of common.sh that was commented out! So if you run sudo os-prober with the modification in place, I think Manjaro line should not be in the output. Can you check?

Anyway that line in common.sh is there for a reason, that it’s still not very clear to me :sweat_smile:. I was reading the original mail thread were developers decided to add the line. That newns command just creates a new Name Space for the mounts (Source code) but I’m not sure how it affects to the detection.

So stay tunned for our next chapter, where we find a way to debug os-prober with that newns command in use! :joy:

Today is already a little late for me, so I will continue tomorrow after work

2 Likes
24

I deleted the previous change from /etc/defaul/grub and kept the last change in /usr/share/os-prober/common.sh:

$ sudo os-prober
/dev/nvme0n1p2@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi

$ sudo update-grub  
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-4.19-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.19-x86_64.img
Found initrd fallback image: /boot/initramfs-4.19-x86_64-fallback.img
Found Windows Boot Manager on /dev/nvme0n1p2@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done

I just rebooted my system and everything seems great, like it used to be. Now the grub menu gives me just 2 options to choose. BTW, I’ve just realized that the last Manjaro update had many various issues.

Is it safe to keep this change in common.sh, or should I undo it and just wait for the next update?

25

Not sure of that, but the line was there for a reason.

So I want to debug your os-prober. Can you test if sudo /usr/lib/os-prober/newns os-prober shows you the Manjaro Line? If yes then I would need the file that is generated by this:
sudo /usr/lib/os-prober/newns bash -x os-prober > os-prober_debug.txt 2>&1

26

With AND without the second line of common.sh commented out:

$ sudo /usr/lib/os-prober/newns os-prober
/dev/nvme0n1p2@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
/dev/nvme0n1p6:Manjaro Linux (20.1):ManjaroLinux:linux
27

Thank you. We are closer. Run findmnt -o TARGET,PROPAGATION /
Does it shows root as shared or private?

Also, please run and post the exit of:

sudo /usr/lib/os-prober/newns bash
cat /proc/mounts
exit
28 
$ findmnt -o TARGET,PROPAGATION /
TARGET PROPAGATION
/      shared
29

The plot thickens…

30

Ok. Time to explain a little bit…

The thing is that os-prober wants to bypass the current system, the system that is mounted right now, and for that it creates a list from /proc/mount with all the lines that start with /dev/ (because in mount there are also a lot of internal virtual devices). In the main loop it checks every physical device against the list that was created to bypass or ignore the root file system (the one that is mounted in /).

This should work, but if you watch carefully the content of the /proc/mount that you sent, you’ll see that the root file system looks like this:

rootfs /dev/nvme0n1p6 / ext4 rw,noatime 0 0

The problem here is that the line doesn’t start with the string /dev/, that is what os-prober is expecting. So the list doesn’t contain nvme0n1p6 and when later checks the physical device, doesn’t notice that this is the current system and has to ignore it. Os-prober thinks that is just another system in your computer and add it to the output.

Compare the line with my system’s /proc/mounts:

/dev/nvme0n1p5 on / type ext4 (rw,noatime)

In my system, the entry gets to the list and the partition is later recognized as the root file system and thus ignored.

But to make this more unusual, the different entry in mounts only shows up when a new name space has been called with the tool newns.

I have tried to find out why this inconsistency, but haven’t succeed. So probably I’m going to open a thread to try to get some attention from the devs.

Probably this is all long and boring, but the tl; dr is that probably you can’t do nothing and you have to wait to os-prober get patched (that can take long and I don’t know even will it happen). For now, as a temporary solution, you can undo the modification to /usr/lib/os-prober/newns and add the line OS_PROBER_NEWNS=1 to /etc/environment

PS: I see you are using kernel 4. That is somehow a possible cause for the “malfunction”

2 Likes
31

Quite the contrary, it was exciting to see main traces of the process of catching the culprit for this issue. We all learnt something here about how this part of the system works, I believe. I think we would all benefit if there are more of bug tracing communication like this, rather than the usual boring stuff. :smiley:

Thanks a lot for your effort to provide such an in-depth explanation that was easy to follow.
It was really a pleasure. :+1:

@sezaan: I didn’t create the original post, so please accept the above comment as the Solution for this issue, since it’s obvious that the communication will be transferred elsewhere.

How safe is it just to switch to the latest stable kernel 5?

Sorry, I’m not aware that I made any change to /usr/lib/os-prober/newns. Could you rephrase?
I reverted my changes in /usr/share/os-prober/common.sh if that’s what you meant…

32

Switching to linux54 shouldnt be a problem and you dont have to uninstall the kernel you are using now.

1 Like
33

Of course! Sorry, I mixed things in my mind.

It should be safe, but depends on your hardware. Anyway you don’t need to uninstall your current kernel to try a newer one. Just add a kernel from the manjaro-settings tool.

Yeah, I learn a lot :joy:. But never enough… Anyway it has been quite entertaining for me. A little bit disappointed for not having found the final nail, but happy for what I have learned in the way.

I didn’t noticed that. So we hijacked the thread! Let’s see if this is a solution for him/her. Maybe the problem was something different…

34

I have to confirm your instinct was right. I just installed the new kernel linux54, then I reverted all the changes proposed in this thread to the defaults, rebooted my system and this time it worked like a charm. It certainly was related to the old kernel linux419. Now with the new kernel the output is:

$ sudo os-prober
/dev/nvme0n1p2@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi

With the new kernel my /proc/mounts starts with:

/dev/nvme0n1p6 / ext4 rw,noatime 0 0

in oppose to the previous:

rootfs /dev/nvme0n1p6 / ext4 rw,noatime 0 0

When comparing to your syntax:

/dev/nvme0n1p5 on / type ext4 (rw,noatime)

… I’ve noticed it’s different than mine (using of type and brackets).

Do you know why’s that and should I change anything, or just leave it as is?

35

Probably I copied from mount command (that shows it that way) instead of the /proc/mount file. So nothing to worry about. That seems fine.

1 Like
36

Yes, I’m also waiting for that.

37

If any of the above answers actually solved your problem, please don’t forget to come back and click the 3 dots below the answer to mark a solution like this below the answer that helped you most :
Solution
so that the next person that has the exact same problem you just had will benefit from your post as well as your question will now be in the “solved” status.

38