The officially official Devuan Forum!

You are not logged in.

#1 Re: Other Issues » video not waking up after suspend » 2023-10-22 16:56:50

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 :-)

#2 Re: Other Issues » video not waking up after suspend » 2023-10-21 14:03:25

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...

#3 Re: Other Issues » video not waking up after suspend » 2023-10-21 00:14:06

semil wrote:

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 :-)

#4 Other Issues » video not waking up after suspend » 2023-10-20 02:43:08

rbit
Replies: 6

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

#5 Re: Hardware & System Configuration » [SOLVED] (Daedalus) live-installer vs installed system » 2023-09-17 03:48:42

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.

#6 Hardware & System Configuration » [SOLVED] (Daedalus) live-installer vs installed system » 2023-09-16 02:38:44

rbit
Replies: 2

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)).

#7 Re: Other Issues » [SOLVED] C-compiled code » 2023-09-03 23:58:30

Thanks, adding -static option to gcc worked.  smile

#8 Other Issues » [SOLVED] C-compiled code » 2023-09-03 21:14:14

rbit
Replies: 2

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?

#9 Re: Desktop and Multimedia » Browsers won't launch » 2023-08-27 02:27:28

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?

#10 Re: Other Issues » ffmpeg split file using -segment_times » 2023-06-10 01:20:07

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

#11 Re: Other Issues » [SOLVED] How to Install the latest version of Python ? » 2023-04-15 02:51:57

SpongeBOB wrote:

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.

#12 Re: Other Issues » Where do I report bugs in devuan-backports packages? » 2023-03-28 23:10:03

steve_v wrote:

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?

#13 Re: Hardware & System Configuration » Web server - a setting off somewhere ... » 2023-01-26 03:50:01

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.

#14 Re: Hardware & System Configuration » [SOLVED] postfix dynamic ipv6 interfaces » 2023-01-13 17:58:37

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.

#15 Re: Hardware & System Configuration » [SOLVED] postfix dynamic ipv6 interfaces » 2023-01-13 01:46:20

bai4Iej2need wrote:

Postfix shall listen on eth1,(LAN) but not on eth0 (World).

bai4Iej2need wrote:

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?

#16 Re: Hardware & System Configuration » [SOLVED] SSL Report - What to Fix & Ignore » 2023-01-05 14:36:13

dcolburn wrote:

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.

#17 Re: Hardware & System Configuration » [SOLVED] memory problem » 2022-12-19 01:38:47

fanderal wrote:

Procps was updated on Dec 6:
[UPGRADE] procps:amd64 2:3.3.17-7.1devuan1 -> 2:4.0.2-1devuan1

Maybe this is the cause of the discrepancy?  apt-listchanges news:

procps (2:4.0.2-1) unstable; urgency=medium

  * free: Used memory is Total - Available
    This means versions of free after 4.0.0 will show different Used
    values for older frees and some other system utilities.

 -- Craig Small Mon, 05 Dec 2022 21:34:57 +1100

#18 Re: ARM Builds » kernel-related question » 2022-11-26 02:10:27

OK, here's where I'm at now.

First, I edited /boot/config.txt and attempted to change the kernel line to the version that I had installed via apt as follows: kernel=vmlinuz-5.10.0-19-arm64
The "file" command reported both files (the previous kernel8.img and the vmlinuz-5.10.0-19-arm64) as "Linux kernel ARM64 boot executable Image, little-endian, 4K pages" -- so I thought it just might work.
When I rebooted, the system was stuck at the initial color "rainbow" screen.

I resized my boot partition (it was 128MB on the ascii image, but 256MB on the chimaera image).  I downloaded the file rpi-3-devuan-chimaera-5.10.110-arm64-ext4-2022-11-25.zip from the page https://arm-files.devuan.org/RaspberryPi%20Latest%20Builds/  ... then using dd I overwrote my boot partition with the one from that image.  At first it would not complete the boot due to missing partition (I forgot to edit cmdline.txt).  After I got that straightened out, it did boot into Linux devuan 5.10.110 #1 SMP PREEMPT Fri Nov 25 00:43:14 CET 2022 aarch64 GNU/Linux

So I guess that part is solved, sort of.  I was hoping there would be a simpler way to just upgrade the kernel (like it works in amd64).

Also, upgrading the kernel didn't even fix the iptables problem.

# iptables -A INPUT -s 1.2.3.4 -j DROP
iptables/1.8.7 Failed to initialize nft: Protocol not supported
# iptables -V
iptables/1.8.7 Failed to initialize nft: Protocol not supported

I think I've got the solution for this, though.
I found on https://superuser.com/questions/1480986/iptables-1-8-2-failed-to-initialize-nft-protocol-not-supported:

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

I had to copy the /lib/modules/5.10.110 from the latest image file to my live system, too (which of course I forgot to do previously).

Now, iptables seems to be functioning correctly.

