Control: retitle -1 dpkg-fsys-usrunmess: Does not deal with untracked kernel 
modules

Hi!

On Sat, 2022-03-26 at 19:21:44 +0100, Eric Valette wrote:
> Package: dpkg
> Version: 1.21.4
> Severity: critical
> Justification: breaks the whole system

> Gobally the scripts does a very good job but it missed to copy 
> /usr/lib/modules to
> /lib/modules on a self generated kernel that has modules build via dkms and a
> few native kernel modules.

I assume the custom built kernel was installed w/o a .deb package?

> Invoquing the dkms postinstall script fails because it does not find 
> /lib/modules/x.y.z
> directories and rebooting without graphic drivers and other stff does not 
> work.

Just to understand, did dpkg-fsys-usrunmess fail (exited non-zero) while
configuring packages (with dkms)? And then you rebooted?

If so, I guess the error message should be more clear that the system
has many chances of not being in a bootable state. And perhaps add
some instructions on how to proceed or similar. And it should ideally
be restartable (as already requested in another report), which I guess
I'll be working on next.

> 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,
  * copy (not move) all untracked files from «/usr/lib/modules/*» to
    «/lib/modules», and print a message at the end, but that will leave
    cruft behind if not cleaned up,
  * record them, and print a list at the end of the execution for the
    user to deal with, but that can be rather unfriendly, and that can
    include usual dkms built modules too,

> To fix i did:
>    1) boot in recovery mode,
>    2) copy /usr/lib/modules to /lib/modules
>    3) dkms autoinstall
>    4) update-grub
> 
> and it wworked.

I guess depending on whether the program failed or not that might
change what the better approach might be.

Thanks,
Guillem

Reply via email to