Help with blank console post boot - Nvidia

I have a HP Z240 with an Nvidia GTX 1050 card & openSUSE 15.1. I’ve just updated the Nvidia driver from 418 to 440 (installed using the Nvidia “run” file) and I get a blank console screen post boot. The computer is working properly (apart from the blank console): the boot log messages come up (I’ve nosplash in the kernel boot line) and then, part way trough the boot, the screen goes blank. If I ssh into the box & systemctl isolate graphical.target, the lightdm login appears normally. If I then switch back to multi-user.target, the console is blanked.

So, in summary, boot works & post-boot console works & graphical use works but the text console is blank.

Any suggestions where the defect is or what to try next?

Steps I’ve tried (none of which changed the defect on reboot, and all reversed out):

  1. add the nvidia modules to initrd

  2. comment out the nvidia udevd power management rules (https://download.nvidia.com/XFree86/Linux-x86_64/450.80.02/README/dynamicpowermanagement.html)

  3. adding & removing the kernel boot line nomodeset & nvidia.modeset=1 options

Thanks
David

p.s. I don’t know when the problem started … I only know now as I was planning to make some network changes and tried the console to check I could login if I couldn’t ssh in … :frowning:

Does plymouth=0 appended to the line beginning with linu in Grub change anything?

Thanks @mrmazda

dmesg post reboot now reports the kernel command line as

BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp151.28.83-default root=UUID=3644e2c6-bd6f-44fc-a050-71772fd09a26 noresume nosplash nomodeset video=vesafb:off vga=0x034c nvidia.modeset=1 plymouth=0 mitigations=auto

Still the same result. :frowning:

$ rpm -qa | egrep -i plymouth lists no packages.

[FONT=courier new]systemctl list-unit-files --type=service --all | egrep -i plymouth also lists nothing.

[/FONT][FONT=courier new]hwinfo --framebuffer:

[/FONT]

02: None 00.0: 11001 VESA Framebuffer
 [Created at bios.459]
  Unique ID: rdCR.FmCKnhCKcQ7
  Hardware Class: framebuffer
  Model: "NVIDIA BIOS-P/N@N11362"
  Vendor: "NVIDIA Corporation"
  Device: "BIOS-P/N@N11362"
  SubVendor: "NVIDIA"
  SubDevice: 
  Revision: "Chip Rev"
  Memory Size: 16 MB
  Memory Range: 0x01000000-0x01ffffff (rw)
  Mode 0x0301: 640x480 (+640), 8 bits
  Mode 0x0303: 800x600 (+800), 8 bits
  Mode 0x0305: 1024x768 (+1024), 8 bits
  Mode 0x0307: 1280x1024 (+1280), 8 bits
  Mode 0x0311: 640x480 (+1280), 16 bits
  Mode 0x0312: 640x480 (+2560), 24 bits
  Mode 0x0314: 800x600 (+1600), 16 bits
  Mode 0x0315: 800x600 (+3200), 24 bits
  Mode 0x0317: 1024x768 (+2048), 16 bits
  Mode 0x0318: 1024x768 (+4096), 24 bits
  Mode 0x031a: 1280x1024 (+2560), 16 bits
  Mode 0x031b: 1280x1024 (+5120), 24 bits
  Mode 0x0345: 1600x1200 (+1600), 8 bits
  Mode 0x0346: 1600x1200 (+3200), 16 bits
  Mode 0x034a: 1600x1200 (+6400), 24 bits
  Mode 0x034b: 2560x1440 (+2560), 8 bits
  Mode 0x034c: 2560x1440 (+5120), 16 bits
  Mode 0x034d: 2560x1440 (+10240), 24 bits
  Mode 0x0371: 1360x768 (+5440), 24 bits
  Config Status: cfg=no, avail=yes, need=no, active=unknown

I’ve just rerun with ‘verbose’ added to the kernel command line and videoed the messages. Not perfect but it gets me close.

In the video, the last visible logged line is ’ 6.993861] ip_tables: (C) 2000-2006 Netfilter Core Team’

This is the segment of dmesg:

    5.600570] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro,acl,user_xattr    5.818998] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: errors=remount-ro,acl,user_xattr
    5.895194] EXT4-fs (dm-9): mounted filesystem with ordered data mode. Opts: errors=remount-ro,acl,user_xattr
    6.232839] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: errors=remount-ro,acl,user_xattr
    6.280217] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro,acl,user_xattr
    6.322769] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: errors=remount-ro,acl,user_xattr
    6.476366] EXT4-fs (dm-10): mounted filesystem with ordered data mode. Opts: errors=remount-ro,acl,user_xattr
    6.836535] ip6_tables: (C) 2000-2006 Netfilter Core Team
    6.896138] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
    6.987414] resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-
0x000dffff window]
    6.990106] caller _nv000908rm+0x1bf/0x1f0 [nvidia] mapping multiple BARs
**    6.993861] ip_tables: (C) 2000-2006 Netfilter Core Team**
    7.639686] No iBFT detected.
    7.704104] r8169 0000:06:01.0 eth0: link down
    7.704106] r8169 0000:06:01.0 eth0: link down
    9.525412] nvidia-uvm: Loaded the UVM driver, major device number 239.
   11.334097] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
   11.353257] NET: Registered protocol family 17
   12.760837] Netfilter messages via NETLINK v0.30.



‘nvidia-uvm’ is 1.5 secs later so I’d point the finger at the previous line ([nvidia] mapping multiple BARs).

Apologies, this is wrong. Checking the video frame by frame, the last (relevant) command logged is “Started NVIDIA Persistence Daemon.” in this sequence:

Dec 20 13:05:30 XXXXXX systemd[1]: Reached target User and Group Name Lookups.
Dec 20 13:05:30 XXXXXX systemd[1]: Reloading.
Dec 20 13:05:30 XXXXXX systemd[1]: Started Authorization Manager.
Dec 20 13:05:30 XXXXXX systemd[1]: Started Avahi mDNS/DNS-SD Stack.
Dec 20 13:05:30 XXXXXX systemd[1]: Started Daily Cleanup of Snapper Snapshots.
Dec 20 13:05:30 XXXXXX systemd[1]: Started Detect if the system suffers from bsc#1089761.
Dec 20 13:05:30 XXXXXX systemd[1]: Started Login Service.
Dec 20 13:05:30 XXXXXX systemd[1]: Started Machine Check Exception Logging Daemon.
Dec 20 13:05:30 XXXXXX systemd[1]: Started Modem Manager.
Dec 20 13:05:30 XXXXXX systemd[1]: Started Name Service Cache Daemon.
Dec 20 13:05:30 XXXXXX systemd[1]: **Started NVIDIA Persistence Daemon.**
Dec 20 13:05:30 XXXXXX systemd[1]: Started Self Monitoring and Reporting Technology (SMART) Daemon.
Dec 20 13:05:30 XXXXXX systemd[1]: Started SuSEfirewall2 phase 1.
Dec 20 13:05:30 XXXXXX systemd[1]: Started System Logging Service.
Dec 20 13:05:30 XXXXXX systemd[1]: Started System Security Services Daemon.
Dec 20 13:05:30 XXXXXX systemd[1]: Started Update system wide CA certificates.
Dec 20 13:05:30 XXXXXX systemd[1]: Started wicked AutoIPv4 supplicant service.
Dec 20 13:05:30 XXXXXX systemd[1]: Started wicked DHCPv4 supplicant service.
Dec 20 13:05:30 XXXXXX systemd[1]: Started wicked DHCPv6 supplicant service.
Dec 20 13:05:30 XXXXXX systemd[1]: Started wicked network management service daemon.
Dec 20 13:05:30 XXXXXX systemd[1]: Started wicked network nanny service.

with these lines (as above) earlier:

Dec 20 13:05:30 XXXXXX kernel: caller _nv000908rm+0x1bf/0x1f0 [nvidia] mapping multiple BARs
Dec 20 13:05:30 XXXXXX kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team
Dec 20 13:05:30 XXXXXX kernel: **ip_tables: (C) 2000-2006 Netfilter Core Team**
Dec 20 13:05:30 XXXXXX kernel: nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
Dec 20 13:05:30 XXXXXX kernel: No iBFT detected.
Dec 20 13:05:30 XXXXXX kernel: r8169 0000:06:01.0 eth0: link down
Dec 20 13:05:30 XXXXXX kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00>
Dec 20 13:05:30 XXXXXX ModemManager[1057]: <info>  ModemManager (version 1.6.12) starting in system bus...
Dec 20 13:05:30 XXXXXX nscd[1061]: 1061 monitoring directory `/etc` (2)
Dec 20 13:05:30 XXXXXX nscd[1061]: 1061 monitoring file `/etc/hosts` (1)
Dec 20 13:05:30 XXXXXX nscd[1061]: 1061 monitoring file `/etc/resolv.conf` (3)
Dec 20 13:05:30 XXXXXX nscd[1061]: nss_ldap: could not search LDAP server - Server is unavailable
Dec 20 13:05:30 XXXXXX nscd[1061]: nss_ldap: failed to bind to LDAP server ldap://leeds.cerdo: Can't contact LDAP server
Dec 20 13:05:30 XXXXXX nvidia-persistenced[1016]: device 0000:03:00.0 - NUMA memory onlined.
Dec 20 13:05:30 XXXXXX nvidia-persistenced[1016]: device 0000:03:00.0 - persistence mode enabled.
Dec 20 13:05:30 XXXXXX nvidia-persistenced[1016]: Local RPC services initialized

… I need to figure out how to get journalctl to display times in msecs for better clarity.

What if you change the Grub linu line to read only:

noresume mitigations=auto

?

nvidia.modeset=1 overrides nomodeset for NVidia GPUs, which results in the default: " ".

No splash is the default, so nosplash also equates to " ".

root= is included in the initrd, so only needed if trying to override the initrd’s specification, and thus pointless if not trying to override.

vga= only has impact until the kernel initiates KMS, a matter of seconds or less that will have zero impact if Plymouth is in effect.

https://www.kernel.org/doc/Documentation/fb/modedb.txt defines valid values for video=. I don’t see vesafb anywhere in it.

Thanks. I get the same result.

I think (comparing it to other, working systems) that the blackout is happening when the boot sequence changes from efifb (used for the initial logging) to the nvidia console / text mode driver.

The issue may also be some dport signalling magic telling the monitor the driver has gone away. Is there a CLI command to get the NVIDIA console driver to issues a “wake up” to the monitor?

Or is my total ignorance of screen drivers creating phantom solutions.

Thanks
David

p.s. the nvidiafb driver is blacklisted, but removing that doesn’t change anything I could see …

In this: The Framebuffer Console — The Linux Kernel documentation

it says:

GOTCHA: A common bug report is enabling the framebuffer without enabling the framebuffer console. Depending on the driver, you may get a blanked or garbled display, but the system still boots to completion. If you are fortunate to have a driver that does not alter the graphics chip, then you will still get a VGA console.

… how would I enable / load fbcon on boot, assuming this is the problem?

Lower down it says:

Notes for vesafb users:Unfortunately, if your bootline includes a vga=xxx parameter that sets the hardware in graphics mode, such as when loading vesafb, vgacon will not load. Instead, vgacon will replace the default boot console with dummycon, and you won’t get any display after detaching fbcon. Your machine is still alive, so you can reattach vesafb.

… but zs I can see efifb is loaded (in the bot log) I assume this is irrelevant.

I never use NVidia’s proprietary drivers, so can’t test this my self. Check if vga=0x317 or 0x314 or 0x318 instead of vga=0x034c makes any difference with your proprietary driver, with or without nomodeset. I wouldn’t expect so, but…

Thanks. The Nvidia drivers are so I can use the GPU for ML learning …

I check the efibf modes (using videoinfo in grub) and it only listed 3 modes: 640x400x32, 800x600x32 & 1024x768x32. Assuming (as I read somewhere) 24 bit is 32 bit, with the extra 8 bits being alpha channel, I tried these using the hex code fro hwinfo --framebuffer converted to decimal.

