1 1
DrPO

postinst of *-dkms package is broken on armbian

Recommended Posts

I'm doing some driver work, and distribute these driver via DKMS package.

when installed on armbian, there is some problem.

 

Test Environment

* Board: OrangePi Plus 2E

* Armbian: 5.85

* OS: Ubuntu 18.04.2

 

Reproduce step

* install dkms and kernel header: `sudo apt-get install dkms linux-headers-next-sunxi`

* install some *-dkms package, acpi-call-dkms for example: `sudo apt-get install acpi-call-dkms`

* you get some error in _/var/lib/dkms/acpi-call/1.1.0/build/make.log_

```

DKMS make.log for acpi-call-1.1.0 for kernel 4.19.38-sunxi (armv7l)
Fri May 10 14:56:03 CST 2019
make: Entering directory '/usr/src/linux-headers-4.19.38-sunxi'
Makefile:619: arch//Makefile: No such file or directory
make: *** No rule to make target 'arch//Makefile'.  Stop.
make: Leaving directory '/usr/src/linux-headers-4.19.38-sunxi'

```

 

but if you manually build with `dkms` command, it built with no error.

`sudo dkms build acpi-call/1.1.0`

 

then I check the source of dkms at https://github.com/dell/dkms

and found that in the postinst hook, ARCH variable is set to empty. so

`ARCH= dkms build acpi-call/1.1.0`

will get the same error as in the `apt-get install` command

 

but ARCH is set to arm in `/etc/environment`

 

finally, as manually build of *-dkms is OK, unable to auto install DKMS package is not a very big problem.

Share this post


Link to post
Share on other sites
On 5/10/2019 at 10:45 AM, DrPO said:

I'm doing some driver work, and distribute these driver via DKMS package.

when installed on armbian, there is some problem.

 

Test Environment

* Board: OrangePi Plus 2E

* Armbian: 5.85

* OS: Ubuntu 18.04.2

 

Reproduce step

* install dkms and kernel header: `sudo apt-get install dkms linux-headers-next-sunxi`

* install some *-dkms package, acpi-call-dkms for example: `sudo apt-get install acpi-call-dkms`

* you get some error in _/var/lib/dkms/acpi-call/1.1.0/build/make.log_

```

DKMS make.log for acpi-call-1.1.0 for kernel 4.19.38-sunxi (armv7l)
Fri May 10 14:56:03 CST 2019
make: Entering directory '/usr/src/linux-headers-4.19.38-sunxi'
Makefile:619: arch//Makefile: No such file or directory
make: *** No rule to make target 'arch//Makefile'.  Stop.
make: Leaving directory '/usr/src/linux-headers-4.19.38-sunxi'

```

 

but if you manually build with `dkms` command, it built with no error.

`sudo dkms build acpi-call/1.1.0`

 

then I check the source of dkms at https://github.com/dell/dkms

and found that in the postinst hook, ARCH variable is set to empty. so

`ARCH= dkms build acpi-call/1.1.0`

will get the same error as in the `apt-get install` command

 

but ARCH is set to arm in `/etc/environment`

 

finally, as manually build of *-dkms is OK, unable to auto install DKMS package is not a very big problem.

 

Hi!

 

Faced a similar problem. As a workaround, I made a small script (in the attachment) that repack the package with postinst patches. Please try it, if you need.

/bin/bash remakedkmsdeb.sh YOURDEB

Unfortunately, it doesn't work with acpi-call-dkms (I try to modify after apt install --download-only acpi-call-dkms), but it works for my modules.

 

remakedkmsdeb.sh

Share this post


Link to post
Share on other sites
(edited)

Is this still an open issue or is there already a solution in progress? I just tried to install the package zfs-dkms (which includes spl-dkms) and observed the same symptoms: Installation failed but when running dkms manually everything worked out fine:

dkms build -m spl -v 0.7.12
dkms build -m zfs -v 0.7.12
dkms install -m spl -v 0.7.12
dkms install -m zfs -v 0.7.12

So my situation is good for now but when thinking about updating the system in the future I expect to run into the problem again.

I'm using Armbian (Debian Buster) for the Rock Pi 4 (on a NanoPi M4v2). The package I installed was: Armbian_5.98_Rockpi-4b_Debian_buster_default_4.4.192_minimal.

Edited by Matthias

Share this post


Link to post
Share on other sites

Thanks for the quick answer. I've absolutely no clue about the builder of Armbian and have never built Armbian by myself. But it sounds like an interesting challenge and the patches on your branch look quite understandable (as understandable as patches are...). Together with the information in this thread at least I have an idea of what needs to be done. So let's hope I get some enlightment to figure out the "how". Don't expect quick results.

Share this post


Link to post
Share on other sites
14 minutes ago, Matthias said:

I've absolutely no clue about the builder of Armbian and have never built Armbian by myself


Special Armbian build script engine know-how is not needed for this challenge. Relevant code location was already added in my previous post. The rest - solving the actual problem - has to be done manual first, then a patch (all four of them to solve for other kernels too) has to be modified. When your modified patch is adjusting post install scripts properly, you submit changes to the code.
 

16 minutes ago, Matthias said:

