Bug 148097 - [patch] suggested addition to linux_base-* packages to set osrealese variable correctly
Summary: [patch] suggested addition to linux_base-* packages to set osrealese variable...
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-24 01:50 UTC by cwf-ml
Modified: 2014-11-23 07:17 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cwf-ml 2010-06-24 01:50:03 UTC
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"
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-06-24 21:27:27 UTC
Responsible Changed
From-To: freebsd-ports-bugs->freebsd-emulation

This is a script that would affect several ports.  Over to maintainers.
Comment 2 Chris Rees freebsd_committer freebsd_triage 2012-06-06 17:49:57 UTC
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: =)
Comment 3 Carlo Strub freebsd_committer freebsd_triage 2014-08-29 21:55:38 UTC
back to pool
Comment 4 Carlo Strub freebsd_committer freebsd_triage 2014-08-31 20:19:20 UTC
Is this PR still relevant?
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2014-11-23 07:17:34 UTC
Timeout (> 2 months).