No change … :frowning:

I did some checking around console etc, and
$ for X in /sys/class/{graphics,vtconsole}// ; do -f “$X” ] && echo “${X#///} $( cat $X 2>&1 )” ; done

graphics/fb0/bits_per_pixel 32graphics/fb0/blank 
graphics/fb0/bl_curve cat: /sys/class/graphics/fb0/bl_curve: No such device
graphics/fb0/console 
graphics/fb0/cursor 
graphics/fb0/dev 29:0
graphics/fb0/mode 
graphics/fb0/modes U:800x600p-75
graphics/fb0/name EFI VGA
graphics/fb0/pan 0,0
graphics/fb0/rotate 0
graphics/fb0/state 0
graphics/fb0/stride 3200
graphics/fb0/uevent MAJOR=29
MINOR=0
DEVNAME=fb0
graphics/fb0/virtual_size 800,600
graphics/fbcon/cursor_blink 1
graphics/fbcon/rotate 0
graphics/fbcon/rotate_all cat: /sys/class/graphics/fbcon/rotate_all: Permission denied
graphics/fbcon/uevent 
vtconsole/vtcon0/bind 0
vtconsole/vtcon0/name (S) dummy device
vtconsole/vtcon0/uevent 
vtconsole/vtcon1/bind 1
vtconsole/vtcon1/name (M) frame buffer device
vtconsole/vtcon1/uevent 

does the vtconsole/vtcon0/name (S) dummy device mean that I have a dummy console where there should be a 'real" one? How can I find out which ttys are attached to each console device?

Thanks
David

Hi
So nothing changed/missing in grub or /etc/vconsole.conf?

I’ve just reinstalled all installed packages grub & boot & dracut*, and nothing changed.

$ rpm -qa | egrep -i 'boot|grub|linux|kernel|dracut|nouveau|nvidia|plymouth' | sort
dracut-044.2-lp151.2.27.1.x86_64
dracut-tools-044.2-lp151.2.27.1.x86_64
efibootmgr-14-lp151.3.4.x86_64
gfxboot-4.5.50-lp151.1.1.x86_64
gfxboot-branding-openSUSE-15.1-lp151.2.2.noarch
grub2-2.02-lp151.21.30.1.x86_64
grub2-branding-openSUSE-15.1-lp151.2.2.noarch
grub2-i386-pc-2.02-lp151.21.30.1.noarch
grub2-snapper-plugin-2.02-lp151.21.30.1.noarch
grub2-systemd-sleep-plugin-2.02-lp151.21.30.1.noarch
grub2-x86_64-efi-2.02-lp151.21.30.1.noarch
kernel-default-4.12.14-lp151.28.75.1.x86_64
kernel-default-4.12.14-lp151.28.79.1.x86_64
kernel-default-4.12.14-lp151.28.83.1.x86_64
kernel-default-devel-4.12.14-lp151.28.75.1.x86_64
kernel-default-devel-4.12.14-lp151.28.79.1.x86_64
kernel-default-devel-4.12.14-lp151.28.83.1.x86_64
kernel-devel-4.12.14-lp151.28.75.1.noarch
kernel-devel-4.12.14-lp151.28.79.1.noarch
kernel-devel-4.12.14-lp151.28.83.1.noarch
kernel-firmware-20200107-lp151.2.15.1.noarch
kernel-macros-4.12.14-lp151.28.83.1.noarch
kernel-syms-4.12.14-lp151.28.75.1.x86_64
kernel-syms-4.12.14-lp151.28.79.1.x86_64
kernel-syms-4.12.14-lp151.28.83.1.x86_64
libdrm_nouveau2-2.4.97-lp151.2.3.1.x86_64
libselinux1-2.8-lp151.1.30.x86_64
linux32-1.0-lp151.479.1.x86_64
linuxconsoletools-1.5.1-lp151.2.3.x86_64
linux-glibc-devel-4.15-lp151.2.72.noarch
master-boot-code-1.22-lp151.2.2.x86_64
nfs-kernel-server-2.1.1-lp151.7.9.1.x86_64
perl-Bootloader-0.924-lp151.2.3.1.x86_64
perl-Bootloader-YAML-0.924-lp151.2.3.1.x86_64
perl-Linux-Pid-0.04-lp151.2.2.x86_64
python3-jupyter_ipykernel-5.1.0-lp151.1.23.noarch
python3-linux-procfs-0.6-lp151.1.1.noarch
python3-selinux-2.8-lp151.1.1.x86_64
ruby2.5-rubygem-cfa_grub2-1.0.1-lp151.1.1.x86_64
selinux-tools-2.8-lp151.1.30.x86_64
syslinux-4.04-lp151.5.1.x86_64
util-linux-2.33.1-lp151.3.6.1.x86_64
util-linux-lang-2.33.1-lp151.3.6.1.noarch
util-linux-systemd-2.33.1-lp151.3.6.1.x86_64
yast2-bootloader-4.1.26-lp151.2.3.1.x86_64

How would I know if something’s missing?

$ cat /etc/vconsole.conf 
KEYMAP=uk
FONT=lat9w-16.psfu
FONT_MAP=trivial
# find /boot/ /boot/efi/ -xdev -type f | egrep -v '\.mod$' | sort
/boot/backup_mbr
/boot/boot.readme
/boot/config-4.12.14-lp151.28.75-default
/boot/config-4.12.14-lp151.28.79-default
/boot/config-4.12.14-lp151.28.83-default
/boot/EFI/boot/bootx64.efi
/boot/EFI/boot/fallback.efi
/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/EFI/EFI/boot/bootx64.efi
/boot/EFI/EFI/boot/fallback.efi
/boot/EFI/EFI/opensuse/boot.csv
/boot/EFI/EFI/opensuse/grub.cfg
/boot/EFI/EFI/opensuse/grub.efi
/boot/efi/EFI/opensuse/grubx64.efi
/boot/EFI/EFI/opensuse/grubx64.efi
/boot/EFI/EFI/opensuse/MokManager.efi
/boot/EFI/EFI/opensuse/shim.efi
/boot/EFI/opensuse/boot.csv
/boot/EFI/opensuse/grub.cfg
/boot/EFI/opensuse/grub.efi
/boot/EFI/opensuse/grubx64.efi
/boot/EFI/opensuse/MokManager.efi
/boot/EFI/opensuse/shim.efi
/boot/grub2/device.map
/boot/grub2/device.map.old
/boot/grub2/fonts/unicode.pf2
/boot/grub2/grub.cfg
/boot/grub2/grubenv
/boot/grub2/i386-pc/boot.img
/boot/grub2/i386-pc/command.lst
/boot/grub2/i386-pc/core.img
/boot/grub2/i386-pc/crypto.lst
/boot/grub2/i386-pc/efiemu32.o
/boot/grub2/i386-pc/efiemu64.o
/boot/grub2/i386-pc/fs.lst
/boot/grub2/i386-pc/moddep.lst
/boot/grub2/i386-pc/modinfo.sh
/boot/grub2/i386-pc/partmap.lst
/boot/grub2/i386-pc/parttool.lst
/boot/grub2/i386-pc/terminal.lst
/boot/grub2/i386-pc/video.lst
/boot/grub2/locale/ast.mo
/boot/grub2/locale/ca.mo
/boot/grub2/locale/da.mo
/boot/grub2/locale/de_CH.mo
/boot/grub2/locale/de.mo
/boot/grub2/locale/en@quot.mo
/boot/grub2/locale/eo.mo
/boot/grub2/locale/es.mo
/boot/grub2/locale/fi.mo
/boot/grub2/locale/fr.mo
/boot/grub2/locale/gl.mo
/boot/grub2/locale/hr.mo
/boot/grub2/locale/hu.mo
/boot/grub2/locale/id.mo
/boot/grub2/locale/it.mo
/boot/grub2/locale/ja.mo
/boot/grub2/locale/ko.mo
/boot/grub2/locale/lt.mo
/boot/grub2/locale/nb.mo
/boot/grub2/locale/nl.mo
/boot/grub2/locale/pa.mo
/boot/grub2/locale/pl.mo
/boot/grub2/locale/pt_BR.mo
/boot/grub2/locale/ru.mo
/boot/grub2/locale/sl.mo
/boot/grub2/locale/sr.mo
/boot/grub2/locale/sv.mo
/boot/grub2/locale/tr.mo
/boot/grub2/locale/uk.mo
/boot/grub2/locale/vi.mo
/boot/grub2/locale/zh_CN.mo
/boot/grub2/locale/zh_TW.mo
/boot/grub2/themes/openSUSE/ascii.pf2
/boot/grub2/themes/openSUSE/COPYING.CC-BY-SA-3.0
/boot/grub2/themes/openSUSE/DejaVuSans10.pf2
/boot/grub2/themes/openSUSE/DejaVuSans12.pf2
/boot/grub2/themes/openSUSE/DejaVuSans-Bold14.pf2
/boot/grub2/themes/openSUSE/highlight_c.png
/boot/grub2/themes/openSUSE/logo.png
/boot/grub2/themes/openSUSE/README
/boot/grub2/themes/openSUSE/slider_c.png
/boot/grub2/themes/openSUSE/slider_n.png
/boot/grub2/themes/openSUSE/slider_s.png
/boot/grub2/themes/openSUSE/theme.txt
/boot/grub2/x86_64-efi/command.lst
/boot/grub2/x86_64-efi/core.efi
/boot/grub2/x86_64-efi/crypto.lst
/boot/grub2/x86_64-efi/fs.lst
/boot/grub2/x86_64-efi/grub.efi
/boot/grub2/x86_64-efi/moddep.lst
/boot/grub2/x86_64-efi/modinfo.sh
/boot/grub2/x86_64-efi/partmap.lst
/boot/grub2/x86_64-efi/parttool.lst
/boot/grub2/x86_64-efi/terminal.lst
/boot/grub2/x86_64-efi/video.lst
/boot/initrd-4.12.14-lp151.28.75-default
/boot/initrd-4.12.14-lp151.28.79-default
/boot/initrd-4.12.14-lp151.28.83-default
/boot/memtest.bin
/boot/message
/boot/symtypes-4.12.14-lp151.28.75-default.gz
/boot/symtypes-4.12.14-lp151.28.79-default.gz
/boot/symtypes-4.12.14-lp151.28.83-default.gz
/boot/symvers-4.12.14-lp151.28.75-default.gz
/boot/symvers-4.12.14-lp151.28.79-default.gz
/boot/symvers-4.12.14-lp151.28.83-default.gz
/boot/sysctl.conf-4.12.14-lp151.28.75-default
/boot/sysctl.conf-4.12.14-lp151.28.79-default
/boot/sysctl.conf-4.12.14-lp151.28.83-default
/boot/System.map-4.12.14-lp151.28.75-default
/boot/System.map-4.12.14-lp151.28.79-default
/boot/System.map-4.12.14-lp151.28.83-default
/boot/vmlinux-4.12.14-lp151.28.75-default.gz
/boot/vmlinux-4.12.14-lp151.28.79-default.gz
/boot/vmlinux-4.12.14-lp151.28.83-default.gz
/boot/vmlinuz-4.12.14-lp151.28.75-default
/boot/.vmlinuz-4.12.14-lp151.28.75-default.hmac
/boot/vmlinuz-4.12.14-lp151.28.79-default
/boot/.vmlinuz-4.12.14-lp151.28.79-default.hmac
/boot/vmlinuz-4.12.14-lp151.28.83-default
/boot/.vmlinuz-4.12.14-lp151.28.83-default.hmac

