You are not logged in.
- Topics: Active | Unanswered
#26 Re: Other Issues » no update » 2023-09-14 19:39:57
English/Inglés: Daedalus occasionally is still giving me wrong system time despite some efforts that I thought were final - see my earlier report .
You can update your system clock by doing:
sudo service ntpsec restart
(or if you have doas, doas service ntpsec restart )
Then reenter your password when updating your system, as your sudo time limit for your password will have expired with the clock update.
Español/Spanish: Daedalus occasionalmente aún me da una hora incorrecta, a pesar de mis esfuerzos en corregirlos. Véase mi reportaje anterior .
Puedes actualizar tu reloj así:
sudo service ntpsec restart
(o si tienes doas, doas service ntpsec restart )
Luego, mete tu palabra de pase de nuevo para actualizar tu sistema, puesto que el tiempo limite para tu palabra de pase habrá expirado con la hora actualizada.
#27 ARM Builds » [SOLVED] Vulnerability in Mousepad? Unable to drag, resize, or lower in cwm » 2023-09-14 17:36:10
- ExposeGlobalistsMadness
- Replies: 5
Mousepad couldn't be dragged, resized or lowered despite using the default key bindings in a cwm window manager (Alt being the Meta key on my system), being Alt+LeftClick+drag, Alt+MiddleClick+dragcorner and Alt+RightClick, respectively:
$ man cwm
[...]
The default mouse bindings are:
M-M1 Move current window.
CM-M1 Toggle group membership of current window.
M-M2 Resize current window
M-M3 Lower current window.
CMS-M3 Hide current window.
[...]Background: My Devuan system (on a Raspberry pi 400 arm64 architecture, in case it is relevant) was recently updated with bash instructions from Chimaera to Daedalus, and the display manager was purged to replace it with the system's interactive text login using an .xinitrc file (plus .bash_profile, .profile, and a soft link from .xsession to .xinitrc). It then automatically launches a cwm window manager and ungoogled-chromium browser among other applications in Xorg. Full disclosure: There may still be some unresolved error messages (see earlier messages), and I am still unsure whether one of Daedalus' offered improvements was automatically implemented - whether Xorg now runs as a user instead, or as root. Hopefully this was not botched in my upgrade, and no security risk as it stands! The system is up-to-date and, though I uninstalled mousepad last night, the current version, according to apt search mousepad, is "mousepad/stable 0.5.10-2 arm64".
I thought it strange when I was not able to drag Mousepad quite a while ago but didn't get concerned enough until last night. Other windows responded well to all three bindings; windows included xfce4-terminal, calligrasheets, librewolf and ungoogled-chromium. I wonder whether someone remotely was able to commandeer my Mousepad to launch inside some kind of vm, with its window borders not visible, and disabling the dragging/resizing of that windows hides any vm(?)'s window borders, so as to eavesdrop. I had been setting some changes in my .cwmrc file that I figured might be interfering.
Mousepad (c.3Mb with dependencies) was therefore purged; featherpad, a "Lightweight Qt5 plain-text editor" was installed instead at c.500kb (with any dependencies), and it appears to offer roughly the same main functions.
Perhaps as a related issue, on a previous Devuan (Chimaera) installation, Mousepad wouldn't launch visibly when right-clicking on various .txt files one at a time in spacefm and when selecting the default 'Mousepad'; it would only launch from a right-click menu when selecting the 'Editor' choice, if my memory is correct.
Note that I don't bother with window grouping or tiling, so no such settings are knowingly amended in .cwmrc.
The only somewhat relevant .cwmrc custom bindings might be:-
# "Sometimes it's necessary to unbind keys first [...]", acc. to https://www.reddit.com/r/openbsd/comments/fo7fou/cwm_default_terminal_cwmrc_applications/fldqiw8/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
unbind-key all
# Window-maximize seems to toggle windows
# BUT THIS SETTING HAS SINCE BEEN COMMENTED OUT, AS DECIDED IT WAS UNNEEDED
bind-mouse M-3 window-maximize
# TO PREVENT POINTER FROM WARPING ON THE fbpanel LAUNCHER/SYSTEMS BAR/TASK BAR -
# THE WINDOWNAME FROM xprop FOR fbpanel IS panel SO "ignore fbpanel" DOES NOT WORK
ignore panelIf it could be of use, I could reinstall Mousepad temporarily to, say, give you its xprop description or terminal output when launched from a terminal in case the artefacts would present again or in case the reports are relevant. The only somewhat relevant .config object perhaps was a Mousepad folder, but I decided not to keep it, sorry (there was no .config/mousepad folder before purging Mousepad, if i recall correctly). I may have synced the Mousepad folder from lingering previous installation backups. I am tired of signing up to different websites so, sorry, but I am not inclined to register to file this as a bug report. If it is of interest or can be replicated, and if this sounds like something worse than a .cwmrc misconfiguration, perhaps an interested Devuan party could take this up.
#28 Re: ARM Builds » [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running » 2023-08-30 16:08:36
Perhaps the reason for the errors with the clock not updating nor the ntp packages being corrected/updated for a long time is simply that one of my /etc/apt/sources.list entries was noted yesterday to be wrong:
deb http://deb.devuan.org/devuan daedalus-security mainInstead of:
deb http://deb.devuan.org/merged daedalus-security mainI also added deb-src lines to that sources.list and non-free-firmware non-free contrib entries on the daedalus-update and daedalus-security lines in case those could help.
As a result, when updating, ntp, ntpsec and python3-ntp were among the 25 packages upgraded then. The clock updates ok now, even with the ntp.sh workaround removed.
#29 Re: ARM Builds » Videos don't play; seat, alsactl, ppdev, parport_pc, crda, hdmi issues » 2023-08-28 19:40:10
Note also messages from today's Xorg.0.log, including an error message re seatd_libseat and information messages such as "[libseat/backend/seatd.c:64] Could not connect to socket /run/seatd.sock", in case it could be helpful to Devuan developers or to troubleshoot the video problems:
$ cat Xorg.0.log | grep -2 seatd
[ 241.894] (++) using VT number 1
[ 241.894] (II) seatd_libseat init
[ 241.895] (II) [libseat/backend/seatd.c:64] Could not connect to socket /run/seatd.sock: No such file or directory
[ 241.896] (II) [libseat/libseat.c:76] Backend 'seatd' failed to open seat, skipping
[ 241.904] (II) [libseat/libseat.c:73] Seat opened with backend 'logind'
[ 241.904] (II) seatd_libseat enable
[ 241.904] (II) seatd_libseat handled 1 events
[...]
[ 245.069] (**) Option "Device" "/dev/input/event4"
--
[ 245.075] (II) No input driver specified, ignoring this device.
[ 245.075] (II) This device may have been added with another device file.
[ 245.075] (II) seatd_libseat try close /dev/input/mouse0 (-1:-1)
[ 245.075] (EE) seatd_libseat device not open (/dev/input/mouse0)
[ 245.076] (II) config/udev: Adding input device CHESEN PS2 to USB Converter System Control (/dev/input/event5)
[...]
[ 245.133] (II) seatd_libseat try open /dev/input/event8
[ 245.133] (EE) [libseat/backend/logind.c:137] Could not take device: Device already taken
[ 245.133] (EE) seatd_libseat open /dev/input/event8 (-1) failed: -11
[ 245.134] (**) vc4: always reports core events
[ 245.134] (**) Option "Device" "/dev/input/event8"
--
[ 11080.002] (EE) event3 - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 28ms, your system is too slow
[ 14794.836] (EE) event4 - CHESEN PS2 to USB Converter Mouse: client bug: event processing lagging behind by 22ms, your system is too slow
[ 17920.236] (II) seatd_libseat try close /dev/input/event0 (30:30)
[...]
[ 17920.496] (II) seatd_libseat try close /dev/input/event7 (39:39)
[ 17920.497] (EE) [libseat/backend/logind.c:184] Could not stat fd 39
[ 17920.497] (EE) seatd_libseat close failed -9
[ 17920.497] (II) seatd_libseat try close /dev/input/event8 (40:40)
[ 17920.497] (EE) [libseat/backend/logind.c:184] Could not stat fd 40
[ 17920.497] (EE) seatd_libseat close failed -9
[ 17920.498] (II) AIGLX: Suspending AIGLX clients for VT switch
[...]
[ 17922.337] (II) event8 - vc4: device is a keyboard
[ 17922.338] (II) seatd_libseat try open /dev/input/event7
[ 17922.339] (EE) [libseat/backend/logind.c:137] Could not take device: Device already taken
[ 17922.339] (EE) seatd_libseat open /dev/input/event7 (-1) failed: -11
[ 17922.340] (II) seatd_libseat try open /dev/input/event8
[ 17922.341] (EE) [libseat/backend/logind.c:137] Could not take device: Device already taken
[ 17922.341] (EE) seatd_libseat open /dev/input/event8 (-1) failed: -11#30 Re: Desktop and Multimedia » Browsers won't launch » 2023-08-27 02:55:40
Devuan Daedalus offers Firefox ESR, which is the 'Extended Support Release', and which I have installed. When I try typing firefox in a terminal in my Daedalus installation, Firefox (the Firefox ESR version) does launch. Maybe your link or wrapper that points to firefox-esr isn't working properly somehow, so try typing firefox-esr in a terminal, which is the actual package name, followed by the 'Return' key.
As for chromium, and similarly for firefox-esr, when you install using sudo apt install chromium, as you indicate, does the terminal report that the package (or more associated packages) was installed? A report such as that one is required to ensure that the package was installed. Also, for firefox, make sure that you have typed sudo apt install firefox-esr - not sudo apt install firefox.
#31 Re: ARM Builds » [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running » 2023-08-22 11:32:50
Another test: during this new session, the clock did not update until it was updated manually (sudo service ntpsec restart) though the ethernet cable was connected, but the router and internet connection were not up until minutes into the session. So why doesn't ntpsec or any other relevant service recheck for an internet connection periodically?
Having to use the ntp.sh script is not an appropriate solution though, so maybe the '[SOLVED]' label should be removed?
#32 Re: ARM Builds » Videos don't play; seat, alsactl, ppdev, parport_pc, crda, hdmi issues » 2023-08-22 10:58:40
But video doesn't display on FF for one webpage in Daedalus, at least; see under "Further information":
2) Audio is ok, and the page loads, but the video screen is just black both in Firefox-ESR (for a change - a failure in Firefox-ESR!) as well as in Librewolf for:
https://odysee.com/@vivreautrement:6/le … merlin-3:d
I'll add Further information:
5) Sources include 'non-free-firmware' and a repo for Pale Moon browser:
$ cat /etc/apt/sources.list
deb http://deb.devuan.org/merged daedalus main non-free-firmware non-free contrib
deb http://deb.devuan.org/merged daedalus-updates main non-free-firmware non-free contrib
# there is no non-free-firmware for daedalus-security, so erased off following line
deb http://deb.devuan.org/devuan daedalus-security main non-free contrib
# deb http://deb.devuan.org/merged daedalus-backports main non-free-firmware non-free contrib
$ cat /etc/apt/sources.list.d/home\:stevenpusser\:palemoon-GTK3.list
deb http://download.opensuse.org/repositories/home:/stevenpusser:/palemoon-GTK3/Debian_12/ /#33 ARM Builds » Videos don't play; seat, alsactl, ppdev, parport_pc, crda, hdmi issues » 2023-08-21 23:29:07
- ExposeGlobalistsMadness
- Replies: 3
After upgrading from Devuan Chimaera to Daedalus, videos and livestreams from odysee.com and gab.com nearly all do not play in a Librewolf browser, a Firefox derivative that is neither in Devuan's nor Debian's arm64 repos (https://gitlab.com/librewolf-community/ … -/releases), while those videos generally do play in firefox-esr 102.14.0esr-1~deb11u1 from Devuan's repo. Yet, videos were playing ok under Chimaera with the second last version of Librewolf (librewolf-116.0.2-1-linux-arm64-package.tar.bz2) prior to the ugrade to Daedalus, while neither that same version nor the current version (librewolf-116.0.3-1-linux-arm64-package.tar.bz2) usually play any videos. The bug could be best reported with the Librewolf team, but why was one version of the same browser, released for all arm64 linux platforms, playing ok on Chimaera but not on Daedalus? This is being reported here in case any developer would want to troubleshoot this with other errors found regarding seatd_libseat, alsactl, ppdev, parport_pc, crda and hdmi-audio-codec.
On odysee.com: videos play ok with sound and video in Firefox-ESR but with neither sound nor video on Librewolf; the pages just load, and the video buffers over a black screen:
https://odysee.com/@TheArmedFisherman:b … e-speech:c
https://odysee.com/@canucktv:b/I-LOVE-OURTUBE:8
https://odysee.com/@InfoNews:f/Trump-wa … om-China:e
https://odysee.com/@GregWycliffe:b/are- … enabling:b
https://odysee.com/@RonVaillant:e/bones:69
On gab.com: same artefact; clips/videos play ok with sound and video on Firefox-esr but neither sound or video on Librewolf; however, with Gab clips/videos, while the video just buffers, an image appears at the start, and the progress bar builds up up to the end:
https://gab.com/QAnon_John/posts/110919 … 47/media/1
https://gab.com/Vladimpaler131313/posts … 1065645855
Installation:-
- Upgraded to Daedalus when released as stable using the recommended bash commands on a Raspberry Pi 400 (https://www.devuan.org/os/documentation … o-daedalus).
- Sysvinit is used out-of-the-box as init.
- I purged the display manager (lightdm) and use an ~/.xinitrc file instead plus a ~/.bash_profile, ~/.bash_login and ~/.profile , as it seems that .bash_profile is being read by the system instead of .bash_login despite that file being more associated with Debian (or Devuan therefore) rather than ~/.bash_profile, as I understand, so both are present in case .bash_login would be more relevant in the process; a debug line placed in ~/.bash_profile (echo "DEBUG: I am .bash_profile") is the one that echoes "DEBUG: I am .bash_profile" after login and not its counterpart line from .bash_login. Also inexplicable to me is that echo "DEBUG: I am .bashrc" is no longer being echoed from ~/.bashrc in an xfce4-terminal as it did at first, some days ago.
Error messages:
1) seatd_libseat: seatd is not installed, and it seems that there will be an update, according to a post from 19th August (https://dev1galaxy.org/viewtopic.php?pid=43565#p43565) but, if I understand correctly, seat would be relevant in systems like mine whose display manager was removed for interactions with the display. Could that be related to why videos don't usually play in a Librewolf browser?
$ apt list --installed | grep seat
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libseat1/stable,now 0.7.0-6 arm64 [installed,automatic]See seatd_libseat errors in Xorg.0.log, among other errors (there are Xorg.0.log sundry messages provided also further on); note that some messages may relate to the use of a PS/2 converter cable and old keyboard and mouse PS/2 devices that hopefully use a lower amperage, for health reasons:
$ sudo cat /var/log/Xorg.0.log | grep "(EE)" -1
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 31.647] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Aug 19 23:28:11 2023
--
[ 34.904] (II) seatd_libseat try close /dev/input/mouse0 (-1:-1)
[ 34.904] (EE) seatd_libseat device not open (/dev/input/mouse0)
[ 34.904] (II) config/udev: Adding input device CHESEN PS2 to USB Converter System Control (/dev/input/event5)
--
[ 34.964] (II) seatd_libseat try open /dev/input/event7
[ 34.964] (EE) [libseat/backend/logind.c:137] Could not take device: Device already taken
[ 34.964] (EE) seatd_libseat open /dev/input/event7 (-1) failed: -11
[ 34.964] (**) vc4: always reports core events
--
[ 34.965] (II) seatd_libseat try open /dev/input/event8
[ 34.966] (EE) [libseat/backend/logind.c:137] Could not take device: Device already taken
[ 34.966] (EE) seatd_libseat open /dev/input/event8 (-1) failed: -11
[ 34.966] (**) vc4: always reports core events
--
[ 40.046] (II) modeset(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e)
[ 221.756] (EE) event3 - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 28ms, your system is too slow
[ 1030.405] (EE) event3 - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 37ms, your system is too slow
[ 1281.718] (EE) event3 - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 34ms, your system is too slow
[ 1796.835] (EE) event3 - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 31ms, your system is too slow
[ 1918.067] (EE) event3 - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 23ms, your system is too slow
[ 1918.067] (EE) event3 - CHESEN PS2 to USB Converter: WARNING: log rate limit exceeded (5 msgs per 60min). Discarding future messages.Note also interesting security concerns expressed elsewhere about whether the user should be in the 'video' or 'seat' groups (in Gentoo anyway): https://forums.gentoo.org/viewtopic-p-8790141.html . I am not in the seat group:
$ id
uid=1000(devuan) gid=1000(devuan) groups=1000(devuan),5(tty),6(disk),20(dialout),27(sudo),29(audio),44(video),46(plugdev),102(netdev),104(input),106(render),109(bluetooth),110(i2c),1001(gpio),1002(spi)Errors displayed on boot up before logging in re re alsactl, ppdev and parport_pc - I can't find the log so some of those error messages were copied perhaps roughly from display on boot up, and the hostname was changed from the logs to whatevermyhostnameis for this forum:
2) alsactl - is it ok for there to be a ctl service in Sysvinit?
Starting up ALSA 'alsactl -E HOME/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore' failed with error message 'alsa_lib main. c:1541: (snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -2' ...In dmesg, there are several entries similar to the following re alsa-mixer and module-alsa-card. (Maybe I set some audio level settings in ~/.xinitrc wrong).
$ sudo cat /var/log/dmesg | grep alsa
[...]
2023-08-19T23:28:16.371851-04:00 whatevermyhostnameis pulseaudio[2936]: [pulseaudio] alsa-mixer.c: The decibel volume range for element 'PCM' (-6337 dB - -6 dB) has negative maximum. Disabling the decibel range.
[...]
2023-08-19T23:28:17.936763-04:00 whatevermyhostnameis pulseaudio[2936]: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="2" name="platform-fef05700.hdmi" card_name="alsa_card.platform-fef05700.hdmi" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1""): initialization failed.
[...]3) Module ppdev:
modprobe: FATAL: Module ppdev not found in directory /lib/modules/5.10.11104) Module parport_pc:
modprobe: FATAL: Module parport_pc not found in directory /lib/modules/5.10.1110Further messages from logs:
5) crda:
$ sudo cat /var/log/dmesg | grep -2 crda
[ 6.506459] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[ 6.517817] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: May 14 2020 17:26:08 version 7.84.17.1 (r871554) FWID 01-3d9e1d87
[ 6.595165] udevd[520]: failed to execute '/sbin/crda' '/sbin/crda': No such file or directory
[ 6.624805] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 6.631371] Registered IR keymap rc-cec
--
[ 9.181107] audit: type=1400 audit(1692584155.039:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=1107 comm="apparmor_parser"
[ 9.193085] audit: type=1400 audit(1692584155.051:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=1097 comm="apparmor_parser"
[ 9.441589] udevd[1156]: failed to execute '/sbin/crda' '/sbin/crda': No such file or directory
[ 12.769722] udevd[1723]: failed to execute '/sbin/crda' '/sbin/crda': No such file or directory
[ 12.993306] NET: Registered protocol family 10
[ 12.995309] Segment Routing with IPv66) hdmi-audio-codec (repeated errors replaced with "[...]"):
$ sudo cat /var/log/kern.log | grep -2 hdmi-audio-codec
2023-08-20T09:55:36.640673-04:00 whatevermyhostnameis kernel: [ 33.758452] cam1-reg: disabling
2023-08-20T09:55:36.640706-04:00 whatevermyhostnameis kernel: [ 33.758463] cam-dummy-reg: disabling
2023-08-20T09:55:43.452698-04:00 whatevermyhostnameis kernel: [ 40.572607] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
2023-08-20T09:55:43.452731-04:00 whatevermyhostnameis kernel: [ 40.573127] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[...]
2023-08-20T09:55:45.089441-04:00 whatevermyhostnameis kernel: [ 42.207026] Bluetooth: RFCOMM TTY layer initialized
2023-08-20T09:55:45.089480-04:00 whatevermyhostnameis kernel: [ 42.207052] Bluetooth: RFCOMM socket layer initialized
--
2023-08-20T22:16:56.231438-04:00 whatevermyhostnameis kernel: [ 70.365240] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
2023-08-20T22:16:56.231440-04:00 whatevermyhostnameis kernel: [ 70.365258] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
2023-08-21T13:42:55.430390-04:00 whatevermyhostnameis kernel: [ 104.393342] hdmi-audio-codec hdmi-audio-codec.2.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
2023-08-21T13:42:55.430428-04:00 whatevermyhostnameis kernel: [ 104.393730] hdmi-audio-codec hdmi-audio-codec.2.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[...]
2023-08-21T13:42:57.042415-04:00 whatevermyhostnameis kernel: [ 106.006864] Bluetooth: RFCOMM TTY layer initialized
2023-08-21T13:42:57.042454-04:00 whatevermyhostnameis kernel: [ 106.006886] Bluetooth: RFCOMM socket layer initializedFurther information:-
1) Kernel command line and other Xorg messages - I added lsm="apparmor" in the kernel line to enable apparmor:
$ cat /var/log/Xorg.0.log
[...]
[ 97.857] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.en
able_hdmi=1 video=HDMI-A-1:1280x1024M@60 smsc95xx.macaddr=DC:A6:32:FA:33:09 vc_mem.mem_base=0x3ec00000 vc_mem.mem_
size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=610768d0-02 rootfstype=ext4 fsck.repair=yes logo.
nologo net.ifnames=0 firmware_class.path=/lib/firmware/updates/brcm lsm="apparmor" rootwait
[...]
[ 97.883] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 97.887] (==) No Layout section. Using the first Screen section.
[ 97.887] (==) No screen section available. Using defaults.
[ 97.887] (**) |-->Screen "Default Screen Section" (0)
[ 97.887] (**) | |-->Monitor "<default monitor>"
[ 97.888] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 97.888] (==) Automatically adding devices
[...]
[ 97.901] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 97.901] Entry deleted from font path.
[...]
[ 98.028] (II) seatd_libseat opened graphics: /dev/dri/card0 (15:15)
[ 98.029] (II) no primary bus or device found
[ 98.029] falling back to /sys/devices/platform/gpu/drm/card1
[ 98.029] (II) LoadModule: "glx"
[ 98.038] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 98.083] (II) Module glx: vendor="X.Org Foundation"
[...]
[ 98.090] (II) modeset(0): using drv /dev/dri/card1
[ 98.090] (WW) Falling back to old probe method for fbdev
[ 98.090] (II) Loading sub module "fbdevhw"
[...]
[ 100.096] (II) modeset(0): glamor initialized
[ 100.096] (==) modeset(0): VariableRefresh: disabled
[ 100.096] (==) modeset(0): AsyncFlipSecondaries: disabled
[ 100.110] (II) modeset(0): Output HDMI-1 has no monitor section
[ 100.110] (II) modeset(0): Output HDMI-2 has no monitor section
[ 100.146] (II) modeset(0): EDID for output HDMI-1
[...]
[ 100.148] (II) modeset(0): Output HDMI-1 connected
[ 100.148] (II) modeset(0): Output HDMI-2 disconnected
[ 100.148] (II) modeset(0): Using exact sizes for initial modes
[...]
[ 100.148] (II) LoadModule: "fb"
[ 100.148] (II) Module "fb" already built-in
[ 100.148] (II) UnloadModule: "fbdev"
[ 100.148] (II) Unloading fbdev
[ 100.148] (II) UnloadSubModule: "fbdevhw"
[ 100.148] (II) Unloading fbdevhw
[...]Xrandr reports in part:
HDMI-1 connected primary
[...]
HDMI-2 disconnected (normal left inverted right x axis y axis)
2) Audio is ok, and the page loads, but the video screen is just black both in Firefox-ESR (for a change - a failure in Firefox-ESR!) as well as in Librewolf for:
https://odysee.com/@vivreautrement:6/le … merlin-3:d
3) A solution that appeared to work on my Daedalus installation after applying it but which did not persist on following sessions (https://dev1galaxy.org/viewtopic.php?pid=41755#p41755), but which might point to a solution:
sudo apt-get remove pipewire* libpipewire*
sudo apt-get install pavucontrol pulseaudio Removing pipewire* (or libpipewire*?) also removes music player daemon mpd. Perhaps, when mpd was reinstalled afterwards on purpose, the video buffering problem may have been triggered to recur (I can't remember whether that problem recurred during the same session immediately after reinstalling mpd).
4) The clock did not update in my experience unless ntp and ntpsec were reinstalled (https://dev1galaxy.org/viewtopic.php?id=5879). Isn't ntpsec supposed to replace ntp in Daedalus?
These, I suppose, are just teething pains from updating from Chimaera to Daedalus since this version recently became released as stable; thank you for your hard work and for otherwise a very good user experience on Devuan!
#34 Re: ARM Builds » [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running » 2023-08-21 22:19:31
Correction: The clock updated ok on the first reboot after doing the steps described but not on the following sessions, somehow. So I continued just as delgado iterated, by installing ntp anew (sudo apt install ntp) as a final step:
Summary / assumption: package ntp was not upgraded corectly by the new metapackage. The (installed file-)content changed after de- and re-installing it.
The clock then updated for all of the following sessions.
#35 Re: ARM Builds » [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running » 2023-08-19 18:59:58
Great points, delgado! When following your reasoning and purging ntp, there was a signal given by apt proposing to autoremove the remaining two ntp packages (ntpsec and python3-ntp), as the operating system might be programmed to think that they were just dependencies to ntp:
$ sudo apt purge ntp
[...]
The following packages were automatically installed and are no longer required:
ntpsec python3-ntp
Use 'sudo apt autoremove' to remove them.
[...]apt otherwise points out that ntpsec was already installed and up-to-date:
$ sudo apt install ntpsec
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ntpsec is already the newest version (1.2.2+dfsg1-1).
ntpsec set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.Developers, note from that output that "ntpsec set to manually installed", in case it could be of interest! Could that be why apt thinks that there is no ntpsec and no python3-ntp to autoremove:
$ sudo apt autoremove
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.The workaround ntp.sh script was removed, and after reboot, it looks indeed that ntpsec needed to be reinstalled as proposed by delgado, since the clock still didn't update after about 15 minutes. So after updating the system (no update found):
$ sudo apt remove ntpsec
[...]
The following packages will be REMOVED:
ntpsec python3-ntp
[...]
$ sudo apt install ntpsec
[...]
The following NEW packages will be installed:
ntpsec python3-ntp
[...]
Stopping NTP server: ntpd.
Starting NTP server: ntpd2023-08-19T12:51:22 ntpd[7742]: INIT: ntpd ntpsec-1.2.2: Starting
2023-08-19T12:51:22 ntpd[7742]: INIT: Command line: /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N
-u ntpsec:ntpsec
.
[...]And so the clock got updated with ntpsec and without ntp. Therefore, with the above adjustments, ntp gets replaced by ntpsec, which tracks Devuan's plan.
They're probably teething pains from updating from Chimaera to Daedalus, as this recently became released as stable. I'm getting other error messages e.g. re alsa; modules ppdev and parport_pc; and seatd (which looks set to get an update, according to a post today - https://dev1galaxy.org/viewtopic.php?pid=43565#p43565), and I wonder whether that might be connected to why videos don't usually play on a librewolf browser, as reported above (it is not in Devuan's or Debian's arm64 repos). Thanks again.
#36 Re: ARM Builds » [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running » 2023-08-18 22:14:47
I am grateful to everyone for your replies, and I trust that they could help some people, but as I don't know how to install chrony nor how to trace scripts, and until hopefully the root of the problem is found and implemented on Daedalus for arm64, a workaround that worked for me was implemented from https://dev1galaxy.org/viewtopic.php?pid=42483#p42483 .
On my Devuan Daedalus system, the /etc/elogind/system-sleep folder didn't exist, so in order to preserve the solution above, in case it is important, I thought to create the mentioned folder:
sudo mkdir /etc/elogind/system-sleep
sudo touch /etc/elogind/system-sleep/ntp.sh
sudo rnano -w /etc/elogind/system-sleep/ntp.sh...and used the script:
#!/bin/sh
# To update clock
# Credit to bigcat, from https://dev1galaxy.org/viewtopic.php?pid=42483#p42483
case $1 in
pre)
/etc/init.d/ntpsec stop
/bin/sleep 1
;;
post)
/usr/sbin/ntpd -gq
/etc/init.d/ntpsec start
;;
esacThen thought that some chown and chmod instructions were appropriate:-
sudo chown root:root /etc/elogind/system-sleep/ntp.sh
sudo chmod +x /etc/elogind/system-sleep/ntp.sh In case it can help any Devuan arm64 developer, please note that on one lone recent occasion, the clock somehow updated quickly before adding the script above, and a log reported at the time:
$ sudo cat /var/log/boot
[...]
Thu Aug 17 21:24:03 2023: Starting NTP server: ntpd2023-08-17T21:24:03 ntpd[2121]: INIT: ntpd ntpsec-1.2.2: Starting
Thu Aug 17 21:24:03 2023: 2023-08-17T21:24:03 ntpd[2121]: INIT: Command line: /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
Thu Aug 17 21:24:03 2023: .
Thu Aug 17 21:24:03 2023: Starting NTP server: ntpd2023-08-17T21:24:03 ntpd[2129]: INIT: ntpd ntpsec-1.2.2: Starting
Thu Aug 17 21:24:03 2023: 2023-08-17T21:24:03 ntpd[2129]: INIT: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 102:107
[...]Thanks again. Please flag up if anything seems wrong, anyone. Thank you!
#37 Re: ARM Builds » [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running » 2023-08-17 19:15:35
Thanks for your prompt reply, alexkemp, it is appreciated! So what are common Devuan users to do? Starting up ntp fails again (sudo service ntp start), even though the clock somehow updated automatically much later during this same session!
Currently:
$ sudo service ntp status
NTP server is not running ... failed!
$ sudo service ntp start
Starting NTP server: ntpd2023-08-17T15:07:05 ntpd[879]: INIT: ntpd ntpsec-1.2.2: Starting
2023-08-17T15:07:05 ntpd[879]: INIT: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 102:107
.Anyone?
#38 ARM Builds » [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running » 2023-08-17 17:45:40
- ExposeGlobalistsMadness
- Replies: 12
After upgrading from Devuan Chimaera to Daedalus using bash commands on a Raspberry Pi, using out-of-the-box sysvinit as init, the clock did not update during sessions, sometimes for very roughly an hour or more.
The Pi isn't generally plugged in between sessions, and the clock needs to do network updates.
(Also note that odysee.com videos and livestreams generally just buffer for me without starting to play in a librewolf browser, perhaps due to a lack of synchronization? They do seem to play in firefox-esr, so it might be due to a bug in librewolf. A temporary solution that worked yesterday but recurs during today's session:
sudo apt-get remove pipewire* libpipewire*
sudo apt-get install pavucontrol pulseaudio See https://dev1galaxy.org/viewtopic.php?pid=41755#p41755).
Notice:
$ sudo service ntp status
NTP server is not running ... failed!Interesting observations from others:-
1) "There are some changes in Bookworm (and hence Daedelus) that don't affect my PC but might others e.g. the packages that set the system clock and reduced accessibility support."(https://dev1galaxy.org/viewtopic.php?pid=42957#p42957)
2) For Bookworm, "The ntp package, which used to be the default way to set the system clock from a Network Time Protocol (NTP) server, has been replaced by ntpsec.
Most users will not need to take any specific action to transition from ntp to ntpsec." (https://www.debian.org/releases/bookwor … stem-clock)
3) If setting clock via BIOS, and "If ntp and nptdate aren't installed, you have no chance to use this path. BTW: with Daedalus(Bookworm) the path to the ntp.conf has changed to /etc/ntpsec." (https://dev1galaxy.org/viewtopic.php?pid=43252#p43252)
Although a Pi uses a Broadcom chip instead of a BIOS anyway, please note that ntpdate is not installed:
$ apt list --installed | grep ntp
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
ntp/stable,stable,now 1:4.2.8p15+dfsg-2~1.2.2+dfsg1-1 all [installed]
ntpsec/stable,now 1.2.2+dfsg1-1 arm64 [installed,automatic]
python3-ntp/stable,now 1.2.2+dfsg1-1 arm64 [installed,automatic]Also, strangely, the path for ntp.conf may have changed indeed to /etc/ntpsec, because a copy was found there, but a copy was somehow found at /etc also.
When trying to update clock, adapted from https://forums.raspberrypi.com/viewtopi … 0e#p487981 :
$ sudo ntpd -gq
2023-08-17T02:50:00 ntpd[10338]: INIT: ntpd ntpsec-1.2.2: Starting
2023-08-17T02:50:00 ntpd[10338]: INIT: Command line: ntpd -gq
2023-08-17T02:50:00 ntpd[10338]: INIT: precision = 0.241 usec (-22)
2023-08-17T02:50:00 ntpd[10338]: INIT: successfully locked into RAM
2023-08-17T02:50:00 ntpd[10338]: CONFIG: readconfig: parsing file: /etc/ntpsec/ntp.conf
2023-08-17T02:50:00 ntpd[10338]: CONFIG: restrict nopeer ignored
2023-08-17T02:50:00 ntpd[10338]: CLOCK: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
2023-08-17T02:50:00 ntpd[10338]: CLOCK: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2023-12-28T00:00Z last=2017-01-01T00:00Z ofs=37
2023-08-17T02:50:00 ntpd[10338]: IO: unable to bind to wildcard address :: - another process may be running: Address already in use; EXITINGSo "ntpd[10338]: IO: unable to bind to wildcard address :: - another process may be running: Address already in use"!
Continuing...
$ sudo /etc/init.d/ntp start
Starting NTP server: ntpd2023-08-17T02:50:15 ntpd[10372]: INIT: ntpd ntpsec-1.2.2: Starting
2023-08-17T02:50:15 ntpd[10372]: INIT: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 102:107
.Having written this, a little later the clock somehow updated, roughly an hour after boot as on recent occasions, although neither of those last two steps were taken on previous occasions. So why no update at boot? When upgrading to Daedalus, does some code need to be amended to enable ntp to start?
Board footer
