Package: virtualbox-dkms
Version: 7.0.10-dfsg-2
virtualbox-dkms module build fails when done with kernel 6.4.10
Output:
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/dkms 6.4.10 /boot/vmlinuz-6.4.10
Error! Bad return status for module build on
I encountered this error as well, however manual removal via 'dkms
remove' is still operational.
Package: nvidia-legacy-340xx-driver
Version: 340.108-11
Severity: serious
The latest nvidia-legacy-340xx-driver succeeds in building the dkms
module with kernel 5.14.9, but startx fails to locate any valid
screens. This same driver works correctly with kernel 5.10.70.
It appears that drm
Package: deluge
Version: 2.0.3-3
Severity:|important > dpkg -l deluge python3 python3-libtorrent
libtorrent-rasterbar10 Desired=Unknown/Install/Remove/Purge/Hold |
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err:
Package: deluge
Version: 2.0.3-3
dpkg -l deluge python3 python3-libtorrent libtorrent-rasterbar10
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name
Submitted the wrong make.log. Attached is the correct one.
-- sRw
DKMS make.log for virtualbox-6.1.12 for kernel 5.8.6 (x86_64)
Thu 03 Sep 2020 11:12:18 AM CDT
make: Entering directory '/usr/src/linux-5.8.6'
CC [M] /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/SUPDrv-linux.o
CC [M]
Package: virtualbox-dkms
Version: 6.1.12-dfsg-9
Kernel: 5.8.6
The dkms build fails for the current version of virtualbox-dkms and kernel
5.8.x sources:
Building module:
cleaning build area...
make -j8 KERNELRELEASE=5.8.6 -C /usr/src/linux-5.8.6
M=/var/lib/dkms/virtualbox/6.1.12/build...(bad
DKMS works for me using kernel 5.6.8 -- sRw
On 2020-04-30 06:09, Andreas Beckmann wrote:
On 30/04/2020 12.09, jim_p wrote:
And then the reference to #956458, which is for nvidia legacy 390xx.
So I would like to ask if the bug I mentioned here is indeed fixed in the -5
revision of the package.
Just my 2d, but I am with Jim P on the whole "nouveau is something I
hate even more" thing. This driver is operational in 5.5.x as we know,
but since that branch went EOL I have just reverted my machines to 5.4.x
for the time being )OK for now since 5.4.x is long-term). The native
NVIDIA
Package: openssh-client
Version: 8.1p1-2
I am going to submit this as a bug in openssh-client for the moment,
tho' it may actually be inside the kernel if it is driver related. The
NIC is:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
PCI Express Gigabit Ethernet
Is this confined to systemd 241-4? Will back-revving to 241-3 be a
sufficient workaround?
Package: systemd, udev
Version: 241-4
Kernel: seen in 5.1.3 and 4.19.44
dpkg -l | egrep "^ii" | egrep "241-4"
ii libnss-systemd:amd64 241-4
amd64nss module providing dynamic user and group name resolution
ii libpam-systemd:amd64
N.B. The nvidia-current dkms built and is operational against kernel v5.0.5
-- sRw
As 4.20.x is going EOL, it may be prudent to investigate this bug WRT 5.0.x
-- sRw
On 3/5/19 11:51 AM, Debian Bug Tracking System wrote:
Thank you for filing a new Bug report with Debian.
You can follow progress on this Bug here: 923815:
Understood. I noted today that even nvidia-current was not able to
build the dkms module against 5.0, so this is really not urgent. -- sRw
On 3/5/19 7:25 PM, Andreas Beckmann wrote:
Control: tag -1 upstream
On 2019-03-05 18:49, S R Wright wrote:
The latest version of nvidia-legacy-340xx
This really needs to be fixed, at this point legacy NVIDIA graphics
cards (such as my NVIDIA Corporation GT216M [NVS 5100M]) cannot use the
legacy driver going past kernel 4.19.
The workaround of course is just to just use nouveau, which at least
*is* operational in 4.20.x but which also
Package: nvidia-legacy-340xx-kernel-dkms
Version: 340.107-3
This is completely functional in kernel 4.19.x and before, but an attempt to
use this in 4.20.x has failed. While dkms can build the module to completion,
at boot time in throws a large number of unknown symbols.
The list is
Can verify, this bug is kernel independent.
On Tue, 10 Jul 2018 12:15:51 +0200 Vincent Gatignol
wrote:
> hi there,
>
> running 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64
> GNU/Linux and having this issue too
>
> not specifically related to the 4.16 versions
>
>
>
On 10/31/2016 06:42 AM, Hannu wrote:
How do I roll back to gcc-6.2.0-6?
If you haven't cleaned package cache recently you might try this:
cd /var/cache/apt/archives
ls -al *6.2.0-6*
and if gcc-6.2.0-6 seems to be present:
dpkg -i *6.2.0-6*
The packages still appear to be available at
As just a data point, when -march=i686, the kernel builds and seems to
work well using 6.2.0-10 and with no patches to Makefile at all.
On 10/29/2016 10:24 AM, Oswald Buddenhagen wrote:
-no-pie is not a useful option here, because it's passed to the _linker_
only.
i got it to build with
h may mean
that the kernels are currently only built/supported with gcc-5.
vanilla kernels (Linus' tree and the stable ones) could be compiled just fine
with gcc 6.2.0-6 and that now fails.
I still think this is a major regression and regard gcc 6.2.0-7 simply as
broken.
On Thu, 2016-10-20 at 11:22 -0500,
I agree. When the version changes from 6.2.0-6 to 6.2.0-7, only bug
fixes should be included, not changes in functionality. In this case
setting enable-default-pie essentially broke backwards compatibility.
Kernel code that built in -6 failed to build in -7. That, I agree,
should be
Concurring with Wolfgang; pulling the source straight from kernel.org
and using identical .config files will work with 6.2.0-6 but fail with
6.2.0-7. I was able to build and install 4.8.3 with no issues after
back-revving gcc et. al. to 6.2.0-6
-- sRw
On 10/20/16 11:09, Wolfgang Walter
Package: gcc-6
Version: 6.2.0-7
Kernel building with stack protection enabled breaks with 6.2.0-7, whereas
identical .config works using 6.2.0-6:
output:
make[2]: Leaving directory '/usr/src/linux-4.8.1'
makeARCH=x86_64 prepare
make[2]: Entering directory '/usr/src/linux-4.8.1'
Ian:
Attached is the info you suggested, pre- and post-upgrade. Was never
prompted to answer any questions or than to continue the upgrade.
-- sRw
## v32:
root@mi6:# debconf-get-selections | grep grub
# /boot/grub/device.map has been regenerated
grub-efi-amd64
On 12/19/2015 10:04 AM, Ian Campbell wrote:
On Sat, 2015-12-19 at 09:52 -0600, S. R. Wright wrote:
Ian:
Attached is the info you suggested, pre- and post-upgrade. Was never
prompted to answer any questions or than to continue the upgrade.
I can't explain how it got there, but I think
It's possible that Windows is not relevant here; it could be that
whatever selection is last on the list that the OS prober constructs may
have this issue, and in my case the last entry just happened to be
Windows. Just FYI.
On 12/19/2015 09:03 AM, Colin Watson wrote:
On Fri, Dec 18, 2015 at 09:26:55PM -0600, S. R. Wright wrote:
dpkg -l "grub*" | egrep "^ii"
ii grub-common2.02~beta2-33 amd64GRand Unified Bootloader
(common files)
ii grub-efi 2.02~beta2-33 amd64
Package: grub-efi-amd64
Version: 2.02~beta2-33
Severity: serious
dpkg -l "grub*" | egrep "^ii"
ii grub-common2.02~beta2-33 amd64GRand Unified Bootloader
(common files)
ii grub-efi 2.02~beta2-33 amd64GRand Unified Bootloader,
version 2 (dummy package)
ii
Package: x11-xserver-utils
Version: 7.7+5
Kernel: 4.2.0
Arch: amd64
The xrandr query command shows a display that had been disconnected with:
xrandr --output LVDS-1 --off
as still being connected. My host has an LCD display (LVDS-1) and an
external monitor (VGA-1). Starting with both
On Sat, 27 Sep 2014 23:48:10 -0400 Michael Gilbert mgilb...@debian.org
wrote:
control: tag -1 moreinfo
Could someone experiencing this please attach configuration files?
I'm not able to reproduce it with a vanilla installation.
Best wishes,
Mike
It pretty reliably crashed for me with
I can confirm that a rollback to version 1:9.9.5.dfsg-4 works
correctly. My name server is just caching-only.
-- sRw
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: bind9
Version: 1:9.9.5.dfsg-4.1
From syslog:
Sep 25 15:16:21 odeon named[12685]: mem.c:1321: REQUIRE(ptr != ((void *)0))
failed, back trace
Sep 25 15:16:21 odeon named[12685]: #0 0x7fd64356522d in ??
Sep 25 15:16:21 odeon named[12685]: #1 0x7fd6417527ba in ??
Sep 25 15:16:21 odeon
33 matches
Mail list logo
