Black screen on restart after update

Support System Updates
21

@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!

22

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)

23

@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.

24

@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?

25

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.

26

@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?

27

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 :smiley:
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.

28

@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!

29

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.

30

@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.

31

@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.

32

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
33

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.

34

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.

35

In which case. Of course fat32 is not cAsE sensitive.
But my main point is that it wasnt always ‘manjaro’, especially from Architect installer iirc, and that the term/path is important.

36

It makes no practical difference either way (unless it does); but, I agree that lowercase should be used even if it’s only a matter of convention.

37

It does if your path ends in ‘grub’ and you use ‘manjaro’.
Then you will, at the very least, end up with duplicated entries.

There are also some other funny quirks around like how some motherboards/EFI wont accept spaces in those directory names.

38

I still recall with some dismay a few of the early (2011-2014) implementations; some of which I struggled with for longer than I care to mention.

Yes, I’m looking at you, Mr. Gigabyte Dual-BIOS…

1 Like
39

I’m taking from all of this that in my case:

Primary bootloader location is $esp/EFI/Manjaro (in my directory structure, Manjaro in fact being title case with capital “M”), where the grubx64.efi file appears.

Fallback location is $esp/EFI/boot, where the bootx64.efi file appears.

Since the --bootloader-id value should reflect the name of the subfolder in which the primary bootloader file resides, the correct value is Manjaro (to be precise and safe, even though the file system for EFI should be case-insensitive).

If I’m getting anything wrong, I’m sure someone will let me know! This is a helpful and generous community, and I’m grateful to all who have contributed here.

At this point, my system is booting up appropriately from the UEFI partition, and fully functional as far as I can tell. But as @Joe_Ge points out, the next time grub gets an update, I could be back to booting up to a black screen. I can of course test that out by forcing a grub refresh, but as you can probably appreciate, after a few weeks of limited productivity using the desktop system, I’m not in a hurry to give that a try.

1 Like