headers
David Brownlee | 1 Mar 2004 17:04
Picon

Re: cpuflags problem

On Fri, 27 Feb 2004, Martin Schmitz wrote:

> Manuel Bouyer wrote:
> > On Thu, Feb 26, 2004 at 02:44:20PM -0800, MetalliQaZ wrote:
> >
> >>Can anyone explain why the following occurs?
> >>
> >>$ sysctl -n hw.model
> >>Intel Pentium III (Katmai) (686-class)
> >>$ cpuflags
> >>-march=pentiumpro
> >>
> >>I looked in the cpuflags script, and even tho the output from sysctl matches
> >>two possibilites in the case statement, by my understanding the output from
> >>cpuflags should still be this:
> >>
> >>-march=pentium3
> >>
> >>I know theres not much difference, expecially on a headless machine, but it
> >>still bugs me.
> >>Thanks in advance for any insights
> >
> > -march=pentium3 doens't work for the gcc shipped with 1.6.x
> >
> -march=pentiumpro doesn't work either. At least many applications from
> pkgsrc fail to build with it.

	To clarify: -march=pentium3 was not supported in the gcc 2.95.3
	shipped with 1.6.x, while -march=pentiumpro was (codegen issues
	aside). I've used -march=pentiumpro on 1.6.x and did nto see any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Tooley | 1 Mar 2004 19:49
Picon

Merging sendmail queues..


I haven't found much in the way of merging sendmail queues around, and 
asking in the usual places didn't garner much, so I thought I'd ask 
here. I know I should be moving to postfix or something else, but one 
thing at a time! :)

I have a chroot environment that I'm using sendmail from within, and 
then subsequently merge the chroot mqueue with the outer. Currently 
what I'm doing is delivering solely within the chroot directly to the 
queue, and then at regular intervals taking a snapshot of those 
messages waiting delivery (for bytecount purposes) and actually running 
the queue. I am using a 1h MinQueueAge for that part.

What I'd like to do, though, to improve the accuracy of the bytecount 
run attempt *merge* the inner chroot mqueue with the outer so it can be 
dealt with normally by the primary sendmail daemon, after the first 
attempt done from within the chroot environment.

Is it possible to just "mv" the queue files into the system's primary 
mail queue after the first-run attempt and not worry too much about 
collision if I check the existence of the destination file beforehand? 
Or, does sendmail have a "better" way of doing this that I'm just not 
aware of?

Thanks for reading this far,
Marc
Permalink | Reply | 2 comments |
headers
Timothy A. Musson | 1 Mar 2004 22:02

Detecting bad blocks

We're having a stat() call fail, and due to less than thorough handling of
return codes we have 4 or 5 candidates as to what the failure is. We will
be re-formatting the slice with newfs, but I'm trying to get a handle on
how bad blocks are dealt with; partially to see if that might be part of
the problem and partially because I'd just like to know more about it, but
mostly so we can tell management whether or not we need to get a
replacement drive ready.

From the links I've found, it seems that you're not supposed to see any
indication of bad blocks until the hard drive is really having problems and
probably needs replaced (because the HD hardware would have been
automatically remapping bad blocks for awhile). I've also found that there
is the bad144 command which can read and write some bad sector info, but
it's unclear to me whether the information it inspects is the same info
used by the hardware or if bad144 is just for the drivers for the OS. In
any case, I'm at the same point as the poster of an email that was answered
by Manuel Bouyer:

from http://mail-index.netbsd.org/netbsd-users/2001/11/14/0007.html
>> On NetBSD (i386) I see the bad144 and badsect tools; however, neither of
>> these appears to do an actual _scan_ of a device for bad blocks.  It
>
>No, you need to know the address of the block you want to remap.

And I'm left with the question, "How do I know when there is a bad block
(that hasn't been handled by the hardware) and how do I find the address of
it?" If there is a bad block problem, will there be an explicit error
message dumped into /var/log/messages saying "bad block" and the block
number? Or, would the errors not be so obvious and require some digging
around to find out that the cause is a bad block?
(Continue reading)

Permalink | Reply | 501 comments |
headers
Radhika Sambamurti | 2 Mar 2004 17:50

Xserver is crashing - netbsd 1.6.1

Hi,
Until yesterday, my Xserver (or rather gnome) was slightly quirky when i started it using startx.
1) As soon as i started X, the gconfd process shot up to about 90%cpu, which I usually killed and then X started up.

But right now, my gconfd is showing the same behavior, but X gives me an error message. I am attaching the X log here.

The netbsd version I am running is 1.6.1

any insight as to what is happening will be great.

thanks,
Radhika
Attachment (XFree86.0.log): application/octet-stream, 26 KiB
Permalink | Reply | 0 comments |
headers
Radhika Sambamurti | 2 Mar 2004 18:05

Window manager warning: Failed to a open

Window manager warning: Failed to a open connection to a session manager, so window positions will not be
saved: SESSION_MANAGER environment variable not defined
/usr/pkg/lib/libXft.so.2: Undefined PLT symbol "XRenderQuerySubpixelOrder" (reloc type = 7, symnum = 170)

Hi,
In my previous message, I thought it was my Xserver giving me trouble.
But once in X, I tried starting metacity, the window manager gnome uses and I got the above error.
twm starts without a problem.

I guess Im a bit lost as to how to fix this, X and gnome not being things I know about well.
I did have a problem when starting X, the gconfd-2 process is always at 80% or > when X starts.
Usually I just killed it and then gnome started. But that does not seem to work now.

Thx
Radhika
Permalink | Reply | 0 comments |
headers
Chuck Yerkes | 2 Mar 2004 21:12

Re: Merging sendmail queues..

Quoting Marc Tooley (netbsdMLpost <at> quake.ca):
> I haven't found much in the way of merging sendmail queues around, and 
> asking in the usual places didn't garner much, so I thought I'd ask 
> here. I know I should be moving to postfix or something else, but one 
> thing at a time! :)

Oh pish!  postfix is for those not smart enough to figure out
sendmail and it's power ;)   (kidding! people).

> Is it possible to just "mv" the queue files into the system's primary 
qtool.pl is in the contrib area of sendmail.  This should be
used (or is the basis for tools for you).

> I have a chroot environment that I'm using sendmail from within, and 
> then subsequently merge the chroot mqueue with the outer. Currently 
> what I'm doing is delivering solely within the chroot directly to the 
> queue, and then at regular intervals taking a snapshot of those 
> messages waiting delivery (for bytecount purposes) and actually running 
> the queue. I am using a 1h MinQueueAge for that part.

For chroot, I use the SafeEnvironment option in the mc when
I need it.  Other neat options on machines that have NO local
delivery (no programs, no users) is to redirect port 25 to,
say, port 20025 and have sendmail running there not as root.

Sendmail is pretty quick about bind to port 25, become another user.
It's no longer setuid in 8.12.

In reality, on DMZ machines, I runas another user, in another group.
It must be able to create/write in the /var/spool/mqueue/ hierarchy
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marc Tooley | 2 Mar 2004 22:38
Picon

Re: Merging sendmail queues.. (plus one more question at the bottom)

On Tuesday 02 March 2004 12:12, Chuck Yerkes wrote:
> Quoting Marc Tooley (netbsdMLpost <at> quake.ca):
> > I haven't found much in the way of merging sendmail queues around,
> > and asking in the usual places didn't garner much, so I thought I'd
> > ask here. I know I should be moving to postfix or something else,
> > but one thing at a time! :)
>
> Oh pish!  postfix is for those not smart enough to figure out
> sendmail and it's power ;)   (kidding! people).

=]

> qtool.pl is in the contrib area of sendmail.  This should be
> used (or is the basis for tools for you).

Absolutely PERFECT. Thank you, that's precisely what I was looking for. 
Your note was much appreciated, and tremendously helpful and detailed. 
Thanks again!

> For chroot, I use the SafeEnvironment option in the mc when
> I need it.  Other neat options on machines that have NO local
> delivery (no programs, no users) is to redirect port 25 to,
> say, port 20025 and have sendmail running there not as root.

