Download | Devuan.org | Git | Bugs | Packages

The officially official Devuan Forum!

You are not logged in.

Pages: 1 2

#1 Re: Installation » [SOLVED] Very strange: is it connman or network-manager? » 2024-09-26 14:33:45

rbit

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

:-)

#2 Re: Installation » [SOLVED] Very strange: is it connman or network-manager? » 2024-09-26 01:26:07

rbit

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.

#3 Re: Off-topic » Thread derailing detritus » 2024-09-08 02:43:58

rbit

It's its, not it's, unless you mean it is, in which case it's it's.

#4 Re: Off-topic » The Joke Thread » 2024-09-07 22:56:45

rbit

A man was injured by an explosion that blew off his left side.

Don't worry, he's all right.

#5 Re: Devuan » Devuan Excalibur ISO » 2024-09-07 22:29:36

rbit

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)

https://git.devuan.org/devuan/installer-iso

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

rbit

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

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

rbit

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

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

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

#9 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

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

rbit

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.

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

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

rbit

Thanks, adding -static option to gcc worked.  smile

#13 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?

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

rbit

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?

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

rbit

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

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

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

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

rbit
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?

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

rbit

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.

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

rbit

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.

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

rbit
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?

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

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

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

rbit
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

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

rbit

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

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

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

rbit

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

Pages: 1 2

Board footer

Forum Software