You are not logged in.
Install NVIDIA firmware for nouveau driver
Most of the NVIDIA firmware is provided by the firmware-misc-nonfree package.
Best Xorg.conf configuration for NVIDIA Nouveau driver
I would encourage people to read nouveau(4) and make their own decisions about the various options. A blanket approach seems unhelpful (IMO).
Suggestions are welcome.
Quilt was incorporated into dpkg some time ago so perhaps try the dpkg-source --commit abstraction:
on the command line 'upgrade-grub' is not recognised
That command is under /usr/sbin/ so you should check if that directory is included in your user's PATH when you attempt to call the command. Or just call the full path. See also https://files.devuan.org/devuan_beowulf … _notes.txt ("Changes in su").
EDIT: hold on, the command is actually /usr/sbin/update-grub; upgrade-grub doesn't exist (AFAIK).
But that command is run automatically when the kernel is upgraded so you shouldn't have to run it manually. Check /boot/grub/grub.cfg to confirm that the Devuan system has menu entries for all of your kernel versions. If that is the case and you can't see these entries when you start the machine then the Devuan system is not in "control" of GRUB. Use the set command from the GRUB command line to find where it is looking for the configuration file.
If this is a UEFI system then the efibootmgr command can show the boot entries and their respective priorities.
As dice notes reinstalling GRUB from Devuan is probably the quickest way to fix this. To do that for a UEFI system use
# dpkg-reconfigure grub-efi-amd64 # or grub-efi-ia32 for 32-bitFor a non-UEFI system use
# dpkg-reconfigure grub-pcNVIDIA's kernel module would be considered "custom" even if compiled from the Debian package. The kernel ring buffer will have a message about the module tainting the kernel.
Is this right?
ie: linux-headers-amd64 -> Linux devuan 5.10.0-0.bpo.3-amd64 does no need it?
Yes, that's right. The kernel does not have the headers listed as a dependency. The headers are only needed for building custom kernel modules so most users don't need them.
How about
getent group sudoPlease also share the full content of /etc/sudoers and any files under /etc/sudoers.d/.
Can we see the output of these commands from your normal user:
sudo -l
groupsso far, no hacked backend on ARM that I'm aware of
From the maintainer of the Cinnamon desktop packages for Debian:
I will most probably NOT packaging Cinnamon 5, nor do any real packaging work of Cinnamon for Debian in the future. Of course, I will try to keep maintenance of the current set of packages for Bullseye, but for the next release, I think it is time that someone new steps in
Full blog post here: https://www.preining.info/blog/2021/06/ … in-debian/
Of course bullseye (and hence Devuan chimeara) will be supported for ~5 years so this isn't an immediate problem but it doesn't look good for fans of Mint's bespoke desktop option. Hopefully another developer will step up.
For De??an it's best to use ~/.xsession instead of ~/.xinitrc because this ensures a consistent desktop environment (see startx(1) for more on this) and also that it can then be selected from a desktop manager as the "default session".
See also https://wiki.debian.org/Xsession
Does the acpi=force kernel parameter help?
Can we see the actual build errors? The full list of commands used would also be useful.
The bug was introduced after the beowulf version was frozen so it was never affected. The version in ceres was fixed by an upstream update.
Better link for the story: https://github.blog/2021-06-10-privileg … -with-bug/
Devuan's default graphical desktop relies pretty heavily on polkit and dbus.
Could it happen that an installed kernel, kept up-to-date via my mindless "aptitude update; aptitude full-upgrade", reaches a point where it no longer receives bugfixes & security updates (Is this the EOL concept?) but the distribution is still maintained ?
No.
For example, Devuan beowulf uses the 4.19 LTS branch and that is supported until December 2024[0]; beowulf itself is due to go EOL in June 2024[1].
How do you select runlevel 1? Perhaps check the logs for any clues.
he would prefer not to ship it in debian was he is not able to debug things as he does not have sysvinit machines around
Hmm. Understandable but disappointing. At least this thread has a link to the init script so that people can add it manually.
This vulnerability is assigned to the policykit-1 package, which is present and used in the current Devuan stable release:
https://security-tracker.debian.org/tra … -2021-3560
It has nothing to do with systemd.
Checking lsusb i see the device.
Please share that output along with the relevant portion of the kernel ring buffer.
Do I have to start eudev? Eudev usually gets not started in single mode.
The init script specifies runlevel "S" so it should be started. Have you checked if it is running?
pgrep -a udevCan we see
apt policyOf course, sometimes a kernel reaches EOL - how do distros deal with this? It's probably beyond the metapackagers art. Is this, once again, a job for "News and Announcements"?
Ben Hutchins works in close collaboration with the upstream kernel developers and maintains Debian's LTS kernel until that branch goes EOL.
Could someone please tell me explicitly how to fix this bug?
Edit /etc/apt/apt.conf.d/50unattended-upgrades and change the Debian repository references to the correct Devuan equivalents.
you should be able to assign letters to specific UUID's using (e)udev rules
^ This: https://wiki.debian.org/Persistent_disk … e_solution
Doesn't work with systemd-udev but eudev might be more compliant.