… I’ve ommitted the .mod files as there are too many to post.

… here are a few of them …

# find /boot/ /boot/efi/ -xdev -type f | egrep '\.mod$' | egrep 'fb|framebuffer|con' | sort
/boot/grub2/i386-pc/configfile.mod
/boot/grub2/i386-pc/video_fb.mod
/boot/grub2/x86_64-efi/configfile.mod
/boot/grub2/x86_64-efi/video_fb.mod

Would the presence of both EFI & efi directories in /boot be an issue?

# ls -l /boot/{efi,EFI}
/boot/efi:
total 4
drwxr-xr-x 4 root root 4096 Dec 16 17:46 EFI

/boot/EFI:
total 12
drwxr-xr-x 2 root root 4096 Jan  9  2017 boot
drwxr-xr-x 4 root root 4096 Jan  9  2017 EFI
drwxr-xr-x 2 root root 4096 Jan  9  2017 opensuse

# mount | egrep boot
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
# ls -l $( find /boot/{efi,EFI} -xdev -type f | sort )
-rw-r--r-- 1 root root 1164376 Jan  9  2017 /boot/EFI/boot/bootx64.efi
-rw-r--r-- 1 root root   72240 Jan  9  2017 /boot/EFI/boot/fallback.efi
-rwxr-xr-x 1 root root  124416 Dec 16 17:48 /boot/efi/EFI/BOOT/BOOTX64.EFI
-rw-r--r-- 1 root root 1164376 Jan  9  2017 /boot/EFI/EFI/boot/bootx64.efi
-rw-r--r-- 1 root root   72240 Jan  9  2017 /boot/EFI/EFI/boot/fallback.efi
-rw-r--r-- 1 root root      58 Jan  9  2017 /boot/EFI/EFI/opensuse/boot.csv
-rw-r--r-- 1 root root     150 Jan  9  2017 /boot/EFI/EFI/opensuse/grub.cfg
-rw-r--r-- 1 root root  993144 Jan  9  2017 /boot/EFI/EFI/opensuse/grub.efi
-rwxr-xr-x 1 root root  124416 Dec 23 09:27 /boot/efi/EFI/opensuse/grubx64.efi
-rw-r--r-- 1 root root  121856 Jan  9  2017 /boot/EFI/EFI/opensuse/grubx64.efi
-rw-r--r-- 1 root root 1166552 Jan  9  2017 /boot/EFI/EFI/opensuse/MokManager.efi
-rw-r--r-- 1 root root 1164376 Jan  9  2017 /boot/EFI/EFI/opensuse/shim.efi
-rw-r--r-- 1 root root      58 Jan  9  2017 /boot/EFI/opensuse/boot.csv
-rw-r--r-- 1 root root     150 Jan  9  2017 /boot/EFI/opensuse/grub.cfg
-rw-r--r-- 1 root root  993144 Jan  9  2017 /boot/EFI/opensuse/grub.efi
-rw-r--r-- 1 root root  121856 Jan  9  2017 /boot/EFI/opensuse/grubx64.efi
-rw-r--r-- 1 root root 1166552 Jan  9  2017 /boot/EFI/opensuse/MokManager.efi
-rw-r--r-- 1 root root 1164376 Jan  9  2017 /boot/EFI/opensuse/shim.efi

