Black Screen of death with leap 42.3 discraceful

System worked fine yesterday. this morning all attempts result in a black screen with mouse pointer that moves. Ctrl-Alt-f2 allows login to console session but the KDE-Desktop is dead. No theme (crazy little green lightbulb), no left right click, no F2, no taskbar nothing.

Really not happy that opensuse would release a broke system. KDE works in 13.2 42.1 and 42.2 did some one ASS-U-ME it was just ok in 42.3. More important how do I get the desktop back.

And there were no changes (e.g.software updates) between the boot taht went flawless andf this morning.

When you say it worked fine yesterday, you hardly can say

that opensuse would release a broke system. 

What has changed today? Maybe an update? There have been reports of trouble with kernel 4.4.90: do you have it installed? Can you boot a previous kernel successfully?

What graphics driver do you use?
I use proprietory nvidia and that happens to me when there’s a change in X and the like. I just reload nvidia and all is well.

  1. Is the “root” partition file system Btrfs?
  2. Is there enough free space? – Check with “df -h” – user “root” in a VT.
  3. Have the Btrfs maintenance cron jobs been running? – user “root” in a VT – “systemctl rescue” – root password – ‘cd’ to “/etc/cron.weekly/” and run ‘btrfs-balance’ and then ‘btrfs-trim’ – cd to “/etc/cron.monthly/” and run ‘btrfs-scrub’ – reboot.
  4. Check that “snapper” is automatically cleaning up the Btrfs snapshots: “snapper list” (need to use the user ‘root’).

Normally “snapper” automatically cleans up the used disk space: openSUSE documentation is here: <https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.snapper.html&gt; – take special note of section 3.6 “Automatic Snapshot Clean-Up”.

Two identical Acer Aspire E1-512-6660 machines, 4 core 2.6GHz , Intel HD graphics 4400 1792MB video memory, 6GB memory
My machine upgraded 13.2 -> 42.1 -> 42.2 -> 42.3 appears to be working fine in normal mode. Used the recovery mode to check my machine before advising the person with the exact same set-up 3000 miles away and when you try to boot the recovery mode, it shows ‘Fail’ on almost every systemd entry leaving you with no xdisplay, and no CLI just a frozen screen. Restart in normal and my system comes back with no issues.

My friends machine, we were using testdisk to recover lost files on an attached harddrive and all seemed fine. She shut down for the night and called me frantic the next day to say all she has is a black screen. We tried various methods to get to a CLI to shutdown/reboot or Logout and finally had to use a forced shutdown. At one point she reported that she was able to logout and back in again but to a black screen once again. Since I posted for help, I have found out from this non-pc person that she got screens of ‘Failed’ sysemd processes covering everything from login, password, devices (/dev) and so forth as the system boots. We tried booting to the recovery mode and all the lines say ‘Fail’.

From what I got from her when I posted it seemed we were dealing with KDE desktop crash but now it would appear that Leap 42.3 in both upgraded
(my system) and fresh install (her system) are to blame. Since upgrading my system to 42.3 I have shut off auto-updates because it keeps breaking vlc stuff and reporting conflicts with kernel version. I am using the main repos only.
We are using :

  • opensuse Leap 42.3
  • KDE Plasma 5.8.7
  • KDE Framework 5.32.0
  • QT 5.6.2
  • Kernel 4.4.87-25-default
  • OS 64 bit.

Sorry but I don’t trust Btrfs we use ext4 for all linux and NTFS for her data partition mounted/attached to $home/mydata. space should not be an issue as we have 6GB swap, 60GB free of 192GB on ext4, and 397GB free of 749GB on the NTFS.
I Tried Btrfs on my other machine with leap 42.2 and file corruption errors at every single boot using a new known good harddisk. Since going back to ext4 on that system it clicks along perfect. I also don’t have snapper installed on any of my systems since ext4 is supposed to avoid fragmentation by always using first available freespace large enough to hold the file with-out splitting it up and compact freespace as you go.

Use of CLI stuff presumes you can boot to a CLI console. It appears what is needed for console mode is failing at bootup. I can’t recall the command at boot menu to invoke single-user / tty mode. I think it was press ‘E’ at boot option screen and type in something.

On Mon 23 Oct 2017 05:36:02 PM CDT, techwiz03 wrote:

dcurtisfra;2842758 Wrote:
>
> > >

  • Is the “root” partition file system Btrfs?
  • Is there enough free space? – Check with “df -h” – user “root”
    > in a VT.
  • Have the Btrfs maintenance cron jobs been running? – user “root”
    > in a VT – “systemctl rescue” – root password – ‘cd’ to
    > “/etc/cron.weekly/” and run ‘btrfs-balance’ and then ‘btrfs-trim’ –
    > cd to “/etc/cron.monthly/” and run ‘btrfs-scrub’ – reboot.
  • Check that “snapper” is automatically cleaning up the Btrfs
    > snapshots: “snapper list” (need to use the user ‘root’).
    > > >
    >
    Normally “snapper” automatically cleans up the used disk
    > space: openSUSE documentation is here: <http://tinyurl.com/go6uw52&gt; –
    > take special note of section 3.6 “Automatic Snapshot Clean-Up”.
    >
    >
    Sorry but I don’t trust Btrfs we use ext4 for all linux and NTFS for her
    data partition mounted/attached to $home/mydata. space should not be an
    issue as we have 6GB swap, 60GB free of 192GB on ext4, and 397GB free of
    749GB on the NTFS.
    I Tried Btrfs on my other machine with leap 42.2 and file corruption
    errors at every single boot using a new known good harddisk. Since going
    back to ext4 on that system it clicks along perfect. I also don’t have
    snapper installed on any of my systems since ext4 is supposed to avoid
    fragmentation by always using first available freespace large enough to
    hold the file with-out splitting it up and compact freespace as you go.

Use of CLI stuff presumes you can boot to a CLI console. It appears what
is needed for console mode is failing at bootup. I can’t recall the
command at boot menu to invoke single-user / tty mode. I think it was
press ‘E’ at boot option screen and type in something.

Hi
It could be the backported drm kmp… is drm-kmp-default installed, if
so remove that and see if it helps. If it does the zypper al
drm-kmp-default it.


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.87-18.29-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

drm-kmp-default … yep zypper says it is installed by default and required. I Liked the power and simplicity of opensuse, the look and feel of KDE but I am left now to feel opensuse = Microsoft (untrustworthy , broken)

With 13.2 I could try and fix things that are malfunctioning but Leap is too big a leap. I can’t even identify where the problems are coming from anymore. The forum tries to help me to help another 3000 miles away but I just keep missing stuff. What TF is drm-kmp-defsult and why would it be installed. Is it like that **** Microsoft played with called drm??. Btrfs seems to be a copy of the crappy restore points that never worked in Microsoft products too. If I wanted a MS copycat I buy MS.

Point is that this problem has uncovered flaws in Leap 42.3 on my system (specifically that the recovery mode doesn’t work) and in general that I may face catostrophic failure in the future. My friend has a totally broken system that I can’t adivise on or help her fix after spending 9 x 8 hour days recovering files she is left with no system and can’t access the recovered work. I don’t have a clue what to try next. BTW zypper won’t remove the drm-kmp-default it says it is required.

Direct Rendering Manager. You had it on 13.2 too, you just didn’t know. drm-kmp-default in this case backports drivers from 4.9 series of kernel that bring fixes and support for some devices but unfortunately also problems on some specific hardware setups.

Restore point is essentially a snapshot (shadow volume copy, to be precise) whereas BTRFS is an entire file system with features way beyond simple snapping. Pooling, multi-device spanning, snapshotting - these are just a few of the functions that it provides that Linux was lacking in a single system. You may not need them but people who run larger systems or setups do.

BTRFS has issues and some of the SUSE defaults on openSUSE (much less so on SLE) are a bit ill designed for home use but it’s getting better on every release.

You can still remove it.

Edit:
I bet you haven’t paid a dime for SUSE to this date and gotten everything, including support, for free here - am I right? If so, you might want to, you know, be a little nicer to people trying to help you.

Hi
So what is the full output when you try and remove the drm-kmp-default?

Alas I don’t use KDE/Plasma, I do use btrfs though and had to rollback a couple of times with Tumbleweed, had no issues across all my other machines in day to day running so far with btrfs.

I had issues with that drm kmp package on 42.3 with my amdgpu driver (GCN 1.1 enabled) hence I removed and locked (black screen and mouse pointer only) and all been good since.

Not looking to step on toes. I evaluate hardware, software, and OS’s based upon performance and reliability. If an item has issues it fails the test and should not be released to general population. To do such is like Microsoft Claiming their new OS is a perfect finished piece of work which is false.

ext2, ext3, ext4 worked with no issues but reiserfs xfs, ufs were more bother than they were worth and Btrfs failed a simple zero-fault-tolerance test which means you can’t trust Btrfs with anything important. I also don’t like fat16/32/NTFS because they also don’t pass zero-fault-tolerance but since
windose requires them what choice do we have.

So have confidence with ext2/3/4 and no trust in Btrfs, All hype no substance by direct experience. Had confidence with 13.2 and as far I used Leap 42.1/2 appeared ok now can’t trust it. because 42.3 seems too unstable. Recovery mode in upgrade and fresh install fail so no security to be able to fix troubles. Using opensuse Leap/42.3-oss and opensuse Leap42.3-Update as the only two repos there should not be kernel conflicts and versions conflicts at updates. ‘systemd’ obviously has issues or maybe ‘/’ is corrupt but since I can’t get to the pc, and my pupil/friend can’t get to desktop or CLI our hands are tied.

In super user terminal:


pass:
zypper rm drm-kmp-default
access denied

I have the Intel HD Graphics 4400 and zypper info drm-kmp-default indicates it’s kernel drivers for upgrading to 4.9.x kernels but mine is the 4.4.87-25 so I am confused. To me it is as you say removeable, so why would zypper not say anything except access denied or is that coming from somewhere else???