The only question remaining is, whether or not there's a simpler kernel upgrade process.  At least things are working again, and it is possible to upgrade kernel, just a bit more time-consuming than I'm used to :-)

#19 ARM Builds » kernel-related question » 2022-11-25 19:16:14

rbit
Replies: 4

I've been reading a few topics on this forum, but haven't yet come across a satisfactory answer.

Here's my situation:
I've got a raspberry pi 3b+.  I originally used the devuan ascii image on sd card, later moved to external usb drive.  After running this setup for a few years, I finally (today) decided to dist-upgrade to beowulf, and then to chimaera.  It all went pretty smoothly.  The one issue that I've noticed during startup now is that iptables refuses to load the rules I have stored in a script.  An example rule is: iptables -A INPUT -s 1.2.3.4 -j DROP and the message that was returned on beowulf is: iptables: Invalid argument. Run `dmesg' for more information.dmesg contains nothing useful or related to the iptables command.  On chimaera the error is: iptables v1.8.7 (nf_tables): Could not fetch rule set generation id: Invalid argument.

From some internet searching, I believe that the problem is due to an outdated kernel.  uname -a result is: Linux devuan 4.16.14-v8+ #1 SMP PREEMPT Tue Jun 5 18:50:10 CEST 2018 aarch64 GNU/Linux.

I then tried: apt install linux-image-arm64 which proceeded to download and install linux-image-5.10.0-19-arm64_5.10.149-2_arm64.deb
This did create the files in /boot, but they were not loaded upon a system reboot, it's still on 4.16.14-v8+.

I *believe* (but may be mistaken) that the newer rpi images contain a newer kernel.  Could I download the chimaera image, and copy the contents of its /boot to my /boot in order to load a newer kernel?  Or is there another way to perform a kernel upgrade on a running system?  Any help is greatly appreciated.

#20 Re: DIY » Linux ports of OpenBSD's ksh » 2022-09-16 22:46:08

FYI, after adding repository, apt install loksh says...

Preparing to unpack .../archives/loksh_7.1-1_amd64.deb ...
Unpacking loksh (7.1-1) ...
Setting up loksh (7.1-1) ...
update-alternatives: error: alternative path /bin/loksh doesn't exist
dpkg: error processing package loksh (--configure):
 installed loksh package post-installation script subprocess returned error exit status 2

loksh is located in /usr/bin, not in /bin
This occurred in devuan chimaera

#21 Re: Other Issues » [SOLVED] Couple questions regarding Chimaera » 2022-09-06 01:31:02

Installing inetutils-ping (which removed iputils-ping) did remove that warning, so that part is solved.  Thanks :-)

The change with tpm2-abrmd (adding the '-u tss' to line 17 of /etc/init.d/tpm2-abrmd) didn't help.

# service tpm2-abrmd start
Starting TPM2 Access Broker and Resource Management Daemon: tpm2-abrmdIllegal option -u
/sbin/start-stop-daemon: unable to stat //tss (No such file or directory)
 failed!

I *do* have a user "tss" listed in /etc/passwd.  I guess I'm wondering, do I need this service?
After a little bit of internet searching, I think I may not even have tpm enabled on my motherboard.  Maybe that's part of the problem.  I'll reboot and check the ol' bios.

OK, under the "Trusted Computing" section of bios setup, my motherboard informed me that no device was found.  Guess it's not built-in and I never added it.  So I'll remove the tpm2-abrmd package, not sure why it got pulled in.  Sorry for the noise

#22 Other Issues » [SOLVED] Couple questions regarding Chimaera » 2022-09-05 17:53:03

rbit
Replies: 3

This weekend I dist-upgraded from Beowulf to Chimaera.
The upgrade itself went well, with one package problem I am stuck at (I've uninstalled for now)
The package that fails is: "tpm2-abrmd" :

Setting up tpm2-abrmd (2.3.3-1+b2) ...
Starting TPM2 Access Broker and Resource Management Daemon: tpm2-abrmd
** (process:6742): WARNING **: 13:44:06.774: tcti_conf before: "device:/dev/tpm0"

** (tpm2-abrmd:6742): WARNING **: 13:44:06.774: tcti_conf after: "device:/dev/tpm0"
Refusing to run as root. Pass --allow-root if you know what you are doing.
 failed!
invoke-rc.d: initscript tpm2-abrmd, action "start" failed.
dpkg: error processing package tpm2-abrmd (--configure):
 installed tpm2-abrmd package post-installation script subprocess returned error exit status 1

I'm not going to "--allow-root", since I obviously don't know what I'm doing here.  I've uninstalled the package (not sure what it is, or why I had it to begin with).  Is this anything important?  I could note, this is on my desktop computer, not an internet server, if that makes any difference.

The second question has to do with ping. 

$ ping -c 1 127.0.0.1
ping: socket: Address family not supported by protocol
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.025 ms

Any fix for this warning?  I keep getting the warning (Address family not supported by protocol), but the ping itself does succeed.  Passing the "-4" switch will take the warning away; I might just make an alias to do that if there's not another workaround.  Possibly related: https://github.com/iputils/iputils/issues/293.

#23 Re: Installation » mariadb on ceres » 2022-08-25 00:01:36

These log entries look very similar to an issue I had at the beginning of the year.

mknoop wrote:

Aug 24 02:19:07 devuan-ceres mysqld: 2022-08-24  2:19:07 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1651026,1651026
Aug 24 02:19:07 devuan-ceres mysqld: 2022-08-24  2:19:07 0 [ERROR] InnoDB: Missing FILE_CHECKPOINT at 1651026 between the checkpoint 1651026 and the end 1651038.
Aug 24 02:19:07 devuan-ceres mysqld: 2022-08-24  2:19:07 0 [ERROR] Plugin 'InnoDB' init function returned error.
Aug 24 02:19:07 devuan-ceres mysqld: 2022-08-24  2:19:07 0 [ERROR] Unknown/unsupported storage engine: InnoDB

What fixed it for me was removing (actually, renaming, in case it was needed later; it wasn't) the file /var/lib/mysql/ib_logfile0

cd /var/lib/mysql
mv ib_logfile0 ib_logfile0.bad-renamed
service mariadb start

#24 Re: Installation » [SOLVED] Pi-Hole and Devuan Chimaera » 2022-08-20 23:33:57

Altoid wrote:
[root@devuan ~]# ss -tnlp | grep 4711
[root@devuan ~]# 

Nothing.

Phooey.  I was hoping another process (the old pihole?) was holding on to that port.  You can't connect, because the service is not running.  The service won't start (or rather, won't stay running) because of... something yet unknown.
Earlier you had posted this from your log:

[2022-08-19 18:05:28.696 1140M] Error opening IPv6 telnet socket: Address family not supported by protocol (97)

Would you mind trying this, add this line into the file /etc/pihole/setupVars.conf

IPV6_ADDRESS=

Then run

# service pihole-FTL start

If it doesn't start properly, check /var/log/pihole/FTL.log for other clues.

Also, in the web interface, there is a section "Pi-hole diagnosis" under the "Tools" menu.  I'm not sure whether or not that is useful.

If all else fails, nuke it (including configs) and re-install.  Sometimes that is quicker (but less satisfying) than finding the actual problem.

#25 Re: Installation » [SOLVED] Pi-Hole and Devuan Chimaera » 2022-08-20 02:33:14

Altoid wrote:
root@chimaera:~# service lighttpd status
lighttpd is running.

can you open the pihole web admin page? ( try http://192.168.1.3/admin ... or whatever the machine's ip address is)

Altoid wrote:
root@chimaera:~# cat /etc/pihole/setupVars.conf
WEBPASSWORD=xxxx
BLOCKING_ENABLED=true
DNSSEC=false
REV_SERVER=false
PIHOLE_INTERFACE=eth0
PIHOLE_DNS_1=127.0.0.1#5335
PIHOLE_DNS_2=
QUERY_LOGGING=true
INSTALL_WEB_SERVER=true
INSTALL_WEB_INTERFACE=true
LIGHTTPD_ENABLED=true
CACHE_SIZE=10000
DNS_FQDN_REQUIRED=true
DNS_BOGUS_PRIV=true
DNSMASQ_LISTENING=local
root@chimaera:~# 

Basically the same as mine, except for PIHOLE_DNS_1=127.0.0.1#5335
This might be valid, I'm not sure, but it's not how mine is set up at all.  My pihole goes out to other DNS servers for its non-piholed queries.  I also don't see IPV4_ADDRESS or IPV6_ADDRESS in your configuration.  Mine is:

PIHOLE_DNS_1=208.67.222.222
PIHOLE_DNS_2=208.67.220.220
PIHOLE_DNS_3=198.6.100.194
PIHOLE_DNS_4=9.9.9.9
IPV4_ADDRESS=192.168.1.4/24
IPV6_ADDRESS=
Altoid wrote:
[2022-08-19 18:05:28.675 1140M] Listening on port 4711 for incoming IPv4 telnet connections
[2022-08-19 18:05:28.696 1140M] Error opening IPv6 telnet socket: Address family not supported by protocol (97)

As you can see, port 4711  is mentioned.

If fsockopen gets refused trying to connect to 127.0.0.1:4711, then there is a permissions problem with port 4711.

How do I troubleshoot that, specifically?

what happens when you run these:

root@devuan:/etc/pihole# ss -tnlp | grep 4711
LISTEN     0      5      127.0.0.1:4711                     *:*                   users:(("pihole-FTL",pid=2819,fd=10))
LISTEN     0      5          ::1:4711                    :::*                   users:(("pihole-FTL",pid=2819,fd=13))
root@devuan:/etc/pihole# telnet 127.0.0.1 4711
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
root@devuan:/etc/pihole# 

Board footer

Forum Software