On 28/03/2022 12:35, Guillem Jover wrote:
There was no printed error beside the arror from dkms postinst (virtualbox
assumed it was running virtualized, and nvidia just failling): just a
congratulation message. Diid not check the return value of the script via echo
$?
Ok, so if the script did not finish with something like:
,---
error: cannot reconfigure packages: ...
`---
Then I suppose it exited normally with something like:
,---
Done, hierarchy unmessed, congrats!
Rebooting now is very strongly advised.
(Note: you might need to run 'hash -r' in your shell.)
`---
The latter. And I did the hash -r and rebooted...
If the latter, I guess the maintainer script(s) running dkms, didn't exit
non-zero. Hmm. Where those from external third-party packages?
Third party code but packaged by debian members:
dpkg -s nvidia-kernel-dkms
Package: nvidia-kernel-dkms
Status: install ok installed
Priority: optional
Section: non-free/kernel
Installed-Size: 49099
Maintainer: Debian NVIDIA Maintainers
<pkg-nvidia-de...@lists.alioth.debian.org>
Architecture: amd64
Multi-Arch: foreign
Source: nvidia-graphics-drivers
Version: 470.103.01-3
Provides: nvidia-kernel-470.103.01
Depends: dkms (>= 2.1.0.0), nvidia-firmware-470.103.01,
nvidia-kernel-support--v1
Pre-Depends: nvidia-installer-cleanup
Recommends: nvidia-driver (>= 470.103.01) | libcuda1 (>= 470.103.01)
Description: NVIDIA binary kernel module DKMS source
This package builds the NVIDIA Xorg binary kernel module needed by
nvidia-driver, using DKMS.
Provided that you have the kernel header packages installed, the kernel
module will be built for your running kernel and automatically rebuilt for
any new kernel headers that are installed.
.
The NVIDIA binary driver provides optimized hardware acceleration of
OpenGL/GLX/EGL/GLES applications via a direct-rendering X Server
for graphics cards using NVIDIA chip sets.
.
This version only supports GeForce, NVS, Quadro, RTX, Tesla, ... GPUs
based on
the Kepler (desktop cards only), Maxwell, Pascal, Volta, Turing, Ampere or
newer architectures.
The (Tesla) 470 drivers are the last driver series supporting GPUs
based on
the Kepler architecture.
Look at the legacy driver packages for older cards.
.
See /usr/share/doc/nvidia-kernel-dkms/README.txt.gz
for a complete list of supported GPUs and PCI IDs.
.
This package contains the blobs for building kernel modules for the
amd64 architecture.
Building the kernel modules has been tested up to Linux 5.17.
Homepage: https://www.nvidia.com
dpkg -s virtualbox-dkms
Package: virtualbox-dkms
Status: install ok installed
Priority: optional
Section: contrib/kernel
Installed-Size: 5571
Maintainer: Debian Virtualbox Team
<team+debian-virtual...@tracker.debian.org>
Architecture: amd64
Source: virtualbox (6.1.32-dfsg-1)
Version: 6.1.32-dfsg-1+b2
Provides: virtualbox-modules
Depends: dkms (>= 2.1.0.0)
Recommends: virtualbox (>= 6.1.32-dfsg-1)
Description: x86 virtualization solution - kernel module sources for dkms
VirtualBox is a free x86 virtualization solution allowing a wide range
of x86 operating systems such as Windows, DOS, BSD or Linux to run on a
Linux system.
.
This package provides the source code for the virtualbox kernel module
to be
build with dkms. Kernel sources or headers are required to compile this
module.
Homepage: https://www.virtualbox.org
So you probably should copy /usr/lib/modules to /lib/modules before the calling
the
postinstall.
Hmm, right, because these were not tracked, they got missed in the
migration. I've checked the Debian archive and at least there, it does
not look like anything else besides kernel modules are being current
shipped in those directories (via apt-file), but the problem is that
I've seen references in source code (via codesearch.d.o) to
/usr/lib/modules, for at least apache and python modules, so I don't
think an unconditional move for untracked files would be safe there.
I'm thinking the following special-case options (in order of decreasing
preference):
* move only untracked «/usr/lib/modules/[0-9]*» expecting/assuming
those to be kernel modules,
You could move only the current running kernel modules using uname
to find the version. It will not hurt and they will be rebuild anyway at least
for the dkms ones.
I guess that would be another option yes, thanks.
The real problem being that dkms generated file does not appear in any file
Sure.
I'll try to prepare something later today.
And thanks for the script anyway it helped a lot. Did not even
remembered I used usrmerge and it did such a mess/wreckage.
-- eric