/boot/EFI/, which is new, does not belong, so I suppose it could. Please show input/output from:

  1. mount | grep -i boot
  2. cat /etc/fstab
  3. sudo parted -l
  4. sudo blkid
    *]ls -gG /boot | grep -v 4.12
# mount | egrep -i boot
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
$ egrep -v '^\s*(#|$)|\s/(srv|mnt|windows|usr)/' /etc/fstab 
UUID=3644e2c6-bd6f-44fc-a050-71772fd09a26  /                   ext4     acl,user_xattr  1  1
none                                       /tmp                tmpfs    rw,size=4G      0  0
UUID=ecf69986-ba01-43f5-9a6d-1b3f84b2373e  /home               ext4     errors=remount-ro,acl,user_xattr,relatime,nosuid,nodev  1  0
UUID=703E-FC52                             /boot/efi           vfat     defaults        0  0
# parted -l /dev/sda
Model: ATA Corsair Force 3 (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: :~> 
Number  Start   End     Size    File system  Name       Flags
 1      2097kB  4194kB  2097kB               bios_boot  bios_grub
 2      4194kB  273MB   268MB   fat16        EFI        msftdata
 4      52.9GB  104GB   51.5GB  ext4         opensuse   legacy_boot
# blkid /dev/sda*
/dev/sda: PTUUID="b718835a-d3fe-4fd2-b698-c54a6df6e6cf" PTTYPE="gpt"
/dev/sda1: PARTLABEL="bios_boot" PARTUUID="1ac68613-ddeb-4ae6-b15f-8de772a5b1c8"
/dev/sda2: SEC_TYPE="msdos" UUID="703E-FC52" TYPE="vfat" PARTLABEL="EFI" PARTUUID="b429db6d-4f3d-411a-9a3a-628e1d72325f"
/dev/sda4: LABEL="opensuse" UUID="3644e2c6-bd6f-44fc-a050-71772fd09a26" TYPE="ext4" PTTYPE="dos" PARTLABEL="oxford" PARTUUID="68bc097a-134e-4bf7-99e6-dfb000e583b8"
# ls -gG /boot | grep -v '4\.12'
total 90036
-rw-r--r-- 1     512 Mar 24  2019 backup_mbr
lrwxrwxrwx 1       1 Apr 19  2015 boot -> .
-rw-r--r-- 1    1725 Jul 13  2019 boot.readme
drwxr-xr-x 2    4096 Aug 26 12:03 dracut
drwxr-xr-x 3   16384 Jan  1  1970 efi
drwxr-xr-x 5    4096 Jan  9  2017 EFI
drwxr-xr-x 7    4096 Dec 23 09:27 grub2
drwxr-xr-x 2    4096 Jan  9  2017 lost+found
-rw-r--r-- 1  182704 Dec 17  2018 memtest.bin
-rw-r--r-- 1  423424 Dec 23 09:26 message

This https://en.opensuse.org/openSUSE:UEFI make it look like the EFI partition should be mounted at /boot/efi but the contents of the directories makes me think it should be mounted at /boot/EFI.

Should I merge /boot/EFI into /boot/efi, preserving the current /boot/efi contents?

I have no idea why you have /boot/EFI or /boot/dracut. I’ve never seen in fstab ‘errors=remount-ro’ for /home or in an openSUSE installation. These make it look to me like 15.1 was installed over the top of a Debian or Fedora installation without formatting /dev/sda4 (openSUSE /). It’s hard to tell what’s what without all the information I asked for. Fstab shows a /home filesystem that is absent from fdisk output.

/home is elsewhere, on an LVM LV. There are another 8-10 irrelevant mounts (e.g. /usr/src, /srv, /opt, /mnt/…) also. This machine predates containers so, at the time, everything ran in one physical server. It’s still like that because, if it ain’t broke, don’t fix it.

This system has always been openSUSE … I don’t remember how far back. I think the last time I did a “clean” install on it was the first Leap version. It’s been upgraded through versions since.

As the problem is occurring in the early stages of boot, and none of the other mounts affect /boot, /etc or any of the other parts of the core system, how they matter?

… and before you say “do a clean install each time” … my answer is the time it takes to identify and copy over the relevant config files from /etc, or reconfigure through the GUIs or CLIs. Distributions and their upgrade have not been designed for long lived systems.

2017 looks about right for the time I got rid of the separate /boot partition … by the simple process of removing it from fatab, umounting it, remounting elsewhere & cp -a to create all the files in the now empty /boot dir. I probably have a pre-change backup somewhere so could check if it made any difference to anything.

This box was non-EFI for a time as I had multi-boot with 2 different windows installs because of software I only had available on windows. They were converted into VMs at least 5 years ago. As part of that change it became headless, accessed firstly through vnc and later x2go. I think (but couldn’t swear) that I added the SSD disk at that time also and created the LVM LVs on the 2 x 2TB HDDs installed for the various mounted directories, and a few extra for such things as /usr/src.

All in all, this computer has had a long and happy life with openSUSE.