Right now the linux compatibility kernel module supports 2 abi versions: 2.4.2 and 2.6.16. 2.4.2 is the default, the other one can be set via a sysctl variable. But the current versions of all linux_base-*packages need the 2.6.16 setting. Unfortunately, though, the packages don't have any mechanism in place to actually set this permanently. I venture to guess the maintainers wanted the user to put this setting into /etc/sysctl.conf . But, aside from the fact that at least the binary package installation makes no mention of this, this creates a unique problem: /etc/rc.d/sysctl (which implements sysctl.conf) is run *before* /etc/rc.d/abi (which loads the kernel module). So, at this point the osrelease setting fails silently. Later on (very late, actually) /etc/rc.d/sysctl is invoked a second time by /etc/rc.d/securelevel, which then sets the variable correctly. But unfortunatley, at this time, many third party package start scripts from /usr/local/etc/rc.d/ have already been run. Most of them either use REQUIRE LOGIN or no such setting at all, both of which results in them being run before securelevel. Any of those needing linux_base fail silently. Now, a workaround would be to have each linux-dependent package use "REQUIRE securelevel". But that is counter-intuitive and might even bring up other problems, especially if you actually use securelevel. The correct way of course is to have the osrelease variable set earlier. A simple way to do this is for the respective linux_base package to install its own small start script that can run much earlier without any adverse consequences. I include such a script below and suggest it or something similar to be added to all linux_base-* packages and installed by them to /usr/local/etc/rc.d/ Fix: #!/bin/sh # # PROVIDE: linuxversion # REQUIRE: abi # BEFORE: DAEMON # # . /etc/rc.subr name="linuxversion" stop_cmd=":" start_cmd="linuxversion_start" reload_cmd="linuxversion_start" linuxversion_start() { echo "Settimg Linux ABI version:" sysctl compat.linux.osrelease=2.6.16 } load_rc_config $name run_rc_command "$1"
Responsible Changed From-To: freebsd-ports-bugs->freebsd-emulation This is a script that would affect several ports. Over to maintainers.
This IRC transcript from Freenode/##FreeBSD might be relevant. <fleximus> frag4: no, I am root under normal system <fleximus> frag4: The behaviour of the script is different when startet during boot. Don't forget to add linuxtest_enable="YES" to /etc/rc.conf <frag4> fleximus: I'm unable to reproduce your problem. <cmanns> yes but you need to call like /compat/linux/bin/bash first er somethin? <frag4> fleximus: please do procstat -f $$ in very same shell you run /bin/sh /usr/local/etc/rc.d/startscript <fleximus> frag4: It's the default /bin/csh for root from command line. The systems reboots at the moment, give you the other result in a second <fleximus> frag4: During boot it is /bin/sh. Anyway, if I call /bin/sh /usr/local/etc/rc.d/startscript it works fine <fleximus> frag4: The latter will also display /bin/sh. <frag4> fleximus: well, I'm running 9.0 here and cannot reproduce this. Eithery way, I'm going home now, some good luck with debugging. :) <frag4> fleximus: s/some/so/ <fleximus> frag4: This is also 9.0, but I must leave soon, too ;-( <fleximus> frag4: Thank you for your ideas <fleximus> oh, that might be the solution, I will test now: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/159646 <fleximus> and this one: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/148097 <fleximus> PR148097 is the workaround for me! Now I can go home. bye bye <fleximus> frag4: =)
back to pool
Is this PR still relevant?
Timeout (> 2 months).