13.2, 42.1, 42.2 are EOL 42.3 will soon be EOL and is crashed so can’t even get our recovered files off the home folder to a safe back-up, or i’d just have her re-install Leap 42.3 fresh so we can find a working Linux version to replace it with. GeckoLinux might be a safer fit.

On Mon 23 Oct 2017 11:16:02 PM CDT, techwiz03 wrote:

malcolmlewis;2842791 Wrote:
> Hi
> So what is the full output when you try and remove the
> drm-kmp-default?
>
> Alas I don’t use KDE/Plasma, I do use btrfs though and had to
> rollback a couple of times with Tumbleweed, had no issues across all
> my other machines in day to day running so far with btrfs.
>
> I had issues with that drm kmp package on 42.3 with my amdgpu driver
> (GCN 1.1 enabled) hence I removed and locked (black screen and mouse
> pointer only) and all been good since.

In super user terminal:

Code:

pass:
zypper rm drm-kmp-default
access denied

I have the Intel HD Graphics 4400 and zypper info drm-kmp-default
indicates it’s kernel drivers for upgrading to 4.9.x kernels but mine is
the 4.4.87-25 so I am confused. To me it is as you say removeable, so
why would zypper not say anything except access denied or is that coming
from somewhere else???

13.2, 42.1, 42.2 are EOL 42.3 will soon be EOL and is crashed so can’t
even get our recovered files off the home folder to a safe back-up, or
i’d just have her re-install Leap 42.3 fresh so we can find a working
Linux version to replace it with. GeckoLinux might be a safer fit.

Hi
How are you changing to root user, if you can’t zypper rm as root user
sounds like your filesystem is read only?

The drm-kmp are 4.9 backports use zypper if to see about it.


Backported drm kernel modules for upgrading to the 4.9.x kernel
implementations. This is mainly for supporting Intel Kabylake graphics,
but also for bringing up / fixing the other graphics devices.


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.87-18.29-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Terminal - Super user mode, enter password, and run what you want. I have zypper’d up|dup|install|rm many times but ever so often zypper complains with access denied.

I am hoping my friend didn’t wipe the GeckoLinux-liveKDEplasma flashdrive. Maybe we can copy the acer home folder to another flashdrive and open up the possibilities to wipe /dev/sda2 clean and install a linux which isn’t so problematic.
Leap 42.3 … can it really be trusted??
Tumbleweed … bleeding edge means not for noobs
GeckoLinux … Based on 42.1 with very long use cycle … I haven’t tested it to know if it is stable and will do as needed.
Ubuntu. Kubuntu, RedHat, Mandriva were not an enjoyable experience for me so they are not going to work at all for a noob.

Hi
How su or su -? Please show the output from the command;


mount


rick@linux:~> mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) 
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=2986096k,nr_inodes=746524,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) 
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) 
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) 
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) 
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-
cgroups-agent,name=systemd) 
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) 
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) 
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) 
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) 
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) 
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) 
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) 
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) 
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) 
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) 
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) 
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) 
/dev/sda5 on / type ext4 (rw,relatime,data=ordered) 
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=23,pgrp=1,timeout=0,minproto=5,maxproto=5,direct) 
mqueue on /dev/mqueue type mqueue (rw,relatime) 
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) 
debugfs on /sys/kernel/debug type debugfs (rw,relatime) 
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=
iso8859-1,shortname=mixed,utf8,errors=remount-ro) 
/dev/sda4 on /home/rick/e_mydata type vfat (rw,nosuid,nodev,noexec,relatime,gid=100,fmask=0002,dmask=0002,allow_utime=0020,
codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro) 
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=598740k,mode=700,uid=1000,gid=100) 
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) 
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100) 
rick@linux:~>     


All I can see out of the mount command is that sda1,and sda4 are remounted read-only if errors detected

Hi, stepping in as Malcolm is likely sleeping now.
To boot to single user mode (once known as “runlevel 3”) press E at the boot menu, look for a line beginning with “linux” or “linuxefi”, append “3” (without quotes) to that line and F10 to boot. You should land to a console login, login as normal user, then “su -” if root privileges are needed.
If the trouble is with drm / graphics / X11 as is likely you should be able to bypass that problem and issue system commands like zypper and the like.
I see nothing strange in your “mount” results. Please don’t clutter the thread with extra considerations for now, let’s rescue the broken system first, then you might consider how to move on.

  • Are they dual-boot systems?
  • Does this issue usually happen when a file in the NTFS partition is opened and/or accessed by a KDE application?
  • Does the KDE indexing service attempt to index the NTFS partition? – (You should forbid the indexing of all partitions which are not local and Linux-pure.)

“Snapper” is Btrfs-only.

Not dual boot we run windows from virtualbox with the NTFS as shared drive.
Day before the problem we used testdisk (a linux app) to recover a huge folder on the NTFS and save it to the home folder with intent to move this saved folder to a flashdrive the following day.
I have KDE indexing on only for the ext4 partition