SOLVED weird boot, graphics, monitors

[adhefe]

Hi,
I've run into problems I cannot understand. Today the boot did not go, stopped with no apparent reason. In failsafe mode, attempts to startplasma-X11 retuned no connection to X server. I've tried drakconf and then upon rebooting I got messages like,

Code: Select all

Detected  loaded display driver kernel module which conflicts with the driver the X server is configured to use. Startup of the X server may now fail.

and it really failed until I remove /etc/X11/xorg.conf and, again, tried drakconf. Although the message of driver conflict above was still there,
then, I could go to graphical mode but my second terminal is not recognized. Checking xorg.conf, I see it is there marked to appear "Rightof" terminal 1.
I've reinstalled kernel and the message on driver conflict was gone but I still don't have my second monitor.
The second monitor is OK and is recognized if I boot with the Mageia 7 live USB.
Everything was Ok up to last night.

Sorry for this long report but I really cannot understand what is going on.

Any one else with similar problems?

Kernel packages:

Code: Select all

kernel-desktop-devel-6.6.50-1.mga9
kernel-desktop-devel-latest-6.6.50-1.mga9
kernel-desktop-latest-6.6.50-1.mga9
kernel-userspace-headers-6.6.50-1.mga9
kernel-desktop-6.6.50-1.mga9

Nvidia packages:

Code: Select all

lib64nvidia-egl-wayland1-1.1.11-1.mga9
nvidia-cuda-toolkit-12.1.1-1.mga9.nonfree
nvidia-cuda-toolkit-devel-12.1.1-1.mga9.nonfree
nvidia-current-utils-550.100-1.mga9.nonfree
dkms-nvidia-current-550.100-1.mga9.nonfree
nvidia-current-doc-html-550.100-1.mga9.nonfree
x11-driver-video-nvidia-current-550.100-1.mga9.nonfree
nvidia-current-cuda-opencl-550.100-1.mga9.nonfree

[adhefe]

I've unplugged the second monitor, reboot, and plugged again. The system sees the second monitor and asks to choose the configuration (extend to the right or to left, etc) but tge second monitor is not activated regardless of the choice.

[adhefe]

Nvidia is not in control. This is a hybrid graphics pc. Intel graphics control the video.

[doktor5000]

Your description overall is quite confusing, it would help if you would post your actual xorg.conf and also an actual Xorg log.

[doktor5000]

Hi, doktor5000, thanks for the reply,

It follows xorg.conf and Xorg.0.log.
I've run into similar problem in the past with the same hardware I have now. I've filed https://bugs.mageia.org/show_bug.cgi?id=28825 and also discussed here in this forum in https://forums.mageia.org/en/viewtopic.php?f=23&t=13981.
Now it seems a bit different.
Thanks in advance

[doktor5000]

You make it more confusing - the bugreport is about an issue following an upgrade from mga7 to 8 and not normal operation during a Mageia release after regular updates.
You also mention in the bugreport that you use mageia-prime but now you mention here that you only use Intel graphics - why use mageia-prime then at all ?

Also https://forums.mageia.org/en/viewtopic.php?f=23&t=13981 is mainly about your questions about mgaapplet and your general ugrade questions and has nothing to do with graphics driver, you just hijacked that thread in the end about something that has nothing to do with the thread.
Hijacking other threads is discouraged, please keep that in mind.

Back to topic, for your xorg.conf, I'd probably remove all the modeline definitions, the section about the nvidia card,
and not hardcode the screen layout in the xorg configuration (serverlayout section) but handle that during runtime dynamically with xrandr or the means of your desktop environment (kscreen for plasma).

[adhefe]

I'm sorry for the confusion.
I'm really lost with this problem.
I turned off the computer last saturday night and everything was OK but I could no longer boot it on sunday morning.
Last udate was done on thursday so I cannot think my problems has something to do with the kernel updates because it was OK on boot friday and saturday.

The problem evolved from messages during boot about timeout related to network, going to messages like

Code: Select all

It was detected the loaded kernel module exhibition and it is in conflict with the X server driver that is configured to use. Initialization of X server may fail.

to now equally new messages of

Code: Select all

Failed to start network.sevice

This as I kept trying to have the graphical section back.
Since I could not relate the problems to any reasonable cause, I've consider any kind of malware and, in an attempt to recover,
I've reinstalled kernel, x11-nvidia-drivers, and recover the graphical session. Then, I've updated clamav database and did

Code: Select all

clamscan -r --bell -i /

No infected files.
I apologize having hijacked topics in the past.
I mention that topic because there I've mention mageia-prime (this is a hybrid graphics notebook).
BTW, I've uninstall mageia-prime, reinstalled it, with no luck.

Back to the topic,
xorg.conf was created by MCC. I did not edit it.
As one can see, xorg.conf has configurations for two monitors which means drakconf saw them.
However, xrandr sees only one:

Code: Select all

$ xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 340mm x 190mm
   1920x1080     60.00*+  59.93    48.00

Also KDE screen configuration does not help since it also sees only one monitor.
Really intriguing, If I unplug monitor 2 (HDMI) and plug again, a request for configuration pop up but no configuration happens to activate it. It is seen but never activated.

Doktor5000, you suggested that I manually edit xorg.conf and try xrandr or KDE's configuration. Given that xrandr and KDE does not see the second monitor, do you still suggest I do it?

[adhefe]

Forgot to say that I've tried booting older kernels as well. No luck either. However something is different: the message on exhibition driver loaded and conflicting still pop up in older kernels (because I did not reinstalled them?) and upon turning off from older kernels there seems to appear (sometimes and for a second) the mageia splash on the second monitor.

[adhefe]

Found this in dmesg on mdmonitor-takeover.service:

Code: Select all

[    5.524787] systemd[1]: Starting lvm2-monitor.service...
[    5.525713] systemd[1]: Starting mdmonitor-takeover.service...
[    5.526728] systemd[1]: Starting modprobe@configfs.service...
[    5.527723] systemd[1]: Starting modprobe@dm_mod.service...
[    5.528725] systemd[1]: Starting modprobe@drm.service...
[    5.529746] systemd[1]: Starting modprobe@fuse.service...
[    5.530803] systemd[1]: Starting modprobe@loop.service...
[    5.531950] systemd[1]: Starting systemd-fsck-root.service...
[    5.533690] systemd[1]: Starting systemd-journald.service...
[    5.534877] systemd[1]: Starting systemd-modules-load.service...
[    5.534931] systemd[1]: systemd-pcrmachine.service was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).


Does it means anything?

[doktor5000]

Maybe you should attach a full journalctl -ab log here after a fresh boot as
you mentioning that there were some errors here and there, for graphical driver and then also for network does not help with troubleshooting the cause.

in an attempt to recover, I've reinstalled kernel, x11-nvidia-drivers, and recover the graphical session.

You mentioned that you only use Intel. As I've mentioned previously in the bugreport you also mentioned mageia-prime.
If you only use Intel, why reinstall anything nvidia related? Sorry but that doesn't make any sense.

[adhefe]

The idea is to install mageia-prime to make use of the GPUs.
I meant intel's driver is in charge (as far as I know) of regular video. Nvidia is activated only for GPU applications.
By now, until I overcome this second monitor problem, mageia-prime is not installed.
I'm attaching journalctl here,

[adhefe]

There are reports of similar problems, on wayland use, so I install wayland to check. No change, neither the login choice which shows only plasma(X11).
How do I reinstall X11 and Wayland? Just in case reinstallation corrects for any misconfiguration.

[doktor5000]

Reinstalling X or wayland packages does not fix broken configuration, config files are usually tagged with %config or %config(noreplace) so that admin configuration is not overwritten.

I don't see any obvious issues related to X server or your desktop session, seems to start normal.

Apart from that, your Seagata SATA disk seems to have some unrecovered read errors, this looks like a broken disk that should be replaced as auto-reallocate already failed.

