mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
* [ptxdist] Running depmod after deploying some extra kernel modules
@ 2016-03-09 15:48 stefan kratochwil
  2016-03-11 11:09 ` Michael Olbrich
  0 siblings, 1 reply; 2+ messages in thread
From: stefan kratochwil @ 2016-03-09 15:48 UTC (permalink / raw)
  To: ptxdist


[-- Attachment #1.1: Type: text/plain, Size: 1713 bytes --]

Hi,

I am struggling with integrating some (unfortunately proprietary) wifi kernel
modules, which are build outside the kernel sources. In fact, I only need to
call depmod after the targetinstall step. However, I'm not feeling too lucky
with my results so far.

The imho most promising way lead me to /etc/rc.once.d, so I created a little
shell script which calls depmod on the first bootup of my target, and added it
to rc.once.d. It turned out that this triggers a reboot (!) after the prelink
step was executed:

[   13.747106] systemd-journald[110]: Received SIGTERM from PID 1
(systemd-shutdow).

I played around a bit and recognized, that this reboot only occurs if my depmod
script is executed _after_ the prelink step. If I prepend a '0_' to my depmod
script name, then no reboot occurs. In both cases, modprobe finds my modules
after having the system fully booted up, so depmod was _definitely_ executed.

I have no explanation for that rebooting behaviour, and I also noticed that
none of my "echo" calls were printed out. Maybe executing depmod during the
system boot process is not the best idea, so I am looking for a more safe way
to do that.

I had no luck with google, the ptxdist mailing lists and the ptxdist git
history, so does anyone know what to do in such a situation? Is the
rc.once.d-way okay for my purpose, or is there a less blunt option? Could I
somehow call depmod at the postinst stage?


I am using:
- ptxdist 2014.11.0
- OSELAS.toolchain() 2013.12.2
- linux kernel 3.16 (with some minor modifications)
- freescale i.mx6 target


My script for executing depmod from rc.once.d:
#!/bin/sh
echo -n "running depmod..."
depmod
echo done


Many thanks in advance!


Cheers,
Stefan






[-- Attachment #1.2: Type: text/html, Size: 2078 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [ptxdist] Running depmod after deploying some extra kernel modules
  2016-03-09 15:48 [ptxdist] Running depmod after deploying some extra kernel modules stefan kratochwil
@ 2016-03-11 11:09 ` Michael Olbrich
  0 siblings, 0 replies; 2+ messages in thread
From: Michael Olbrich @ 2016-03-11 11:09 UTC (permalink / raw)
  To: ptxdist

On Wed, Mar 09, 2016 at 03:48:51PM +0000, stefan kratochwil wrote:
> I am struggling with integrating some (unfortunately proprietary) wifi kernel
> modules, which are build outside the kernel sources. In fact, I only need to
> call depmod after the targetinstall step. However, I'm not feeling too lucky
> with my results so far.
> 
> The imho most promising way lead me to /etc/rc.once.d, so I created a little
> shell script which calls depmod on the first bootup of my target, and added it
> to rc.once.d. It turned out that this triggers a reboot (!) after the prelink
> step was executed:
> 
> [   13.747106] systemd-journald[110]: Received SIGTERM from PID 1
> (systemd-shutdow).
> 
> I played around a bit and recognized, that this reboot only occurs if my depmod
> script is executed _after_ the prelink step. If I prepend a '0_' to my depmod
> script name, then no reboot occurs. In both cases, modprobe finds my modules
> after having the system fully booted up, so depmod was _definitely_ executed.
> 
> I have no explanation for that rebooting behaviour, and I also noticed that
> none of my "echo" calls were printed out. Maybe executing depmod during the
> system boot process is not the best idea, so I am looking for a more safe way
> to do that.
> 
> I had no luck with google, the ptxdist mailing lists and the ptxdist git
> history, so does anyone know what to do in such a situation? Is the
> rc.once.d-way okay for my purpose, or is there a less blunt option? Could I
> somehow call depmod at the postinst stage?
[...]

Don't do this during runtime. Take a look at the out-of-tree kernel driver
template. You can create a example driver with "ptxdist newpackage
src-linux-driver". If you do it this way, then the kernel package will
include your driver and run depmod at build-time.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-03-11 11:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-09 15:48 [ptxdist] Running depmod after deploying some extra kernel modules stefan kratochwil
2016-03-11 11:09 ` Michael Olbrich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox