Exactly; it was a clear indicator.
I dont see your point.
Youāve now edited your original response to include the install-grub script.
But ā¦ yes. it was an indicator. Every post in reply highlighted the issue and provided solutions.
Yet you asked āDidnt anyone notice this?ā - yes, everyone did.
Yes, and you were typing something while I added to that post, which I only read after finishing the edit. I donāt see the point in that comment either. 
ok if soundofthunder is done being themself I have one final (god I hope) hurdle.
[manjaro /]# pacman -Syu install-grub
:: Synchronizing package databases...
core is up to date
extra 8.3 MiB 9.21 MiB/s 00:01 [####################################################################] 100%
community is up to date
multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (1) install-grub-2.12-4
Total Download Size: 0.01 MiB
Total Installed Size: 0.01 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
install-grub-2.12-4-x86_64 5.2 KiB 104 KiB/s 00:00 [####################################################################] 100%
(1/1) checking keys in keyring [####################################################################] 100%
(1/1) checking package integrity [####################################################################] 100%
(1/1) loading package files [####################################################################] 100%
(1/1) checking for file conflicts [####################################################################] 100%
(1/1) checking available disk space [####################################################################] 100%
:: Processing package changes...
(1/1) installing install-grub [####################################################################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Refreshing PackageKit...
Error connecting: Could not connect: No such file or directory
error: command failed to execute correctly
[manjaro /]# install-grub
EFI variables are not supported on this system.
WARNING: EFI directory not found! Grub couldn't be installed.
so I just browsed the files and confirmed I do not have a /efi folder, but do have a /boot/efi folder (which itself contains an /EFI folder with more stuff in it). additionally when entering chroot I get
==> Mounting (ManjaroLinux) [/dev/nvme0n1p2]
--> mount: [/mnt]
--> mount: [/mnt/boot/efi]
so Iām 99% sure it would be safe for me to run the
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Manjaro --recheck
command, but at this point I am not taking any chances, can someone confirm?
Well, hey, since youāre so observant of indicators, how about we take another look at the output I provided earlier for you.
[manjaro kitt]# pacman -Syu
pacman: error while loading shared libraries: libicuuc.so.75: cannot open shared object file: No such file or directory
Upon very close inspection, you might notice the [manjaro kitt]# prefix, which indicates that I am currently in a chroot environment. Now this is very difficult to spot, but if you look really carefully you might also see that the output of the command was not error: you cannot perform this operation unless you are root. Now if you add these two clues together, you may notice that only an idiot $%*&head would think that I did not run that command with elevated privileges.
Now kindly take your arse out of my help thread, thanks.
The grub-install command you propose should be adequate for your needs;
Itās easy to make errors in judgement, especially in the wee hours; Iām sure nobody is exempt from that. Easier still, is to make an unprovoked personal attack such as you have now demonstrated; and in such a petty manner; however, Iām willing to overlook it.
As it happens, I am generally observant of indicators.
For example:
The removal of the community repo was documented in the respective Update Announcement at the time - so long ago, in fact, that it is no longer listed under recent announcements;
The community repository has been merged into extra and is now empty
The Arch git migration is now complete .
The [community] repository has been merged into [extra] and is now empty.
It may take a bit of time for mirrors to catch up (more details here).
Update your system and handle the pacman
sudo pacman -Syu "pacman>=6.0.2-11"
In order to remove the defunct [community] repo changes must be made to /etc/pacman.conf.
Changes will be provided in a file with the extension .pacnew.
Pacman provides the utility pacdiff to manage these files and will use vim -d for comparison if the environment variable DIFFPROG is not set.
pacdiff -s
If you would like to use a different comparison tool you may prepend the env var:
DIFFPROG=meld pacdiff -s
Then sync with the repositories again:
sudo pacman -Syu
And you can also remove the now unused repository.
sudo pacman -Sc
NOTE: Be aware that this last command will also remove all packages in the pacman cache that are not currently installed: in other words, backup copies of packages that you have uninstalled at some point will no longer be stored on your hard drive.
In most cases, this probably will not cause headaches. To prevent even minor aches and pains, see the Arch Wiki for information on cleaning the cache
As it happens this issue had a comparatively easy fix, which was provided via a pacnew file for you to carefully merge with the existing file.
- See System Maintenance for more information.
Failure to correct that issue could simply be an oversight, however, it can also be indicative of a disregard and/or ignorance of system maintenance.
This is common among (particularly newer) users who make an assumption that performing an update equates to system maintenance, and nothing else needs to be done; or, if they take an entitled stance that they should not have to do that !@#$%, which happens more often than one might reasonably expect.
Gladly. Though, to be clear, not because you so eloquently request it.
The command looks sane,
except for the fact that you are in chroot and do not need sudo -
the target platform is correct (or is it not?), the efi directory is as well
and id is also what it should be.
You will have to take the chance.
Only you can confirm the result by running it.
As of now, the system is not booting.
This will not change if you do nothing.
Or the possibly, by a very small margin, wrong thing.
1 Like
[manjaro /]# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Manjaro --recheck
Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.
seems to have failed for a similar reason as install-grub
still taking suggestions while I research what OS to switch to and how to fully uninstall manjaro
do we have an
inxi -Fazy
from your system?
I didnāt see it.
It appears you did perhaps not boot in UEFI mode, but Bios instead.
Or some such thing - some mixup.
Because you do have an efi partition ā¦
This is above my paygrade, as they say - I canāt help further here.
This message:
might indicate that your Manjaro Installer was not created using a GUID Partition Table (GPT); the GPT partitioning scheme; but instead with a Master Boot Record (MBR) scheme. UEFI requires GPT. This can be an easy mistake to make when creating an Installer USB (or even a Ventoy USB).
When booting with an MBR disk in a UEFI based system, an installed UEFI OS disk might be detected incorrectly, or not at all.
Please provide (if possible) the full command output of:
inxi --admin --verbosity=8 --filter --no-host --width
after booting with the Installer USB; this will help to confirm this; or, rule it out; while also providing other potentially useful information.