In my case all I'm doing (or trying to do, with varying degrees of 
success) is providing a way for chroot'd users to send mail to the 
primary mail mechanism outside the chroot and via a command-line 
program, and in a recordable, byte-countable way.

> In reality, on DMZ machines, I runas another user, in another group.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Herzog | 3 Mar 2004 01:57

downgrade -current --> 1.6.2

Hi.

Just today I used tar to install the 1.6.2 sets on my Sun U5 firewall.
I did not update etc and I left the 1.6ZG kernel in place. When I attempt 
to compile anything in pkgsrc, I see:

make: "/usr/pkgsrc/www/lhs/../../mk/compiler/gcc.mk" line 315: Malformed conditional (empty(BSD_PREFS_MK))
make: "/usr/pkgsrc/www/lhs/../../mk/compiler/gcc.mk" line 315: Missing dependency operator
make: "/usr/pkgsrc/www/lhs/../../mk/compiler/gcc.mk" line 321: Malformed conditional (empty(PREPEND_PATH:M${_GCC_DIR}/bin))
make: "/usr/pkgsrc/www/lhs/../../mk/compiler/gcc.mk" line 321: Missing dependency operator
make: "/usr/pkgsrc/www/lhs/../../mk/compiler/gcc.mk" line 360: if-less endif
make: "/usr/pkgsrc/www/lhs/../../mk/compiler/gcc.mk" line 360: Need an operator
make: "/usr/pkgsrc/www/lhs/../../mk/compiler.mk" line 115: if-less endif
make: "/usr/pkgsrc/www/lhs/../../mk/compiler.mk" line 115: Need an operator
make: Fatal errors encountered -- cannot continue

make: stopped in /usr/pkgsrc/www/lhs

What are my options?

Thanks.
--

-- 
Matthew Herzog

acamm.org is powered by NetBSD		 :www.netbsd.org:
Permalink | Reply | 0 comments |
headers
gabriel ware | 3 Mar 2004 18:19
Picon
Picon
Favicon

chsh bug ?

Readed on bugs <at> openbsd :
  Using chsh to change the login field does change the old line in passwd, 
  but creates a second line with the same user id and different login
  name. 
  This leads to warnings from the daily security scan and unexpected
  behaviour from various programs. 

This has been tested on this machine (NetBSD i386 1.6.1) and seems produce
the same error. 
I cannot anymore test that on -current or 1.6.2 .

After reading chpass's source files it seems that it's the correct
behavior since it uses pw_copy to update passwd fields.
man pw_copy says :
" If an entry is not found to match pw, a new entry is appended to the
  passwd file only if the real user ID is 0."

Should I open a pr ?
If so, the fix would probably be on this call to pw_copy (replacing it
    by a new function).

thanks for reading this, 

--

-- 
Gabriel WARE
tel  :  06 64 35 91 19
mail :  ware_g <at> epita.fr
http://www.epita.fr/~ware_g
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Rauch | 3 Mar 2004 22:46

Aqsis package.

Is anyone using ...pkgsrc/graphics/aqsis from a relatively recent pkgsrc?

On AMD64, it doesn't build without numerous patches.  (I gave up for a bit
when I hit a patch of linker errors.)  Because the AMD64 uses 64-bit pointers
and 32-bit ints, there are numerous bugs that crop up.  Because it is
running -current (perforce), I also get a rash of warnings about
deprecated C++ constructs.

On i386, I was able to make it build by adding some libraries to the
Makefiles for the framebuffer_glut{,_z} directories.  But when I run
on a simple file, aqsis says that it ran into an error accessing the
"[ framebuffer ]" device.  It is trying to load a file called "ddmsock.ini",
which looks like a BillOS type of file.  One is included with the sources.
Failing to find it, it defaults to "framebuffer"...

It'd almost be better---certainly no flaw---if it rendered to a file
rather than a window.  But right now, it doesn't seem to send the
output anywhere.  On a 450MHz PIII, it takes about 5 seconds to render
a simple scene with an unlit sphere, then throws away the output as
near as I can tell.  The only way that I can induce it to write a file
is a core-dump...

--

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/
Permalink | Reply | 0 comments |

Gmane