headers
Tom Ivar Helbekkmo | 1 Feb 2010 08:46
Picon
Gravatar

Re: Boot problems - grub related?

I've got -current running nicely on the machine, now, by including
MONOLITHIC instead of GENERIC from my local configuration file.  With
all the WARNING: lines gone, I can see that it says, before the kernel
starts generating output, "Kernel symbol table missing!".

The warnings I used to get look like:

[...]
WARNING: linker error: symbol `soo_ioctl' not found
WARNING: linker error: symbol `trace_enter' not found
WARNING: linker error: symbol `kern_free' not found
WARNING: module error: unable to affix module `compat_svr4'
[...]

Weird how this doesn't happen with the same /boot and /netbsd on another
machine, though...

-tih
--

-- 
Self documenting code isn't. User application constraints don't. --Ed Prochak
Permalink | Reply | 0 comments |
headers
Kurt Schreiner | 1 Feb 2010 10:34
Picon
Picon
Favicon

compiling kernel fails (amd64)

Hi,

with source cvs updated some minutes ago, compiling a new kernel
fails in uvm_fault.c

    compile  U24M2/uvm_fault.o
cc1: warnings being treated as errors
/u/NetBSD/src/sys/uvm/uvm_fault.c: In function 'uvm_fault_lower_generic1':
/u/NetBSD/src/sys/uvm/uvm_fault.c:1278: warning: unused variable 'uobjpage'
/u/NetBSD/src/sys/uvm/uvm_fault.c:1277: warning: unused variable 'uobj'
/u/NetBSD/src/sys/uvm/uvm_fault.c:1276: warning: unused variable 'amap'

*** Failed target:  uvm_fault.o

Above vars are only used in KASSERT(...) which lint doesn't count as "used"...

Kurt
Permalink | Reply | 0 comments |
headers
NetBSD source update | 2 Feb 2010 04:15
Picon

daily CVS update output


Updating src tree:
P src/sys/arch/sparc64/include/ctlreg.h
P src/sys/arch/sparc64/include/pmap.h
P src/sys/arch/sparc64/include/psl.h
P src/sys/arch/sparc64/sparc64/cache.h
P src/sys/arch/sparc64/sparc64/ipifuncs.c
P src/sys/arch/sparc64/sparc64/locore.s
P src/sys/arch/sparc64/sparc64/pmap.c
P src/sys/ddb/db_write_cmd.c
P src/sys/dev/acpi/acpi_tz.c
P src/sys/dev/pci/auich.c
P src/sys/dev/pci/hifn7751.c
P src/sys/dev/pci/if_bge.c
P src/sys/dev/pci/pcireg.h
P src/sys/kern/kern_ssp.c
P src/sys/uvm/uvm_fault.c

Updating xsrc tree:

Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Tue Feb  2 03:05:40 2010
SUP Scan for current completed at Tue Feb  2 03:05:52 2010
SUP Scan for mirror starting at Tue Feb  2 03:05:52 2010
SUP Scan for mirror completed at Tue Feb  2 03:11:09 2010

Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  40579250 Feb  2 03:15 ls-lRA.gz
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rhialto | 2 Feb 2010 09:04
Picon

Re: fsck seg fault failure on vmware -i386?

On Sat 30 Jan 2010 at 00:14:44 -0000, yancm <at> sdf.lonestar.org wrote:
> Why would /usr influence /rescue/fsck_ffs?

I know that my idea about /etc/localtime was discounted, but you can try
it fairly easy anyway: give it a go with /usr mounted, but with
/etc/localtime pointing to some non-existent file. If that still works,
you could try moving aside one of the directories inside /usr, retry,
etc, until you find one where it starts failing. Then you can try the
same procedure inside that directory. It's a bit tedious though...

> --gene
-Olaf.
--

-- 
___ Olaf 'Rhialto' Seibert    -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl      -- Cetero censeo "authored" delendum esse.
Permalink | Reply | 0 comments |
headers
Robert Elz | 2 Feb 2010 13:46
Picon

Re: fsck seg fault failure on vmware -i386?

    Date:        Tue, 2 Feb 2010 09:04:53 +0100
    From:        Rhialto <rhialto <at> falu.nl>
    Message-ID:  <20100202080453.GA12520 <at> falu.nl>

  | I know that my idea about /etc/localtime was discounted, but you can try
  | it fairly easy anyway: give it a go with /usr mounted, but with
  | /etc/localtime pointing to some non-existent file.

It actually could be related, but not in the way that you probably think,
just having the file absent wouldn't cause a problem, but having it absent
would mean a different default timezone was in use, and (in a few very
unlikely cases) different timezones can mean different times are valid,
and others not (and end up generating NULL from localtime() which does seem
to be the only way asctime_r() could core dump).

What would be useful would be to find out (if it is possible, I hestiated
to ask earlier, as I suspect this will not be easy) would be to find out
just what the value of the time_t is that was handed to ctime() and ended
up with a core dump.    That, and the (much easier to discover) what timezone
would normally be in use (ie: what is /etc/localtime) ?

If the core dump from fsck can be obtained, the way to discover the time
value most easily (I think) would be to do a stack trace, look at the call
of ctime(), see its (one) parameter, and look at what that points to - that's
the time_t value of interest.

Apart form that, it would require finding the inode in question, and dumping
its contents, which is probably not-trivial.

Of course, an alternative way to see if this is what the problem is would be
(Continue reading)

Permalink | Reply | 3 comments |
headers
NetBSD Security Officer | 2 Feb 2010 20:04
Picon

Updated: NetBSD Security Advisory 2010-001: File system module autoloading Denial of Service attack


		 NetBSD Security Advisory 2010-001
		 =================================

Topic:		File system module autoloading Denial of Service attack

Version:	NetBSD-current:		affected prior to 2009-12-19 20:28:27 UTC
		NetBSD 5.0.1:		not affected
		NetBSD 5.0:		not affected
		NetBSD 4.0.*:		not affected
		NetBSD 4.0:		not affected

Severity:	Local Denial of Service

Fixed:		NetBSD-current:		Dec 19, 2009

Please note that NetBSD releases prior to 4.0 are no longer supported.
It is recommended that all users upgrade to a supported release.

Abstract
========

A coding error in the NetBSD VFS code allows a local attacker to
crash the local system by passing a soon-to-be-unmapped pointer
as a file system name to the mount system call.

Technical Details
=================

When entering the mount_get_vfsops() function, the string "fstype",
(Continue reading)

Permalink | Reply | 0 comments |
headers
NetBSD Security Officer | 2 Feb 2010 20:04
Picon

Updated: NetBSD Security Advisory 2010-002: OpenSSL TLS renegotiation man in the middle vulnerability


		 NetBSD Security Advisory 2010-002
		 =================================

Topic:		OpenSSL TLS renegotiation man in the middle vulnerability

Version:	NetBSD-current:		affected prior to 2009-12-04
		NetBSD 5.0:		affected
		NetBSD 4.0.*:		affected
		NetBSD 4.0:		affected
		pkgsrc:			openssl package prior to 0.9.8l

Severity:	Information disclosure

Fixed:		NetBSD-current:		Dec 03, 2009
		NetBSD-5-0 branch:	Jan 12, 2010
		NetBSD-5 branch:	Jan 12, 2010
		NetBSD-4-0 branch:	Jan 12, 2010
		NetBSD-4 branch:	Jan 12, 2010
		pkgsrc 2009Q4:		openssl-0.9.8l corrects this issue

Please note that NetBSD releases prior to 4.0 are no longer supported.
It is recommended that all users upgrade to a supported release.

Abstract
========

An error in the OpenSSL TLS session renegotiation allows a remote
attacker to intercept communication and conduct a Man-in-the-Middle
attack on TLS sessions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aleksej Saushev | 2 Feb 2010 21:26
Picon

Hackathon, February 19-22 2010

  Hello!

We're running 13th Hackathon February 19-22 2010,
come and join us on IRC channel #netbsd-code at FreeNode (irc.freenode.net).
You may choose other ways to participate, if you find it more convenient.
See Hackathon page for updates: http://wiki.netbsd.se/Hackathon13

Goal

Fix as many bugs as possible, close as many PRs as possible.

Details

In previous years we have accumulated a lot of problem reports.
Some of them relate to no longer supported branches (e.g. 2.0)
and were occasionally fixed during regular code work.
Some of them relate to hardware developers don't have access to.
Some of them may be too easy to fix, but noone looks at that part
of code (e.g. documentation).
Some of them relate to packages already removed or heavily reworked.
Some of them relate to packages in exotic environment (Solaris, Interix)
and developers cannot test if the bug is present or not.

You can find more in PR database at http://netbsd.org/support/query-pr.html

More specifically, David Holland maintains categorized lists of PRs at

  http://www.netbsd.org/~dholland/buglists/

of which "Wanted for 5.1" (http://www.netbsd.org/~dholland/buglists/51-WANTED.html)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Schreiner | 2 Feb 2010 23:30
Picon
Picon
Favicon

(cross) compiling INSTALL kernel for vax fails

Hi,

with -current source cvs updated some minutes ago I got the
following runnig "build.sh ... release" for vax (tried on
both NetBSD/amd64 and Solaris/x86):

[...]
making sure the compat library is up to date...
`libcompat.a' is up to date.
making sure the kern library is up to date...
`libkern.o' is up to date.
    compile  INSTALL/uvm_fault.o
     create  vers.c
    compile  INSTALL/vers.o
       link  INSTALL/netbsd
uvm_fault.o: In function `uvm_fault_internal':
uvm_fault.c:(.text+0x8e1): undefined reference to `memset'

*** Failed target:  netbsd
[...]

GENERIC{,.MP} both compile and link fine, but some "mysterious"
call to memset in uvm_fault.c isn't #defined to vax_memset.
("mysterious" as I've not found where this "memset" comes
from... ;-)

Kurt
Permalink | Reply | 0 comments |
headers
yancm | 3 Feb 2010 00:31
Picon
Favicon

Re: fsck seg fault failure on vmware -i386?

> What would be useful would be to find out (if it is possible, I hestiated
> to ask earlier, as I suspect this will not be easy) would be to find out
> just what the value of the time_t is that was handed to ctime() and ended
> up with a core dump.    That, and the (much easier to discover) what
> timezone
> would normally be in use (ie: what is /etc/localtime) ?
>
> If the core dump from fsck can be obtained, the way to discover the time
> value most easily (I think) would be to do a stack trace, look at the call
> of ctime(), see its (one) parameter, and look at what that points to -
> that's
> the time_t value of interest.
>
> Apart form that, it would require finding the inode in question, and
> dumping its contents, which is probably not-trivial.
>
> Of course, an alternative way to see if this is what the problem is would
> be
> to fix asctime_r() (simply make it return NULL if its timeptr arg is
> NULL),
> and fix fsck_ffs (if ctime() returns NULL, don't attempt to dereference
> it).
> Then see if that version of fsck_ffs still dumps core, if it does, then we
> haven't yet found the real problem.  If those changes fix it, then you
> have
> the guts of a PR to submit to get a big fixed...

OK, have core and gdb - you already saw the backtrace ouput...

Is this what you are looking for?:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane