No console after 387.22 also with 387.34

To not repeat myself
https://bbs.archlinux.org/viewtopic.php?pid=1751141

This thread will be a copy/paste of that thread.

Alright,
I was in another country from 10.08.2017-21.11.2017.
When I returned I did a pacman -Syu
and rebooted.

After reboot I couldn’t get past “loading initial ramdisk…”.
So it seemed.
What actually happened and happens is I can’t get a console and it can’t get past that.

I switched to text mode grub and it boots however I still don’t get a console
And when I reboot the system it’s the same, when the system shuts down I get that black screen or alternating backlights or so it seems as if it turns on and off.

The motherboard is a UEFI board Gigabyte GA-X170-EXTREME-ECC
and there’s a nvidia gtx 1080
connected via DP to a 4k monitor
Intel® Xeon® CPU E3-1275 v5 @ 3.60GHz, for what it’s worth

noveuau is blacklisted

sddm or gdm - there’s no difference

I get to gdm or pass sddm’s autologin into cinnamon or gnome3 if you like
but only if grub text mode is enabled
else I’m not getting anywhere past the loading initrd message

/etc/default/grub

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="transparent_hugepage=never"
GRUB_CMDLINE_LINUX=""

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=3140x2160,1920x1080,1280x1024,auto

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=text

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true

/etc/mkinitcpio.conf

MODULES="nvidia nvidia_modeset nvidia_uvm nvidia_drm"
BINARIES=""
FILES=""
HOOKS="base udev autodetect keyboard modconf block filesystems fsck"

I also had MODULES=""

dmesg, you’ll notice the kernel segfaults, which is not happening with the lts kernel

-snip dmesg for readability-

bug report attachment post… I think
this forum is weird

You don’t get a console at all after the initial ramdisk is loaded? That doesn’t sound like a driver problem – does it work if you uninstall the driver entirely?

Since you’re booting in EFI mode, there should be messages about efifb initializing in the dmesg output. It’s not in the logs you pasted, but it’s in nvidia-bug-report-log.gz:

[    0.457391] efifb: probing for efifb
[    0.457409] efifb: framebuffer at 0xe0000000, mapped to 0xffffc90005c00000, using 8640k, total 8640k
[    0.457410] efifb: mode is 1920x1080x32, linelength=8192, pages=1
[    0.457411] efifb: scrolling: redraw
[    0.457412] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.461308] Console: switching to colour frame buffer device 240x67
[    0.465469] fb0: EFI VGA frame buffer device

It looks like you booted the kernel with the “quiet” parameter. If you remove that, do you get a working console?

Please try

/etc/default/grub

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
-GRUB_TERMINAL_OUTPUT=console
+#GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
-GRUB_GFXMODE=3140x2160,1920x1080,1280x1024,auto
+GRUB_GFXMODE=auto

# Uncomment to allow the kernel use the same resolution used by grub
-GRUB_GFXPAYLOAD_LINUX=text
+GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true

blablo,
when I do that I don’t get past the initrd. (see also archlinux forum thread, it’s more detailed)
believe me when I write that I tried all kinds of combinations.
GRUB_TERMINAL_OUTPUT=gfxterm
GRUB_TERMINAL_OUTPUT=console
I’ll try commenting GRUB_TERMINAL_OUTPUT now, but I doubt that it will be much difference.

aplattner,
I’m not booting with quiet on.

menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-932147a3-5af2-48e0-a5fb-f94d686f2b16' {
        set gfxpayload=text
        insmod gzio
        insmod part_gpt
        insmod ext2
        set root='hd1,gpt2'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2  932147a3-5af2-48e0-a5fb-f94d686f2b16
        else
          search --no-floppy --fs-uuid --set=root 932147a3-5af2-48e0-a5fb-f94d686f2b16
        fi
        echo    'Loading Linux linux ...'
        linux   /boot/vmlinuz-linux root=UUID=932147a3-5af2-48e0-a5fb-f94d686f2b16 rw  transparent_hugepage=never nvidia-drm.modeset=1 systemd.unit=default.target
        echo    'Loading initial ramdisk ...'
        initrd  /boot/intel-ucode.img /boot/initramfs-linux.img
}

Idk why it’s in the bug report logs but not in the dmesg

dev ~ # dmesg | grep efifb
dev ~ #

were you browsing a different log?

according to arch wiki efifb is compiled into the kernel.

# zgrep EFI /proc/config.gz 
CONFIG_EFI_PARTITION=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_EFI_MIXED=y
CONFIG_FB_EFI=y
CONFIG_XEN_EFI=y
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
# EFI (Extensible Firmware Interface) Support
# CONFIG_EFI_VARS is not set
CONFIG_EFI_ESRT=y
CONFIG_EFI_RUNTIME_MAP=y
# CONFIG_EFI_FAKE_MEMMAP is not set
CONFIG_EFI_RUNTIME_WRAPPERS=y
CONFIG_EFI_CAPSULE_LOADER=m
# CONFIG_EFI_TEST is not set
CONFIG_UEFI_CPER=y
CONFIG_EFI_DEV_PATH_PARSER=y
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set
CONFIG_EFIVAR_FS=y
CONFIG_EARLY_PRINTK_EFI=y
# CONFIG_EFI_PGT_DUMP is not set

and it is

No I have not tried disabling and uninstalling the driver entirely, yet.
I have tried booting without the nvidia modules in the initrd with the same result.

I’m pretty sure that I could absolutely boot with noveau, but I’m not keen on not having adaptive power switching and no glx.
I don’t know what booting without the driver is supposed to achive, since I’m interested in using the driver and the problem occurs when the driver is used.
If it was a kernel issue then the lts 4.9 kernel would be able to boot and have a console of what ever kind.
But it doesn’t. (yes kernel-lts and nvidia-lts (aka 387.22 for 4.9 kernel) installed)

I did now, again, try booting in gfxmode, with what blablo suggested and I didn’t get past the loading initrd screen.

the “backlight on/off thing” looks like a corrupted display… blue dots on the top left side.
please see photos in the archlinux forum’s thread.

https://lh3.googleusercontent.com/ExFeIriE2S2ZJRq9hp4Imr1FgZqBnM3HEqrR6Y-ec1UBpX-3VnNua73q_9poudiawmYfRkBR20Hdsw
https://lh3.googleusercontent.com/oNY3uhFGkid6GnLeL8deK-lm-X43FrB467uR6YWbqjAICftOLTjSdWwDvMjPP7yCQAA1i6c1xXDT2w

It’s the same blue dots.

Also, aplattner:
I don’t know where you see quiet boot or efifb in the log file. You have the wrong log file.

What the hell, this is not the log file I’ve uploaded.
This forum software is…bad


this is my log

Some more info:

uninstalled nvidia package
turned off vt-d in bios
removed the modules from mkinitcpio.conf
grub mode remained text
booted with noveau
I’m getting a vga console
but I’m not getting an xorg session (cinnamon)

grub mode gfx
system locks, no vga console

installed nvidia package
NOT added nvidia stuff to mkinitcpio.conf MODULES
nvidia-drm.modeset=1 remained in /etc/modprobe.d/nvidia
grub text mode
I’m getting a vga console
but unable to get an xorg session

added nvidia stuff to mkinitcpio.conf MODULES
grub text mode
not getting a vga console or any console at all
but getting an xorg session

however I’m able to ctrl+alt+f2(e.g.) and back to ctrl+alt+f1 without the system crashing

things I’ve noticed:
noveau before switching to vga console displays one horizontal stripe of grey/green short blocks (like 1mm grey|1mm green)
nvidia before switching to vga console displays the blue dots

So now I’m going to try to

sudo mv /etc/X11/xorg.conf.d/20-nvidia.conf ./

and remove the MODULES from mkinitcpio.conf

update

so what actually happens in 3. is:
altough the nvidia package blacklists nouveau in /usr/lib/modprobe.d/nvidia
this is completely ignored
nouveau is loaded (I noticed because of the grey/green blocks)
and nvidia can’t load resulting in xorg not running

however the current config with nvidia loaded and nouveau blacklisted in /etc/modprobe.d/blacklist_nouveau
and

MODULES="nvidia nvidia_modeset nvidia_uvm nvidia_drm"

in /etc/mkinitcpio.conf
results in more of the same, blue dots and no console but xorg running…
goto 10

and the same happens with kernel 4.14.2 and 387.34-6

So what happened between august 10th and november 21st that killed the console?

When nouveau loads, it will do its own modeset to graphics mode, overriding whatever the console was before (assuming you didn’t configure it with the ‘nomodeset’ option). That’s something I’ve considered for the nvidia driver, but I haven’t implemented anything like that yet. For now, the nvidia driver inherits whatever console configuration it got from the kernel.

From your new log from Google Drive, it looks like the kernel is not getting an EFI framebuffer configuration from grub, or maybe it’s not recognizing what grub is telling it. If it did get a framebuffer configuration, it would have initialized efifb and printed lines like the ones I pasted in #3.

Since the nvidia driver doesn’t override the console with its own, then you won’t get a console if the kernel never set one up in the first place. This seems like an interaction problem between grub and the kernel, and nothing fundamentally wrong with the driver.

On a related note, there is no VGA text mode in EFI. To have a console at all, it has to be a framebuffer console of some kind. That’s probably why it complains when you try to set it to “text”.

In the configuration blablo suggested where you say it doesn’t get past the initial ramdisk, can you SSH into the system? If not, my next suggestion would be to set up a serial console, if possible, to see why it’s getting stuck.

I can’t ICMP ping because Networkmanager sets the IP.
And even if I wait 5 minutes I can’t send pings to the configured static IP.

This pretend-professional motherboard doesn’t have a serial port (hardware), but I can toggle “serial port” in the BIOS (woohoo).

I seem to be having a similar problem.

Recovery mode freezes after “loading initial ramdisk…” indefinitely.
I can boot into desktop manager however TTYs don’t work and the screen freezes at the point where it’s supposed to show the console at startup and it resumes once the desktop manager takes over.

TTY screens are blank, however If I login on the TTY blindly and type a command it is executed.

These issues do not occur with the nouveau driver

I’ve tried many of the same things as described in OP to no avail.

====================
Ubuntu 17.10
MOBO: ASUS Maximus VIII Hero
UEFI Mode
GTX 970 with 384.90 driver

$ uname -a
Linux caleb-whiting 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:04:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ hwinfo --gfxcard
22: PCI 100.0: 0300 VGA compatible controller (VGA)
[Created at pci.378]
Unique ID: VCu0.IuoTaz1A7sA
Parent ID: vSkL.uQnIAf5OKS4
SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
SysFS BusID: 0000:01:00.0
Hardware Class: graphics card
Model: “nVidia GM204 [GeForce GTX 970]”
Vendor: pci 0x10de “nVidia Corporation”
Device: pci 0x13c2 “GM204 [GeForce GTX 970]”
SubVendor: pci 0x1462 “Micro-Star International Co., Ltd. [MSI]”
SubDevice: pci 0x3160
Revision: 0xa1
Driver: “nvidia”
Driver Modules: “nvidia”
Memory Range: 0xde000000-0xdeffffff (rw,non-prefetchable)
Memory Range: 0x2fe0000000-0x2fefffffff (ro,non-prefetchable)
Memory Range: 0x2ff0000000-0x2ff1ffffff (ro,non-prefetchable)
I/O Ports: 0xe000-0xe07f (rw)
Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled)
IRQ: 139 (436410 events)
Module Alias: “pci:v000010DEd000013C2sv00001462sd00003160bc03sc00i00”
Driver Info #0:
Driver Status: nvidiafb is not active
Driver Activation Cmd: “modprobe nvidiafb”
Driver Info #1:
Driver Status: nouveau is not active
Driver Activation Cmd: “modprobe nouveau”
Driver Info #2:
Driver Status: nvidia_384_drm is not active
Driver Activation Cmd: “modprobe nvidia_384_drm”
Driver Info #3:
Driver Status: nvidia_384 is not active
Driver Activation Cmd: “modprobe nvidia_384”
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #20 (PCI bridge)

Primary display adapter: #22

you’re also using grub2, I assume?

That’s correct, GRUB is working fine.

I beg to differ.

I got rid of grub2 and am using systemd-boot now.
And I’m getting a console, not a high-res one but it’s a console.

So the problem is with grub2. Version 2.02. Arch’s version 2.02-3

And Aaron’s info is what lead me to this

since the fb is corrupt and grub delivers this fb it has to be grub and it is.

Which kernel are you using? Try linux-4.11 first.

There was an framebuffer-breaking change around linux-4.12 which caused
my framebuffer (and console) to disappear:

[ 0.612863] ioremap on RAM at 0x00000000e0000000 - 0x00000000e167ffff
[ 0.612865] ------------[ cut here ]------------
[ 0.612869] WARNING: CPU: 0 PID: 1 at /usr/src/linux-4.14.2/arch/x86/mm/ioremap.c:119 __ioremap_caller+0x278/0x2c0
[…]
[ 0.612925] —[ end trace c9d1393307cb0050 ]—
[ 0.612927] simple-framebuffer: probe of simple-framebuffer.0 failed with error -12

0a000000-ed260fff : System RAM
e0000000-e167ffff : BOOTFB

for some reason I cannot get efifb to work, but simple-framebuffer did work until 4.11 or 4.12.

However that’s not an nvidia driver problem…

I tried on 4.13 and 4.14 and there is no console at all. therefore I completely disable efifb from kernel. Just curious is the problem for nvidia or also happens to other graphic cards?

Now, after having booted Windows 10 and played “Spellforce 3” I powered off the computer to remember I forgot something and powered it on again.
Now I’m not even getting a BIOS screen anymore. But I’m getting the same blue dots.

But since Linux (arch) is the default OS in systemd-boot, which is switched to,
Linux boots, however it doesn’t boot into Cinnamon but it seems to fail and I get thrown back to sddm @1920x1080, then I enter my password and cinnamon loads as expected at 3840x2160.

https://drive.google.com/open?id=1ZwaIgPUg0k0r1Rh4Ftck6FGROw40jNrZ

I believe my BIOS just died partially or some malicious program wrote some config vars to UEFI, since I dual-boot I have secure-boot off.

I’ve then switched from DP to HDMI without a positive result.

I’ve contacted Amazon, where I bought the GA-X170-EXTREME-ECC motherboard, which should now be the 2nd replacement in 13 months. 1st way in May 2017 and I bought it in October 2016. Gigabyte has shit quality mainboards and their support is so bad that they’re unable to grasp that a motherboard that has ECC in it, and it’s selling point is it supporting ECC RAM and when reading the sales page’s spec it says explicitly that it supports ECC RAM, when this support is asked which ECC RAM modules it supports they respond with “this board doesn’t support ECC RAM”…
The amount of facepalm that was caused by this response is not measurable.
I don’t know how those people even got the job. Not only did it take a week for them to respond, but they respond with this.
Anyhow, quality Gigabyte service. Last time I ever bought a Gigabyte product. I’ve had nothing but problems in the recent years, but hope dies last. They used to make great products, now they don’t. USB being broken is now the 2nd time too. Freaking failsauce company.
Anyhow enough of me ranting.

But hey maybe nvidia is the bad boy here (asus strix gaming 1080 the middle one and it was replaced once too), however I can’t try because I’m not getting into the BIOS, because black screen.
Oh btw I’ve turned off “serial support” because there is no physical connector, maybe this broke EFIFB? I also turned on ERP (aka. power down completely). Fast boot is off.

and those are all available efi vars