Code: Select all

set 24 17:53:03 localhost.localdomain kernel: ata1.00: exception Emask 0x0 SAct 0x80 SErr 0x0 action 0x0
set 24 17:53:03 localhost.localdomain kernel: ata1.00: irq_stat 0x40000008
set 24 17:53:03 localhost.localdomain kernel: ata1.00: failed command: READ FPDMA QUEUED
set 24 17:53:03 localhost.localdomain kernel: ata1.00: cmd 60/60:38:20:4f:dd/00:00:01:00:00/40 tag 7 ncq dma 49152 in
                                                       res 41/40:60:30:4f:dd/00:00:01:00:00/00 Emask 0x409 (media error) <F>
set 24 17:53:03 localhost.localdomain kernel: ata1.00: status: { DRDY ERR }
set 24 17:53:03 localhost.localdomain kernel: ata1.00: error: { UNC }
set 24 17:53:03 localhost.localdomain kernel: ata1.00: configured for UDMA/133
set 24 17:53:03 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
set 24 17:53:03 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#7 Sense Key : Medium Error [current]
set 24 17:53:03 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#7 Add. Sense: Unrecovered read error - auto reallocate failed
set 24 17:53:03 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#7 CDB: Read(10) 28 00 01 dd 4f 20 00 00 60 00
set 24 17:53:03 localhost.localdomain kernel: I/O error, dev sda, sector 31280944 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
set 24 17:53:03 localhost.localdomain kernel: ata1: EH complete
set 24 17:53:03 localhost.localdomain kernel: ata1.00: exception Emask 0x0 SAct 0x21 SErr 0x0 action 0x0
set 24 17:53:03 localhost.localdomain kernel: ata1.00: irq_stat 0x40000008
set 24 17:53:03 localhost.localdomain kernel: ata1.00: failed command: READ FPDMA QUEUED
set 24 17:53:03 localhost.localdomain kernel: ata1.00: cmd 60/08:00:30:4f:dd/00:00:01:00:00/40 tag 0 ncq dma 4096 in
                                                       res 41/40:08:30:4f:dd/00:00:01:00:00/00 Emask 0x409 (media error) <F>
set 24 17:53:03 localhost.localdomain kernel: ata1.00: status: { DRDY ERR }
set 24 17:53:03 localhost.localdomain kernel: ata1.00: error: { UNC }
set 24 17:53:03 localhost.localdomain kernel: ata1.00: configured for UDMA/133
set 24 17:53:03 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
set 24 17:53:03 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Medium Error [current]
set 24 17:53:03 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: Unrecovered read error - auto reallocate failed
set 24 17:53:03 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 01 dd 4f 30 00 00 08 00
set 24 17:53:03 localhost.localdomain kernel: I/O error, dev sda, sector 31280944 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
set 24 17:53:03 localhost.localdomain kernel: ata1: EH complete
[...]
set 24 17:53:06 localhost.localdomain kernel: ata1.00: exception Emask 0x0 SAct 0x8000 SErr 0x0 action 0x0
set 24 17:53:06 localhost.localdomain kernel: ata1.00: irq_stat 0x40000008
set 24 17:53:06 localhost.localdomain kernel: ata1.00: failed command: READ FPDMA QUEUED
set 24 17:53:06 localhost.localdomain kernel: ata1.00: cmd 60/08:78:30:4f:dd/00:00:01:00:00/40 tag 15 ncq dma 4096 in
                                                       res 41/40:08:30:4f:dd/00:00:01:00:00/00 Emask 0x409 (media error) <F>
