You are not logged in.
As a workaround, I'd make a script to do this
/etc/pm/sleep.d/50_resolution (make it executable)
#!/bin/bash
case $1 in
suspend|suspend_hybrid|hibernate)
:
;;
resume|thaw)
xrandr --output HDMI-0 --mode 1920x1080 --rate 60 --primary
;;
esac
Obviously, change the "HDMI-0" to your device's correct output, and make any other adjustments to the xrandr line to fit your desired setting. If this doesn't work, try putting a short sleep command before the xrandr command.
well that didn't work so well.
screen went black during boot (instead of showing scrolling text and eventually login prompt). I waited until a login prompt should have been there, then logged in, attempted startx. eventually the screen came back, X did not start. some errors in Xorg.0.log:
[ 81.998] (EE) NVIDIA: Failed to load module "glxserver_nvidia" (module does not exist, 0)
[ 81.998] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
[ 81.998] (EE) NVIDIA(0): log file that the GLX module has been loaded in your X
[ 81.998] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If
[ 81.998] (EE) NVIDIA(0): you continue to encounter problems, Please try
[ 81.998] (EE) NVIDIA(0): reinstalling the NVIDIA driver.
[ 81.999] (EE) NVIDIA(GPU-0): Failed to acquire modesetting permission.
[ 81.999] (EE) NVIDIA(0): Failing initialization of X screen
[ 82.000] (EE) Screen(s) found, but none have a usable configuration.
[ 82.000] (EE)
Fatal server error:
[ 82.000] (EE) no screens found(EE)
[ 82.000] (EE)
So... I removed the /etc/modprobe.d/nvidia_drm.conf file, rebooted, and put export WEBKIT_DISABLE_COMPOSITING_MODE=1 in my .profile. good enough, it's working at least. Not going to worry about the modesetting thing. Thanks again :-)
Very promising information, thank you both.
Today I updated to kernel 6.11.10+bpo-amd64 6.11.10-1~bpo12+1 and also updated the nvidia driver to NVIDIA-Linux-x86_64-550.142.run - and it still wasn't working.
Following the suggestions on the linked pages, I tried statring midori as follows:
$ env WEBKIT_DISABLE_COMPOSITING_MODE=1 midori
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
Those errors were still in the console, but this time the error "KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied" wasn't present, and the window frame correctly showed the information.
I've now added the file /etc/modprobe.d/nvidia_drm.conf with the contents options nvidia_drm modeset=1 as suggested in the first link; I'll reboot in a little while and see if that fixes the issue without needing to set an env variable.
A related post by someone else, with no answers: https://dev1galaxy.org/viewtopic.php?id=6540
Basically, there are some programs I use / would like to use that are not working properly on my system.
I don't recall when exactly the issue started; I'm thinking it may have been when I upgraded to daedalus, but that may not be accurate. The weird thing is, it was working correctly for a while somewhat recently, but now has gone wrong again. I don't use the affected programs often enough to pinpoint what has changed - that is, there are several kernel upgrades and possibly video driver updates in between.
The issue: when I open some programs, the main window is blank. I've had to start from a terminal to see any kind of error. The main programs I've noticed this affecting are midori and xiphos. There were some other webkit browsers I recently tried that were all affected also.
Here's a sample output from the terminal:
$ xiphos
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 995x836: Permission denied
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 398x158: Permission denied
$ midori
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 1440x780: Permission denied
The windows get created. midori shows the tab title "speed dial" and other buttons for the ui, but the main window is blank. xiphos shows the main ui elements, open tabs, etc, but again the main text window is blank. I found something on an ubuntu forum that suggested updating the video driver. I use the driver from nvidia.com. I had been using NVIDIA-Linux-x86_64-550.107.02, and have now updated it to NVIDIA-Linux-x86_64-550.135 but that didn't help.
Any suggestions?
further system information:
Linux hostname 6.11.5+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.5-1~bpo12+1 (2024-11-11) x86_64 GNU/Linux
desktop: xfce
video card: geforce gtx 1050 ti
i have 3 monitors in case that matters
all installed packages up-to-date
if it matters, I boot into text mode, using startx to start x. Xorg runs as my user, not as root.
After initially posting this, I also tried the same programs under a different user account. That did not help (the same errors showed).
Any help would be most appreciated.
Thanks for that, golinux. (btw your link is off, but I found the post from the title. just add a "2" to the end of your link -- id=6842).
:-)
I know this topic's "solved." I just have a comment related to something that you brought up a few times in this thread, and that's wicd. A few weeks ago (maybe a month, it's hard to keep track of time), during some periods of spare time, I attempted to get wicd to run on python3 with devuan daedalus. Made a fair amount of progress, but as of yet it is still nonfunctional. Haven't messed with it for probably 2 weeks now, but I may return to it, if/when I have the time. There's a lot of things that have changed with python and gtk... and I'm not a python programmer so some parts are a bit confusing. I primarily use my desktop on wired network anyway, no real need for network-manager or connman or wicd there.
It's its, not it's, unless you mean it is, in which case it's it's.
A man was injured by an explosion that blew off his left side.
Don't worry, he's all right.
If you've got a bit of patience (it can several hours depending on machine and connection) you can build your own installer iso(s)
OK, so after installing seatd, and re-upgrading xserver-common and xserver-xorg-core, awaking the computer from suspend did not properly wake up the monitors [no input signal]. Today, I've downgraded xserver-common and left xserver-xorg-core upgraded (weird, I know) to try to see which of those 2 packages is causing this. I know, I could save the xfce session and shut down as a workaround. I'd like to get this working properly, though :-)
OK, so...yesterday I downgraded xserver-xorg-core and xserver-common to the versions on the installation media (as suggested by semil).
apt-cache policy xserver-common xserver-xorg-core
xserver-common:
Installed: 2:21.1.7-3devuan1
Candidate: 2:21.1.7-3devuan2
Version table:
2:21.1.7-3devuan2 500
500 http://deb.devuan.org/merged daedalus/main amd64 Packages
*** 2:21.1.7-3devuan1 100
100 /var/lib/dpkg/status
xserver-xorg-core:
Installed: 2:21.1.7-3devuan1
Candidate: 2:21.1.7-3devuan2
Version table:
2:21.1.7-3devuan2 500
500 http://deb.devuan.org/merged daedalus/main amd64 Packages
*** 2:21.1.7-3devuan1 100
100 /var/lib/dpkg/status
I rebooted (maybe not necessary) and restarted X. Suspended the computer last night; upon waking it up this morning, the screens came back up as they should. So one of those packages is the culprit. I can be content using the older versions of these and leave things alone.
Other info:
This system has been upgraded over and over since Jessie. I don't use a gui login (such as slim) anymore, nor do I run X as root. Some things that are installed are (or were) defaults and I'm not that knowledgeable about what's best. When I do apt search seat I find that I have the following installed: elogind, libelogind-compat, libelogind0, libseat1. I do not have seatd installed. Does this replace elogind? Could installing seatd fix the issue I'm having with the latest xserver? I just might try that anyway and find out...
you could get the old debs out of installation media.
Thanks for the suggestion. Again, I'm not sure what started the problem, but at least I can roll back these updates and try to narrow it down, hopefully :-)
I'm running Daedalus amd64 with xfce and sysvinit, kernel 6.1.0-13.
The problem just started happening some time in the week or so. I regularly suspend my PC overnight and awaken it in the morning. Now, when I awaken it, the monitors are all blank for about a minute, and then show some strange patterns on them. My suspend script (which has not changed recently) calls /usr/bin/xflock4 followed by /usr/sbin/pm-suspend . The computer, upon awakening, is not completely frozen; I can use the SysRq keys to force a reboot, or even switch to a vt (ctrl-alt-function key) and then ctrl-alt-delete to reboot. But it is annoying; I generally have some (or many) things open and ready to resume work with in the morning. From browsing through my apt history.log, I am suspecting it may be the recent updates to xserver-xorg-cor and xserver-common, but I don't have the older debs to downgrade those packages. I have tried a few things, in an attempt to narrow down the problem. 1st, I tried booting into an older kernel (6.1.0-12), that made no difference. I tried re-installing my nvidia driver (470.199.02; the card is GeForce GTX 650), that made no difference. I tried closing X down, logged into a VT, and ran pm-suspend. In the morning, blank screen on the VT, but I could type startx and had the GUI working, but all the VTs (ctrl-alt-function keys) were blank. So that was weird. And not really a solution because I would like to have things open in X when I suspend/resume. The very latest package I had installed before this started was arandr; but I purged that and it didn't help. Other than that, there were several package upgrades around that time, but nothing seemed suspicious to me. Any ideas / what else can I check?
Start-Date: 2023-10-07 14:06:37
Commandline: apt upgrade
Install: linux-headers-6.1.0-13-amd64:amd64 (6.1.55-1, automatic), linux-image-6.1.0-13-amd64:amd64 (6.1.55-1, automatic), linux-headers-6.1.0-13-common:amd64 (6.1.55-1, automatic)
Upgrade: telnet:amd64 (0.17+2.4-2, 0.17+2.4-2+deb12u1), libcups2:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), libcurl4-openssl-dev:amd64 (7.88.1-10+deb12u1, 7.88.1-10+deb12u3), qemu-system-x86:amd64 (1:7.2+dfsg-7+deb12u1, 1:7.2+dfsg-7+deb12u2), libcurl4:amd64 (7.88.1-10+deb12u1, 7.88.1-10+deb12u3), libxnvctrl0:amd64 (525.85.05-1, 525.85.05-3~deb12u1), libpam-runtime:amd64 (1.5.2-6, 1.5.2-6+deb12u1), libvpx7:amd64 (1.12.0-1+deb12u1, 1.12.0-1+deb12u2), krb5-locales:amd64 (1.20.1-2, 1.20.1-2+deb12u1), libgssapi-krb5-2:amd64 (1.20.1-2, 1.20.1-2+deb12u1), libcurl3-gnutls:amd64 (7.88.1-10+deb12u1, 7.88.1-10+deb12u3), openssh-client:amd64 (1:9.2p1-2, 1:9.2p1-2+deb12u1), calibre-bin:amd64 (6.13.0+repack-2, 6.13.0+repack-2+deb12u1), libkf5plasmaquick5:amd64 (5.103.0-1, 5.103.0-1+deb12u1), libnftables1:amd64 (1.0.6-2+deb12u1, 1.0.6-2+deb12u2), libgtk-4-common:amd64 (4.8.3+ds-2, 4.8.3+ds-2+deb12u1), cups-bsd:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), libx11-xcb1:amd64 (2:1.8.4-2+deb12u1, 2:1.8.4-2+deb12u2), cups-common:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), libldb2:amd64 (2:2.6.2+samba4.17.10+dfsg-0+deb12u1, 2:2.6.2+samba4.17.11+dfsg-0+deb12u1), mariadb-client-core:amd64 (1:10.11.3-1, 1:10.11.4-1~deb12u1), libqt5positioning5:amd64 (5.15.8+dfsg-3, 5.15.8+dfsg-3+deb12u1), libc++1:amd64 (1:14.0-55.6, 1:14.0-55.7~deb12u1), libbrlapi0.8:amd64 (6.5-7, 6.5-7+deb12u1), grub-pc-bin:amd64 (2.06-13, 2.06-13+deb12u1), libgs10-common:amd64 (10.0.0~dfsg-11+deb12u1, 10.0.0~dfsg-11+deb12u2), cups-client:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), cups-ppdc:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), cups-daemon:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), linux-compiler-gcc-12-x86:amd64 (6.1.52-1, 6.1.55-1), libgs10:amd64 (10.0.0~dfsg-11+deb12u1, 10.0.0~dfsg-11+deb12u2), pandoc-data:amd64 (2.17.1.1-1.1, 2.17.1.1-2~deb12u1), transmission-gtk:amd64 (3.00-2.1+b1, 3.00-2.1+deb12u1), mariadb-server-core:amd64 (1:10.11.3-1, 1:10.11.4-1~deb12u1), debianutils:amd64 (5.7-0.4, 5.7-0.5~deb12u1), libwbclient0:amd64 (2:4.17.10+dfsg-0+deb12u1, 2:4.17.11+dfsg-0+deb12u1), linux-headers-amd64:amd64 (6.1.52-1, 6.1.55-1), openssh-server:amd64 (1:9.2p1-2, 1:9.2p1-2+deb12u1), libkrb5support0:amd64 (1.20.1-2, 1.20.1-2+deb12u1), libsmbclient:amd64 (2:4.17.10+dfsg-0+deb12u1, 2:4.17.11+dfsg-0+deb12u1), libimlib2:amd64 (1.10.0-4+b1, 1.10.0-4+deb12u1), gir1.2-gtk-3.0:amd64 (3.24.37-2, 3.24.38-2~deb12u1), libxpm4:amd64 (1:3.5.12-1.1, 1:3.5.12-1.1+deb12u1), linux-kbuild-6.1:amd64 (6.1.52-1, 6.1.55-1), cups-ipp-utils:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), debian-archive-keyring:amd64 (2023.3, 2023.3+deb12u1), qemu-utils:amd64 (1:7.2+dfsg-7+deb12u1, 1:7.2+dfsg-7+deb12u2), libx11-data:amd64 (2:1.8.4-2+deb12u1, 2:1.8.4-2+deb12u2), inetutils-ping:amd64 (2:2.4-2, 2:2.4-2+deb12u1), ghostscript:amd64 (10.0.0~dfsg-11+deb12u1, 10.0.0~dfsg-11+deb12u2), libssl3:amd64 (3.0.9-1, 3.0.11-1~deb12u1), libkrb5-3:amd64 (1.20.1-2, 1.20.1-2+deb12u1), libpam-modules:amd64 (1.5.2-6, 1.5.2-6+deb12u1), libhwy1:amd64 (1.0.3-3, 1.0.3-3+deb12u1), linux-image-amd64:amd64 (6.1.52-1, 6.1.55-1), libvte-2.91-common:amd64 (0.70.6-1~deb12u1, 0.70.6-2~deb12u1), inetutils-telnet:amd64 (2:2.4-2, 2:2.4-2+deb12u1), libk5crypto3:amd64 (1.20.1-2, 1.20.1-2+deb12u1), libssl-dev:amd64 (3.0.9-1, 3.0.11-1~deb12u1), libx11-xcb-dev:amd64 (2:1.8.4-2+deb12u1, 2:1.8.4-2+deb12u2), calibre:amd64 (6.13.0+repack-2, 6.13.0+repack-2+deb12u1), libcupsimage2:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), mariadb-common:amd64 (1:10.11.3-1, 1:10.11.4-1~deb12u1), libpam-modules-bin:amd64 (1.5.2-6, 1.5.2-6+deb12u1), grub2-common:amd64 (2.06-13, 2.06-13+deb12u1), qemu-system-common:amd64 (1:7.2+dfsg-7+deb12u1, 1:7.2+dfsg-7+deb12u2), libx11-dev:amd64 (2:1.8.4-2+deb12u1, 2:1.8.4-2+deb12u2), libx11-doc:amd64 (2:1.8.4-2+deb12u1, 2:1.8.4-2+deb12u2), openssh-sftp-server:amd64 (1:9.2p1-2, 1:9.2p1-2+deb12u1), libpam0g:amd64 (1.5.2-6, 1.5.2-6+deb12u1), grub-common:amd64 (2.06-13, 2.06-13+deb12u1), libgtk-3-0:amd64 (3.24.37-2, 3.24.38-2~deb12u1), libgtk-4-1:amd64 (4.8.3+ds-2, 4.8.3+ds-2+deb12u1), cups-core-drivers:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), samba-libs:amd64 (2:4.17.10+dfsg-0+deb12u1, 2:4.17.11+dfsg-0+deb12u1), libmariadb3:amd64 (1:10.11.3-1, 1:10.11.4-1~deb12u1), transmission-common:amd64 (3.00-2.1, 3.00-2.1+deb12u1), gtk-update-icon-cache:amd64 (3.24.37-2, 3.24.38-2~deb12u1), libgtk-3-common:amd64 (3.24.37-2, 3.24.38-2~deb12u1), libkf5plasma5:amd64 (5.103.0-1, 5.103.0-1+deb12u1), libvpx-dev:amd64 (1.12.0-1+deb12u1, 1.12.0-1+deb12u2), libgtk-3-bin:amd64 (3.24.37-2, 3.24.38-2~deb12u1), libmariadb-dev:amd64 (1:10.11.3-1, 1:10.11.4-1~deb12u1), libgtk-3-dev:amd64 (3.24.37-2, 3.24.38-2~deb12u1), cups:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), curl:amd64 (7.88.1-10+deb12u1, 7.88.1-10+deb12u3), libgs-common:amd64 (10.0.0~dfsg-11+deb12u1, 10.0.0~dfsg-11+deb12u2), libx11-6:amd64 (2:1.8.4-2+deb12u1, 2:1.8.4-2+deb12u2), transmission:amd64 (3.00-2.1, 3.00-2.1+deb12u1), cups-server-common:amd64 (2.4.2-3+deb12u1, 2.4.2-3+deb12u4), libvte-2.91-0:amd64 (0.70.6-1~deb12u1, 0.70.6-2~deb12u1), qemu-system-data:amd64 (1:7.2+dfsg-7+deb12u1, 1:7.2+dfsg-7+deb12u2), plasma-framework:amd64 (5.103.0-1, 5.103.0-1+deb12u1), grub-pc:amd64 (2.06-13, 2.06-13+deb12u1), qemu-system-gui:amd64 (1:7.2+dfsg-7+deb12u1, 1:7.2+dfsg-7+deb12u2), openssl:amd64 (3.0.9-1, 3.0.11-1~deb12u1), pandoc:amd64 (2.17.1.1-1.1, 2.17.1.1-2~deb12u1), nftables:amd64 (1.0.6-2+deb12u1, 1.0.6-2+deb12u2), linux-libc-dev:amd64 (6.1.52-1, 6.1.55-1)
End-Date: 2023-10-07 14:08:07
Start-Date: 2023-10-07 16:54:29
Commandline: apt upgrade --fix-missing
Upgrade: dbus-daemon:amd64 (1.14.6-1devuan1, 1.14.10-1~deb12u1devuan1), libdbus-1-3:amd64 (1.14.6-1devuan1, 1.14.10-1~deb12u1devuan1), dbus-bin:amd64 (1.14.6-1devuan1, 1.14.10-1~deb12u1devuan1), dbus-x11:amd64 (1.14.6-1devuan1, 1.14.10-1~deb12u1devuan1), eudev:amd64 (3.2.12-1, 3.2.12-4+deb12u1), dbus-session-bus-common:amd64 (1.14.6-1devuan1, 1.14.10-1~deb12u1devuan1), libeudev-dev:amd64 (3.2.12-1, 3.2.12-4+deb12u1), libdbus-1-dev:amd64 (1.14.6-1devuan1, 1.14.10-1~deb12u1devuan1), dbus-system-bus-common:amd64 (1.14.6-1devuan1, 1.14.10-1~deb12u1devuan1), dbus:amd64 (1.14.6-1devuan1, 1.14.10-1~deb12u1devuan1), libeudev1:amd64 (3.2.12-1, 3.2.12-4+deb12u1)
End-Date: 2023-10-07 16:54:40
Start-Date: 2023-10-07 17:00:58
Commandline: apt autoremove
Purge: linux-image-6.1.0-11-amd64:amd64 (6.1.38-4), linux-headers-6.1.0-11-common:amd64 (6.1.38-4), linux-headers-6.1.0-11-amd64:amd64 (6.1.38-4)
End-Date: 2023-10-07 17:01:07
Start-Date: 2023-10-08 17:18:56
Commandline: apt upgrade
Upgrade: python2.7-minimal:amd64 (2.7.18-13ubuntu2, 2.7.18-13ubuntu2), xserver-xorg-core:amd64 (2:21.1.7-3devuan1, 2:21.1.7-3devuan2), palemoon:amd64 (32.4.0.1-1.gtk2, 32.4.0.1-1.gtk2), xserver-common:amd64 (2:21.1.7-3devuan1, 2:21.1.7-3devuan2)
End-Date: 2023-10-08 17:19:00
Start-Date: 2023-10-08 17:20:25
Commandline: apt remove python2.7 python2.7-minimal libpython2.7-minimal libpython2.7-stdlib
Purge: python2.7-minimal:amd64 (2.7.18-13ubuntu2), python2.7:amd64 (2.7.18-13ubuntu2), libpython2.7-minimal:amd64 (2.7.18-13ubuntu2), libpython2.7-stdlib:amd64 (2.7.18-13ubuntu2)
End-Date: 2023-10-08 17:20:27
Start-Date: 2023-10-13 00:00:03
Commandline: apt upgrade --fix-missing
Upgrade: libcurl4-openssl-dev:amd64 (7.88.1-10+deb12u3, 7.88.1-10+deb12u4), libcurl4:amd64 (7.88.1-10+deb12u3, 7.88.1-10+deb12u4), libcurl3-gnutls:amd64 (7.88.1-10+deb12u3, 7.88.1-10+deb12u4), chromium-sandbox:amd64 (117.0.5938.149-1~deb12u1, 118.0.5993.70-1~deb12u1), libldb2:amd64 (2:2.6.2+samba4.17.11+dfsg-0+deb12u1, 2:2.6.2+samba4.17.12+dfsg-0+deb12u1), libjavascriptcoregtk-4.1-0:amd64 (2.40.5-1~deb12u1, 2.42.1-1~deb12u1), gir1.2-javascriptcoregtk-4.0:amd64 (2.40.5-1~deb12u1, 2.42.1-1~deb12u1), gir1.2-webkit2-4.0:amd64 (2.40.5-1~deb12u1, 2.42.1-1~deb12u1), libwbclient0:amd64 (2:4.17.11+dfsg-0+deb12u1, 2:4.17.12+dfsg-0+deb12u1), libsmbclient:amd64 (2:4.17.11+dfsg-0+deb12u1, 2:4.17.12+dfsg-0+deb12u1), chromium:amd64 (117.0.5938.149-1~deb12u1, 118.0.5993.70-1~deb12u1), libjavascriptcoregtk-4.0-18:amd64 (2.40.5-1~deb12u1, 2.42.1-1~deb12u1), libwebkit2gtk-4.1-0:amd64 (2.40.5-1~deb12u1, 2.42.1-1~deb12u1), chromium-common:amd64 (117.0.5938.149-1~deb12u1, 118.0.5993.70-1~deb12u1), samba-libs:amd64 (2:4.17.11+dfsg-0+deb12u1, 2:4.17.12+dfsg-0+deb12u1), libwebkit2gtk-4.0-37:amd64 (2.40.5-1~deb12u1, 2.42.1-1~deb12u1), curl:amd64 (7.88.1-10+deb12u3, 7.88.1-10+deb12u4)
End-Date: 2023-10-13 00:00:14
Start-Date: 2023-10-13 22:05:50
Commandline: apt install arandr
Install: arandr:amd64 (0.1.11-1)
End-Date: 2023-10-13 22:05:53
Start-Date: 2023-10-16 08:30:57
Commandline: apt purge arandr
Purge: arandr:amd64 (0.1.11-1)
End-Date: 2023-10-16 08:31:00
Thanks for the response. I've actually got X working now, every boot. What I had to do was make the disk gpt, re-partition it, addding an efi partition, and re-install devuan in efi mode instead of legacy. There's still a minor issue with booting, I have to select the efi file each time but I may have found a fix for that too. Not sure why it has this problem with legacy boot. It booted fine, just something with the graphics/drm would not load consistently. Anyway, I'm marking this solved.
I've got a bit of a conundrum. I have the desktop-live installer, amd64, on a usb stick and it runs great on my hp elitedesk 705 G4... It's got an Amd ryzen 5 pro 2400ge w/ radeon vega graphics. I ran the installer from the desktop-live environment. The problem is in the installed system. It boots. X will usually refuse to start - errors are
[ 10.529] (EE) open /dev/dri/card0: No such file or directory
[ 10.530] (EE) Unable to find a valid framebuffer device
[ 10.530] (EE) open /dev/fb0: No such file or directory
[ 10.530] (EE) Screen 0 deleted because of no matching config section.
[ 10.532] (EE) VESA(0): No V_BIOS found
[ 10.533] (EE) Screen(s) found, but none have a usable configuration.
[ 10.533] (EE) no screens found(EE)
The few times X is able to start up, a mouse arrow appears on the screen and the screen does not respond at this point (no mouse movement; ctrl-alt-f1 does not display a text-mode vt). I am able to ssh in, and see that Xorg is taking up 100% cpu. when I kill the process, the plugged-in monitor still shows the mouse arrow and black background - have to reboot to get anything back on the screen.
Some things I have tried (1 at a time):
- update the kernel to 6.4 (backports)
- boot the 6.1.0-10-amd64 kernel (that matches the desktop-live iso)
- install seatd
- uninstall slim
- add "nomodeset" to grub cmdline
(as a side note, it was necessary for me to add "acpi_rev_override" to grub cmdline in order for eth0 to work properly - but it works properly in desktop-live)
desktop-live reports:
[ 18.279] Kernel command line: BOOT_IMAGE=/live/vmlinuz initrd=/live/initrd.img boot=live username=devuan apparmor=0
installed-system (on 6.1.0-10-amd64 kernel) reports:
2023-09-15T22:05:00.730651-04:00 fccvideo kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-10-amd64 root=UUID=d68c3ae3-7db1-4c37-a6d9-2dd16cd407c5 ro quiet acpi_rev_override nomodeset
The installed system does not have /dev/fb0, nor /dev/dri/* - I think this is part of X's startup problem. These files do exist when booting from the desktop-live iso. What do I need to do to get the installed system working right?
Other things that may be of note
I've tried both "disabling" (hiding) TPM and re-enabling it, in the UEFI setup. Currently it is enabled.
The boot is legacy, not EFI. Partition table is dos (not gpt).
---- edit ----
It's now the next day. I tried removing the acpi_rev_override and nomodeset from the grub commandline. Then I installed every .deb package in /firmware. The network adapter seems to be working fine now without that acpi_rev_override. X does start (with startx) but the local screen is locked up again, and Xorg uses 100% cpu. /dev/fb0 and /dev/dri/* do not exist.
I have another system (the one I'm posting from) that also does not have /dev/fb0 so that may not be related.
I've noticed when I startx as user "fcc" on the non-working machine, that Xorg is started as root (?) Could this be the problem?
$ ps aux|grep Xorg
root 1931 96.4 1.2 375984 89548 tty2 Rl 12:29 0:44 /usr/lib/xorg/Xorg -nolisten tcp :0 vt2 -keeptty -auth /tmp/serverauth.EYjJMCyPr8
On my working machine, Xorg runs as the logged in user:
$ ps aux|grep Xorg
tempo 3152 1.0 0.7 6720588 249772 tty8 Sl Aug25 327:26 /usr/lib/xorg/Xorg -nolisten tcp :0 vt8 -keeptty -auth /tmp/serverauth.UUKV7OIIz6
Still stuck, unsure how to proceed.
---- edit later ----
I copied the /etc/X11/xorg.conf from my working system to the non-working system (it had no xorg.conf), and edited it, only replacing Driver "nvidia" with Driver "amdgpu". Now startx does start x, and Xorg runs as the current user. /dev/fb0 and /dev/dri/ do exist now. Unfortunately things are not completely working right. If I press ctrl-alt-f2 to change virtual terminals, the X server on tty1 is instantly killed. Also, the display settings application (as well as xrandr) only show modes 640x480 and 720x400. That doesn't seem right. But, progress is being made! :-)
---- edit later later ----
After a reboot, X failed to start again, with the same errors as given above. Another reboot, it did start, with the 2 low-resolution options again. Other reboots, X will not start at all. Now (I'm not going to update the subject line but it is inaccurate) now, the desktop-live iso is not starting X either (same USB stick). Arg.
---- later ----
Tried some more things. Ubuntu iso goes into GUI mode and screen freezes. Linux Mint iso boots, goes into GUI mode, seems to run okay. Now the Devuan desktop-live iso booted into GUI mode successfully again (and when it does, it's not in low resolution mode; it looks right). I think I have some flakey hardware (I did get this machine "refurbished" (used)).
Thanks, adding -static option to gcc worked.
There's probably another, better place to post this than devuan forums (but that's the O/S I'm using, so, there's that).
I've upgraded my main system to daedalus. When I gcc a simple program here, and try to run it on chimaera (the same architecture, amd64), I get this error: ./a.out: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./a.out)
I can transfer the source to the chimaera machine and re-build it there and it runs fine on either. Is there a simple workaround to avoid that step, some kind of build setting I can change on my daedalus machine to produce a binary executable that will run on chimaera?
Sometimes when a GUI application doesn't start up properly, it can help to start it within a terminal window.
Open up your favorite terminal emulator, and enter the command firefox
What response appears in the terminal?
segment_times times
Specify a list of split points. times contains a list of comma separated duration specifications, in increasing order. See also the segment_time option.
It doesn't seem that -segment_times takes a filename argument. You could try -segment_times $(cat /media/split) and see if that works
I've found this --> https://aruljohn.com/blog/install-pytho … on--source
is this ok for Devuan too ?
That page looks okay, but it is for python 3.11.1, not 3.11.3. The 3.11.3 source can be downloaded here https://www.python.org/ftp/python/3.11. … 3.11.3.tgz. The build/install process should work the same in devuan as in debian.
If you want a slightly smaller download, the xz-compressed source can be downloaded here https://www.python.org/ftp/python/3.11. … 1.3.tar.xz.
Here, just change the first section of that blog page to this:
cd /tmp/
wget https://www.python.org/ftp/python/3.11.3/Python-3.11.3.tar.xz
tar -xvf Python-3.11.3.tar.xz
cd Python-3.11.3/
I believe all the rest should be the same.
Apparently, Devuan derives from Debian and Veteran Unix Administrators... I took this to mean that the distro would cater to administrators (who, ya know, administer things, like production servers), and inherit the stability and reliabilty of Debian... Rather than turn into another hobby distro for anti-conformist tinkerers with old laptops.
I appear to be mistaken, if the apparent focus on desktop customisation and the attitude I see from many people here have any bearing on things.As for my bug-tracking skills... That's kinda my point. If my relatively meagre expertise and attention are all that stands between Devuan and undetected broken packages in the repos, we have problems. How am I the only one to have noticed this, in rsyslog of all things?
I use devuan (mainly chimaera) on a few servers, and never noticed this bug. If it had affected me, I hope that I would have noticed pretty quickly... My completely uninformed guess is that not many people use backports of rsyslog, as it seems none of the other versions were affected. What does the backports version of rsyslog do that I'm missing?
A few questions, to help figure out where the problem lies...
The local-network address of the webserver is 192.168.50.3 ?
If so, can another computer on the network successfully open the site http://192.168.50.3/? It does appear that your web-server is listening for connections, but if this step isn't working then you may have a firewall that is blocking the connection. So... do you have a software firewall (such as ufw) installed? You may need to configure it to allow incoming traffic on ports 80 and 443.
Also, are you behind a NAT/router? If so, you'll probably need to set up port forwarding for TCP ports 80 and 443, if you haven't done so already. This would make your webserver accessible to the outside internet (http://www.realupnow.com). The process to do this varies, but it should be found somewhere on your router's admin page.
I'm still not understanding something here.
Do you have two NICs (eth0 and eth1)?
If eth1 = LAN as posted earlier, then set up a static IPv6 network there. https://en.wikipedia.org/wiki/Reserved_IP_addresses use one of the "Private internets" ranges (64:ff9b:1::/48 for example). eth0 will receive whatever address is assigned when connecting to ISP. In your postfix conf, use the static address that you've chosen for eth1.
(Note, I don't actually use IPv6, maybe someone with experience with this can chime in.)
You can do the same thing even if you only have one physical device, with a virtual interface (for example, ifconfig eth0:1 64:ff9b:1::1). I do this with IPv4 addresses and postfix.
AFAIK, there's currently no other way to configure postfix for dynamic IP addresses, except for inet_interfaces = all. I could be wrong there, but from skimming through http://www.postfix.org/postconf.5.html I'm not seeing it.
Postfix shall listen on eth1,(LAN) but not on eth0 (World).
with ipv6 I do not have fixed ip numbers, because these will change dynamically
The ipv6 numbers will change dynamically , what ever I receive from my ISP .
These statements appear to be contrary to each other. Do you want postfix for local network only, or for world (internet)? If you only need it for LAN, then it does not matter what your ISP assigns; just set up a static local address to use on eth1.
If you actually do want it to be reachable from outside your network (internet), then is there any reason not to use inet_interfaces = all?
I'm guessing I need to figure out why DNS CAA isn't being reported ... DNS CAA No (more info)
This is set by your domain registrar. Log into the site that you registered the domain name, and add a CAA record using the issuer of your certificate. https://letsencrypt.org/docs/caa/ may have more information. One of my CAA records looks like this:
example.com 1799 IN CAA 0 issue "letsencrypt.org"
Unfortunately, I don't know what to make of those handshake failures. That seems unrelated to caa.