@Kobold
All evidence from inspecting file timestamps indicates that operations performed from chroot in the live USB environment are updating the installed system on the hard drive, not the live system from the ISO on the USB drive. I do now have both 5.15 and 6.6 showing in grub when I try to boot up the installed Manjaro system.
Can you chroot again into the system, then see if sudo pacman -R plymouth is really removed?
Then please try a sudo pacman -S install-grub then again a sudo pacman -S grub
It should run automatically then, since there was a topic about a installation script
It should find your installation, otherwise, you would need to make sure, your efi drive (nvme0n1p1) is mounted on /boot/efi and install grub with --efi-directory.
That simple reinstallation seems like a shortcut, if it works.
If not, you need to do from your live-usb after chroot sudo mount dev/sdb/nvme01p1 /mnt/boot/efi
and sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
and update-grub and reboot.
You can also look with inxi -G if you got any video driver installed.
If there is nothing, you can autoinstall it with sudo mhwd -a pci free 0300 or nonfree, depends, what you prefer. It looks like, there is a problem with the video driver.
1 Like
@Joe_Ge
Thank you so much for your suggestions. I really appreciate your help.
Sure seems like plymouth is fully absent:
[manjaro /]# pacman -R plymouth
error: target not found: plymouth
The attempt to reinstall the install-grub script appears to fail on a PackageKit error:
[manjaro /]# pacman -S install-grub
warning: install-grub-2.12-3.10 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Packages (1) install-grub-2.12-3.10
Total Installed Size: 0.01 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n] y
(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%
:: Running pre-transaction hooks...
(1/1) Creating Timeshift snapshot before upgrade...
==> skipping timeshift-autosnap due skipRsyncAutosnap in /etc/timeshift-autosnap.conf set to TRUE.
:: Processing package changes...
(1/1) reinstalling 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
Proceeding to try to reinstall grub anyway, I get the following, with the PackageKit error again and an “EFI directory not found” error:
[manjaro /]# pacman -S grub
warning: grub-2.12-3 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Packages (1) grub-2.12-3
Total Installed Size: 47.86 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n] y
(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%
:: Running pre-transaction hooks...
(1/1) Creating Timeshift snapshot before upgrade...
==> skipping timeshift-autosnap due skipRsyncAutosnap in /etc/timeshift-autosnap.conf set to TRUE.
:: Processing package changes...
(1/1) reinstalling grub [####################################] 100%
:: Running post-transaction hooks...
(1/4) Arming ConditionNeedsUpdate...
(2/4) Refreshing PackageKit...
Error connecting: Could not connect: No such file or directory
error: command failed to execute correctly
(3/4) Installing Grub to MBR/EFI
WARNING: EFI directory not found! Grub couldn't be installed.
error: command failed to execute correctly
(4/4) Updating the info directory file...
It looks like the EFI directory is already mounted as a result of the manjaro-chroot -a invocation. Here’s the partial output from lsblk:
nvme0n1 259:0 0 476.9G 0 disk
|-nvme0n1p1 259:1 0 300M 0 part /boot/efi
`-nvme0n1p2 259:2 0 476.6G 0 part /
Proceeding to execute the grub-install script anyway, I get:
[manjaro /]# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.
Then updating grub I have the following, with errors and warnings that may or may not be significant:
[manjaro /]# update-grub
Generating grub configuration file ...
Found background: /usr/share/grub/background.png
Found linux image: /boot/vmlinuz-6.6-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.6-x86_64.img
Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.15-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.15-x86_64.img
Found initrd fallback image: /boot/initramfs-5.15-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
ERROR: mkdir /var/lock/dmraid
grub-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done
Executing inxi -G to query installed graphics drivers, I get the following (about which I have two questions: (1) What’s with the “12” prefixing? (2) Do these results reflect the live USB environment or the installed environment on the hard drive?):
[manjaro /]# inxi -G
12Graphics:
12Device-1 AMD Picasso/Raven 2 [Radeon Vega Series / Radeon Mobile Series] 12driver amdgpu 12v kernel
12Device-2 Microdia USB Live camera 12driver snd-usb-audio,uvcvideo 12type USB
12Display 12server X.org 12v 1.21.1.11 12driver 12X 12loaded modesetting 12dri radeonsi 12gpu amdgpu
12resolution 1920x1080
12API EGL 12v 1.5 12drivers radeonsi,swrast 12platforms surfaceless,device
12API OpenGL 12v 4.6 12compat-v 4.5 12vendor mesa 12v 24.0.2-manjaro1.1 12note incomplete (EGL sourced)
12renderer AMD Radeon Vega 8 Graphics (radeonsi raven LLVM 16.0.6 DRM 3.54 6.6.10-1-MANJARO),
llvmpipe (LLVM 16.0.6 256 bits)
12API Vulkan 12Message No Vulkan data available.
Finally, querying devices with mhwd I get (in part, showing results for the graphic display device):
[manjaro /]# mhwd -l -d
--------------------------------------------------------------------------------
> PCI Device: /devices/pci0000:00/0000:00:08.1/0000:04:00.0 (0300:1002:15d8)
Display controller ATI Technologies Inc Picasso
--------------------------------------------------------------------------------
> INSTALLED:
NAME: video-linux
ATTACHED: PCI
VERSION: 2018.05.04
INFO: Standard open source drivers.
PRIORITY: 2
FREEDRIVER: true
DEPENDS: -
CONFLICTS: -
CLASSIDS: 0300 0380 0302
VENDORIDS: 1002 8086 10de
I had already executed mhwd -a pci free 0300 to install the video driver at least once previously, with no errors.
Bottom line: when I reboot without interrupting the boot process, I get the four error messages, then a black screen with nothing happening, no Ctrl-Alt-Fn or anything. In other words, absolutely nothing has changed in terms of (bad) results.
error: no server is specified.
error: no suitable video mode found.
error: no video mode activated.
error: symbol 'grub_efi_set_variable_to_string' not found.
It’s entirely possible, maybe likely, that I’m making some fundamental stupid pervasive error that subverts the effectiveness of my attempts to recover my installed system. It seems unlikely that hours of trying to recover would result in no discernible change to the results of booting into the system. More likely, things should have gotten either worse or better.
Hm, did your internet not work?
Maybe you try a ping -c2 manjaro.org
And if it works, may do a pacman -Syyu
And well, the last updates did break more things.
Seems your video is working, it still looks for me like an error from grub.
May you can see an error at journalctl -b ?
Can you see if install-grub is now installed with pacman -Ql install-grub ?
I think i skipped a step at mounting the drives.
Can you try again at chroot,
sudo mount /dev/sdb/nvme0n1 /mnt/boot
then
sudo mount dev/sdb/nvme01p1 /mnt/boot/efi
then
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
and update-grub and reboot.
Hopefully, then this error during update-grub is gone.
@Joe_Ge
Internet was connected and working reliably throughout this session. Is “Error connecting” associated with the “Refreshing PackageKit…” message? If so, might it just mean the script wasn’t able to find and connect to the PackageKit installation locally?
pacman -Syyu runs without incident, except for the “Refreshing PackageKit…” then “Error connecting…” sequence.
Running journalctl -b results in no error, but output is null.
Running pacman -Q install-grub results in:
install-grub 2.12-3.10
Running df to show what’s mounted results in:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/nvme0n1p2 490825920 67956996 397862832 15% /
/dev/nvme0n1p1 306584 292 306292 1% /boot/efi
efivarfs 128 16 108 13% /sys/firmware/efi/efivars
udev 7099592 0 7099592 0% /dev
shm 7132184 0 7132184 0% /dev/shm
run 7132184 0 7132184 0% /run
tmp 7132184 0 7132184 0% /tmp
overlay 10698280 280136 10418144 3% /etc/resolv.conf
Running the suggested mount command results in:
[manjaro /]# mount /dev/sdb/nvme0n1 /mnt/boot
mount: /mnt/boot: mount point is not a directory.
dmesg(1) may have more information after failed mount system call.
and creating the boot subfolder then rerunning the mount command fails similarly.
As before, grub-install runs with no errors:
[manjaro /]# grub-install --target=x86_64-efi --efi-directory=/boot/efi bootloader-id=manjaro --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.
And update-grub results in the same errors as before: (1) mkdir failure; (2) No grub drive for /dev/sda1; (3) unknown device type nvme0n1:
[manjaro /]# update-grub
Generating grub configuration file ...
Found background: /usr/share/grub/background.png
Found linux image: /boot/vmlinuz-6.6-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.6-x86_64.img
Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.15-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.15-x86_64.img
Found initrd fallback image: /boot/initramfs-5.15-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
ERROR: mkdir /var/lock/dmraid
grub-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done
Thanks for your patience with this process. It seems to be going nowhere, very slowly. Time to abandon ship, maybe either work on acquiring better Manjaro understanding and skills, or just give up on the idea that Manjaro is any kind of good fit for me?
This one is only an error from the package Package kit, where someone suggest, to simple remove it with pacman -Rs Packagekit because it caused more problems at past and is not really needed.
That digit [12] at inxi was indeed, because you been in a chroot enviroment.
I think pretty all distros are the same, if something breaks, you are with all in trouble.
I wouldn’t say “This or that one is not for you” as far you look for solutions and got a little understanding.
For a reinstall, i did learn, that a easy way is to have /home on a separate partition, so if you install the system new, you can simple keep it, just mount it at the new installation as home and use the same user and password, and it will work again.
And well, Ok, my bad, mounting nvme0n1 is useless, you can’t mount a disk when it contains partitions. I did read that wrong.
That error about error: cannot find a GRUB drive for /dev/sda1 is probatly only because there is no grub installed, seems that is not a problem.
But i am still not out of Ideas.
You can look at your pacman log file, after you chroot, at /mnt/var/log/pacman.log
maybe with nano /var/log/pacman.log or from the live iso with an editor.
It can be some big, so you may have to scroll down far.
Maybe you can see there some errors during the update.
And may install another Kernel ie, 6.1, what is still LTS with pacman -S linux61 and see if you can boot that.
i would also try a mkinitcpio -P and install-grub this time.
The package should now work, since pacman showed, it is installed.
There is another error, ERROR: mkdir /var/lock/dmraid
what points with a problem with an raid system, but maybe better ignore it right now too, or do you have / had a raid installation?
There is a topic about it, but i dont wanna suggest now you should delete anything.
@Joe_Ge I admire your patience and persistence! But it’s another round of trying stuff that leads to no apparent change in boot results: still four error messages then black screen with no further operation possible.
I should’ve said “Maybe Linux isn’t for me” rather than specifying Manjaro. I use Chrome OS most of the time and find that it does maybe 90% of what I need or want to do, and in most cases when it doesn’t do it perfectly, it does it well enough. The remaining 10% that Chrome OS doesn’t do is important to me, but if this is what I have to go through to maintain a Linux installation, I have to wonder about the balance of costs and benefits.
I tried removing PackageKit with pacman -Rs packagekit resulting in the following. I’m guessing what I need to remove is instead packagekit-qt5 but I didn’t pursue further for now.
[manjaro /]# pacman -Rs packagekit
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing packagekit breaks dependency 'packagekit' required by packagekit-qt5
[manjaro /]# systemctl disable packagekit.service
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.
Possible reasons for having these kinds of units are:
* A unit may be statically enabled by being symlinked from another unit's
.wants/, .requires/, or .upholds/ directory.
* A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
* A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
* In case of template units, the unit is meant to be enabled with some
instance name specified.
I again read through the pacman log for the failed update (March 8). In addition to errors and warnings previously discussed (missing consolefont, possibly missing firmware, unknown device type nvme0n1, grub drive missing for /dev/sda1), there’s ERROR: Missing 6.1.80-1-MANJARO kernel modules tree for module v4l2loopback/0.12.7. I don’t know how to evaluate the significance of that one (or, really, the others). Here are quoted portions of the log:
...
[2024-03-08T15:43:26-0500] [ALPM-SCRIPTLET] ==> dkms install --no-depmod v4l2loopback/0.12.7 -k 5.15.150-1-MANJARO
[2024-03-08T15:43:30-0500] [ALPM-SCRIPTLET] ==> depmod 5.15.150-1-MANJARO
[2024-03-08T15:43:35-0500] [ALPM-SCRIPTLET] ==> ERROR: Missing 6.1.80-1-MANJARO kernel modules tree for module v4l2loopback/0.12.7.
During processing of mkinitcpio.conf:
[2024-03-08T15:43:37-0500] [ALPM-SCRIPTLET] ==> WARNING: consolefont: no font found in configuration
And continuing with log extracts:
...
[2024-03-08T15:43:39-0500] [ALPM-SCRIPTLET] ==> Starting build: '5.15.150-1-MANJARO'
[2024-03-08T15:43:39-0500] [ALPM-SCRIPTLET] -> Running build hook: [base]
[2024-03-08T15:43:39-0500] [ALPM-SCRIPTLET] -> Running build hook: [udev]
[2024-03-08T15:43:39-0500] [ALPM-SCRIPTLET] -> Running build hook: [modconf]
[2024-03-08T15:43:39-0500] [ALPM-SCRIPTLET] -> Running build hook: [block]
[2024-03-08T15:43:40-0500] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'qla2xxx'
[2024-03-08T15:43:41-0500] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'qla1280'
[2024-03-08T15:43:41-0500] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'qed'
[2024-03-08T15:43:41-0500] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'bfa'
...
[2024-03-08T15:43:45-0500] [ALPM-SCRIPTLET] -> Running build hook: [consolefont]
[2024-03-08T15:43:45-0500] [ALPM-SCRIPTLET] ==> WARNING: consolefont: no font found in configuration
...
[2024-03-08T15:44:05-0500] [ALPM-SCRIPTLET] Adding boot menu entry for UEFI Firmware Settings ...
[2024-03-08T15:44:05-0500] [ALPM-SCRIPTLET] Root filesystem isn't btrfs
[2024-03-08T15:44:05-0500] [ALPM-SCRIPTLET] If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
[2024-03-08T15:44:06-0500] [ALPM-SCRIPTLET] Found memtest86+ image: /boot/memtest86+/memtest.bin
[2024-03-08T15:44:06-0500] [ALPM-SCRIPTLET] /usr/bin/grub-probe: warning: unknown device type nvme0n1.
[2024-03-08T15:44:06-0500] [ALPM-SCRIPTLET] done
I executed mkinitcpio -P then install-grub, both of which completed successfully.
I installed linux61 and selected it from advanced options at boot time, with no change in the result: still the four errors, black screen, entirely inoperable OS.
No, no RAID in my hardware setup, now or ever. I have just the Minisforum UM350 mini PC with an external USB hard drive.
Once again, thanks so much for all your efforts and your suggestions!
The possibly missing firmware and missing consolefont can be safely ignored, that is if you have no hardware that needs such firmware, and as for consolefont, you can always pick one and the warning will disappear (I personally picked a retro one: sun12x22)
@abuladeen
Well, i wonder lately a bit about linux too, it could do better, i got still problems with my suspend, where my computer dont awake anymore, and i have to restart lightdm, to get my desktop back.
Xfce dont apply some changes at the configuration and i am missing some fine tuning. But well, i hate M$ more with her policy.
You can remove then both sudo pacman -Rs packagekit packagekit-qt5 from chroot.
Lets see what it does when you fix v4l2loopback, there is a topic here
Install sudo pacman -Syu dkms base-devel --needed and reboot.
If it still dont work, install headers, as its mentioned at the other topic.
Not sure, if you need to run a install-grub once more, to update the kernel.
That error about unknown device nvme0n1 could be only a not proper loaded kernel, too.
There is still a topic about some settings to boot with UEFI, but i think, since you didnt touch the bios, there should be no problem.
@Joe_Ge
I removed PackageKit so that’s no longer a distraction.
I successfully followed the procedure for fixing v4l2loopback and tried to boot into the installed kernels, but there was no change in boot status: still a black screen. I then tried installing kernel headers, again without any apparent beneficial effect.
When I run install-grub it now fails with the error Cannot find EFI directory. Attempts to reinstall grub with pacman likewise fail with the same error.
I’m completely frustrated and just thrashing at this point. I even got the system stuck on a rescue mode command line, but managed to recover from that and return to the unfortunate and persistent black-screen-on-boot status, along with the new Cannot find EFI directory error.
Given the state of my system, my severely limited understanding of the operating system, and my increasingly loose-cannon desperation approach, recovery by anything short of reinstalling seems hopeless. Agree?
You can run a sudo fsck /dev/nvme0n1p2 from your live cd before chroot, since your system is installed on that partition.
Also may check all other drives like /dev/sda1 + sda2, /dev/sdb1 since you are already on it.
Sometimes they have some errors, even it doesnt show up anywere.
I had some cases, where my system didnt boot up after a a forced power off of reboot, because it was in a locked state and i had to do a fsck first (from another system), even it didnt show it anywhere.
fsck can run for a while so if it looks like, nothing happens, just wait for it, even its 5 minutes.
At the end, it will show a message.
May reboot, and see if it worked. Else, chroot again and see, if there are missing files
pacman -Qk It can be a long list, you could use the |less option or scroll back at the tty.
It will show some errors, but mainly its about missing files.
Also you can look what sudo efibootmgr show, if it points to nvme0n1p1 and may try at a reboot by pressing Key F12 boot straight from nvme0n1p1.
If it shows at install grub cannot find EFI directory you need to mount before sudo mount /dev/nvme0n1p1 /mnt/boot/efi at the chroot enviroment.
@Joe_Ge
Finally, something different: my Manjaro installation returns!
I ran fsck on the system partition on the internal hard drive, also on the remaining partitions. No conspicuous errors were detected. Rebooting, I had the usual result: the four error messages mentioned in previous messages, then a black screen completely unresponsive to keystrokes.
I then tried selecting the manjaro option from the system boot override menu:
Boot Override
UEFI OS (ESO512GYLCT-EP3-2L)
manjaro (ESO512GYLCT-EP3-2L)
UEFI: hp v165w 8192
UEFI: hp v165w 8192, Partition 2
ESO512GYLCT-EP3-2L
hp v165w 8192
Lauch EFI Shell from filesystem device
And my installed system actually appeared, to all appearances operating normally—something I hadn’t seen in quite a while. That’s progress, I guess, but I still have to interrupt the normal boot sequence to get the grub menu in order to subvert the currently inoperable default boot option.
I’m wondering if this problem is related to the one described in the article here: Boot entries differences. I can use the manjaro boot option workaround, but I don’t know how to restore the system to the correct boot options sequence so it simply boots up normally.
Here’s the efibootmgr output:
[manjaro /]# efibootmgr
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0003,0000,0004,0005,0001,0002
Boot0000* manjaro HD(1,GPT,191f352d-eee8-dc42-984f-5f9ac41da946,0x1000,0x96000)/\EFI\MANJARO\GRUBX64.EFI
Boot0001* NVME BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,1300)0000474f00004e4fc5000000010000008d00450053004f00350031003200470059004c00430054002d004500500033002d0032004c000000050109000200000000010416008b12e85cec2cf040837280640e3dc85813007fff040002010c00d041030a0000000001010600010101010600000003171000010000006479a7797a3040357fff040001043a00ef47642dc93ba041ac194d51d01b4ce635003100310032003300300034003200310031003600350030003000300037003100360000007fff04000000424f
Boot0002* USB BBS(USB,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0500)0000474f00004e4fad000000010000007f0068007000200076003100360035007700200038003100390032000000050109000500000000010416008b12e85cec2cf040837280640e3dc85805007fff040002010c00d041030a000000000101060001080101060003000305060001007fff040001043600ef47642dc93ba041ac194d51d01b4ce6410041003100380030003100300036003000300030003000300031003100340000007fff04000000424f00004e4fcd000000010000008f0057004400200045006c0065006d0065006e007400730020003200360032003100200031003000320036000000050109000500000000010416008b12e85cec2cf040837280640e3dc85805007fff040002010c00d041030a000000000101060001080101060004000305060002007fff040001044600ef47642dc93ba041ac194d51d01b4ce635003700350038003400310033003200340035003300330033003000330038003300370035003800340043003400310000007fff04000000424f
Boot0003* UEFI OS HD(1,GPT,191f352d-eee8-dc42-984f-5f9ac41da946,0x1000,0x96000)/\EFI\BOOT\BOOTX64.EFI0000424f
Boot0004* UEFI: hp v165w 8192 PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x3)/USB(1,0)/CDROM(1,0x608a9c,0x8000)0000424f
Boot0005* UEFI: hp v165w 8192, Partition 2 PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x3)/USB(1,0)/HD(2,MBR,0x0,0x608a9c,0x2000)0000424f
And here’s what my current boot options (including the USB for the live system) look like in the system BIOS:
FIXED BOOT ORDER Priorities
Boot Option #1 [UEFI NVME:UEFI OS (ESO512GYLCT-EP3-2L)]
Boot Option #2 [UEFI Hard Disk]
Boot Option #3 [UEFI CD/DVD]
Boot Option #4 [UEFI USB Device:UEFI: hp v165w 8192]
Boot Option #5 [UEFI Network]
Boot Option #6 [NVME:ESO512GYLCT-EP3-2L]
Boot Option #7 [Hard Disk]
Boot Option #8 [CD/DVD]
Boot Option #9 [USB Device:hp v165w 8192]
Boot Option #10 [Network]
Thanks for hanging in there through all this fumbling around on my part. Left to my own devices, I would have bailed a while ago. But having persisted with your help, I’m learning a lot about Linux and Manjaro—enough to get a better idea how much more I need to know, anyway—and now it’s looking like I even get my system back, preserving my applications and customization.
Any guidance as to where I should go from here?
I would start with booting the system, then do again
sudo grub-install --recheck && sudo update-grub
It hopefully fix it better from your enviroment.
If not, change the Boot order and repeat it.
And yes, it seems its related to that topic, it seems, that you are booting that UEFI OS entry,
which points to nowhere.
I am not sure here, why it doesn’t work, because it actually points also on nvme0n1p1 partition what should contain your grub64.efi.
I found, that you can change the bootorder by 2 methods. Either move your
Boot option #6, [NVME:ESO512GYLCT-EP3-2L]
to Boot option #1, save and exit your bios
or modify it with sudo efibootmgr -o 0000,0003,0004,0005,0001,0002
I guess it both does pretty the same, to modify the NVRAM from the bios.
Changing the bootorder at the bios, is for me the logical way to boot from the disk, where your bootloader is installed if it will not work by simple reinstalling grub.
I have read further at the net, that it seems, that some HP Laptop change by itself the bootorder for the favor of Windows. But since you dont have it, i dont know, how that happend right now.
And hopefully it fixes your kernel boot option too, else, you have to show again, what options you have to modify at the grub menu.
And well, learning about linux by fixing the bootup is some …special. I prefer other things 
I am not really into the UEFI Bios, i avoide it as long as i can. That logic behind this system is a bit ‘advanced’ and seems not much more save, since there been already viruses for it.
For me, it was only another attempt from windows to kinda lock Linux out, but they failed miserable.
@Joe_Ge
Reinstalling grub (grub-install --target=x86_64.efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck && update-grub) completed successfully. On rebooting, no change: still the initial four messages, then black screen.
I tried moving Boot option #6, [NVME:ESO512GYLCT-EP3-2L] to the top of the stack, using the BIOS Boot tab. Seems like that would have the effect of making the boot override option manjaro (ESO512GYLCT-EP3-2L) the default, so the system would boot normally without interrupting to display the BIOS menus and select the override. But the effect instead was to cause the boot process to fall through to boot the live environment from USB (still inserted and available), with the resulting environment showing no awareness of UEFI.
efibootmgr and the grub-install commands at this point showed the following from chroot:
[manjaro /]# efibootmgr
EFI variables are not supported on this system.
[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.
From the BIOS, I restored the boot order, returning the system to the previous status quo: booting to the installed OS only if I interrupt the boot process to override the boot option, selecting manjaro (ESO512GYLCT-EP3-2L).
I checked for differences between the primary EFI image and the fallback as suggested here: [root tip] [How To] Primer on handling a grub package update, and found that the timestamps were different. As recommended, I copied the grubx64.efi file over the bootx64.efi file.
The system is now booting up normally. Does that mean we’re finally done? It does seem like progress at least! Or is there more work to do?
As always, thanks so much for all your efforts on my behalf!
Yw, i am a tinkerer, so its not a big thing, only some ‘training’
Well, if it works now for you, you can stop here and use it.
It seems for me, you copied the last working grubx64 over, and it still works as it did before.
Just not sure, if it still works, when you or ie an update run grub-install or the manjaro script install-grub again, and it saves again a grubx64.
You may find out, when you run again install-grub, if it does still work or not.
After you did change the bootorder, it may had worked, when you use the F12 menu again and select manjaro, then load it, and run again at least update-grub that it applies the new bootorder to the bootloader.
Case changing bootorder.
At your old grubx64.efi file seems you had the entry “Bootcurrent 0004” as you have shown, the new one 0000.
This seems points to your usb-stick, you may simple unplug it, that it skip it, to boot from there.
Or changed the “Bootcurrent” with efibootmgr -a 0000
Anyway, seems you now have a new grubx64, what works, and you could see the value when you run again efibootmgr, if there is now 0000 active.
This means, your efivars was not loaded into the kernel.
Look, if you got the package installed sudo pacman -S efitools efivar
and maybe check, if its installed, despite, if you continue or not.
Then sudo modeprobe evivars and grub-install should normal run through.
Well, for now then, if you want leave it at this state, i would rerun grub-install&update-grub, and reboot,
to find out, if a future update will work again or cause some problems again.
@Joe_Ge
For directory structure as follows:
[jms-um350 abuladeen]# ls /boot/efi/EFI
boot Manjaro
[jms-um350 abuladeen]# ls /boot/efi/EFI/boot
bootx64.efi
[jms-um350 abuladeen]# ls /boot/efi/EFI/manjaro
grubx64.efi
what should I be using for the bootloader-id parameter value with the grub-install command? I’ve been using bootloader-id=manjaro (copying uncritically from documentation). But should it be bootloader-id=boot to point to the folder containing bootx64.efi?
I see here that the value to specify is
the name of the directory in which Grub’s ‘name-of-boot-file_x64.efi’ file should reside
but I’m not certain how to interpret that.
@abuladeen
The command should configure itself proper.
As i read it, the option bootloader-id= only points to the subfolder and should have the same format as the folder, in that case all letter low and it will then be the name for your entry.
Here is some more explanation at the bottom from the page.
Btw, you can can make more postings at one day, if you want speedup things a bit.
The id should always be bootloader-id=manjaro; which translates as $esp/EFI/manjaro; and likewise the mount path /boot/efi/EFI/manjaro.
$esp/EFI/BOOT (or /boot/efi/EFI/BOOT) is the fallback location which should automatically be populated at the same time as $esp/EFI/manjaro.
Under normal circumstances there is no need to point to $esp/EFI/BOOT directly.
I hope this helps. Cheers.
1 Like
Incorrect.
The case is as written directly above you;
The casesIDs do matter … and it can be different for different systems (age, community-spin, etc) … the idea is it should match the existing directory.
Beyond that though it doesnt really matter. If you moved things around or came from a different Arch distro and its ‘grub’ then thats fine too and you just use that.
In terms of filesystems, being that the ESP is fat32, case is irrelevent; however, as it happens, my use of capitalization was purely out of habit.