set 24 17:53:06 localhost.localdomain kernel: ata1.00: status: { DRDY ERR }
set 24 17:53:06 localhost.localdomain kernel: ata1.00: error: { UNC }
set 24 17:53:06 localhost.localdomain kernel: ata1.00: configured for UDMA/133
set 24 17:53:06 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#15 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
set 24 17:53:06 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#15 Sense Key : Medium Error [current]
set 24 17:53:06 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#15 Add. Sense: Unrecovered read error - auto reallocate failed
set 24 17:53:06 localhost.localdomain kernel: sd 0:0:0:0: [sda] tag#15 CDB: Read(10) 28 00 01 dd 4f 30 00 00 08 00
set 24 17:53:06 localhost.localdomain kernel: I/O error, dev sda, sector 31280944 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
set 24 17:53:06 localhost.localdomain kernel: ata1: EH complete

[adhefe]

OK!
I'll try fsck. Would you say that this disk errors could be the real cause of my problems?
Thanks a lot!

[doktor5000]

fsck can only repair filesystems, not a broken disk.

For your question, I have no clue as you've not posted your filesystem layout.

[morgano]

If the disk is not reliable, anything can and will go wrong.
Make sure you have backups of everything important before it breaks more...!
I even had a new drive with problems once, took time to prove and convince the seller, and before that paid a windows guru (W95 times...) to try to fix the system, in vain.
Be happy there is so good logging nowadays

[adhefe]

fsck can only repair filesystems, not a broken disk.

For your question, I have no clue as you've not posted your filesystem layout.

This is /etc/fstab:

Code: Select all

$ cat /etc/fstab
# Entry for /dev/sdb1 :
UUID=ae29d4dc-eefa-4f63-bb09-bc71884913e1 / btrfs defaults 1 1
# Entry for /dev/sdb2 :
UUID=C25E-24D3 /boot/EFI vfat defaults,umask=000 0 0
# Entry for /dev/sda1 :
UUID=c0bc8328-86ce-4d09-a2f7-01a3c18b4292 /home ext4 defaults 1 2
none /proc proc defaults 0 0
/dev/nvme0n1p1 swap swap defaults 0 0

It's intriguing that a problem related to mageia installation itself could be caused by a problem in the disk where I only have /home.
Mageia installation is on /dev/sdb1 and the DRDY ERR is (as far as I understood) on /dev/sda.
The problem in /dev/sda seems to be another, different, problem that I will have to face later.

[adhefe]

Backup on the way!

[doktor5000]

lsblk output would be more helpful to see the layout across your disks. Apart from that seems strange to me to span a Mageia installation across 3 disks,
sdb1 for / and sda1 for /home but nvme0n1p1 for swap - why not have everything on an SSD?

[adhefe]

The nvme0n1p1 would have no other use. The manufacturer include that as a means to help Windows starting faster. This did not work on Linux. In fact, having it as a swap made the use of swap as fast as regular memory.

removed quote. ~Germ

[doktor5000]

This is the output of lsblk:

Code: Select all

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 931,5G  0 disk
└─sda1        8:1    0 931,5G  0 part /home
sdb           8:16   0 447,1G  0 disk
├─sdb1        8:17   0 446,8G  0 part /
└─sdb2        8:18   0   300M  0 part /boot/EFI
nvme0n1     259:0    0  13,4G  0 disk
└─nvme0n1p1 259:1    0  13,4G  0 part [SWAP]

[doktor5000]

Do you really need 1.400GB for your Mageia installation ? IMHO it should easily fit on sdb so everything including /home would be on an SSD which is a noticeable speed increase (unlike swap, which does not help speed up anything during normal operation).

[adhefe]

Well, this seems to me a matter of use. Having 1TB for /home seems insteresting to my work. Do you mean I could purge sda as this seems to be broken? But, again, this sda problem is likely not related to messages on network failures, bluetooth misconfiguration, seen in journalctl, and the limitations on the use of a second monitor, is it?

removed quote. ~Germ

[morgano]

Not my cup of tea but I suspect Plasma configures and store monitor as well as desktop setups per user, so in home?

[adhefe]

Upon booting, before full load, second monitor should exhibit the mageia splash screens. It does so with mageia live USB. Now it does not with Mageia 9 installation. So I don't think anything belonging to users has something to do with this problem.


removed quote. not appropriate to quote previous message. ~Germ