Re: CVS commit: src/etc/powerd/scripts
On Tue, Apr 10, 2012 at 01:58:52PM +, Jukka Ruohonen wrote: > Module Name: src > Committed By: jruoho > Date: Tue Apr 10 13:58:52 UTC 2012 > > Modified Files: > src/etc/powerd/scripts: sensor_temperature > > Log Message: > Gracefully shutdown upon reaching critical temperature levels. Prevents few > laptops (ThinkPad T61 and x61s, among others) from hitting the in-CPU reset. FYI, this is a temporary solution; I will rework powerd(8) as planned, but it won't make to 6.0. - Jukka.
Re: CVS commit: src/etc/skel
This "can't please everybody, so please nobody" reasoning is why NetBSD also ships with twm as default. EDITOR=vi has been in /etc/skel for >11yrs now, lots of discussion about it here: http://gnats.netbsd.org/10985 On Wed, 19 Oct 2011, Greg Troxel wrote: Jared McNeill writes: Please restore EDITOR=vi, otherwise the following message is going to haunt me for the rest of time: $ svn commit svn: Commit failed (details follow): svn: Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment variable or using the --message (-m) or --file (-F) options svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR are set, and no 'editor-cmd' run-time configuration option was found I thought the historical default was that EDITOR should be ex, and VISUAL vi. But again this is preference; others like emacs. So you're really asking that the default for all users be set the way you like it, instead of making your own choices and setting them. To me this is an argument for not having these values set in global default files.
Re: CVS commit: src/etc/skel
On Wed, Oct 19, 2011 at 08:53:48AM -0400, Greg Troxel wrote: > > Please restore EDITOR=vi, otherwise the following message is going to > > haunt me for the rest of time: > > > > $ svn commit > > svn: Commit failed (details follow): > > svn: Could not use external editor to fetch log message; consider > > setting the $SVN_EDITOR environment variable or using the --message > > (-m) or --file (-F) options > > svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR > > are set, and no 'editor-cmd' run-time configuration option was found > > I thought the historical default was that EDITOR should be ex, and > VISUAL vi. But again this is preference; others like emacs. So you're > really asking that the default for all users be set the way you like it, > instead of making your own choices and setting them. To me this is an > argument for not having these values set in global default files. Until we import emacs into base, the only sane thing to set EDITOR to by default is vi. Since there is apparently at least one program that fails gratuitously when EDITOR isn't set at all, and other programs will run ed by default, setting EDITOR to vi by default is not wrong. Remember, this is in /etc/skel, not /etc/csh.cshrc. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/etc/skel
Jared McNeill writes: > Please restore EDITOR=vi, otherwise the following message is going to > haunt me for the rest of time: > > $ svn commit > svn: Commit failed (details follow): > svn: Could not use external editor to fetch log message; consider > setting the $SVN_EDITOR environment variable or using the --message > (-m) or --file (-F) options > svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR > are set, and no 'editor-cmd' run-time configuration option was found I thought the historical default was that EDITOR should be ex, and VISUAL vi. But again this is preference; others like emacs. So you're really asking that the default for all users be set the way you like it, instead of making your own choices and setting them. To me this is an argument for not having these values set in global default files. pgpvv4xnkvShB.pgp Description: PGP signature
Re: CVS commit: src/etc/skel
> Please restore EDITOR=vi, otherwise the following message is going to > haunt me for the rest of time: Heh, I'm surpised that I see so much useradd(8) users who have not complained about su -m and EXINIT ;-p --- Izumi Tsutsui
Re: CVS commit: src/etc/skel
Please restore EDITOR=vi, otherwise the following message is going to haunt me for the rest of time: $ svn commit svn: Commit failed (details follow): svn: Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment variable or using the --message (-m) or --file (-F) options svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR are set, and no 'editor-cmd' run-time configuration option was found On Wed, 19 Oct 2011, Izumi Tsutsui wrote: Module Name:src Committed By: tsutsui Date: Wed Oct 19 10:14:35 UTC 2011 Modified Files: src/etc/skel: dot.cshrc dot.profile Log Message: Cleanup ancient entries derived from 4.4BSD Lite2 merge for newer useradd(8) users: - remove all aliases - remove annoying EXINIT setting - comment out other environment settings Discussed on tech-userlevel@. To generate a diff of this commit: cvs rdiff -u -r1.4 -r1.5 src/etc/skel/dot.cshrc cvs rdiff -u -r1.5 -r1.6 src/etc/skel/dot.profile Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/etc/mtree
In article <2011091027.gb...@apb-laptoy.apb.alt.za>, Alan Barrett wrote: >On Tue, 06 Sep 2011, Alan Barrett wrote: >>On Tue, 06 Sep 2011, Christos Zoulas wrote: >>>We definitely don't want to add such magic. Please revert. Otherwise >>>we should go and do this in 100's of Makefiles. >> >>I have an idea for letting "make cleandir" deal with this problem, >>and may be willing to revert if that works out. > >I have committed the changes to "make cleandir", and reverted the >change to etc/mtee/Makefile. Thanks! christos
Re: CVS commit: src/etc/mtree
On Tue, 06 Sep 2011, Alan Barrett wrote: On Tue, 06 Sep 2011, Christos Zoulas wrote: We definitely don't want to add such magic. Please revert. Otherwise we should go and do this in 100's of Makefiles. I have an idea for letting "make cleandir" deal with this problem, and may be willing to revert if that works out. I have committed the changes to "make cleandir", and reverted the change to etc/mtee/Makefile. --apb (Alan Barrett)
Re: CVS commit: src/etc/mtree
On Wed, Sep 07, 2011 at 08:13:20AM +, David Holland wrote: > > The fundamental problem is that the make library finds files by > implicit path searches (of various kinds) which is inherently wobbly > no matter how many bandaids are applied. Especially in large items like libc andthe kernel... > The robust approach is to change the makefiles to do > > .for S in $(SRCS:M*.c) > $(OBJDIR)/$(S:T:R).o: $(S) > $(COMPILE.c) $(S) -o $(.TARGET) > .endfor I tried to do that (without the actual commands) just to force the .o file to depend on the relevant .c .S (or .cpp) file. It would save make doing a lot of stat() calls searching for the source - and always get the right one when, for example, libc has a .S file that you don't want. Unfortunately it all exploded due to the way lex and yacc generate stuff. In my case I was still using the commands from the suffix rule. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/etc/mtree
On Tue, Sep 06, 2011 at 02:53:58PM +0400, Valeriy E. Ushakov wrote: > Are you saying you are going to add a special case for each foo.o file > each time an accidental non-objdir build left foo.o in src? (and no, > that's not a rhetoric question). The fundamental problem is that the make library finds files by implicit path searches (of various kinds) which is inherently wobbly no matter how many bandaids are applied. The robust approach is to change the makefiles to do .for S in $(SRCS:M*.c) $(OBJDIR)/$(S:T:R).o: $(S) $(COMPILE.c) $(S) -o $(.TARGET) .endfor and forget about make's builtin objdir hackery entirely. Unfortunately there are many reasons why this is not a trivial undertaking... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/etc/mtree
On Tue, 6 Sep 2011, Valeriy E. Ushakov wrote:
> On Tue, Sep 06, 2011 at 08:43:10 +0100, Iain Hibbert wrote:
>
> > On Mon, 5 Sep 2011, Valeriy E. Ushakov wrote:
> >
> > > On Mon, Sep 05, 2011 at 15:13:49 +0100, Iain Hibbert wrote:
> > >
> > > > On Mon, 5 Sep 2011, Joerg Sonnenberger wrote:
> > > >
> > > > > On Mon, Sep 05, 2011 at 09:57:02AM +, Alan Barrett wrote:
> > > > > > Module Name:src
> > > > > > Committed By: apb
> > > > > > Date: Mon Sep 5 09:57:02 UTC 2011
> > > > > >
> > > > > > Modified Files:
> > > > > > src/etc/mtree: Makefile
> > > > > >
> > > > > > Log Message:
> > > > > > Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
> > > > > > This fixes a problem in which NetBSD.dist.tmp had been created in
> > > > > > the SRCDIR by an earlier build (performed without an OBJDIR), and
> > > > > > the existence of the file in the SRCDIR confused a subsequent build
> > > > > > (performed with an OBJDIR).
> > > > >
> > > > > Do we really want to add special cases like this? There are all kinds
> > > > > of
> > > > > mysterious errors triggered by unclean SRCDIR, I don't think it is
> > > > > worth
> > > > > adding this specific hack.
> > > >
> > > > IMO these cases are worth handling just because if an OBJDIR is
> > > > specified,
> > > > it should be used. The alternative being that the OBJDIR is used
> > > > "sometimes"? Thats just wrong..
> > >
> > > So whay do you treat NetBSD.dist.tmp and NetBSD.dist differently then?
> >
> > Well, I don't know but ${.OBJDIR}/NetBSD.dist is already referenced in
> > that file?
> >
> > > If you go down that path, where do you stop?
> >
> > You can sleep when you have a system that works as expected, not one that
> > fails with mysterious errors because even though you told it to use an
> > OBJDIR for work files, it was confused by some it found elsewhere. As
> > noted, most of this is handled invisibly by the make framework, but some
> > of it needs to be manually handled. I guess people fix things as they
> > notice them..
>
> Are you saying you are going to add a special case for each foo.o file
> each time an accidental non-objdir build left foo.o in src? (and no,
> that's not a rhetoric question).
clearly not, since the foo.o files are already handled by a general case
iain
Re: CVS commit: src/etc
On 06.09.2011 21:29, Thomas Klausner wrote:
>> If the source ('-s' of postinstall(8)) is not specified at command line,
>> according to code it takes "/usr/src" as default. Do you have a
>> stale/old rc.conf(5) file in there, /usr/src/etc/defaults/rc.conf?
>
> I have the CVS checkout there that was used to build the snapshot I
> installed, so yes there is a file there but no it is not stale.
>
>> Now, if this case should be handled properly is another question. There
>> are multiple solutions, all of them end up tweaking postinstall(8):
>> - raise a warning when overriding certain configuration files with older
>> versions (perhaps by using the CVS tags?)
>
> It's not an older version.
>
>> - make source an explicit arg to etcupdate/postinstall
>> - something else?
>
> Or perhaps prefer ./etc to /usr/src/etc, that would solve the issue
> for me at least :)
postinstall(8) and etcupdate(8) all take /usr/src/ as default, so I
won't change that.
The problem is that rc.conf is now generated at build time, and I am
always using postinstall(8) via -s /usr/cvs/dest (my default DESTDIR),
so this went unnoticed during my tests as the correct /etc/defaults gets
parsed.
I'll add the required code to handle this; thanks for reporting!
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
Re: CVS commit: src/etc
On Tue, Sep 06, 2011 at 01:48:41PM +0200, Jean-Yves Migeon wrote:
> Hmmm, /etc/defaults/rc.conf should be transparent to postinstall(8), as
> it gets installed via during build.sh.
>
> If the source ('-s' of postinstall(8)) is not specified at command line,
> according to code it takes "/usr/src" as default. Do you have a
> stale/old rc.conf(5) file in there, /usr/src/etc/defaults/rc.conf?
I have the CVS checkout there that was used to build the snapshot I
installed, so yes there is a file there but no it is not stale.
> Now, if this case should be handled properly is another question. There
> are multiple solutions, all of them end up tweaking postinstall(8):
> - raise a warning when overriding certain configuration files with older
> versions (perhaps by using the CVS tags?)
It's not an older version.
> - make source an explicit arg to etcupdate/postinstall
> - something else?
Or perhaps prefer ./etc to /usr/src/etc, that would solve the issue
for me at least :)
Thomas
Re: CVS commit: src/etc/mtree
In article <20110906150225.gc16...@apb-laptoy.apb.alt.za>,
Alan Barrett wrote:
>On Tue, 06 Sep 2011, Christos Zoulas wrote:
Modified Files:
src/etc/mtree: Makefile
Log Message:
Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
This fixes a problem in which NetBSD.dist.tmp had been created in
the SRCDIR by an earlier build (performed without an OBJDIR), and
the existence of the file in the SRCDIR confused a subsequent build
(performed with an OBJDIR).
>>
>> We definitely don't want to add such magic. Please
>> revert. Otherwise we should go and do this in 100's of
>> Makefiles.
>
>I certainly see no reason to make similar changes in hundreds of
>Makefiles; only in the few places where people actually encounter
>(and report) problems traceable to this sort of issue. There have
>been only a few such issues, and we have fixed all the others
>(elsewhere under src/etc).
Out of 5565 Makefiles in the source tree only 77 mention .OBJDIR and
from a cursory glance most of the uses are bogus/can be avoided.
christos
Re: CVS commit: src/etc/mtree
On Tue, 06 Sep 2011, Christos Zoulas wrote:
Modified Files:
src/etc/mtree: Makefile
Log Message:
Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
This fixes a problem in which NetBSD.dist.tmp had been created in
the SRCDIR by an earlier build (performed without an OBJDIR), and
the existence of the file in the SRCDIR confused a subsequent build
(performed with an OBJDIR).
We definitely don't want to add such magic. Please
revert. Otherwise we should go and do this in 100's of
Makefiles.
I certainly see no reason to make similar changes in hundreds of
Makefiles; only in the few places where people actually encounter
(and report) problems traceable to this sort of issue. There have
been only a few such issues, and we have fixed all the others
(elsewhere under src/etc).
I have an idea for letting "make cleandir" deal with this problem,
and may be willing to revert if that works out.
--apb (Alan Barrett)
Re: CVS commit: src/etc
On 06.09.2011 12:54, Thomas Klausner wrote:
> On Mon, Aug 22, 2011 at 06:54:07PM +, Jean-Yves Migeon wrote:
>> Module Name: src
>> Committed By:jym
>> Date:Mon Aug 22 18:54:06 UTC 2011
>>
>> [snip]
>>
>> Log Message:
>> Modify etc/defaults/Makefile so that architectures can specify an additional
>> rc.conf file. This one should reside under etc/etc.${MACHINE}/, and will
>> get automatically appended to etc/defaults/rc.conf at build time if present.
>>
>>[snip]
>>
>> See also
>> http://mail-index.netbsd.org/tech-userlevel/2011/07/25/msg005246.html
>
> In a snapshot from a few hours ago I installed, "postinstall fix"
> without any other arguments removed the architecture specific section
> (the rc.conf included in the build output directory is fine).
> Thomas
Hmmm, /etc/defaults/rc.conf should be transparent to postinstall(8), as
it gets installed via during build.sh.
If the source ('-s' of postinstall(8)) is not specified at command line,
according to code it takes "/usr/src" as default. Do you have a
stale/old rc.conf(5) file in there, /usr/src/etc/defaults/rc.conf?
Now, if this case should be handled properly is another question. There
are multiple solutions, all of them end up tweaking postinstall(8):
- raise a warning when overriding certain configuration files with older
versions (perhaps by using the CVS tags?)
- make source an explicit arg to etcupdate/postinstall
- something else?
--
Jean-Yves Migeon
j...@netbsd.org
Re: CVS commit: src/etc/mtree
In article <20110905111014.gb12...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Mon, Sep 05, 2011 at 09:57:02AM +, Alan Barrett wrote:
>> Module Name: src
>> Committed By:apb
>> Date:Mon Sep 5 09:57:02 UTC 2011
>>
>> Modified Files:
>> src/etc/mtree: Makefile
>>
>> Log Message:
>> Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
>> This fixes a problem in which NetBSD.dist.tmp had been created in
>> the SRCDIR by an earlier build (performed without an OBJDIR), and
>> the existence of the file in the SRCDIR confused a subsequent build
>> (performed with an OBJDIR).
>
>Do we really want to add special cases like this? There are all kinds of
>mysterious errors triggered by unclean SRCDIR, I don't think it is worth
>adding this specific hack.
We definitely don't want to add such magic. Please revert. Otherwise we should
go and do this in 100's of Makefiles.
christos
Re: CVS commit: src/etc
On Mon, Aug 22, 2011 at 06:54:07PM +, Jean-Yves Migeon wrote:
> Module Name: src
> Committed By: jym
> Date: Mon Aug 22 18:54:06 UTC 2011
>
> Modified Files:
> src/etc: Makefile
> src/etc/defaults: Makefile rc.conf
> Added Files:
> src/etc/etc.amd64: rc.conf
> src/etc/etc.i386: rc.conf
>
> Log Message:
> Modify etc/defaults/Makefile so that architectures can specify an additional
> rc.conf file. This one should reside under etc/etc.${MACHINE}/, and will
> get automatically appended to etc/defaults/rc.conf at build time if present.
>
> This is used by i386 and amd64 to append a small MD rc.conf(5) configuration
> at the end of the defaults/rc.conf file, so that powerd(8) can be started
> by default when we are running in a Xen environment. This is needed to support
> save/restore functions for domains.
>
> From all the alternatives proposed to fix that issue (from /etc/rc.conf
> parsing in postinstall to etc/defaults/rc.conf arch-hooks) I believe
> this one will appease everyone because it:
> - does not touch etc/defaults/rc.conf template file,
> - patches it at build time for MD hooks only when required,
> - does not need to parse/modify a user-specified file like /etc/rc.conf (which
> is a complex, error-prone operation),
> - only enables powerd(8) by default when conditions are met (Xen environment)
> while still allowing root to shoot himself in the foot if he wants to
> override this manually in /etc/rc.conf.
>
> See also http://mail-index.netbsd.org/tech-userlevel/2011/07/25/msg005246.html
In a snapshot from a few hours ago I installed, "postinstall fix"
without any other arguments removed the architecture specific section
(the rc.conf included in the build output directory is fine).
Thomas
Re: CVS commit: src/etc/mtree
On Tue, Sep 06, 2011 at 08:43:10 +0100, Iain Hibbert wrote:
> On Mon, 5 Sep 2011, Valeriy E. Ushakov wrote:
>
> > On Mon, Sep 05, 2011 at 15:13:49 +0100, Iain Hibbert wrote:
> >
> > > On Mon, 5 Sep 2011, Joerg Sonnenberger wrote:
> > >
> > > > On Mon, Sep 05, 2011 at 09:57:02AM +, Alan Barrett wrote:
> > > > > Module Name: src
> > > > > Committed By: apb
> > > > > Date: Mon Sep 5 09:57:02 UTC 2011
> > > > >
> > > > > Modified Files:
> > > > > src/etc/mtree: Makefile
> > > > >
> > > > > Log Message:
> > > > > Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
> > > > > This fixes a problem in which NetBSD.dist.tmp had been created in
> > > > > the SRCDIR by an earlier build (performed without an OBJDIR), and
> > > > > the existence of the file in the SRCDIR confused a subsequent build
> > > > > (performed with an OBJDIR).
> > > >
> > > > Do we really want to add special cases like this? There are all kinds of
> > > > mysterious errors triggered by unclean SRCDIR, I don't think it is worth
> > > > adding this specific hack.
> > >
> > > IMO these cases are worth handling just because if an OBJDIR is specified,
> > > it should be used. The alternative being that the OBJDIR is used
> > > "sometimes"? Thats just wrong..
> >
> > So whay do you treat NetBSD.dist.tmp and NetBSD.dist differently then?
>
> Well, I don't know but ${.OBJDIR}/NetBSD.dist is already referenced in
> that file?
>
> > If you go down that path, where do you stop?
>
> You can sleep when you have a system that works as expected, not one that
> fails with mysterious errors because even though you told it to use an
> OBJDIR for work files, it was confused by some it found elsewhere. As
> noted, most of this is handled invisibly by the make framework, but some
> of it needs to be manually handled. I guess people fix things as they
> notice them..
Are you saying you are going to add a special case for each foo.o file
each time an accidental non-objdir build left foo.o in src? (and no,
that's not a rhetoric question).
-uwe
Re: CVS commit: src/etc/mtree
On Mon, 5 Sep 2011, Valeriy E. Ushakov wrote:
> On Mon, Sep 05, 2011 at 15:13:49 +0100, Iain Hibbert wrote:
>
> > On Mon, 5 Sep 2011, Joerg Sonnenberger wrote:
> >
> > > On Mon, Sep 05, 2011 at 09:57:02AM +, Alan Barrett wrote:
> > > > Module Name:src
> > > > Committed By: apb
> > > > Date: Mon Sep 5 09:57:02 UTC 2011
> > > >
> > > > Modified Files:
> > > > src/etc/mtree: Makefile
> > > >
> > > > Log Message:
> > > > Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
> > > > This fixes a problem in which NetBSD.dist.tmp had been created in
> > > > the SRCDIR by an earlier build (performed without an OBJDIR), and
> > > > the existence of the file in the SRCDIR confused a subsequent build
> > > > (performed with an OBJDIR).
> > >
> > > Do we really want to add special cases like this? There are all kinds of
> > > mysterious errors triggered by unclean SRCDIR, I don't think it is worth
> > > adding this specific hack.
> >
> > IMO these cases are worth handling just because if an OBJDIR is specified,
> > it should be used. The alternative being that the OBJDIR is used
> > "sometimes"? Thats just wrong..
>
> So whay do you treat NetBSD.dist.tmp and NetBSD.dist differently then?
Well, I don't know but ${.OBJDIR}/NetBSD.dist is already referenced in
that file?
> If you go down that path, where do you stop?
You can sleep when you have a system that works as expected, not one that
fails with mysterious errors because even though you told it to use an
OBJDIR for work files, it was confused by some it found elsewhere. As
noted, most of this is handled invisibly by the make framework, but some
of it needs to be manually handled. I guess people fix things as they
notice them..
iain
Re: CVS commit: src/etc/mtree
On Mon, Sep 05, 2011 at 03:13:49PM +0100, Iain Hibbert wrote: > > IMO these cases are worth handling just because if an OBJDIR is specified, > it should be used. The alternative being that the OBJDIR is used > "sometimes"? Thats just wrong.. A lot of the OBJDIR support happens by magic in make. Mostly make will look for files in SRCDIR before OBJDIR. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/etc/mtree
On Mon, Sep 05, 2011 at 15:13:49 +0100, Iain Hibbert wrote:
> On Mon, 5 Sep 2011, Joerg Sonnenberger wrote:
>
> > On Mon, Sep 05, 2011 at 09:57:02AM +, Alan Barrett wrote:
> > > Module Name: src
> > > Committed By: apb
> > > Date: Mon Sep 5 09:57:02 UTC 2011
> > >
> > > Modified Files:
> > > src/etc/mtree: Makefile
> > >
> > > Log Message:
> > > Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
> > > This fixes a problem in which NetBSD.dist.tmp had been created in
> > > the SRCDIR by an earlier build (performed without an OBJDIR), and
> > > the existence of the file in the SRCDIR confused a subsequent build
> > > (performed with an OBJDIR).
> >
> > Do we really want to add special cases like this? There are all kinds of
> > mysterious errors triggered by unclean SRCDIR, I don't think it is worth
> > adding this specific hack.
>
> IMO these cases are worth handling just because if an OBJDIR is specified,
> it should be used. The alternative being that the OBJDIR is used
> "sometimes"? Thats just wrong..
So whay do you treat NetBSD.dist.tmp and NetBSD.dist differently then?
If you go down that path, where do you stop?
-uwe
Re: CVS commit: src/etc/mtree
On Mon, 5 Sep 2011, Joerg Sonnenberger wrote:
> On Mon, Sep 05, 2011 at 09:57:02AM +, Alan Barrett wrote:
> > Module Name:src
> > Committed By: apb
> > Date: Mon Sep 5 09:57:02 UTC 2011
> >
> > Modified Files:
> > src/etc/mtree: Makefile
> >
> > Log Message:
> > Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
> > This fixes a problem in which NetBSD.dist.tmp had been created in
> > the SRCDIR by an earlier build (performed without an OBJDIR), and
> > the existence of the file in the SRCDIR confused a subsequent build
> > (performed with an OBJDIR).
>
> Do we really want to add special cases like this? There are all kinds of
> mysterious errors triggered by unclean SRCDIR, I don't think it is worth
> adding this specific hack.
IMO these cases are worth handling just because if an OBJDIR is specified,
it should be used. The alternative being that the OBJDIR is used
"sometimes"? Thats just wrong..
iain
Re: CVS commit: src/etc/mtree
On Mon, 05 Sep 2011, Joerg Sonnenberger wrote:
On Mon, Sep 05, 2011 at 09:57:02AM +, Alan Barrett wrote:
Modified Files:
src/etc/mtree: Makefile
Log Message:
Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
Do we really want to add special cases like this? There are all
kinds of mysterious errors triggered by unclean SRCDIR, I don't
think it is worth adding this specific hack.
I am not sure. We have done this sort of thing before, for other
files under src/etc, and I think it's reasonable to treat src/etc
differently from the rest of the source tree because etcupdate and
postinstall may run "make" in src/etc without the user being aware
that their source directory is being polluted.
On the other hand, if we can get postinstall and etcupdate to run
"make clean" afterwards, then I'd be happier for this and similar
special cases to be removed.
--apb (Alan Barrett)
Re: CVS commit: src/etc/mtree
On Mon, Sep 05, 2011 at 09:57:02AM +, Alan Barrett wrote:
> Module Name: src
> Committed By: apb
> Date: Mon Sep 5 09:57:02 UTC 2011
>
> Modified Files:
> src/etc/mtree: Makefile
>
> Log Message:
> Use ${.OBJDIR}/NetBSD.dist.tmp instead of just NetBSD.dist.tmp.
> This fixes a problem in which NetBSD.dist.tmp had been created in
> the SRCDIR by an earlier build (performed without an OBJDIR), and
> the existence of the file in the SRCDIR confused a subsequent build
> (performed with an OBJDIR).
Do we really want to add special cases like this? There are all kinds of
mysterious errors triggered by unclean SRCDIR, I don't think it is worth
adding this specific hack.
Joerg
re: CVS commit: src/etc
> Module Name: src
> Committed By: jym
> Date: Mon Aug 22 18:54:06 UTC 2011
>
> Modified Files:
> src/etc: Makefile
> src/etc/defaults: Makefile rc.conf
> Added Files:
> src/etc/etc.amd64: rc.conf
> src/etc/etc.i386: rc.conf
>
> Log Message:
> Modify etc/defaults/Makefile so that architectures can specify an additional
> rc.conf file. This one should reside under etc/etc.${MACHINE}/, and will
> get automatically appended to etc/defaults/rc.conf at build time if present.
>
> This is used by i386 and amd64 to append a small MD rc.conf(5) configuration
> at the end of the defaults/rc.conf file, so that powerd(8) can be started
> by default when we are running in a Xen environment. This is needed to support
> save/restore functions for domains.
>
> From all the alternatives proposed to fix that issue (from /etc/rc.conf
> parsing in postinstall to etc/defaults/rc.conf arch-hooks) I believe
> this one will appease everyone because it:
> - does not touch etc/defaults/rc.conf template file,
> - patches it at build time for MD hooks only when required,
> - does not need to parse/modify a user-specified file like /etc/rc.conf (which
> is a complex, error-prone operation),
> - only enables powerd(8) by default when conditions are met (Xen environment)
> while still allowing root to shoot himself in the foot if he wants to
> override this manually in /etc/rc.conf.
>
> See also http://mail-index.netbsd.org/tech-userlevel/2011/07/25/msg005246.html
this looks good. i've wondered about this myself. however, i do have
one minor request.
could you please make the additional files be eg, "rc.conf.post" or
something else, that indicates it isn't a replacement of the normal
rc.conf, but something added on the end?
thanks,
.mrg.
Re: CVS commit: src/etc
Am 29.07.11 10:03, schrieb Aleksej Saushev: > "Simon Burge" writes: > >> Module Name: src >> Committed By:simonb >> Date:Thu Jul 28 22:28:07 UTC 2011 >> >> Modified Files: >> src/etc: ntp.conf >> >> Log Message: >> Restore "duplicate" entries, but use 0. and 1. names to ensure that >> same hosts aren't used by both entries. > >> # Northern Europe >> -#server de.pool.ntp.org >> +#server 0.de.pool.ntp.org >> +#server 1.de.pool.ntp.org >> #server dk.pool.ntp.org > > This removes more useful information on how to setup NTP. > I believe that I don't need to remember how many groups there're in > ru.pool.ntp.org when DNS does that for me. > (I think that previous version is correct, at least ru.pool.ntp.org > seems to cycle through all servers in subpools.) there should be a keyword 'servers' to make it clear that we expect more than one IP address, i.e. server xyz -> one IP servers xzy -> several IPs
Re: CVS commit: src/etc
"Simon Burge" writes: > Module Name: src > Committed By: simonb > Date: Thu Jul 28 22:28:07 UTC 2011 > > Modified Files: > src/etc: ntp.conf > > Log Message: > Restore "duplicate" entries, but use 0. and 1. names to ensure that > same hosts aren't used by both entries. > # Northern Europe > -#server de.pool.ntp.org > +#server 0.de.pool.ntp.org > +#server 1.de.pool.ntp.org > #server dk.pool.ntp.org This removes more useful information on how to setup NTP. I believe that I don't need to remember how many groups there're in ru.pool.ntp.org when DNS does that for me. (I think that previous version is correct, at least ru.pool.ntp.org seems to cycle through all servers in subpools.) -- HE CE3OH...
Re: CVS commit: src/etc
Alan Barrett wrote: > On Thu, 28 Jul 2011, Marc Balmer wrote: > >Modified Files: > > src/etc: ntp.conf > > > >Log Message: > >Remove duplicate (but commented out) entries. > > I think the duplicates were deliberate. The idea is that names > like foo.pool.ntp.org are associated with many IP addresses, > and if you use the name twice then you get two of the many IP > addresses. That's correct. The original intent of this: # Northern U.S.A #serverca.pool.ntp.org #serverus.pool.ntp.org -#serverus.pool.ntp.org # Northern Europe #serverde.pool.ntp.org -#serverde.pool.ntp.org #serverdk.pool.ntp.org was two servers in the US and two servers in Germany. That said, the current wisdom says that we should use N..pool.ntp.org which we do indeed do at the bottom of our current file. I'll adjust our NTP conf to match that. Cheers, Simon.
Re: CVS commit: src/etc
On Thu, 28 Jul 2011, Marc Balmer wrote: Modified Files: src/etc: ntp.conf Log Message: Remove duplicate (but commented out) entries. I think the duplicates were deliberate. The idea is that names like foo.pool.ntp.org are associated with many IP addresses, and if you use the name twice then you get two of the many IP addresses. --apb (Alan Barrett)
Re: CVS commit: src/etc/mtree
On Mon, Jan 10, 2011 at 05:17:37PM +, Nicolas Joly wrote: > Module Name: src > Committed By: njoly > Date: Mon Jan 10 17:17:36 UTC 2011 > > Modified Files: > src/etc/mtree: NetBSD.dist.tests > > Log Message: > Add lib/libc/sys test dirs. Thanks! Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: CVS commit: src/etc/rc.d
On Sun, Jan 09, 2011 at 02:47:27AM +, David Holland wrote: > On Sat, Jan 08, 2011 at 11:49:54PM +, Matthias Scheler wrote: > > > This is no longer true, for lvm and other things, so let's take a deep > > > breath and move chown. > > > > Yes, but we should probably provide a symlink from > > "/usr/sbin/chown" to "/sbin/chown" for backwards compatibility > > reasons. > > Maybe for a while, but I hope not permanently... It's been in "/usr/sbin" for almost 18 years. And the symlink doesn't really hurt. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/etc/rc.d
On Sat, 8 Jan 2011, David Holland wrote: > XXX. Why is chown in /usr/sbin ? it should be moved to /sbin Because historically nothing needed to be chowned during boot because it was all root. This is no longer true, for lvm and other things, so let's take a deep breath and move chown. I don't like the idea of having rc.d scripts depend on /rescue. Seconded (on the "don't depend on /rescue" part). FWIW: fehu.org% cat /etc/debian_version squeeze/sid fehu.org% which chown /bin/chown - Hubert
Re: CVS commit: src/etc/rc.d
On Sat, Jan 08, 2011 at 11:49:54PM +, Matthias Scheler wrote: > > This is no longer true, for lvm and other things, so let's take a deep > > breath and move chown. > > Yes, but we should probably provide a symlink from > "/usr/sbin/chown" to "/sbin/chown" for backwards compatibility > reasons. Maybe for a while, but I hope not permanently... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/etc/rc.d
On 8 Jan 2011, at 23:21, David Holland wrote: > This is no longer true, for lvm and other things, so let's take a deep > breath and move chown. Yes, but we should probably provide a symlink from "/usr/sbin/chown" to "/sbin/chown" for backwards compatibility reasons. > I don't like the idea of having rc.d scripts depend on /rescue. Me neither. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/etc/rc.d
On Sat, Jan 08, 2011 at 04:16:52PM +, Adam Hamsik wrote: > Modified Files: > src/etc/rc.d: mountcritlocal > > Log Message: > Use /rescue/chown not chown from /usr/sbin which might not be available in > time of running this script. > > XXX. Why is chown in /usr/sbin ? it should be moved to /sbin Because historically nothing needed to be chowned during boot because it was all root. This is no longer true, for lvm and other things, so let's take a deep breath and move chown. I don't like the idea of having rc.d scripts depend on /rescue. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 12:51:24PM -0600, David Young wrote:
> IMO, we should put the system to sleep by sending a
> power-saving/wakeup-latency goal and a set of waking events (e.g.,
> keystroke, mouse movement, LAN activity) to the root device_t using
> drvctl. To put any smaller set of devices to sleep, send the goal &
> wake events to some subtree.
>
> FWIW, the sleep states that ACPI names are not sufficient even to
> describe all of the potential sleep states of ACPI hardware. I have a
> laptop that's perfectly capable of an "S3-like" sleep, but the ACPI BIOS
> doesn't support S3, and the HDD is not formatted properly for the S4
> sleep.
I would still make the distinction between "system sleep" and "device sleep".
It seems to me that you describe above the latter. In the former you still
need to call the machine-dependent suspend-sequences at some point.
There is nothing quite like ACPI when it comes to jargon. The actual device
power states are represented as "D-states", which range from D0 ("fully on")
to D3 ("fully off"). If I recall correctly, the same abstraction is used in
the USB or PCI specifications. As I've noted before, we lack a representation
for this in device_t.
- Jukka.
Re: CVS commit: src/etc/mtree
On Jan,Saturday 1 2011, at 11:11 PM, Adam Hamsik wrote: > Module Name: src > Committed By: haad > Date: Sat Jan 1 22:11:45 UTC 2011 > > Modified Files: > src/etc/mtree: NetBSD.dist.base > > Log Message: > Remove optional keyword from directory definition. > > This fixes PR misc/44308 Regards Adam.
Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 08:11:52PM +0100, Jean-Yves Migeon wrote: > On 31.12.2010 19:51, David Young wrote: > > IMO, we should put the system to sleep by sending a > > power-saving/wakeup-latency goal and a set of waking events (e.g., > > keystroke, mouse movement, LAN activity) to the root device_t using > > drvctl. To put any smaller set of devices to sleep, send the goal & > > wake events to some subtree. > > I haven't looked at the details of the ioctl(), but I would expect it to > be used against /dev/drvctl, no? Correct. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: CVS commit: src/etc/powerd/scripts
On 31.12.2010 19:51, David Young wrote: > IMO, we should put the system to sleep by sending a > power-saving/wakeup-latency goal and a set of waking events (e.g., > keystroke, mouse movement, LAN activity) to the root device_t using > drvctl. To put any smaller set of devices to sleep, send the goal & > wake events to some subtree. I haven't looked at the details of the ioctl(), but I would expect it to be used against /dev/drvctl, no? This seems plausible to me; at least, suspend/sleep should be part of pmf(9) (even in my Xen's case, all driver sleep/wake coded uses pmf(9)). > FWIW, the sleep states that ACPI names are not sufficient even to > describe all of the potential sleep states of ACPI hardware. I have a > laptop that's perfectly capable of an "S3-like" sleep, but the ACPI BIOS > doesn't support S3, and the HDD is not formatted properly for the S4 > sleep. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 11:01:08AM +0100, Jean-Yves Migeon wrote: > On 31.12.2010 10:36, Jukka Ruohonen wrote: > > Module Name:src > > Committed By: jruoho > > Date: Fri Dec 31 09:36:15 UTC 2010 > > > > Modified Files: > > src/etc/powerd/scripts: sleep_button > > > > Log Message: > > Use hw.acpi.sleep.state instead of machdep.sleep_state. > > And so it begins :) > > I am using machdep.sleep_state as node to put a domU into suspend mode. > Up to now, putting sleep_state under machdep allowed powerd(8) > sleep_button to be used regardless of the environment (eg. ACPI sleep or > Xen domU sleep). > > While retiring sleep_state from machdep goes in the right direction > IMHO, will it be replaced by a MI interface to put a system into sleep, > as it is not a feature specific to ACPI? IMO, we should put the system to sleep by sending a power-saving/wakeup-latency goal and a set of waking events (e.g., keystroke, mouse movement, LAN activity) to the root device_t using drvctl. To put any smaller set of devices to sleep, send the goal & wake events to some subtree. FWIW, the sleep states that ACPI names are not sufficient even to describe all of the potential sleep states of ACPI hardware. I have a laptop that's perfectly capable of an "S3-like" sleep, but the ACPI BIOS doesn't support S3, and the HDD is not formatted properly for the S4 sleep. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 04:54:47AM -0800, Paul Goyette wrote:
> However, the current implementation is simply a text string with no
> defined semantics. A back-end is able to set the value, and it can be
> retrieved via the POWER_IOC_GET_TYPE ioctl, but otherwise nothing uses
> the value.
Sure, I mean the idea, not the actual existing code. Something simple as
sysmon_pswitch(9). Say
struct sysmon_sleep {
const char *smpsl_name;
void *smpsl_arg;
void(*smpsl_func)(void *, int);
};
int sysmon_sleep_register(struct sysmon_sleep *);
int sysmon_sleep_unregister(struct sysmon_sleep *);
And the smpsl::smpsl_func(arg, state) would be called from an ioctl, invoked
by the zzz(8) program.
- Jukka.
Re: CVS commit: src/etc/powerd/scripts
On Fri, 31 Dec 2010, Jukka Ruohonen wrote: On Fri, Dec 31, 2010 at 11:29:23AM +0100, Jean-Yves Migeon wrote: Seems reasonable to me. We could have a more featureful binary later, and just alias zzz(8) to it. We have ready ioctl-facilities in sysmon's "sysmon_power.c". I believe it was originally intended by the author that MD code should use the sysmon_power_settype() function to register a "power-backend" (ACPI, APM, Xen, PowerBook, and so on). Extending this idea seems like a plausible route. Yes. However, the current implementation is simply a text string with no defined semantics. A back-end is able to set the value, and it can be retrieved via the POWER_IOC_GET_TYPE ioctl, but otherwise nothing uses the value. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 11:29:23AM +0100, Jean-Yves Migeon wrote: > Seems reasonable to me. We could have a more featureful binary later, > and just alias zzz(8) to it. We have ready ioctl-facilities in sysmon's "sysmon_power.c". I believe it was originally intended by the author that MD code should use the sysmon_power_settype() function to register a "power-backend" (ACPI, APM, Xen, PowerBook, and so on). Extending this idea seems like a plausible route. - Jukka.
Re: CVS commit: src/etc/powerd/scripts
On 31.12.2010 11:10, Jukka Ruohonen wrote:
> On Fri, Dec 31, 2010 at 11:01:08AM +0100, Jean-Yves Migeon wrote:
>> I am using machdep.sleep_state as node to put a domU into suspend mode.
>> Up to now, putting sleep_state under machdep allowed powerd(8)
>> sleep_button to be used regardless of the environment (eg. ACPI sleep or
>> Xen domU sleep).
>
> So Xen uses a *machine-dependent* sysctl(8) variable for purposes entirely
> different from the intended one?
machine-dependent: yes
for purposes entirely different from the intended one: not really,
purpose is arguably the same, put system into "sleep" ("sleep" state
being not well defined, I admit).
It's only in my local tree though. This can be done in entirely
different ways, nothing is set in stone.
The side effect of your change is that the sleep_state node will move
under hw.acpi, which is not right in Xen domU case.
>> While retiring sleep_state from machdep goes in the right direction
>> IMHO, will it be replaced by a MI interface to put a system into sleep,
>> as it is not a feature specific to ACPI?
>
> Definitely agreed. Maybe we could steal zzz(8) from APM?
Seems reasonable to me. We could have a more featureful binary later,
and just alias zzz(8) to it.
> Generally, most of the problems ("the mess") in the area of power management
> have been directly caused by the lack of proper MI interfaces and the overall
> lack of planning. The move towards sysmon_pswitch(9), pmf(9), and powerd(8)
> were a step to the right direction; the mistakes done with the i386-specific
> apm(4) should not be repeated.
Of course not; that's why I am asking.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 11:01:08AM +0100, Jean-Yves Migeon wrote:
> I am using machdep.sleep_state as node to put a domU into suspend mode.
> Up to now, putting sleep_state under machdep allowed powerd(8)
> sleep_button to be used regardless of the environment (eg. ACPI sleep or
> Xen domU sleep).
So Xen uses a *machine-dependent* sysctl(8) variable for purposes entirely
different from the intended one?
> While retiring sleep_state from machdep goes in the right direction
> IMHO, will it be replaced by a MI interface to put a system into sleep,
> as it is not a feature specific to ACPI?
Definitely agreed. Maybe we could steal zzz(8) from APM?
Generally, most of the problems ("the mess") in the area of power management
have been directly caused by the lack of proper MI interfaces and the overall
lack of planning. The move towards sysmon_pswitch(9), pmf(9), and powerd(8)
were a step to the right direction; the mistakes done with the i386-specific
apm(4) should not be repeated.
- Jukka.
Re: CVS commit: src/etc/powerd/scripts
On 31.12.2010 10:36, Jukka Ruohonen wrote: > Module Name: src > Committed By: jruoho > Date: Fri Dec 31 09:36:15 UTC 2010 > > Modified Files: > src/etc/powerd/scripts: sleep_button > > Log Message: > Use hw.acpi.sleep.state instead of machdep.sleep_state. And so it begins :) I am using machdep.sleep_state as node to put a domU into suspend mode. Up to now, putting sleep_state under machdep allowed powerd(8) sleep_button to be used regardless of the environment (eg. ACPI sleep or Xen domU sleep). While retiring sleep_state from machdep goes in the right direction IMHO, will it be replaced by a MI interface to put a system into sleep, as it is not a feature specific to ACPI? -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/etc
On Sun, Sep 19, 2010 at 08:52:23PM +, Jonathan A. Kollasch wrote: > Log Message: > Make pci(4) device nodes root:wheel 0640 by default. > Mortals do not need to be able to generate PCI Configuration Space > read transactions, which are not entirely without side effect, as > reported in PR#16300. Should we add these to mtree/special as optional so there'll be a nightly moan on existing installs? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/etc
On Sun, Jun 06, 2010 at 08:37:57AM -0400, Christos Zoulas wrote: > Modified Files: > src/etc: rc.subr > > Log Message: > fix conditional, from dholland. That makes a lot more sense :-) (but now I'm wondering if sh should provide some kind of WIFEXITED/WEXITSTATUS logic so we don't have to hardcode this bit pattern) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/etc
On Fri, Jun 04, 2010 at 02:42:55PM -0400, Christos Zoulas wrote: > Modified Files: > src/etc: rc rc.subr > > Log Message: > print human readable exit code. + elif [ $1 -eq 127 ] + then + echo "stopped with signal $(expr $1 / 256)" that can't be right... -- David A. Holland dholl...@netbsd.org
CVS commit: src/etc
Module Name:src Committed By: plunky Date: Sat Mar 6 21:33:20 UTC 2010 Modified Files: src/etc: MAKEDEV.tmpl Log Message: include ttyHS0 in usbs target [for uhso(4)] To generate a diff of this commit: cvs rdiff -u -r1.131 -r1.132 src/etc/MAKEDEV.tmpl Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/etc/MAKEDEV.tmpl diff -u src/etc/MAKEDEV.tmpl:1.131 src/etc/MAKEDEV.tmpl:1.132 --- src/etc/MAKEDEV.tmpl:1.131 Sat Mar 6 21:05:36 2010 +++ src/etc/MAKEDEV.tmpl Sat Mar 6 21:33:20 2010 @@ -1,5 +1,5 @@ #!/bin/sh - -# $NetBSD: MAKEDEV.tmpl,v 1.131 2010/03/06 21:05:36 plunky Exp $ +# $NetBSD: MAKEDEV.tmpl,v 1.132 2010/03/06 21:33:20 plunky Exp $ # # Copyright (c) 2003,2007,2008 The NetBSD Foundation, Inc. # All rights reserved. @@ -798,6 +798,7 @@ makedev ulpt0 ulpt1 makedev ttyU0 ttyU1 makedev ttyY0 ttyY1 + makedev ttyHS0 makedev urio0 makedev uscanner0 uscanner1 makedev utoppy0 utoppy1
CVS commit: src/etc
Module Name:src Committed By: plunky Date: Sat Mar 6 21:33:20 UTC 2010 Modified Files: src/etc: MAKEDEV.tmpl Log Message: include ttyHS0 in usbs target [for uhso(4)] To generate a diff of this commit: cvs rdiff -u -r1.131 -r1.132 src/etc/MAKEDEV.tmpl Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc/rc.d
Module Name:src Committed By: christos Date: Wed Feb 17 23:32:08 UTC 2010 Modified Files: src/etc/rc.d: fsck Log Message: Exclude root, since that is done in fsck_root. To generate a diff of this commit: cvs rdiff -u -r1.10 -r1.11 src/etc/rc.d/fsck Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/etc/rc.d
Am 16.02.10 03:46, schrieb matthew green: Module Name:src Committed By: mrg Date: Tue Feb 16 02:46:02 UTC 2010 Modified Files: src/etc/rc.d: fsck_root Log Message: only fsck / if we find it in /etc/fstab. diskless systems don't need a / entry. XXX: still get an error from "mount /" in etc/rc.d/root itself. There is a corner case that will now use an unchecked filesystem: When you specify it during boot on the console. Not sure if that is a real problem, though.
re: CVS commit: src/etc/rc.d
On Tue, 16 Feb 2010, matthew green wrote: > Modified Files: >src/etc/rc.d: fsck_root > > Log Message: > only fsck / if we find it in /etc/fstab. diskless systems don't need > a / entry. This seems reasonable. But, without this patch, would it work to place "from_mount" in the fs_spec column, and "0" in the fs_passno column? fs_spec="from_mount" seems to be documented only in the mount(8) man page, not in fstab(5). hmmm, interesting idea. initially i didn't realise that you meant for "from_mount" to be a literal string. that would also fix the "mount /" problem in rc.d/root. .mrg.
Re: CVS commit: src/etc/rc.d
On Tue, 16 Feb 2010, matthew green wrote: > Modified Files: > src/etc/rc.d: fsck_root > > Log Message: > only fsck / if we find it in /etc/fstab. diskless systems don't need > a / entry. This seems reasonable. But, without this patch, would it work to place "from_mount" in the fs_spec column, and "0" in the fs_passno column? fs_spec="from_mount" seems to be documented only in the mount(8) man page, not in fstab(5). --apb (Alan Barrett)
CVS commit: src/etc/rc.d
Module Name:src Committed By: mrg Date: Tue Feb 16 02:46:02 UTC 2010 Modified Files: src/etc/rc.d: fsck_root Log Message: only fsck / if we find it in /etc/fstab. diskless systems don't need a / entry. XXX: still get an error from "mount /" in etc/rc.d/root itself. To generate a diff of this commit: cvs rdiff -u -r1.3 -r1.4 src/etc/rc.d/fsck_root Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc/powerd/scripts
Module Name:src
Committed By: pgoyette
Date: Mon Feb 15 22:56:13 UTC 2010
Modified Files:
src/etc/powerd/scripts: sensor_battery
Log Message:
Add cases for new {high,maximum}-capacity events
To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/etc/powerd/scripts/sensor_battery
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
re: CVS commit: src/etc
Module Name: src Committed By:jmmv Date:Fri Feb 5 16:29:02 UTC 2010 Modified Files: src/etc: daily security src/etc/defaults: daily.conf security.conf Log Message: Deprecate the pkgdb_dir settings from daily.conf and security.conf in favor of the PKG_DBDIR variable in /etc/pkg_install.conf. The purpose of this is to only have to define the location of the packages database in a single place and have all other system components pick it up. thanks for doing this! it has always bothered me. pkgdb_dir is still honored if defined and the scripts will spit out a warning in that case, asking the administrator to migrate to the PKG_DBDIR setting. We can't remove this compatibility workaround until, at least, after NetBSD 6 is released. if we've decided to do this now, then after netbsd 7 is the time to remove it. please make sure it is part of the new install notes.. .mrg.
CVS commit: src/etc
Module Name:src Committed By: jmmv Date: Fri Feb 5 16:29:02 UTC 2010 Modified Files: src/etc: daily security src/etc/defaults: daily.conf security.conf Log Message: Deprecate the pkgdb_dir settings from daily.conf and security.conf in favor of the PKG_DBDIR variable in /etc/pkg_install.conf. The purpose of this is to only have to define the location of the packages database in a single place and have all other system components pick it up. pkgdb_dir is still honored if defined and the scripts will spit out a warning in that case, asking the administrator to migrate to the PKG_DBDIR setting. We can't remove this compatibility workaround until, at least, after NetBSD 6 is released. To generate a diff of this commit: cvs rdiff -u -r1.75 -r1.76 src/etc/daily cvs rdiff -u -r1.107 -r1.108 src/etc/security cvs rdiff -u -r1.13 -r1.14 src/etc/defaults/daily.conf cvs rdiff -u -r1.22 -r1.23 src/etc/defaults/security.conf Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc
Module Name:src Committed By: roy Date: Thu Feb 4 21:01:16 UTC 2010 Modified Files: src/etc: Makefile src/etc/root: Makefile Added Files: src/etc/root: dot.terminfo mkterminfo Log Message: Install a minimal .terminfo and .terminfo.db in /root. This allows terminfo to be used when /usr is not available. Fixes PR misc/6879. To generate a diff of this commit: cvs rdiff -u -r1.378 -r1.379 src/etc/Makefile cvs rdiff -u -r1.1 -r1.2 src/etc/root/Makefile cvs rdiff -u -r0 -r1.1 src/etc/root/dot.terminfo src/etc/root/mkterminfo Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc
Module Name:src Committed By: jmmv Date: Wed Jan 27 16:22:41 UTC 2010 Modified Files: src/etc: daily Log Message: Reset the umask while refreshing the vulnerabilities database so that it remains world-readable. Otherwise, it ends up with 600 permissions which make it unusable for building pkgsrc packages as non-root. Problem found by w...@. To generate a diff of this commit: cvs rdiff -u -r1.74 -r1.75 src/etc/daily Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc/rc.d
Module Name:src Committed By: drochner Date: Sat Jan 23 17:44:44 UTC 2010 Modified Files: src/etc/rc.d: mdnsd Log Message: fix an obvious typo in directory check To generate a diff of this commit: cvs rdiff -u -r1.1 -r1.2 src/etc/rc.d/mdnsd Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc
Module Name:src Committed By: jmmv Date: Wed Jan 20 22:19:20 UTC 2010 Modified Files: src/etc: daily src/etc/defaults: daily.conf Log Message: Default fetch_pkg_vulnerabilities to NO and complain if it is set to that value when packages are found (so that the user knows he is not getting the vulnerability checks). Why? People is complaining. (And somehow, the argument that NetBSD doesn't do any network operation by default convinces me that it should continue to do so.) But still, I will be adding a question to sysinst to enable/disable this. To generate a diff of this commit: cvs rdiff -u -r1.73 -r1.74 src/etc/daily cvs rdiff -u -r1.12 -r1.13 src/etc/defaults/daily.conf Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc
Module Name:src Committed By: jmmv Date: Tue Jan 19 22:08:11 UTC 2010 Modified Files: src/etc: daily security src/etc/defaults: daily.conf security.conf Log Message: Add the fetch_pkg_vulnerabilities option to the daily script to keep the packages vulnerability database up to date. This will only fetch the file from the server if it has changed since the last run. Add the check_pkg_vulnerabilities and check_pkg_signatures options to the security script to check that the installed packages are sane. All of these options are enabled by default but they will only run if there is, at least, one installed package. To generate a diff of this commit: cvs rdiff -u -r1.72 -r1.73 src/etc/daily cvs rdiff -u -r1.106 -r1.107 src/etc/security cvs rdiff -u -r1.11 -r1.12 src/etc/defaults/daily.conf cvs rdiff -u -r1.21 -r1.22 src/etc/defaults/security.conf Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc
Module Name:src Committed By: ahoka Date: Mon Jan 18 17:10:29 UTC 2010 Modified Files: src/etc: wscons.conf Log Message: Add examples to make switching wscons to ISO 8859-2 as easy as removing some hashmarks. To generate a diff of this commit: cvs rdiff -u -r1.17 -r1.18 src/etc/wscons.conf Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc/etc.sparc64
Module Name:src Committed By: jdc Date: Mon Jan 18 10:35:18 UTC 2010 Modified Files: src/etc/etc.sparc64: MAKEDEV.conf Log Message: Add RSC ports (ttyh2, ttyh3) to all_md. To generate a diff of this commit: cvs rdiff -u -r1.13 -r1.14 src/etc/etc.sparc64/MAKEDEV.conf Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc/mtree
Module Name:src Committed By: plunky Date: Mon Jan 18 10:25:29 UTC 2010 Modified Files: src/etc/mtree: Makefile Log Message: also clean up NetBSD.dist.tmp as if a second build is done without the NetBSD.dist changing, the tmp file will remain. To generate a diff of this commit: cvs rdiff -u -r1.14 -r1.15 src/etc/mtree/Makefile Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc
Module Name:src Committed By: dholland Date: Tue Jan 12 04:44:06 UTC 2010 Modified Files: src/etc: Makefile Log Message: Fix previous: use correct mode as well as owner/group. My bad. PR misc/41544. To generate a diff of this commit: cvs rdiff -u -r1.377 -r1.378 src/etc/Makefile Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc
Module Name:src Committed By: dholland Date: Sun Jan 10 06:13:25 UTC 2010 Modified Files: src/etc: Makefile Log Message: Fix installation permissions of /var/db/locate.database as per PR misc/41544. To generate a diff of this commit: cvs rdiff -u -r1.376 -r1.377 src/etc/Makefile Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/etc/rc.d
Date:Tue, 29 Dec 2009 15:28:01 -0500
From:Elad Efrat
Message-ID: <4b3a6651.2080...@netbsd.org>
| This makes 3 or 4 different opinions as to how the message read.
| You will not hear any objections from me if you change it...
I don't care what the message says, but please make it go away when the
user (admin) isn't actually trying to set securelevel (ie, in the
script, only print the message if test -n "${securelevel}" )
Having the boot system tell you it can't set securelevel, when you never
wanted to touch it would be decidedly annoying (regardless of what would
happen by default if the syslog var was there.)
kre
Re: CVS commit: src/etc/rc.d
Am 29.12.2009 um 21:29 schrieb Elad Efrat: > Elad Efrat wrote: >> Marc Balmer wrote: -osecurelevel=$(sysctl -n kern.securelevel) +osecurelevel=$(sysctl -n kern.securelevel 2>&-) +if [ $? != 0 ]; then +echo "Can't set securelevel. (kern.securelevel sysctl not present.)" >>> >>> the error message should probably read >>> >>> Can't set securelevel. (kern.securelevel sysctl variable not present.) >> This makes 3 or 4 different opinions as to how the message read. > > I question is: is it a "sysctl" or a "sysctl variable". I would go for the latter.
Re: CVS commit: src/etc/rc.d
Elad Efrat wrote: Marc Balmer wrote: -osecurelevel=$(sysctl -n kern.securelevel) +osecurelevel=$(sysctl -n kern.securelevel 2>&-) +if [ $? != 0 ]; then +echo "Can't set securelevel. (kern.securelevel sysctl not present.)" the error message should probably read Can't set securelevel. (kern.securelevel sysctl variable not present.) This makes 3 or 4 different opinions as to how the message read. I meant "should read." Sorry, -e.
Re: CVS commit: src/etc/rc.d
Marc Balmer wrote: -osecurelevel=$(sysctl -n kern.securelevel) +osecurelevel=$(sysctl -n kern.securelevel 2>&-) +if [ $? != 0 ]; then +echo "Can't set securelevel. (kern.securelevel sysctl not present.)" the error message should probably read Can't set securelevel. (kern.securelevel sysctl variable not present.) This makes 3 or 4 different opinions as to how the message read. You will not hear any objections from me if you change it... -e.
Re: CVS commit: src/etc/rc.d
Am 29.12.2009 um 18:06 schrieb Elad Efrat: Module Name:src Committed By: elad Date: Tue Dec 29 17:06:11 UTC 2009 Modified Files: src/etc/rc.d: securelevel Log Message: Securelevel might not be present, properly complain instead of printing error messages from sysctl(8). To generate a diff of this commit: cvs rdiff -u -r1.7 -r1.8 src/etc/rc.d/securelevel Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/etc/rc.d/securelevel diff -u src/etc/rc.d/securelevel:1.7 src/etc/rc.d/securelevel:1.8 --- src/etc/rc.d/securelevel:1.7Wed Nov 12 12:35:52 2008 +++ src/etc/rc.d/securelevelTue Dec 29 17:06:10 2009 @@ -1,6 +1,6 @@ #!/bin/sh # -# $NetBSD: securelevel,v 1.7 2008/11/12 12:35:52 ad Exp $ +# $NetBSD: securelevel,v 1.8 2009/12/29 17:06:10 elad Exp $ # # PROVIDE: securelevel @@ -19,7 +19,12 @@ # it is 0, change it to 1 here, before we start daemons # or login services. # - osecurelevel=$(sysctl -n kern.securelevel) + osecurelevel=$(sysctl -n kern.securelevel 2>&-) + if [ $? != 0 ]; then + echo "Can't set securelevel. (kern.securelevel sysctl not present.)" the error message should probably read Can't set securelevel. (kern.securelevel sysctl variable not present.) + exit 1 + fi + if [ -n "$securelevel" -a "$securelevel" != "$osecurelevel" ]; then if [ "$securelevel" -lt "$osecurelevel" ]; then echo "Can't lower securelevel."
Re: CVS commit: src/etc/mtree
> Log Message: > NetBSD/mips64e[bl] userland is default to N32 ABI. It needs /usr/lib/o32 > for O32 ABI and /usr/lib/64 for N32 ABI. ^^^ Of course I meant N64. Masao -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/etc/rc.d
On Oct 6, 2009, at 1:22 AM, Adam Hamsik wrote: > Hi, > On Oct,Tuesday 6 2009, at 9:03 AM, Alan Barrett wrote: > >> On Mon, 05 Oct 2009, Adam Hamsik wrote: >>> Modified Files: >>> src/etc/rc.d: mountall >>> >>> Log Message: >>> Add support for mounting zfs filesystems to mountall script. ZFS >>> configuration >>> is stored in /etc/zpool.cache and it is automatically loaded to kernel from >>> filesystem. Filesystems are then configured accordingly to their properties >>> loaded from cache file. >> >> Is /etc/zpool.cache a human-edited configuration file (in which >> case, why the ".cache" name?), or is it a machine-readable database (in >> which case, why is it in /etc?), or is it something else? > > It is a binary file. Something like binary plist. Do you have any better > place for it ? I think that we should keep it in etc until we start work on a > zfs on root support then we will need to move it some where else anyway. It belongs in /var/db ... but I'd like to ask why you need it at all? > > Regards > > Adam. -- thorpej
Re: CVS commit: src/etc/rc.d
Hi, On Oct,Tuesday 6 2009, at 9:03 AM, Alan Barrett wrote: On Mon, 05 Oct 2009, Adam Hamsik wrote: Modified Files: src/etc/rc.d: mountall Log Message: Add support for mounting zfs filesystems to mountall script. ZFS configuration is stored in /etc/zpool.cache and it is automatically loaded to kernel from filesystem. Filesystems are then configured accordingly to their properties loaded from cache file. Is /etc/zpool.cache a human-edited configuration file (in which case, why the ".cache" name?), or is it a machine-readable database (in which case, why is it in /etc?), or is it something else? It is a binary file. Something like binary plist. Do you have any better place for it ? I think that we should keep it in etc until we start work on a zfs on root support then we will need to move it some where else anyway. Regards Adam.
Re: CVS commit: src/etc/rc.d
On Mon, 05 Oct 2009, Adam Hamsik wrote: > Modified Files: > src/etc/rc.d: mountall > > Log Message: > Add support for mounting zfs filesystems to mountall script. ZFS configuration > is stored in /etc/zpool.cache and it is automatically loaded to kernel from > filesystem. Filesystems are then configured accordingly to their properties > loaded from cache file. Is /etc/zpool.cache a human-edited configuration file (in which case, why the ".cache" name?), or is it a machine-readable database (in which case, why is it in /etc?), or is it something else? --apb (Alan Barrett)
re: CVS commit: src/etc
Module Name: src Committed By:christos Date:Thu Sep 24 14:53:36 UTC 2009 Modified Files: src/etc: MAKEDEV.tmpl Log Message: fix dri/drm confusiog thanks. .mrg.
re: CVS commit: src/etc/rc.d
matthew green wrote: >On Thu, 10 Sep 2009, Erik Fair wrote: >> On Sep 8, 2009, at 01:56, Christoph Egger wrote: >> >Modified Files: >> > src/etc/rc.d: network >> > >> >Log Message: >> >Do not flush routes if root file system is nfs mounted. >> >Fixes boot problem when the nfs server is in a different subnet. >> >> This change should be pulled up to netbsd-5. > >No, this change should be backed out, and the real problem (incorrect >default for flushroutes) addressed in a different way. > > > i agree. > > this is the 2nd time in recent history that controversial > changes to rc.d have been commited without discussion. recent history has shown that patches got discussed after commit not before. that doesn't make it good or right. thanks for backing this change out. .mrg.
Re: CVS commit: src/etc/rc.d
christoph_eg...@gmx.de wrote: > recent history has shown that patches got discussed after commit > not before. The history has also shown you put too much botches ;-p --- Izumi Tsutsui
Re: CVS commit: src/etc/rc.d
On Fri, Sep 11, 2009 at 11:26:54PM +0200, Christoph Egger wrote: > matthew green wrote: > >On Thu, 10 Sep 2009, Erik Fair wrote: > >> On Sep 8, 2009, at 01:56, Christoph Egger wrote: > >> >Modified Files: > >> > src/etc/rc.d: network > >> > > >> >Log Message: > >> >Do not flush routes if root file system is nfs mounted. > >> >Fixes boot problem when the nfs server is in a different subnet. > >> > >> This change should be pulled up to netbsd-5. > > > >No, this change should be backed out, and the real problem (incorrect > >default for flushroutes) addressed in a different way. > > > > > > i agree. > > > > this is the 2nd time in recent history that controversial > > changes to rc.d have been commited without discussion. > > recent history has shown that patches got discussed after commit > not before. Recent history has shown that you're not a stranger to committing convenience workarounds and then freely admitting that you have no complete grasp of the issue at hand. I'm not sure you want to continue on that slope. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007. pgpNFiyiFpYae.pgp Description: PGP signature
Re: CVS commit: src/etc/rc.d
matthew green wrote: >On Thu, 10 Sep 2009, Erik Fair wrote: >> On Sep 8, 2009, at 01:56, Christoph Egger wrote: >> >Modified Files: >> >src/etc/rc.d: network >> > >> >Log Message: >> >Do not flush routes if root file system is nfs mounted. >> >Fixes boot problem when the nfs server is in a different subnet. >> >> This change should be pulled up to netbsd-5. > >No, this change should be backed out, and the real problem (incorrect >default for flushroutes) addressed in a different way. > > > i agree. > > this is the 2nd time in recent history that controversial > changes to rc.d have been commited without discussion. recent history has shown that patches got discussed after commit not before. Christoph
re: CVS commit: src/etc/rc.d
On Thu, 10 Sep 2009, Erik Fair wrote: > On Sep 8, 2009, at 01:56, Christoph Egger wrote: > >Modified Files: > > src/etc/rc.d: network > > > >Log Message: > >Do not flush routes if root file system is nfs mounted. > >Fixes boot problem when the nfs server is in a different subnet. > > This change should be pulled up to netbsd-5. No, this change should be backed out, and the real problem (incorrect default for flushroutes) addressed in a different way. i agree. this is the 2nd time in recent history that controversial changes to rc.d have been commited without discussion. this needs to stop. .mrg.
Re: CVS commit: src/etc/rc.d
> On Thu, 10 Sep 2009, Erik Fair wrote: > > On Sep 8, 2009, at 01:56, Christoph Egger wrote: > > >Modified Files: > > > src/etc/rc.d: network > > > > > >Log Message: > > >Do not flush routes if root file system is nfs mounted. > > >Fixes boot problem when the nfs server is in a different > > >subnet. > > > > This change should be pulled up to netbsd-5. > > No, this change should be backed out, and the real problem > (incorrect default for flushroutes) addressed in a different way. I want to fix the problem with getting nfs server unreachable when multiple interfaces are configured with "dhcp" in /etc/ifconfig. locally first to understand what else is going wrong. Christoph
Re: CVS commit: src/etc/rc.d
On Thu, 10 Sep 2009, Erik Fair wrote: > On Sep 8, 2009, at 01:56, Christoph Egger wrote: > >Modified Files: > > src/etc/rc.d: network > > > >Log Message: > >Do not flush routes if root file system is nfs mounted. > >Fixes boot problem when the nfs server is in a different subnet. > > This change should be pulled up to netbsd-5. No, this change should be backed out, and the real problem (incorrect default for flushroutes) addressed in a different way. --apb (Alan Barrett)
Re: CVS commit: src/etc/rc.d
On Sep 8, 2009, at 01:56, Christoph Egger wrote: Module Name:src Committed By: cegger Date: Tue Sep 8 08:56:34 UTC 2009 Modified Files: src/etc/rc.d: network Log Message: Do not flush routes if root file system is nfs mounted. Fixes boot problem when the nfs server is in a different subnet. To generate a diff of this commit: cvs rdiff -u -r1.58 -r1.59 src/etc/rc.d/network Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. This change should be pulled up to netbsd-5. Erik
Re: CVS commit: src/etc/rc.d
On Tue, Sep 08, 2009 at 06:07:57PM +0200, Christoph Egger wrote: > Joerg Sonnenberger wrote: > > On Tue, Sep 08, 2009 at 02:30:56PM +0200, Christoph Egger wrote: > >>> Perhaps a better test would be that dhcpcd shouldn't touch > >>> the default route unless the default route is through the > >>> interface that dhcpcd is managing. > >> I agree. > >> How should dhcpcd deal with /etc/resolv.conf ? > >> If dhcpcd removes and rewrites the entries, DNS queries in-between > >> may fail (i.e. mounting nfs) > > > > I would say you have a completely broken setup in that case. You can > > easily prevent dhcpcd from changing the default route at all if you need > > to. > > I tried dhcpcd -n -p but I ended up with having the nfs server > unreachable. You haven't included -G to keep the default route. Joerg
Re: CVS commit: src/etc/rc.d
Joerg Sonnenberger wrote: > On Tue, Sep 08, 2009 at 02:30:56PM +0200, Christoph Egger wrote: >>> Perhaps a better test would be that dhcpcd shouldn't touch >>> the default route unless the default route is through the >>> interface that dhcpcd is managing. >> I agree. >> How should dhcpcd deal with /etc/resolv.conf ? >> If dhcpcd removes and rewrites the entries, DNS queries in-between >> may fail (i.e. mounting nfs) > > I would say you have a completely broken setup in that case. You can > easily prevent dhcpcd from changing the default route at all if you need > to. I tried dhcpcd -n -p but I ended up with having the nfs server unreachable. Christoph
Re: CVS commit: src/etc/rc.d
On Tue, Sep 08, 2009 at 02:30:56PM +0200, Christoph Egger wrote: > > Perhaps a better test would be that dhcpcd shouldn't touch > > the default route unless the default route is through the > > interface that dhcpcd is managing. > > I agree. > How should dhcpcd deal with /etc/resolv.conf ? > If dhcpcd removes and rewrites the entries, DNS queries in-between > may fail (i.e. mounting nfs) I would say you have a completely broken setup in that case. You can easily prevent dhcpcd from changing the default route at all if you need to. Joerg
Re: CVS commit: src/etc/rc.d
> On Tue, 08 Sep 2009, Christoph Egger wrote: > > > > Do not flush routes if root file system is nfs mounted. > > > > Fixes boot problem when the nfs server is in a different > > > > subnet. > > > > > > Why do you need this special case code, when a simple > > > flushroutes=NO in /etc/rc.conf will do the job? > > > > I prefer a default value that works out-of-the box. > > So do I, but why is flushroutes true out of the box? Isn't that > the right thing to fix? I am not sure. > > there's another problem still to address: > > > > if you have multiple interfaces and you have > > 'dhcp' in /etc/ifconfig. then > > dhcpcd tries to remove and re-add the default route. > > dhcpcd shouldn't touch the default route if root is on NFS > > because you end up with > > I still don't see why "root on NFS" is the right condition to > use in a test for whether to flush routes or to change the > default route. For example, if root is local but /var is on > NFS, you will get similar problems. We can extend rc.subr with a function which determines if we mount nfs and if we have root-on-nfs and exports corresponding variables set to yes or no. All scripts can use them to easily test "root on NFS". > Perhaps a better test would be that dhcpcd shouldn't touch > the default route unless the default route is through the > interface that dhcpcd is managing. I agree. How should dhcpcd deal with /etc/resolv.conf ? If dhcpcd removes and rewrites the entries, DNS queries in-between may fail (i.e. mounting nfs) Christoph
Re: CVS commit: src/etc/rc.d
On Tue, 08 Sep 2009, Christoph Egger wrote: > > > Do not flush routes if root file system is nfs mounted. > > > Fixes boot problem when the nfs server is in a different > > > subnet. > > > > Why do you need this special case code, when a simple > > flushroutes=NO in /etc/rc.conf will do the job? > > I prefer a default value that works out-of-the box. So do I, but why is flushroutes true out of the box? Isn't that the right thing to fix? > there's another problem still to address: > > if you have multiple interfaces and you have > 'dhcp' in /etc/ifconfig. then > dhcpcd tries to remove and re-add the default route. > dhcpcd shouldn't touch the default route if root is on NFS > because you end up with I still don't see why "root on NFS" is the right condition to use in a test for whether to flush routes or to change the default route. For example, if root is local but /var is on NFS, you will get similar problems. Perhaps a better test would be that dhcpcd shouldn't touch the default route unless the default route is through the interface that dhcpcd is managing. --apb (Alan Barrett)
Re: CVS commit: src/etc/rc.d
> On Tue, 08 Sep 2009, Christoph Egger wrote: > > Modified Files: > > src/etc/rc.d: network > > > > Log Message: > > Do not flush routes if root file system is nfs mounted. > > Fixes boot problem when the nfs server is in a different > > subnet. > > Why do you need this special case code, when a simple > flushroutes=NO in /etc/rc.conf will do the job? I prefer a default value that works out-of-the box. > Perhaps sysinst should automatically set > flushroutes=NO if it knows you have root on NFS. there's another problem still to address: if you have multiple interfaces and you have 'dhcp' in /etc/ifconfig. then dhcpcd tries to remove and re-add the default route. dhcpcd shouldn't touch the default route if root is on NFS because you end up with nfs_timer: ignoring error 65 nfs_timer: ignoring error 65 nfs_timer: ignoring error 65 [...] Christoph
Re: CVS commit: src/etc/rc.d
On Tue, 08 Sep 2009, Christoph Egger wrote: > Modified Files: > src/etc/rc.d: network > > Log Message: > Do not flush routes if root file system is nfs mounted. > Fixes boot problem when the nfs server is in a different subnet. Why do you need this special case code, when a simple flushroutes=NO in /etc/rc.conf will do the job? Perhaps sysinst should automatically set flushroutes=NO if it knows you have root on NFS. --apb (Alan Barrett)
Re: CVS commit: src/etc/rc.d
Hi, I am only intermittently online - thus no reply for so long time. burst is not nice to use (sends always 8 pkts at 0.5 pkt/sec per query) - iburst (fast resending 0.5 pkt/sec when the filter is empty) is the better choice - it is perfect for startup and recovery. Synchronisation takes about 8-10 secs (4 replys until selection and set) for setting the clock. Thinking ntpdate is safe is risky. ntpdate could very well fail to find valid servers and then the time would be wrong anyway (being set then at a later time). Given that and todays fast startup starting ntpd with -g and waiting the previous ntpdate timeout period (or at least 10 seconds) should give us functionally what we have today. If we really want to be sure we have a valid time we need to pay attention to ntpdates return code (old scheme) or check ntpd for synchronization. Requiring the time to be correctly set may introduce arbitrary long delays during startup of services in case we find no valid time source - this may not be what we want, Best regards, Frank Matthias Drochner wrote: i...@bsdimp.com said: With ntpd -g, it means that time will be messed up until the time is first set (which isn't after the first measurement). There are several polling intervals, about a minute apart, that have to happen before ntpd believes the time There is some "burst" option which should accelerate that. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: CVS commit: src/etc/rc.d
i...@bsdimp.com said: > With ntpd -g, it means that time will be messed up until the time is > first set (which isn't after the first measurement). There are > several polling intervals, about a minute apart, that have to happen > before ntpd believes the time There is some "burst" option which should accelerate that. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: CVS commit: src/etc/rc.d
In message: <87y6px9cr9@snark.cb.piermont.com> "Perry E. Metzger" writes: : : "M. Warner Losh" writes: : > In message: <87ab2dat79@snark.cb.piermont.com> : > "Perry E. Metzger" writes: : > : : > : Frank Kardel writes: : > : > Actually we can retire ntpdate in rc unless we are very tight on : > : > memory. ntpd_flags should add the -g flag. This allows for a big : > : > (time setting) initial (and only one time) step in ntpd. : > : : > : I was made aware of that a few days ago. : > : > How long after startup does ntpd exit in this case? : : It doesn't. -g says that the initial time difference may be large and to : just step the time rather than slewing it on initial start. Then you : don't need ntpdate. (You *can* use ntpd with other flags to behave like : ntpdate but that's not the purpose here.) I think you've missed my point. With ntpdate the time is set when ntpdate is run, and the adjtime/ntpd_adjtime parameters aren't set (which is part of what I meant by 'not going to change', the other part is 'time will pass normally without jumps'). With ntpd -g, it means that time will be messed up until the time is first set (which isn't after the first measurement). There are several polling intervals, about a minute apart, that have to happen before ntpd believes the time (at least historically, I haven't checked the exact version in NetBSD). This means that different things in the system will start up with the wrong time. Eg, the system starts up with Jan 1, 1980 (lovely bios error, pick any other year you want, the example is still valid)... ntpd starts, as does sendmail, cron, sshd, etc. Then, a few minutes later, time jumps forward 29 years. Warner
Re: CVS commit: src/etc/rc.d
On Thu, Aug 06, 2009 at 10:54:34AM -0400, Perry E. Metzger wrote: > > Frank Kardel writes: > > Actually we can retire ntpdate in rc unless we are very tight on > > memory. ntpd_flags should add the -g flag. This allows for a big > > (time setting) initial (and only one time) step in ntpd. > > I was made aware of that a few days ago. > > If we go that route, however, we will have to move ntpd to start much > earlier (where ntpdate currently runs), because various tools like the > kdc stuff require that the time be properly set before they execute. > > I'm willing to do that for -current but not for 5.0 (the fixes now in > -current are being pulled up.) Huh? The change itself is controversial, so it should NOT be pulled up right now. Bernd
Re: CVS commit: src/etc/rc.d
"M. Warner Losh" writes: > In message: <87ab2dat79@snark.cb.piermont.com> > "Perry E. Metzger" writes: > : > : Frank Kardel writes: > : > Actually we can retire ntpdate in rc unless we are very tight on > : > memory. ntpd_flags should add the -g flag. This allows for a big > : > (time setting) initial (and only one time) step in ntpd. > : > : I was made aware of that a few days ago. > > How long after startup does ntpd exit in this case? It doesn't. -g says that the initial time difference may be large and to just step the time rather than slewing it on initial start. Then you don't need ntpdate. (You *can* use ntpd with other flags to behave like ntpdate but that's not the purpose here.) > Just be careful here about the races here... ntpdate guaranteed the > time was set and wasn't going to change... It guaranteed that the time was set -- not that it would not change. Perry -- Perry E. Metzgerpe...@piermont.com
