.install/.hook scripts not run with pacstrap

Manjaro ARM Bug Reports
,
#1

This is something I discovered recently, and only recently did it actually start to matter for Manjaro ARM.

Because of the way we do our images and build or packages, the .install and .hook scripts from pacman packages does not get run when the manjaro-arm-tools does it's pacstrap section.
It seems to be because pacstrap uses the hosts pacman to execute on the guest chroot, which is another architecture for us.
I did hope that the qemu binaries for arm, would fix this, but not quite. According to Eli from Arch Linux, using pacstrap to create a chroot for another architecture, will probably result in problems. But we did not have these problems, until recently.

Because pacman (x86_64) assumes an x86_64 architecture when it runs inside the chroot with pacstrap, any packages providing a .install or .hook will (appearently) not get it run when on armv7h or aarch64 architectures instead. This can be seen by lines like execv failed when running the build commands. Most of the time it does not matter, but right now we have encountered a problem with a kernel update for the raspberry pi.

The rpi2 18.09 images use kernel 4.14.66, which works fine from the image. But if you try updating that kernel, to say the current 4.14.74 in the repo, USB input devices will seize to work, probably all USB devices in general.
But if I create an image with kernel 4.14.74 on it and boot it, I have working USB.
The only difference I can see, is that when I create the image, the .install and .hook from the kernel package does not get run properly, and thus it still works. These scripts will obviously get run when a normal update on the device is performed.

So my question is this. What inside the .install and .hook files can result in USB not working?
The device still boots.

Disclaimer: I have not tested this out on other devices/kernels. I will when I get home. So I don't know if this is also a problem with them.

PS: These .install files not running, might also be the problem with certain package builds failing on armv7h too. But it seems odd that aarch64 is not affected by this.

#2 
~ >>> depmod -h                                                                                                      
Usage:
	depmod -[aA] [options] [forced_version]

If no arguments (except options) are given, "depmod -a" is assumed

depmod will output a dependency list suitable for the modprobe utility.

Options:
	-a, --all            Probe all modules
	-A, --quick          Only does the work if there's a new module
	-e, --errsyms        Report not supplied symbols
	-n, --show           Write the dependency file on stdout only
	-P, --symbol-prefix  Architecture symbol prefix
	-C, --config=PATH    Read configuration from PATH
	-v, --verbose        Enable verbose mode
	-w, --warn           Warn on duplicates
	-V, --version        show version
	-h, --help           show this help

The following options are useful for people managing distributions:
	-b, --basedir=DIR    Use an image of a module tree.
	-F, --filesyms=FILE  Use the file instead of the
	                     current kernel symbols.
	-E, --symvers=FILE   Use Module.symvers file to check
	                     symbol versions.

If no arguments (except options) are given, "depmod -a" is assumed

Could adding -a -P armv7h do it?

#3

Inside the .install file?

From the man depmod:

 -P
           Some architectures prefix symbols with an extraneous character. This specifies a prefix character (for example '_') to ignore.

Not sure I want to ignore armv7h. :slight_smile:

#4

That was my thought - I have absolutely no idea of what I am talking about - so it is just brainstorming.

But the depmod command is what is run in the .install and and you point that the host system architecture is x86_64 - which leads me to think you could add the arguments.

But I can see that the approach would cause issues otherwise - so it could be used to test if the added arguments would change anything.

No - that would defeat the purpose :laughing:

#5

But according to the man page og depmod, that is what -P armv7h would do. :stuck_out_tongue:

#6

I did not dive into the man page - just assumed the -P would point depmod to what architecture was used, not an elimination feature.

I don't have any other ideas so sparkle with - sorry :slight_smile:

1 Like
#7

Alright.
Created a new image with the new kernel. Then re-installed that kernel with sudo pacman -S linux-raspberrypi to make it run the .install and .hook and this actually worked!
So it's a problem with the old kernel in 18.09 I think.
linux-aarch64 from 18.09 does not have said problem either.

1 Like
#8

I found out what was causing this exact behaviour.
The 18.09 images for the raspberry pi's are missing the /boot entry in /etc/fstab.
This means, that the kernel update (which boots stuff into /boot) cannot find the files it needs to actually boot the new kernel.

I will create new images, with a fix for this, this weekend.
If you have a 18.09 raspberry pi image, please do this before you update:

  • Open /etc/fstab:
    sudo nano /etc/fstab

  • Add the following line to it:

/dev/mmcblk0p1  /boot   vfat    defaults        0       0

  • Reboot

  • Then update to get an up to date working system:
    sudo pacman -Syyu

Forum kindly sponsored by