4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeExecUSec
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderEntrySelected
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeMenuUSec
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderImageIdentifier
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderDevicePartUUID
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareType
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareInfo
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderInfo
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeInitUSec
1b838190-4625-4ead-abc9-cd5e6af18fe0-HiiDB
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes
b08f97ff-e6e8-4193-a997-5e9e9b0adb32-CpuSetupVolatileData
8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOutDev
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOptionSupport
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConInDev
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOutDev
9cb2e73f-7325-40f4-a484-659bb344c3cd-SOFTWAREGUARDSTATUS
01368881-c4ad-4b1d-b631-d57a8ec8db6b-MeVS
dd41adf5-4368-4654-b1ca-46a6b98d9e84-EasyHealthAddress
dd41adf5-4368-4654-b1ca-46a6b98d9e84-EasyVoltageAddress
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported
01368881-c4ad-4b1d-b631-d57a8ec8db6b-OA3MSDMvariable
e6a01b2b-a795-41f0-85a0-53acaab21d97-SetupXtuBufferAddress
01368881-c4ad-4b1d-b631-d57a8ec8db6b-FPDT_Volatile
8be4df61-93ca-11d2-aa0d-00e098032b8c-PKDefault
8be4df61-93ca-11d2-aa0d-00e098032b8c-KEKDefault
8be4df61-93ca-11d2-aa0d-00e098032b8c-dbDefault
8be4df61-93ca-11d2-aa0d-00e098032b8c-dbxDefault
8be4df61-93ca-11d2-aa0d-00e098032b8c-VendorKeys
8be4df61-93ca-11d2-aa0d-00e098032b8c-SignatureSupport
8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
8be4df61-93ca-11d2-aa0d-00e098032b8c-DeployedMode
8be4df61-93ca-11d2-aa0d-00e098032b8c-AuditMode
80e1202e-2697-4264-9cc9-80762c3e5863-Setup
7b59104a-c00d-4158-87ff-f04d6396a915-SecureBootSetup
d1405d16-7afc-4695-bb12-41459d3695a2-NetworkStackVar
69ecc1be-a981-446d-8eb6-af0e53d06ce8-NewOptionPolicy
5e9a565f-cdc0-413b-ad13-1fe8713ffdcd-PcieSataModVar
90d93e09-4e91-4b3d-8c77-c82ff10e3c81-CpuSmm
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0501_0_NV
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-UsbSupport
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderConfigTimeout
b05e6b5f-6ed8-4015-b5c5-b1049faf3e5b-Profile0
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0008
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0007
eaec226f-c9a3-477a-a826-ddc716cdc0e3-OfflineUniqueIDRandomSeedCRC
eaec226f-c9a3-477a-a826-ddc716cdc0e3-OfflineUniqueIDRandomSeed
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0001
b540a530-6978-4da7-91cb-7207d764d262-FastBootOption
c811fa38-42c8-4579-a9bb-60e94eddfb34-AMITSESetup
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-SetupCpuFeatures
ba57e015-65b3-4c3c-b274-659192f699e3-BugCheckParameter1
ba57e015-65b3-4c3c-b274-659192f699e3-BugCheckCode
ba57e015-65b3-4c3c-b274-659192f699e3-BugCheckProgress
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0000
77fa9abd-0359-4d32-bd60-28f4e78f784b-CurrentPolicy
4b3082a3-80c6-4d7e-9cd0-583917265df1-MaximumTableSize
4b3082a3-80c6-4d7e-9cd0-583917265df1-SmbiosScratchBuffer
4b3082a3-80c6-4d7e-9cd0-583917265df1-SmbiosV3EntryPointTable
4b3082a3-80c6-4d7e-9cd0-583917265df1-SmbiosEntryPointTable
81c76078-bfde-4368-9790-570914c01a65-SetUpdateCountVar
73dad563-8f27-42af-918f-8651eb0a93ef-Ep
46fe2754-75ed-40db-a395-032d70994457-CoolConCRC
46fe2754-75ed-40db-a395-032d70994457-CoolConsole
5432122d-d034-49d2-a6de-65a829eb4c74-MeSetupStorage
2a64d079-aceb-4ad9-afd5-252e35ba994a-EasyTuneSetupAddress
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-AdvMitAttrib
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-MemMitAttrib
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-ProcMitAttrib
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002
45cf35f6-0d6e-4d04-856a-0370a5b16f53-DefaultBootOrder
3c4ead08-45ae-4315-8d15-a60eaa8caf69-DefaultLegacyDevOrder
a56074db-65fe-45f7-bd21-2d2bdd8e9652-LegacyDevOrder
8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOut
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
e20939be-32d4-41be-a150-897f85d49829-MemoryOverwriteRequestControl
bb983ccf-151d-40e1-a07b-4a17be168292-MemoryOverwriteRequestControlLock
8be4df61-93ca-11d2-aa0d-00e098032b8c-Timeout
c60aa7f6-e8d6-4956-8ba1-fe26298f5e87-EPCBIOS
ba1d893b-803e-4b26-a3de-585703ff7bd6-TbtHRStatusVar
4b3082a3-80c6-4d7e-9cd0-583917265df1-WriteOnceStatus
eda41d22-7729-5b91-b3ee-ba619921cefa-IntUcode
074e1e48-8132-47a1-8c2c-3f14ad9a66dc-AmiEntryS3Addr
4da4f952-2516-4d06-8975-65036403a8c7-RstOptaneConfig
35c6ccb8-e380-41ef-5ba7-92850d9a5a0a-PREBOOT CLOCK DATA
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-Setup
98744b1b-d66d-41fd-8e89-80adbd668140-FlexIoData
7d3dceee-cbce-4ea7-8709-6e552f1edbde-TpmServFlags
01368881-c4ad-4b1d-b631-d57a8ec8db6b-MonotonicCounter
97e8965f-c761-4f48-b6e4-9ffa9cb2a2d6-DeploymentModeNv
4599d26f-1a11-49b8-b91f-858745cff824-StdDefaults

the 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-* parts are probably systemd-boot attribs.