You are not logged in.
So, many Excalibur updates later, and this is still occurring. I tried manually changing the driver for both video cards to modesetting, and while X no longer loaded the nouveau driver, it still crashed with a backtrace pointing to /usr/lib/x86_66-linux-gnu/dri/nouveau_dri.so. As far as I can tell, then, the nouveau kernel module is causing X to crash even when I'm not using the nouveau display driver.
There doesn't seem to be a way to get around this problem as long as I'm using this hardware. I'm OK using Daedalus for now, but I'm not sure how close Excalibur is to a stable release. If this bug survives to it, I'll have to abandon the distro entirely.
I've noticed that Excalibur updates sometime remove packages, then install newer versions of the same package. I'm not sure why it does that, rather than just updating the package, but I'm sure there's a good reason.
The libc6 package is marked with priority "required," and contains the GNU version of the standard C library, along with some other core support libraries. I don't think it's even possible to install a usable system without it. The other three libraries are part of the LLVM toolchain, though. I've had to install them to compile C++ projects. Did you install clang at some point? If you never selected them manually, they might have been included with a meta-package.
There are also a couple of directories for 32-bit libraries that become links in a default merged system. Here is a full listing from a system I created by running debootstrap with the --merged-usr option:
$ find / -maxdepth 1 -type l -xtype d -printf '%p -> %l\n'
/libx32 -> usr/libx32
/sbin -> usr/sbin
/bin -> usr/bin
/lib32 -> usr/lib32
/lib64 -> usr/lib64
/lib -> usr/lib
I was looking over the setup scripts for schroot to get a better sense for how the system works, when I stumbled across this comment in the file /etc/schroot/setup.d/10mount:
# Work around systemd insanity.
#
# Mark this mountpoint as private; some systems have / as a shared mountpoint.
# As an example, assume /home/m/ch is the chroot directory.
# schroot will mount -o bind /home/m/ch to /var/lib/schroot/mount/ch-123
# Afterwards, it will bind-mount /dev to /var/lib/schroot/mount/ch-123.
# With shared mountpoints, that mount will also show up in the original
# /home/m/ch. This is a problem once schroot mounted /home: the following
# mount of /tmp will show up in /var/lib/schroot/mount/ch-123/tmp,
# /home/m/ch/tmp and /home/m/ch/home/m/ch/tmp (!), which leads to failure
# on unmounting.
if [ "$(uname -s)" = "Linux" ]; then
mount --make-private "$3"
fi
I had no idea systemd made everything a shared mount by default, but now I'm wondering if it could have been the cause of some weird issues I had in the past. I guess it's another reason to be grateful I'm not using systemd anymore.
The line you may need to un-comment in /etc/default/grub to enable the OS prober is this one:
GRUB_DISABLE_OS_PROBER=false
The default setting is true, which disables the prober. Un-commenting the line sets it to false, which enables the prober. If you install grub manually, the line is commented out by default. I'm not sure what happens when you use the installer, though.
I booted the system off another partition with Daedalus and X starts fine. If I'm understanding the backtrace, it appears that the nouveau kernel module (nouveau_dri.so) is causing a hardware exception (SIGILL) which would make sense, as this issue started to occur after a kernel upgrade. I'm not sure if I'm reading it right, though. I would like to make a proper bug report, but I don't where it should go, as this problem involves the X server, display driver, and kernel.
Update: Apparently it wasn't the kernel after all. I rebooted with multiple kernel versions, but the X server always fails to start. I guess I'll stick with Daedalus for now. Expecting this old nvidia card to work reliably on the testing branch may be asking too much.
It seems the seatd issue is unrelated to the problem of X not starting on this system. The same message shows up on one of my other systems, where X starts successfully:
[ 20.893] (II) seat-libseat: libseat integration requires -keeptty and -keeptty was not provided, disabling libseat integration
seatd has been installed on both systems for many months, and the seatd daemon is currently running on both. `dpkg-reconfigure seatd` didn't make the message go away. Removing and reinstalling seatd would require reinstalling the X server itself. I don't know whether this message represents a genuine problem on either system, but it doesn't seem to be related to the signal 4 issue on the nvidia system.
Intel i7-4770MQ CPU + NVIDIA GeForce GTX 765 M GPU. I'm running Excalibur and just did an update today. X now fails to start, and I'm seeing the message below in the log. Searching turned up nothing helpful. I thought it might have something to do with the nouveau firmware I installed a few weeks ago, but removing the firmware made no difference.
I next thought it might be a problem with the nouveau driver, but looking at the log, the crash seemed to happen when loading the modesetting driver. At any rate, trying to disable the nouveau driver (by forcing the modesetting driver) had the exact same result.
The crash appears to happen specifically when glamoregl is loaded, so I tried forcing the server to load without glamoregl by putting the lines below into the file /etc/X11/xorg.conf.d/00-noglamoregl.conf. The log did initially say that glamoregl would not be loaded by default, however, glamorgl did load when the fbdev driver was loaded. At that point, it crashed just as before.
Section "Device"
Identifier "nogpu"
Driver "modesetting"
Option "Accelmethod" "none"
EndSection
Section "Module"
Disable "glamoregl"
EndSection
It appears glamoregl is the culprit, but I don't know how to disable it universally, or whether the server will even be usable without it. Any suggestions would be appreciated. At this point, I'm afraid I may just have to wait for an update. Below is the full text of the initial log.
[ 165.321]
X.Org X Server 1.21.1.11
X Protocol Version 11, Revision 0
[ 165.321] Current Operating System: Linux alien 6.9.9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.9-1 (2024-07-13) x86_64
[ 165.322] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.9.9-amd64 root=UUID=3eff8d67-d669-4093-816d-08f3ff918faa ro quiet
[ 165.322] xorg-server 2:21.1.12-1devuan1 (https://www.devuan.org/os/community)
[ 165.322] Current version of pixman: 0.42.2
[ 165.322] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 165.322] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 165.322] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul 24 12:31:21 2024
[ 165.322] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 165.322] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 165.322] (**) Option "defaultserverlayout" "ServerLayout0"
[ 165.322] (**) ServerLayout "ServerLayout0"
[ 165.322] (==) No screen section available. Using defaults.
[ 165.322] (**) |-->Screen "Default Screen Section" (0)
[ 165.322] (**) | |-->Monitor "<default monitor>"
[ 165.322] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 165.322] (**) Option "BlankTime" "0"
[ 165.322] (**) Option "StandbyTime" "0"
[ 165.322] (**) Option "SuspendTime" "0"
[ 165.322] (**) Option "OffTime" "0"
[ 165.322] (**) Allowing byte-swapped clients
[ 165.322] (==) Automatically adding devices
[ 165.322] (==) Automatically enabling devices
[ 165.322] (==) Automatically adding GPU devices
[ 165.322] (==) Automatically binding GPU devices
[ 165.322] (==) Max clients allowed: 256, resource mask: 0x1fffff
[ 165.322] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 165.322] Entry deleted from font path.
[ 165.322] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 165.322] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 165.322] (II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 165.322] (II) Loader magic: 0x564b0d38eea0
[ 165.322] (II) Module ABI versions:
[ 165.322] X.Org ANSI C Emulation: 0.4
[ 165.322] X.Org Video Driver: 25.2
[ 165.322] X.Org XInput driver : 24.4
[ 165.322] X.Org Server Extension : 10.0
[ 165.322] (++) using VT number 7
[ 165.322] (II) seat-libseat: libseat integration requires -keeptty and -keeptty was not provided, disabling libseat integration
[ 165.322] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 165.322] (II) Platform probe for /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
[ 165.323] (II) xfree86: Adding drm device (/dev/dri/card1)
[ 165.323] (II) Platform probe for /sys/devices/pci0000:00/0000:00:01.1/0000:07:00.0/drm/card1
[ 165.325] (--) PCI:*(1@0:0:0) 10de:11e1:1028:05ab rev 161, Mem @ 0xd4000000/16777216, 0xa0000000/268435456, 0xb0000000/33554432, I/O @ 0x00005000/128, BIOS @ 0x????????/131072
[ 165.325] (--) PCI: (7@0:0:0) 10de:11e1:1028:05ab rev 161, Mem @ 0xd2000000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x00004000/128, BIOS @ 0x????????/524288
[ 165.325] (II) LoadModule: "glx"
[ 165.325] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 165.326] (II) Module glx: vendor="X.Org Foundation"
[ 165.326] compiled for 1.21.1.11, module version = 1.0.0
[ 165.326] ABI class: X.Org Server Extension, version 10.0
[ 166.042] (==) Matched modesetting as autoconfigured driver 0
[ 166.042] (==) Matched fbdev as autoconfigured driver 1
[ 166.042] (==) Matched vesa as autoconfigured driver 2
[ 166.042] (==) Assigned the driver to the xf86ConfigLayout
[ 166.042] (II) LoadModule: "modesetting"
[ 166.042] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 166.042] (II) Module modesetting: vendor="X.Org Foundation"
[ 166.042] compiled for 1.21.1.11, module version = 1.21.1
[ 166.042] Module class: X.Org Video Driver
[ 166.042] ABI class: X.Org Video Driver, version 25.2
[ 166.042] (II) LoadModule: "fbdev"
[ 166.042] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 166.042] (II) Module fbdev: vendor="X.Org Foundation"
[ 166.042] compiled for 1.21.1.3, module version = 0.5.0
[ 166.042] Module class: X.Org Video Driver
[ 166.042] ABI class: X.Org Video Driver, version 25.2
[ 166.042] (II) LoadModule: "vesa"
[ 166.042] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[ 166.042] (II) Module vesa: vendor="X.Org Foundation"
[ 166.042] compiled for 1.21.1.9, module version = 2.6.0
[ 166.042] Module class: X.Org Video Driver
[ 166.042] ABI class: X.Org Video Driver, version 25.2
[ 166.042] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 166.042] (II) FBDEV: driver for framebuffer: fbdev
[ 166.042] (II) VESA: driver for VESA chipsets: vesa
[ 166.042] (WW) xf86OpenConsole: setpgid failed: Operation not permitted
[ 166.042] (WW) xf86OpenConsole: setsid failed: Operation not permitted
[ 166.051] (II) modeset(0): using drv /dev/dri/card0
[ 166.051] (WW) Falling back to old probe method for fbdev
[ 166.051] (II) Loading sub module "fbdevhw"
[ 166.051] (II) LoadModule: "fbdevhw"
[ 166.051] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 166.051] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 166.051] compiled for 1.21.1.11, module version = 0.0.2
[ 166.051] ABI class: X.Org Video Driver, version 25.2
[ 166.051] (II) modeset(G0): using drv /dev/dri/card1
[ 166.052] (II) modeset(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
[ 166.052] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[ 166.052] (==) modeset(0): RGB weight 888
[ 166.052] (==) modeset(0): Default visual is TrueColor
[ 166.052] (II) Loading sub module "glamoregl"
[ 166.052] (II) LoadModule: "glamoregl"
[ 166.052] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[ 166.055] (II) Module glamoregl: vendor="X.Org Foundation"
[ 166.055] compiled for 1.21.1.11, module version = 1.0.1
[ 166.055] ABI class: X.Org ANSI C Emulation, version 0.4
[ 166.079] (EE)
[ 166.079] (EE) Backtrace:
[ 166.079] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x14d) [0x564b0d30243d]
[ 166.080] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7fce28b8e590]
[ 166.080] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (nouveau_drm_screen_create+0x1326) [0x7fce267cf4a6]
[ 166.080] (EE) 3: ? (?+0x0) [0xb90]
[ 166.080] (EE) 4: ? (?+0x0) [0x564b14bc4aa0]
[ 166.080] (EE)
[ 166.080] (EE) Illegal instruction at address 0x7fce267cf4a6
[ 166.080] (EE)
Fatal server error:
[ 166.080] (EE) Caught signal 4 (Illegal instruction). Server aborting
[ 166.080] (EE)
[ 166.080] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 166.080] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 166.080] (EE)
[ 166.090] (EE) Server terminated with error (1). Closing log file.
EDIT - I just noticed there's an error in there about seatd, I'm not sure why I would suddenly be having problems with that, or what to do about it. There's virtually nothing online about seatd. Someone else mentioned getting the same error on this forum:
https://dev1galaxy.org/viewtopic.php?id=6385
But the thread wasn't very helpful. I've had seatd installed and working on this system for many months.
Yes, debsums is excelllent, thank you! Running 'debsums -ec' printed all of my edited configuration files to stdout. It found a few I had completely forgotten about. It won't report newly created config files, of course, such as those under /etc/network/interfaces.d/. I doubt there would be a simple way to automate finding those, unfortunately. It would probably be wise to make a note somewhere whenever they are created.
I started seeing errors about missing nvidia firmware recently as well. It's confusing, because the nouveau driver didn't report this error in the past, but the official site says nouveau has always required the nvidia firmware.
Fortunately, it is relatively easy to extract and install the nvidia firmware yourself. The whole issue is explained here, in the Firmware section: https://nouveau.freedesktop.org/VideoAcceleration.html
That appears to be corrrect. Perhaps your system does not have EFI selected as the default boot option. Some PCs support both EFI and legacy BIOS boot. That's the only other thing I can think of, as grub seems to be set up properly.
Wow, thirty minutes! I had no idea I was leaving my posts unfinished for that long. I often pause to look up references, test things in the terminal, etc. before posting, as I want to make sure my posts are accurate. It's easy to get sidetracked.
I understand the reasons for the time limit, and the desire to keep the site code simple. I wouldn't say it's a major inconvenience, I was just offering up another data point.
I went ahead and did the dist-upgrade on two systems, and everything seems OK so far. In both cases, only gdb was uninstalled without a replacement. It wasn't clear why. I was able to reinstall it immediately after the upgrade.
One system got up to 154 held packages before I ran the upgrade. That's almost 120 new packages released in less than 24 hours. It seems there's a big push going on right now to get the transition done, maybe before the end of the month. When I checked 24 hours ago, the dist-upgrade would have removed some really important applications, including LibreOffice. The list of removals was much shorter today. There's probably no harm in waiting a while longer if you aren't in a hurry to upgrade.
Devuan/Debian may not be set as the first entry in the EFI boot order. You can use efibootmgr to diagnose and fix this issue. Run 'efibootmgr' on the command line with no options to print the current configuration. You should see a line beginning with 'BootOrder:' followed by a list of numbers. There should also be a listing of boot entries, one per line, starting with 'Boot<number>* <name>'. Here's the output on my system, with only the entry for my main Devuan system shown: (The long string of x's is a censored UUID.)
$ efibootmgr
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0007,0001,0003,0005,0006,0004,0000,2001,2002,2003
[...irrelevant boot entries trimmed...]
Boot0007* debian HD(1,GPT,xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,0x800,0x100000)/File(\EFI\debian\shimx64.efi)
[...more irrelevant entries trimmed...]
One of the boot entries should be your Devuan system; it will probably appear similar to the entry shown above. Its number should be first in the BootOrder list. If it isn't, then you can fix it with the 'efibootmgr -o' option. (The manpage for efibootmgr explains how.) If your Devuan system is already the first boot option, then your problem unfortunately lies elsewhere.
It must be a Firefox issue then, as I'm having the same problem. I looked at the cookies in the Storage Inspector, but the "Expiration / Max-Age" is just set to "Session". There didn't seem to be any way to actually change the session length.
I came here to search for information on this issue because I noticed today that one of my Excalibur installations had 68 packages held back. Running a dist-upgrade would clear the holds, but would also remove dozens of packages without installing replacements. I'm not sure whether I should wait for this issue to be resolved, or run the dist-upgrade now before it gets any worse. Discussions around the web are confusing and contradictory. Some say to wait, while others say get it over with. Is anyone else dealing with this issue?
Update: The number of held back packages jumped to 120 today. If this continues, it may end up being easier to just reinstall these systems from scratch. I'm kind of surprised no one else is dealing with this issue. Maybe it's because I installed a lot of development libraries when I was building the latest version of GNUstep/libobjc2. I do have one system that has no held back packages at all, but there's almost nothing installed on it but the base system and a simple C+X11 toolchain.
The avalanche of dependencies that occurs if you accept the "recommended" packages for ssh-server on Debian is truly mind-boggling. The exact list might change depending on your system, but it wanted to pull in an entire GNOME desktop on mine, and I didn't even have X installed! It was all because polkitd recommended a little GUI authentication widget.
Now it seems that there is no such thing as /dev/dsp anymore.
PulseAudio can still emulate it, but virtually nothing uses it anymore. (I think NAS does, but NAS is itself a relic.) Pretty much every piece of Linux software written this millennium uses ALSA, either directly, or through an intermediary such as Pipewire or Jack.
The glitching sounds like it could be buffer underruns. The fact that it's happening on two different programs points to the audio system. There are different ways to adjust your buffer settings depending on which audio system/driver you're using for output; ALSA and PulseAudio both have ways to do it, for example. Unfortunately I haven't had to fiddle with that stuff for decades, so I can't give you any specifics, but at least it's a place to start.
ntpsec is the "default" time daemon that will be installed if you run 'apt install ntp'. There's also the aforementioned chrony, as well as openntpd, which comes from OpenBSD. I just install with ntpsec on my systems since it's the default, and I didn't have a pressing reason to use one of the others. IIRC setup was entirely automatic; I didn't need to edit any init scripts or config files. However, I did run 'dpkg-reconfigure tzdata' to set my correct time zone.
I've already run usrmerge. Doesn't the below mean that the original /lib/init is already gone? So apt would have actually been trying to delete /usr/lib/init.
$ realpath /lib/init
/usr/lib/init
$ realpath /lib/init/init-d-script
/usr/lib/init/init-d-script
I just ran an Excalibur upgrade and got these errors:
Preparing to unpack .../sysvinit-utils_3.08-7devuan1_amd64.deb ...
Unpacking sysvinit-utils (3.08-7devuan1) over (3.08-5devuan1) ...
dpkg: warning: unable to delete old directory '/lib/lsb/init-functions.d': Directory not empty
dpkg: warning: unable to delete old directory '/lib/lsb': Directory not empty
Setting up sysvinit-utils (3.08-7devuan1) ...
[...]
Preparing to unpack .../2-initscripts_3.08-7devuan1_all.deb ...
Unpacking initscripts (3.08-7devuan1) over (3.08-5devuan1) ...
dpkg: warning: unable to delete old directory '/lib/init': Directory not empty
I checked, and dozens of scripts in /etc/init.d still source the scripts in /lib/init. So it seems odd that an upgrade would try to delete it. Does anyone know what's going on here? Is this usrmerge related?
Not sure if this helps with your particular situation, but you can change the title of a window with the WM_NAME atom. I edited the previous version of this post because I provided a long example that did this with XSetWindowProperty(), but it turns out there's a dedicated function XFetchame() that does this much more easily. The documentation is here:
https://www.x.org/releases/current/doc/ … E_Property
If you first need to identify the windows that need their name changed, you can use XGetClassHint() to get the unaltered application name. (Terminals will usually update the title with the working directory, etc.)
You need to install grub to the disk, not the partition, i.e., 'grub-install /dev/sda' not 'grub-install /dev/sda2'.
There are two versions of grub, grub-efi and grub-pc. The former is for UEFI systems, the latter for BIOS. I don't know how it works if you install Devuan with the automatic installer, but is it possible you got the wrong version?
You can find out whether the system is in UEFI mode by checking the contents of /sys/firmware/efi/efivars/. There should be a large number of files in there if the system is UEFI. If the efivars aren't there, it's not EFI. Some systems allow you to switch between UEFI and legacy BIOS boot in the BIOS setup menu.
Here's the full process for setting up a legacy BIOS boot partition: After creating the partition in gdisk (type EF02) enter the expert menu with the x command. Then issue the a (attributes) command, and select the BIOS partition number. An attribute menu will be printed. Select the 'hide from EFI' and 'legacy BIOS bootable' attributes (should be options 1 & 2.) Do not to format this partition.
Weird, I have Devuan and firefox-esr on four different systems now, and all of them work fine with bare ALSA. One thing I've noticed, though, is that the ALSA mixer on a new installation always starts out with deranged settings that give me no sound. Channels are muted, or set to zero, or multiple combinations thereof. On a new system, before I try to use audio, I add my user to the audio group, open alsamixer, max out everything, and make sure all switches are un-muted.