Don't expect quick results.


Take your time. If I put this task on my 2do list it will surely take months - a year - never. I rather help you to solve it even this represent more work.

Share this post


Link to post
Share on other sites

I have some news. After playing around a bit randomly to understand (a tiny part of) the internals of dpkg and dkms I did the following, knowing that we have some problems with the environment variable ARCH (see comments above): I checked the file /usr/lib/dkms/common.postinst. I replaced all occurences of ARCH by ARCH_. The idea behind that: In general ARCH is a global variable, in the script is used like a local variable: It it set to the architecture the script receives as parameter $4.

 

Then I ran "apt install zfs-dkms". It succeeded. (just to make it clear: I ran it before the edit and it failed. Of course I deinstalled zfs-dkms and spl-dkms afterwards)

 

Could that count as a fix or do you think it's just a workaround for some problem hidden much deeper in the system? I installed the same dkms-modules some while ago on a Debian or Ubuntu x86 system and it worked like a charm right from the beginning. So I'm a bit it doublt that we are facing a general problem of DKMS here...

 

Edit 1: Just realised that this is more or less what Petr's script (above) does.

Edit 2: The patch mentioned above only(?) works when running the following sequence of commands on a fresh installation of Armbian (important part: install linux headers AFTER the first attempt to build zfs-dkms and try again):

apt update
apt install zfs-dkms                                     # yes, do this without any kernel headers installed.
# patch /usr/lib/dkms/common.postinst ($ARCH -> $ARCH_)
apt remove spl-dkms zfs-dkms                             # allow zfs-dkms to be installed again
apt install linux-headers-rockchip64
apt install zfs-dkms

 

Share this post


Link to post
Share on other sites

Ok, now I think I understand the background why dkms-packages cannot be installed. The example from my previous post is still valid, but now I can give further explanations:

apt update

# Make sure all packages required to build zfs-dpkg are installed.
# Easiest way to do it, is by installing the package itself.
# As a side effect, this also provides all tools required to successfully compile the headers of the kernel.
# Afterwards the dkms-packages can (and need to) be deinstalled again.
apt install zfs-dkms
apt remove spl-dkms zfs-dkms

# The installed packages dkms has a problem: In the postinst script the local variable ARCH is in conflict with the environment variable ARCH. Two solutions are avaiable:
# 1) Manually patch file /usr/lib/dkms/common.postinst ($ARCH -> $ARCH_)
# 2) Install patched deb-package available as attachment (dpkg -i dkms)

# Install linux-headers. This is a (soft) requirement of the package dkms-zfs. (not enforced as dependency)
# The step "Compiling headers" takes quite some time, indicating that work is actually done.
apt install linux-headers-rockchip64

# Now the package zfs-dkms can be installed without problems
apt install zfs-dkms

So I can nail down the problem to two individual problems:

  1. The Debian package "dkms" is incompatible with Armbian (at least with version Armbian_5.98_Rockpi-4b_Debian_buster_default_4.4.192_minimal)
  2. The packages linux-headers is patched by Armbian to have no dependencies and run some scripts (make) after installation. The success of the execution of the scripts is not checked, so problems are hidden from the user. Due to the lack of dependencies the linux-headers cannot be installed successfully on the minimal Armbian without manually installing required packages (even "make" is not installed by default).

So far for the observations. The interpretation of those is more complex and beyond my knowledge of Armbian and Debian. Those are my personal thoughts:

  1. I expect fixing the package "dkms" is outside the scope of Armbian. So this would need to be clarified with the Debian project. I can think of two theoretical solutions how that could be handled within Armbian:
    1. Create patched version of official debian package "dpkg" by the builder of Armbian and provide it for download via apt. Is this even intended within Armbian?
    2. Make Armbian work without the environment variable "ARCH". Potentially goes extremely deep into the system.
  2. Add dependencies to the linux-headers so the postinst can run successfully. Standard debian defines dependencies to packages like gcc and kbuild. Why doesn't Armbian?
    1. Another example: When running "make scripts" after the end of the sequence above it still fails because "libssl-dev" is not installed.

Igor, what's your point of view on that?

dkms_2.6.1-4_all.deb

Share this post


Link to post
Share on other sites
9 hours ago, Matthias said:

4.4.192


Retry your observation on a modern kernel and make a diff. I remember dkms was broken on stock x86 Debian / Ubuntu several times. Kernel 4.4.y is the oldest we have around .... we have to fix it on latest stable (4.19.y or 5.3.y) and potentially port to 4.4.y (if its trivial).

 

Why we don't use upstream packaging here? Simply because we have more different kernels per architecture. Now, they were reduced, but the logic remains. What we gain is, that we narrowed down needed patches. This means we have much better control for their adjustments. Previously they were scattered around in per kernel patches. Before proceeding doing any real changes this task has to be closed. Then dependencies are adjusted. It is possible to get rid of this run-time make adjustment but it is again (possibly a lot) more work. 

 

9 hours ago, Matthias said:

Make Armbian work without the environment variable "ARCH". Potentially goes extremely deep into the system.


IMHO only this can be a fix, others are workarounds.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
1 1