Jump to content

postinst of *-dkms package is broken on armbian

DrPO

By DrPO
in Beginners

 Share

Recommended Posts

DrPO

DrPO

Posted
Posted

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.

Petr Fedchenkov

Petr Fedchenkov

Posted
Posted
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

Matthias

Matthias

Posted
Posted (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
Igor

Igor

Posted
Posted
1 hour ago, Matthias said:

Is this still an open issue

 

Yes, if not found in the release documentation. And it will remain this way until you/somebody submit fix to the build code.

 

Good thing is that after this RFC there are less files to adjust:

Matthias

Matthias

Posted
Posted

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.

Igor

Igor

Posted
Posted
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.

Matthias

Matthias

Posted
Posted

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

 

Matthias

Matthias

Posted
Posted

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

Igor

Igor

Posted
Posted
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.

Matthias

Matthias

Posted
Posted

Update on the current state of my activities. All changes mentioned below are not yet on Armbian's master:

  1. I modified /etc/environment and removed the export of the variable ARCH. This fixes the problem about that variable mentioned at the begin of the thread.
  2. I added dependencies to the linux headers compiled during build of Armbian images. That way packages like "make" and "flex" are automatically installed when installing the header package. I was not able to test all supported kernels (and adjust the dependecies to all of them) yet, so this work is incomplete. So this part is still in progress. Also: If the headers are installed during the build of the image the part "Compiling headers - please wait ..." still fails as make cannot be found in the chrooted environment. Update: The previous sentence was a misobservation. Thanks to QEMU the installation can proceed within the chrooted environment. Is just very slow if you choose to install the headers during the build of the image.
  3. I also found out that the version of ZFS for Linux that is part of Debian Buster is not compatible with kernels >5.2. (see https://github.com/vpsfreecz/zfs/commit/36c110f9943f3abe2ac59ffa7e76b48e8dbfc1b6). So it is possible that I won't get it running with current kernels after all. But it makes me believe that DKMS is not generally broken and I can get it running with the modifications 1 and 2.

I'll keep you posted...

Matthias

Matthias

Posted
Posted

I finally complete and tested my fixes. Concerning the dependencies of the linux headers I added the following for kernels <=4.14: make, gcc, libc6-dev, libssl-dev. And the following for newer kernels: make, gcc, libc6-dev, bison, flex, libssl-dev

 

The results of my tests on a NanoPi M4V2:

 

Legacy kernel (4.14-rockchip): Works out perfectly. After installing the kernel headers, zfs-dkms can be installed flawlessly. The modules are compiled.

 

Current kernel (mainline 5.4.6): ZFS (0.7.12) cannot be installed. I assume this is caused by the problem mentioned above (https://github.com/vpsfreecz/zfs/commit/36c110f9943f3abe2ac59ffa7e76b48e8dbfc1b6): This version of ZFS is not compatible with kernels >=5.2. I also tried the backport of ZFS (0.8.2) which should be compatible with the kernel but then next problem pops up (https://github.com/zfsonlinux/zfs/issues/8545). So I decided ZFS is a bad reference for confirming the fix of DKMS as there seem to be too many issues with ZFS itself.

 

But I was able to install other DKMS-packages successfully:

  • dm-writeboost-dkms
  • lime-forensics-dkms

My conclusion: My changes seem to fix DKMS in Armbian but it seems to be too optimistic to expect DKMS-packages compile successfully against the most current kernels. The following branch contains my changes: https://github.com/mmriech/armbian-build/tree/fix_dkms. I'm going to create a pull request for that.

Matthias

Matthias

Posted
Posted

Just one thing I would like to mention here for the sake of documentation: The modification of the dependencies of the kernel headers should get into existing installations sooner or later by regular updates of packages (as soon as PR 1697 is merged). But the modification of /etc/environment won't, as far as I understand the build process of Armbian. That modification needs to be made manually on existing installations in order to get DKMS working.

 

Sorry about all those tiny increments of information day by day, but I was a complete newbee to the build system of Armbian when I joined this quest and I'm still learning a lot on every step I take...

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept