Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Fabian Keil 
Konstantin Belousov  wrote:

> On Tue, Dec 15, 2015 at 05:42:38PM +0100, Fabian Keil wrote:
> > I've seen the following panic a couple of times in the last three
> > months, usually while poudriere was running and with sh being the
> > current process.
> > 
> > This one is from a system based on r290926 running with
> > kern.randompid=9001 and forking frequently (>1000 forks/second)
> > due to poudriere and afl-fuzz:
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 04
> > fault virtual address   = 0x618b00a8
> > fault code  = supervisor read data, page not present
> > instruction pointer = 0x20:0x80909158
> > stack pointer   = 0x28:0xfe011e03b940
> > frame pointer   = 0x28:0xfe011e03b960
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 71325 (sh)
> > trap number = 12
> > panic: page fault
> > cpuid = 1
> > KDB: stack backtrace:
> > [...]
> > Uptime: 13d20h43m20s
> > [...]
> > (kgdb) where
> > #0  doadump (textdump=1) at pcpu.h:221
> > #1  0x8094a923 in kern_reboot (howto=260) at 
> > /usr/src/sys/kern/kern_shutdown.c:364
> > #2  0x8094ae8b in vpanic (fmt=, ap= > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:757
> > #3  0x8094acc3 in panic (fmt=0x0) at 
> > /usr/src/sys/kern/kern_shutdown.c:688
> > #4  0x80c2fbb1 in trap_fatal (frame=, 
> > eva=) at /usr/src/sys/amd64/amd64/trap.c:834
> > #5  0x80c2fda4 in trap_pfault (frame=0xfe011e03b890, 
> > usermode=) at /usr/src/sys/amd64/amd64/trap.c:684
> > #6  0x80c2f55e in trap (frame=0xfe011e03b890) at 
> > /usr/src/sys/amd64/amd64/trap.c:435
> > #7  0x80c120a7 in calltrap () at 
> > /usr/src/sys/amd64/amd64/exception.S:234
> > #8  0x80909158 in fork_findpid (flags=) at 
> > /usr/src/sys/kern/kern_fork.c:281  
> It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.

Unfortunately it's not available and apparently I removed the attempts
to get it from the previous output.

#8  0x80909158 in fork_findpid (flags=) at 
/usr/src/sys/kern/kern_fork.c:281
warning: Source file is more recent than executable.

281 (p->p_pgrp != NULL &&
Current language:  auto; currently minimal
(kgdb) p p
No symbol "p" in current context.
(kgdb)  p trypid
$1 = 
(kgdb)  p pidchecked
$2 = 9
(kgdb) p lastpid
$3 = 51281

allproc is available and the first one matches lastpid and has an invalid
p_pgrp, but due to trypid being optimized out as well, it's not obvious
(to me) that it's the right process.

(kgdb)  p *allproc->lh_first
$4 = {p_list = {le_next = 0xf800a99e4548, le_prev = 0x813f3cc8}, 
p_threads = {tqh_first = 0xf801162819a0, tqh_last = 0xf801162819b0}, 
p_slock = {lock_object = {
  lo_name = 0x80e22449 "process slock", lo_flags = 537067520, 
lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, p_ucred = 0xf8009d07, 
p_fd = 0x0, p_fdtol = 0x0, p_stats = 0xf800299e5800, 
  p_limit = 0x0, p_limco = {c_links = {le = {le_next = 0x0, le_prev = 0x0}, sle 
= {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, 
c_precision = 0, c_arg = 0x0, c_func = 0, 
c_lock = 0xf800304df120, c_flags = 0, c_iflags = 0, c_cpu = 0}, 
p_sigacts = 0x0, p_flag = 268443648, p_flag2 = 0, p_state = PRS_NEW, p_pid = 
51281, p_hash = {le_next = 0x0, 
le_prev = 0xfec8a288}, p_pglist = {le_next = 0x0, le_prev = 
0xf800aa94d618}, p_pptr = 0xf800aa94d548, p_sibling = {le_next = 0x0, 
le_prev = 0xf800aa94d640}, p_children = {
lh_first = 0x0}, p_reaper = 0xf800029a5548, p_reaplist = {lh_first = 
0x0}, p_reapsibling = {le_next = 0xf8007e713548, le_prev = 
0xf80023df1110}, p_mtx = {lock_object = {
  lo_name = 0x80e2243c "process lock", lo_flags = 558039040, 
lo_data = 0, lo_witness = 0x0}, mtx_lock = 18446735280470265856}, p_statmtx = 
{lock_object = {lo_name = 0x80e22457 "pstatl", 
  lo_flags = 537067520, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, 
p_itimmtx = {lock_object = {lo_name = 0x80e2245e "pitiml", lo_flags = 
537067520, lo_data = 0, lo_witness = 0x0}, 
mtx_lock = 4}, p_profmtx = {lock_object = {lo_name = 0x80e22465 
"pprofl", lo_flags = 537067520, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, 
p_ksi = 0xf80126950380, p_sigqueue = {
sq_signals = {__bits = 0xf800304df1a8}, sq_kill = {__bits = 
0xf800304df1b8}, sq_list = {tqh_first = 0x0, tqh_last = 
0xf800304df1c8}, sq_proc = 0xf800304df000, sq_flags = 1}, p_oppid = 0, 
  p_vmspace = 0x0, p_swtick = 3344683412, p_cowgen = 0, p_realtimer = 
{it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 
0}}, p_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Konstantin Belousov 
On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
> Konstantin Belousov  wrote:
> > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.
> 
> Unfortunately it's not available and apparently I removed the attempts
> to get it from the previous output.

> allproc is available and the first one matches lastpid and has an invalid
> p_pgrp, but due to trypid being optimized out as well, it's not obvious
> (to me) that it's the right process.

p_suspcount = 0, p_xthread = 0xf801162819a0, p_boundary_count = 0, 
p_pendingcnt = 0, p_itimers = 0x0, p_procdesc = 0x0, p_treeflag = 0, p_magic = 
3203398350, p_osrel = 1100090, 
>   p_comm = 0xf800304df3c4 "privoxy",
p_pgrp = 0x618b0080,

> I've changed p's declaration to static so hopefully its value will
> be available the next time the panic occurs, but it may take a while
> until that happens.

>From the state of the process you provided, it is a new (zigote) of the
forking process, which was already linked into allproc list.  Also,
it seems that bzero part of the forking procedure was finished, but bcopy
was not yet.  The p_pgrp cannot be a pointer, it is not yet initialized.

There, we have at least one issue, since zigote is linked before the
p_pgrp is initialized, and the proctree/allproc locks are dropped.
As result, fork_findpid() accesses memory with undefined content.

It seems that the least morbid solution is to slightly extend the scope
of the allproc lock in do_fork(), to prevent fork_findpid() from working
while we did not finished copying data from old to new process.

diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index 1b556be..ae04c9f 100644
--- a/sys/kern/kern_fork.c
+++ b/sys/kern/kern_fork.c
@@ -396,13 +396,12 @@ do_fork(struct thread *td, int flags, struct proc *p2, 
struct thread *td2,
PROC_LOCK(p2);
PROC_LOCK(p1);
 
-   sx_xunlock(&allproc_lock);
-
bcopy(&p1->p_startcopy, &p2->p_startcopy,
__rangeof(struct proc, p_startcopy, p_endcopy));
pargs_hold(p2->p_args);
 
PROC_UNLOCK(p1);
+   sx_xunlock(&allproc_lock);
 
bzero(&p2->p_startzero,
__rangeof(struct proc, p_startzero, p_endzero));
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Konstantin Belousov 
On Tue, Dec 15, 2015 at 05:42:38PM +0100, Fabian Keil wrote:
> I've seen the following panic a couple of times in the last three
> months, usually while poudriere was running and with sh being the
> current process.
> 
> This one is from a system based on r290926 running with
> kern.randompid=9001 and forking frequently (>1000 forks/second)
> due to poudriere and afl-fuzz:
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 04
> fault virtual address   = 0x618b00a8
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80909158
> stack pointer   = 0x28:0xfe011e03b940
> frame pointer   = 0x28:0xfe011e03b960
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 71325 (sh)
> trap number = 12
> panic: page fault
> cpuid = 1
> KDB: stack backtrace:
> [...]
> Uptime: 13d20h43m20s
> [...]
> (kgdb) where
> #0  doadump (textdump=1) at pcpu.h:221
> #1  0x8094a923 in kern_reboot (howto=260) at 
> /usr/src/sys/kern/kern_shutdown.c:364
> #2  0x8094ae8b in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:757
> #3  0x8094acc3 in panic (fmt=0x0) at 
> /usr/src/sys/kern/kern_shutdown.c:688
> #4  0x80c2fbb1 in trap_fatal (frame=, eva= optimized out>) at /usr/src/sys/amd64/amd64/trap.c:834
> #5  0x80c2fda4 in trap_pfault (frame=0xfe011e03b890, 
> usermode=) at /usr/src/sys/amd64/amd64/trap.c:684
> #6  0x80c2f55e in trap (frame=0xfe011e03b890) at 
> /usr/src/sys/amd64/amd64/trap.c:435
> #7  0x80c120a7 in calltrap () at 
> /usr/src/sys/amd64/amd64/exception.S:234
> #8  0x80909158 in fork_findpid (flags=) at 
> /usr/src/sys/kern/kern_fork.c:281
It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.

> #9  0x80907225 in do_fork (td=0xf8009db9a9a0, flags=20, 
> p2=0xf8009dbe1a90, td2=0xf800aa6884d0, vm2=0xf800a9eee000, 
> pdflags=0) at /usr/src/sys/kern/kern_fork.c:385
> #10 0x80906c08 in fork1 (td=0xf8009db9a9a0, flags=20, 
> pages=, procp=0xfe011e03bac0, procdescp=0x0, 
> pdflags=9, fcaps=)
> at /usr/src/sys/kern/kern_fork.c:937
> #11 0x809066ca in sys_fork (td=0xf8009db9a9a0, uap= optimized out>) at /usr/src/sys/kern/kern_fork.c:108
> #12 0x80c3054b in amd64_syscall (td=0xf8009db9a9a0, traced=0) at 
> subr_syscall.c:140
> #13 0x80c1238b in Xfast_syscall () at 
> /usr/src/sys/amd64/amd64/exception.S:394
> #14 0x0008009257aa in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently minimal
> (kgdb) f 8
> #8  0x80909158 in fork_findpid (flags=) at 
> /usr/src/sys/kern/kern_fork.c:281
> warning: Source file is more recent than executable.
>
> 281 (p->p_pgrp != NULL &&
> (kgdb) l -
> 271  * id is kept reserved only while there is a
> 272  * non-reaped process in the subtree, so amount of
> 273  * reserved pids is limited by process limit times
> 274  * two.
> 275  */
> 276 p = LIST_FIRST(&allproc);
> 277 again:
> 278 for (; p != NULL; p = LIST_NEXT(p, p_list)) {
> 279 while (p->p_pid == trypid ||
> 280 p->p_reapsubtree == trypid ||
> (kgdb) l
> 281 (p->p_pgrp != NULL &&
> 282 (p->p_pgrp->pg_id == trypid ||
> 283 (p->p_session != NULL &&
> 284 p->p_session->s_sid == trypid {
> 285 trypid++;
> 286 if (trypid >= pidchecked)
> 287 goto retry;
> 288 }
> 289 if (p->p_pid > trypid && pidchecked > 
> p->p_pid)
> 290 pidchecked = p->p_pid;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Fabian Keil 
Oliver Pinter  wrote:

> Is this with latest 11-CURRENT or 10-STABLE?
> 
> Or contains the ad578c311ef commit?

The panic is from a system based on 11-CURRENT r290926.

Is ad578c311ef a HardenedBSD commit? It doesn't seem to
exist in https://github.com/freebsd/freebsd.git.

Fabian


pgpHRlok72ddQ.pgp
Description: OpenPGP digital signature

Re: "libssl.so.8" not found

2015-12-16 Thread Willem Jan Withagen 
On 14-12-2015 16:35, Brad Davis wrote:
> On Mon, Dec 14, 2015 at 06:03:25AM -0700, Warner Losh wrote:
>> On Mon, Dec 14, 2015 at 2:21 AM, Ronald Klop  wrote:
>>
>>> On Mon, 14 Dec 2015 10:11:35 +0100, Ronald Klop 
>>> wrote:
>>>
>>> On Mon, 14 Dec 2015 08:18:40 +0100, Matthias Apitz 
 wrote:

 El d??a Sunday, December 13, 2015 a las 10:40:22PM -0800, Russell Haley
> escribi??:
>
> Hi There,
>>
>> I am trying to bring up an Arm image off the FreeBSD website for my
>> hummingboard. The problem seems to be when I run pkg the system installs
>> the latest version - 1.6.2, and then fails with:
>>
>> Shared object "libssl.so.8" not found, required by "pkg"
>>
>> I've seen this in NextBSD, and DesktopBSD and even on my previous arm
>> image
>> but I was able to get around the problem by creating links from
>> libssl.so.7
>> to libssl.so.8.
>>
>
> I have had the same issue on r285885 with ports as well from July this
> year and pkg 1.5.5 ... I accidently updated pkg to 1.6.x which could not
> find libssl.so.8; I forced back to 1.5.5 with an older pkg-static and
> now pkg
> complains about it database, but still works:
>
> $ pkg info pkg
> pkg: warning: database version 32 is newer than libpkg(3) version 31,
> but still compatible
> pkg-1.5.5
>
> I don't know why pkg 1.6.2 was produced with this recent libssl.so.8; it
> should have been done more conservative, IMHO
>
> matthias
>
>
 I had the same problem on my amd64 laptop. Your FreeBSD version is too
 old. Upgrading the FreeBSD base will give you the new libssl version. After
 that you can upgrade your packages.

 What version of FreeBSD is running on this hummingboard? I guess
 11-CURRENT. Probably ssl was upgraded in FreeBSD and the new packages are
 build on this newer version. In 10-STABLE this is kept backwards
 compatible, but in 11-CURRENT you have to keep up yourself.

 Regards,

 Ronald.

>>>
>>> It has to do with this message in /usr/src/UPDATING:
>>>
>>>
>>> https://svnweb.freebsd.org/base/head/UPDATING?r1=290206&r2=290207&pathrev=292177&;
>>
>>
>> As a temporary measure, for bootstrapping or installing packages, you can
>> also
>> use libmap.conf to map libssl.so.7 to libssl.so.8. There's a second library
>> that
>> you'll find you need to map too. This will get you over the hump. However,
>> once you do upgrade, you'll need to remove the lines because slogin and such
>> have a check for the right version of openssl, and will give an error
>> message if
>> you try to use them cross-threaded.
> 
> Or just use pkg-static. :)

Cool trick, never though about that.
However that does not help with auxilary tools that are code to use pkg. :(

So in the end I just manually build the pkg port, which will compile
against whatever is available as ssl-lib. Not the best solution, since
next time Bapt releases a new version, the game starts again.

perhaps in this case it is best to move pkg-static to pkg?
and always use a static linked version. It is not like a deamon running
for ever. So the temporary overhead of 4Mb <> 150K code space would be
acceptable.

--WjW
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Oliver Pinter 
Yes, it's a HardenedBSD commit. Currently only a workaround, because I have
now lesser time for the real fix in this month.

Are you running on ZFS?

On Wednesday, December 16, 2015, Fabian Keil 
wrote:

> Oliver Pinter > wrote:
>
> > Is this with latest 11-CURRENT or 10-STABLE?
> >
> > Or contains the ad578c311ef commit?
>
> The panic is from a system based on 11-CURRENT r290926.
>
> Is ad578c311ef a HardenedBSD commit? It doesn't seem to
> exist in https://github.com/freebsd/freebsd.git.
>
> Fabian
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Mateusz Guzik 
On Wed, Dec 16, 2015 at 02:10:00PM +0200, Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
> > Konstantin Belousov  wrote:
> > > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.
> > 
> > Unfortunately it's not available and apparently I removed the attempts
> > to get it from the previous output.
> 
> > allproc is available and the first one matches lastpid and has an invalid
> > p_pgrp, but due to trypid being optimized out as well, it's not obvious
> > (to me) that it's the right process.
> 
> p_suspcount = 0, p_xthread = 0xf801162819a0, p_boundary_count = 0, 
> p_pendingcnt = 0, p_itimers = 0x0, p_procdesc = 0x0, p_treeflag = 0, p_magic 
> = 3203398350, p_osrel = 1100090, 
> >   p_comm = 0xf800304df3c4 "privoxy",
> p_pgrp = 0x618b0080,
> 
> > I've changed p's declaration to static so hopefully its value will
> > be available the next time the panic occurs, but it may take a while
> > until that happens.
> 
> From the state of the process you provided, it is a new (zigote) of the
> forking process, which was already linked into allproc list.  Also,
> it seems that bzero part of the forking procedure was finished, but bcopy
> was not yet.  The p_pgrp cannot be a pointer, it is not yet initialized.
> 
> There, we have at least one issue, since zigote is linked before the
> p_pgrp is initialized, and the proctree/allproc locks are dropped.
> As result, fork_findpid() accesses memory with undefined content.
> 
> It seems that the least morbid solution is to slightly extend the scope
> of the allproc lock in do_fork(), to prevent fork_findpid() from working
> while we did not finished copying data from old to new process.
> 
> diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
> index 1b556be..ae04c9f 100644
> --- a/sys/kern/kern_fork.c
> +++ b/sys/kern/kern_fork.c
> @@ -396,13 +396,12 @@ do_fork(struct thread *td, int flags, struct proc *p2, 
> struct thread *td2,
>   PROC_LOCK(p2);
>   PROC_LOCK(p1);
>  
> - sx_xunlock(&allproc_lock);
> -
>   bcopy(&p1->p_startcopy, &p2->p_startcopy,
>   __rangeof(struct proc, p_startcopy, p_endcopy));
>   pargs_hold(p2->p_args);
>  
>   PROC_UNLOCK(p1);
> + sx_xunlock(&allproc_lock);
>  
>   bzero(&p2->p_startzero,
>   __rangeof(struct proc, p_startzero, p_endzero));

While I agree with analysis the patch does not look right. Since the
struct is only assigned and all locks get dropped, there is nothing
preventing another thread from the forking process to change the process
group.

Interestngly very same function assigns the pointer explicitely later:
p2->p_pgrp = p1->p_pgrp;

As such, I would argue the right solution is to move p_pgrp out of the
copied area. Exit path clears the pointer, so it should be fine to just
do that.

That is (untested):

diff --git a/sys/sys/proc.h b/sys/sys/proc.h
index 90effa6..cb94318 100644
--- a/sys/sys/proc.h
+++ b/sys/sys/proc.h
@@ -586,7 +586,6 @@ struct proc {
int p_osrel;/* (x) osreldate for the
   binary (from ELF note, if any) */
charp_comm[MAXCOMLEN + 1];  /* (b) Process name. */
-   struct pgrp *p_pgrp;/* (c + e) Pointer to process group. */
struct sysentvec *p_sysent; /* (b) Syscall dispatch info. */
struct pargs*p_args;/* (c) Process arguments. */
rlim_t  p_cpulimit; /* (c) Current CPU limit in seconds. */
@@ -599,6 +598,7 @@ struct proc {
u_int   p_xsig; /* (c) Stop/kill sig. */
 /* End area that is copied on creation. */
 #definep_endcopy   p_xsig
+   struct pgrp *p_pgrp;/* (c + e) Pointer to process group. */
struct knlist   p_klist;/* (c) Knotes attached to this proc. */
int p_numthreads;   /* (c) Number of threads. */
struct mdproc   p_md;   /* Any machine-dependent fields. */

-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Aw: Re: make .SUFFIXES bug?

2015-12-16 Thread Carsten Kunze 
Hello Simon, 

> > .SUFFIXES:
> > .SUFFIXES: .roff .in .ps .mom .pdf .me .ms .ps .html .txt .texi .dvi .pdf
> .xhtml .man .c .cpp .log .o .obj .sed .sin .test .test$(EXEEXT) .trs .ypp
> 
> What is the value of EXEEXT at this point?

You are right, the example is not as small as it could be for reproducing the 
issue.
These lines are just extracted from groff's makefile.  The issue does still 
occur
if .test$(EXEEXT) is removed.

Regards,
Carsten
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Oliver Pinter 
Hi!

Is this with latest 11-CURRENT or 10-STABLE?

Or contains the ad578c311ef commit?

On Tuesday, December 15, 2015, Shawn Webb 
wrote:

> On Tue, Dec 15, 2015 at 05:42:38PM +0100, Fabian Keil wrote:
> > I've seen the following panic a couple of times in the last three
> > months, usually while poudriere was running and with sh being the
> > current process.
> >
> > This one is from a system based on r290926 running with
> > kern.randompid=9001 and forking frequently (>1000 forks/second)
> > due to poudriere and afl-fuzz:
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 04
> > fault virtual address   = 0x618b00a8
> > fault code  = supervisor read data, page not present
> > instruction pointer = 0x20:0x80909158
> > stack pointer   = 0x28:0xfe011e03b940
> > frame pointer   = 0x28:0xfe011e03b960
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 71325 (sh)
> > trap number = 12
> > panic: page fault
> > cpuid = 1
> > KDB: stack backtrace:
> > [...]
> > Uptime: 13d20h43m20s
> > [...]
>
> Hey Fabien,
>
> I'm glad you've seen this, too. We've observed this in HardenedBSD,
> especially when running Poudriere and Jenkins. I think Oliver Pinter
> might have a potential patch to fix this. I've CC'd him on this thread.
>
> Thanks,
>
> --
> Shawn Webb
> HardenedBSD
>
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Konstantin Belousov 
On Wed, Dec 16, 2015 at 02:54:27PM +0100, Mateusz Guzik wrote:
> While I agree with analysis the patch does not look right. Since the
> struct is only assigned and all locks get dropped, there is nothing
> preventing another thread from the forking process to change the process
> group.
> 
> Interestngly very same function assigns the pointer explicitely later:
> p2->p_pgrp = p1->p_pgrp;
> 
> As such, I would argue the right solution is to move p_pgrp out of the
> copied area. Exit path clears the pointer, so it should be fine to just
> do that.
For reused struct proc it would be enough, but not for the new allocation.
Neither init nor ctr for the proc zone do not initialize p_pgrp, so
you would end up with the garbage in the pointer.

I think that your patch should add explcit zeroing of the member into
proc_init().

> 
> That is (untested):
> 
> diff --git a/sys/sys/proc.h b/sys/sys/proc.h
> index 90effa6..cb94318 100644
> --- a/sys/sys/proc.h
> +++ b/sys/sys/proc.h
> @@ -586,7 +586,6 @@ struct proc {
>   int p_osrel;/* (x) osreldate for the
>  binary (from ELF note, if any) */
>   charp_comm[MAXCOMLEN + 1];  /* (b) Process name. */
> - struct pgrp *p_pgrp;/* (c + e) Pointer to process group. */
>   struct sysentvec *p_sysent; /* (b) Syscall dispatch info. */
>   struct pargs*p_args;/* (c) Process arguments. */
>   rlim_t  p_cpulimit; /* (c) Current CPU limit in seconds. */
> @@ -599,6 +598,7 @@ struct proc {
>   u_int   p_xsig; /* (c) Stop/kill sig. */
>  /* End area that is copied on creation. */
>  #define  p_endcopy   p_xsig
> + struct pgrp *p_pgrp;/* (c + e) Pointer to process group. */
>   struct knlist   p_klist;/* (c) Knotes attached to this proc. */
>   int p_numthreads;   /* (c) Number of threads. */
>   struct mdproc   p_md;   /* Any machine-dependent fields. */
> 
> -- 
> Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Do keymaps need to be in /usr/...?

2015-12-16 Thread Carsten Kunze 
Hello,

disk decryption works for me when I put

kbdcontrol -l /usr/share/syscons/keymaps/german.iso.kbd

into /etc/rc.d/geli.

But do the keymaps need to be in a file system which may be mounted delayed?  
If there is an error at boot time and something needs to be input to the 
console the keyboard can be considered as unusable until the correct keymap has 
been set.

Carsten
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

keymap set after file system decryption

2015-12-16 Thread Carsten Kunze 
Hello,

according to the boot messages the keymap is set after decryption of file 
systems.  I consider this as a bug.  The geli decryption script asks for the 
passphrase which can't of course be input if the kaymap is not set.

Handbook §17.12 does not mention the keymap setup.  What can I do to make this 
work?  (Of course I can call e.g. kbdmap in /etc/rc.d/geli, but this is kind of 
tinkering.)

Carsten
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: keymap set after file system decryption

2015-12-16 Thread Trond Endrestøl 
On Wed, 16 Dec 2015 11:04+0100, Carsten Kunze wrote:

> Hello,
> 
> according to the boot messages the keymap is set after decryption of 
> file systems.  I consider this as a bug.  The geli decryption script 
> asks for the passphrase which can't of course be input if the kaymap 
> is not set.
> 
> Handbook §17.12 does not mention the keymap setup.  What can I do to 
> make this work?  (Of course I can call e.g. kbdmap in 
> /etc/rc.d/geli, but this is kind of tinkering.)

I guess we who live outside the US should take into account that PCs 
are initialised by firmware to the US keyboard layout and the 437 code 
page, courtesy of IBM, 1981.

I'm not sure if the creators of (U)EFI has considered other keyboard 
layouts and/or code pages at boot time.

A bad workaround is to copy the suitable keymap from /usr/share... to 
/etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one 
or either of /etc/rc.d/geli{,2}, e.g.:

/etc/kbdcontrol -l /etc/german.iso.kbd

kbdcontrol is linked only to libc:

$ ldd `which kbdcontrol`
/usr/sbin/kbdcontrol:
libc.so.7 => /lib/libc.so.7 (0x800827000)

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Fabian Keil 
Oliver Pinter  wrote:

> Yes, it's a HardenedBSD commit. Currently only a workaround, because I have
> now lesser time for the real fix in this month.
> 
> Are you running on ZFS?

Yes.

Fabian


pgpuOBy_BlV8u.pgp
Description: OpenPGP digital signature

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Fabian Keil 
Konstantin Belousov  wrote:

> On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
> > Konstantin Belousov  wrote:  
> > > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 
> > > 8.  
> > 
> > Unfortunately it's not available and apparently I removed the attempts
> > to get it from the previous output.  
> 
> > allproc is available and the first one matches lastpid and has an invalid
> > p_pgrp, but due to trypid being optimized out as well, it's not obvious
> > (to me) that it's the right process.  
> 
> p_suspcount = 0, p_xthread = 0xf801162819a0, p_boundary_count = 0, 
> p_pendingcnt = 0, p_itimers = 0x0, p_procdesc = 0x0, p_treeflag = 0, p_magic 
> = 3203398350, p_osrel = 1100090, 
> >   p_comm = 0xf800304df3c4 "privoxy",  
> p_pgrp = 0x618b0080,
> 
> > I've changed p's declaration to static so hopefully its value will
> > be available the next time the panic occurs, but it may take a while
> > until that happens.  
> 
> From the state of the process you provided, it is a new (zigote) of the
> forking process, which was already linked into allproc list.  Also,
> it seems that bzero part of the forking procedure was finished, but bcopy
> was not yet.  The p_pgrp cannot be a pointer, it is not yet initialized.
> 
> There, we have at least one issue, since zigote is linked before the
> p_pgrp is initialized, and the proctree/allproc locks are dropped.
> As result, fork_findpid() accesses memory with undefined content.
> 
> It seems that the least morbid solution is to slightly extend the scope
> of the allproc lock in do_fork(), to prevent fork_findpid() from working
> while we did not finished copying data from old to new process.

Thanks. I'm currently testing the patch on three systems but it may take a 
while ...

Fabian


pgpvGkzQ7IxHR.pgp
Description: OpenPGP digital signature

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Konstantin Belousov 
On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote:
> Thanks. I'm currently testing the patch on three systems but it may take a 
> while ...
> 

Better use mjg' patch with the small adjustment.  I put it below.

diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c
index 435a07b..fc39217 100644
--- a/sys/kern/kern_proc.c
+++ b/sys/kern/kern_proc.c
@@ -251,6 +251,7 @@ proc_init(void *mem, int size, int flags)
TAILQ_INIT(&p->p_threads);   /* all threads in proc */
EVENTHANDLER_INVOKE(process_init, p);
p->p_stats = pstats_alloc();
+   p->p_pgrp = NULL;
SDT_PROBE3(proc, kernel, init, return, p, size, flags);
return (0);
 }
diff --git a/sys/sys/proc.h b/sys/sys/proc.h
index 90effa6..cb94318 100644
--- a/sys/sys/proc.h
+++ b/sys/sys/proc.h
@@ -586,7 +586,6 @@ struct proc {
int p_osrel;/* (x) osreldate for the
   binary (from ELF note, if any) */
charp_comm[MAXCOMLEN + 1];  /* (b) Process name. */
-   struct pgrp *p_pgrp;/* (c + e) Pointer to process group. */
struct sysentvec *p_sysent; /* (b) Syscall dispatch info. */
struct pargs*p_args;/* (c) Process arguments. */
rlim_t  p_cpulimit; /* (c) Current CPU limit in seconds. */
@@ -599,6 +598,7 @@ struct proc {
u_int   p_xsig; /* (c) Stop/kill sig. */
 /* End area that is copied on creation. */
 #definep_endcopy   p_xsig
+   struct pgrp *p_pgrp;/* (c + e) Pointer to process group. */
struct knlist   p_klist;/* (c) Knotes attached to this proc. */
int p_numthreads;   /* (c) Number of threads. */
struct mdproc   p_md;   /* Any machine-dependent fields. */
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Aw: Re: keymap set after file system decryption

2015-12-16 Thread Carsten Kunze 
Trond Endrestøl  wrote:

> I guess we who live outside the US should take into account that PCs 
> are initialised by firmware to the US keyboard layout and the 437 code 
> page, courtesy of IBM, 1981.

In 1981 I had accepted this.  Now it's simply a bug and I wonder it has not 
been fixed in 22 years.  I'll file a bug report.

> I'm not sure if the creators of (U)EFI has considered other keyboard 
> layouts and/or code pages at boot time.

I don't care for the BIOS here, the OS has to take care of it.  It may be ok 
that at the boot prompt only US keymap is set.  But when the rc scripts are 
running the keymap must be set correctly (as one of the first actions).

> A bad workaround is to copy the suitable keymap from /usr/share... to 
> /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one 
> or either of /etc/rc.d/geli{,2}, e.g.:
> 
> /etc/kbdcontrol -l /etc/german.iso.kbd
> 
> kbdcontrol is linked only to libc:
> 
> $ ldd `which kbdcontrol`
> /usr/sbin/kbdcontrol:
> libc.so.7 => /lib/libc.so.7 (0x800827000)

In my case it's simpler since I have /usr in /, but as you descripted 
kbdcontrol must be in /sbin and the maps in /etc in the future.

Carsten
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: "libssl.so.8" not found

2015-12-16 Thread Daniel Kalchev 

> On 14.12.2015 г., at 17:35, Brad Davis  wrote:
> 
> 
> Or just use pkg-static. :)
> 

I always wondered, why pkg is not static ONLY. That eliminates the chicken/egg 
dilemma. 

Yes, you eliminate the friendly reminder that your system is out of sync with 
the FreeBSD package building platforms, but still…

Daniel
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: "libssl.so.8" not found

2015-12-16 Thread Brad Davis 
On Wed, Dec 16, 2015 at 11:00:19AM +0100, Willem Jan Withagen wrote:
> On 14-12-2015 16:35, Brad Davis wrote:
> > On Mon, Dec 14, 2015 at 06:03:25AM -0700, Warner Losh wrote:
> >> On Mon, Dec 14, 2015 at 2:21 AM, Ronald Klop  wrote:
> >>
> >>> On Mon, 14 Dec 2015 10:11:35 +0100, Ronald Klop 
> >>> wrote:
> >>>
> >>> On Mon, 14 Dec 2015 08:18:40 +0100, Matthias Apitz 
>  wrote:
> 
>  El d??a Sunday, December 13, 2015 a las 10:40:22PM -0800, Russell Haley
> > escribi??:
> >
> > Hi There,
> >>
> >> I am trying to bring up an Arm image off the FreeBSD website for my
> >> hummingboard. The problem seems to be when I run pkg the system 
> >> installs
> >> the latest version - 1.6.2, and then fails with:
> >>
> >> Shared object "libssl.so.8" not found, required by "pkg"
> >>
> >> I've seen this in NextBSD, and DesktopBSD and even on my previous arm
> >> image
> >> but I was able to get around the problem by creating links from
> >> libssl.so.7
> >> to libssl.so.8.
> >>
> >
> > I have had the same issue on r285885 with ports as well from July this
> > year and pkg 1.5.5 ... I accidently updated pkg to 1.6.x which could not
> > find libssl.so.8; I forced back to 1.5.5 with an older pkg-static and
> > now pkg
> > complains about it database, but still works:
> >
> > $ pkg info pkg
> > pkg: warning: database version 32 is newer than libpkg(3) version 31,
> > but still compatible
> > pkg-1.5.5
> >
> > I don't know why pkg 1.6.2 was produced with this recent libssl.so.8; it
> > should have been done more conservative, IMHO
> >
> > matthias
> >
> >
>  I had the same problem on my amd64 laptop. Your FreeBSD version is too
>  old. Upgrading the FreeBSD base will give you the new libssl version. 
>  After
>  that you can upgrade your packages.
> 
>  What version of FreeBSD is running on this hummingboard? I guess
>  11-CURRENT. Probably ssl was upgraded in FreeBSD and the new packages are
>  build on this newer version. In 10-STABLE this is kept backwards
>  compatible, but in 11-CURRENT you have to keep up yourself.
> 
>  Regards,
> 
>  Ronald.
> 
> >>>
> >>> It has to do with this message in /usr/src/UPDATING:
> >>>
> >>>
> >>> https://svnweb.freebsd.org/base/head/UPDATING?r1=290206&r2=290207&pathrev=292177&;
> >>
> >>
> >> As a temporary measure, for bootstrapping or installing packages, you can
> >> also
> >> use libmap.conf to map libssl.so.7 to libssl.so.8. There's a second library
> >> that
> >> you'll find you need to map too. This will get you over the hump. However,
> >> once you do upgrade, you'll need to remove the lines because slogin and 
> >> such
> >> have a check for the right version of openssl, and will give an error
> >> message if
> >> you try to use them cross-threaded.
> > 
> > Or just use pkg-static. :)
> 
> Cool trick, never though about that.
> However that does not help with auxilary tools that are code to use pkg. :(
> 
> So in the end I just manually build the pkg port, which will compile
> against whatever is available as ssl-lib. Not the best solution, since
> next time Bapt releases a new version, the game starts again.

No.  This was caused by ssl being bumped, not pkg.  Pkg is updated
regularly without this issue.

> perhaps in this case it is best to move pkg-static to pkg?
> and always use a static linked version. It is not like a deamon running
> for ever. So the temporary overhead of 4Mb <> 150K code space would be
> acceptable.

There is talk about making the static version the default.


Regards,
Brad Davis

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Don Lewis 
On 16 Dec, Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
>> Konstantin Belousov  wrote:
>> > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.
>> 
>> Unfortunately it's not available and apparently I removed the attempts
>> to get it from the previous output.
> 
>> allproc is available and the first one matches lastpid and has an invalid
>> p_pgrp, but due to trypid being optimized out as well, it's not obvious
>> (to me) that it's the right process.
> 
> p_suspcount = 0, p_xthread = 0xf801162819a0, p_boundary_count = 0, 
> p_pendingcnt = 0, p_itimers = 0x0, p_procdesc = 0x0, p_treeflag = 0, p_magic 
> = 3203398350, p_osrel = 1100090, 
>>   p_comm = 0xf800304df3c4 "privoxy",
> p_pgrp = 0x618b0080,
> 
>> I've changed p's declaration to static so hopefully its value will
>> be available the next time the panic occurs, but it may take a while
>> until that happens.
> 
> From the state of the process you provided, it is a new (zigote) of the
> forking process, which was already linked into allproc list.  Also,
> it seems that bzero part of the forking procedure was finished, but bcopy
> was not yet.  The p_pgrp cannot be a pointer, it is not yet initialized.
> 
> There, we have at least one issue, since zigote is linked before the
> p_pgrp is initialized, and the proctree/allproc locks are dropped.
> As result, fork_findpid() accesses memory with undefined content.
> 
> It seems that the least morbid solution is to slightly extend the scope
> of the allproc lock in do_fork(), to prevent fork_findpid() from working
> while we did not finished copying data from old to new process.

I used to have a patch the deferred linking the new process into
proctree/allproc until it was fully formed.  The motivation was to get
rid of all of the PRS_NEW stuff scattered around the source.
Unfortunately the patch bit-rotted and I'm pretty sure that I lost it.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Fabian Keil 
Konstantin Belousov  wrote:

> On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote:
> > Thanks. I'm currently testing the patch on three systems but it may take a 
> > while ...
> >   
> 
> Better use mjg' patch with the small adjustment.  I put it below.

Will do.

Fabian


pgpARhuAh6qDb.pgp
Description: OpenPGP digital signature

Re: webcamd & cuse4bsd

2015-12-16 Thread Kostya Berger 
Well, this seems to be either hardware or software (driver code) bug.
After `usbconfig -d ugen1.4 reset` webcamd restarting sometimes creates the 
device /dev/video0 -- sometimes,, but not every time. More often than not it 
doesn't. So there's no method seen in this behaviour so far. I wonder how I 
could debug this.

Sent from Yahoo Mail on Android 
 
  On Wed, Dec 16, 2015 at 1:22, Kostya Berger wrote:   
Ok, I failed to make it clear enough: the module is loaded on boot. This was 
what was actually meant by the expression "when the system starts". By 
contrast, loading on demand is... well, loading "on demand". These are two ways 
of starting a program, "on demand", as opposite to "when the system starts". 
Please, correct me if I'm wrong here.Yet the situation is as I described. 
That's what I'm actually reporting. Just now I've done a reboot, and here we go 
again: all modules loaded, /dev/cuse persent, the message telling me "webcam is 
already running on ugen1.4.0" (my web-camera) -- and NO /dev/video0.

Though it hits me now, there are 3 devices /dev/usb/1.4.*. Maybe 1.4.0 is not 
the correct one?
Sent from Yahoo Mail on Android 
 
  On Tue, Dec 15, 2015 at 23:54, Allan Jude wrote:   On 
2015-12-15 14:13, Kostya Berger wrote:
> You misread my message, sorry. I said the devices are not created EVERY
> TIME the system starts. Rather, it becomes A MATTER OF CHANCE. That is,
> sometimes they are, sometimes they aren't.
> (with the modules not loaded it would be stable NO)
> 
> 
> Sent from Yahoo Mail on Android
> 
> 
>    On Tue, Dec 15, 2015 at 23:01, Allan Jude
>     wrote:
> 
>    On 2015-12-15 13:37, Kostya Berger wrote:
> 
>    > There is this problem I'm experiencing with webcamd (set to
>    webcamd_enable=YES) and cuse4bsd: special devices /dev/video0 and
>    /dev/cuse are NOT cteated every time on system start. Rather, it
>    becomes a matter of chance.Have the same problem on RELEASE & STABLE
>    as well.
>    >
>    > Sent from Yahoo Mail on Android
>    > ___
>    > freebsd-current@freebsd.org  mailing list
>    > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>    > To unsubscribe, send any mail to
>    "freebsd-current-unsubscr...@freebsd.org 
>    "
>    >
> 
>    In /boot/loader.conf try adding:
> 
>    cuse_load="YES"
> 
>    this will load the module, and should ensure the devices are available
>    before webcamd starts.
> 
>    -- 
>    Allan Jude
> 

The module is loaded 'on demand', but obviously something it not loading
it on-demand when you want it. Forcing it to always be loaded, should
solve your problem.

-- 
Allan Jude
  
  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI and i915kms questions

2015-12-16 Thread John Baldwin 
On Thursday, December 03, 2015 07:16:45 PM Joe Maloney wrote:
> It works!  Would it be helpful if I did a pull request from github, or just 
> let you guys take it from here?  Thanks for helping me figure out how to get 
> up, and running!  This will be so much better than the framebuffer driver I 
> was having to use.

I've posted this at https://reviews.freebsd.org/D4599 for review.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Re: keymap set after file system decryption

2015-12-16 Thread Kevin Oberman 
On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze 
wrote:

> Trond Endrestøl  wrote:
>
> > I guess we who live outside the US should take into account that PCs
> > are initialised by firmware to the US keyboard layout and the 437 code
> > page, courtesy of IBM, 1981.
>
> In 1981 I had accepted this.  Now it's simply a bug and I wonder it has
> not been fixed in 22 years.  I'll file a bug report.
>
> > I'm not sure if the creators of (U)EFI has considered other keyboard
> > layouts and/or code pages at boot time.
>
> I don't care for the BIOS here, the OS has to take care of it.  It may be
> ok that at the boot prompt only US keymap is set.  But when the rc scripts
> are running the keymap must be set correctly (as one of the first actions).
>
> > A bad workaround is to copy the suitable keymap from /usr/share... to
> > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one
> > or either of /etc/rc.d/geli{,2}, e.g.:
> >
> > /etc/kbdcontrol -l /etc/german.iso.kbd
> >
> > kbdcontrol is linked only to libc:
> >
> > $ ldd `which kbdcontrol`
> > /usr/sbin/kbdcontrol:
> > libc.so.7 => /lib/libc.so.7 (0x800827000)
>
> In my case it's simpler since I have /usr in /, but as you descripted
> kbdcontrol must be in /sbin and the maps in /etc in the future.
>
> Carsten
>

You can specify your default keymap in your kernel config file.
ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
/boot/loader.conf, as well, but I'm not too sure of this. See atkbd(4).
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"