On Thu, Aug 23, 2018, at 8:34 AM, Rodney W. Grimes wrote:
> > On 8/22/18 8:37 PM, Mark Millard wrote:
> > > I'm just using this move as an example for some more
> > > general questions.
> > >
> > > After this change when I look at:
> > >
> > >
> On 8/22/18 8:37 PM, Mark Millard wrote:
> > I'm just using this move as an example for some more
> > general questions.
> >
> > After this change when I look at:
> >
> > https://www.freebsd.org/cgi/man.cgi?query=devfs.conf=0=5=FreeBSD+12-current=default=html
> >
> > I see in the man page:
> >
On 8/22/18 8:37 PM, Mark Millard wrote:
> I'm just using this move as an example for some more
> general questions.
>
> After this change when I look at:
>
> https://www.freebsd.org/cgi/man.cgi?query=devfs.conf=0=5=FreeBSD+12-current=default=html
>
> I see in the man page:
>
> FILES
>
I'm just using this move as an example for some more
general questions.
After this change when I look at:
https://www.freebsd.org/cgi/man.cgi?query=devfs.conf=0=5=FreeBSD+12-current=default=html
I see in the man page:
FILES
/etc/devfs.conf
/usr/share/examples/etc/devfs.conf
So . . .
/kern/vfs_mount.c:1229
2nd 0xf00014a695f0 devfs (devfs) 0 /usr/src/sys/kern/vfs_subr.c:2176
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame ...
witness_checkorder() at witness_checkorder+...
__lockmgr_args() at __lockmgr_args+...
vop_stdlock() at vop_stdlock+0x3c
On Wed, Feb 18, 2015 at 9:53 AM, Damjan Jovanovic damjan@gmail.com wrote:
Hi
On r278909 (and probably earlier) I get the following when I run
poweroff (retyped from a video of it I had to record, since it
disappears very quickly):
Hi Damjan,
This is a known LOR.
Thanks!
Hi,
Is this real LoR or is it known to be invalid?
lock order reversal:
1st 0xf800323725f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237
2nd 0xf8010e9cdb78 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2210
KDB: stack backtrace:
db_trace_self_wrapper() at
I have just committed a significant change to devfs path matching logic
http://svnweb.freebsd.org/changeset/base/253677
Jaakko Heinonen (jh@) has full credit for the code while I have full
responsibility for any consequences of the commit.
Before this change the logic of matching the devfs
on 26/07/2013 17:39 Andriy Gapon said the following:
Please note that nothing changes with respect to matching simple paths like
/dev/something.
I must add: and thus rules in etc/defaults/devfs.rules should not be affected
except for their unintended side-effects.
--
Andriy Gapon
:
http://people.freebsd.org/~jh/patches/devfs-rule-fullpath.3.diff
There is no functional change. I intend to commit the patch soon.
--
Jaakko
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
Mar 23 10:29:39 2013 +0200
rc.subr: disabling globbing while processing devfs rules in
devfs_rulesets_from_file()
The rules themselves typically have shell-like patterns and it is
incorrect
when they get replaced with matching filesystem entries.
Shell magic by: jilles
On Mon, Apr 01, 2013 at 02:06:50PM -0400, John Baldwin wrote:
Why not use 'local -' instead of the $- magic? That is:
devfs_rulesets_from_file()
{
local file _err _me -
...
set -f
...
}
That would seem to be simpler.
I had mentioned this possibility on IRC, but this
On Monday, April 01, 2013 3:56:01 pm Jilles Tjoelker wrote:
On Mon, Apr 01, 2013 at 02:06:50PM -0400, John Baldwin wrote:
Why not use 'local -' instead of the $- magic? That is:
devfs_rulesets_from_file()
{
local file _err _me -
...
set -f
...
}
That would
on 01/04/2013 23:16 John Baldwin said the following:
On Monday, April 01, 2013 3:56:01 pm Jilles Tjoelker wrote:
On Mon, Apr 01, 2013 at 02:06:50PM -0400, John Baldwin wrote:
Why not use 'local -' instead of the $- magic? That is:
devfs_rulesets_from_file()
{
local file _err _me -
On 2013-03-28, Andriy Gapon wrote:
Would like to ask for opinions on this topic...
Please read this PR for context:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838
Especially Jaakko's insightful description of the problem.
So I would like to commit the following patch sooner
patch sooner rather than later:
http://people.freebsd.org/~avg/devfs_rule.diff
The only difference from the Jaakko's patch in the PR is FNM_PATHNAME.
Please review and test.
Especially if you rely on any non-trivial devfs rules.
Thank you.
--
Andriy Gapon
22:37:44 +0200
From: Andriy Gapon a...@freebsd.org
Subject: Re: kern/122838: [devfs] devfs doesn#39;t handle complex paths (like
zvol/pool/vms) good
Can't believe that we are still where we were more than two years ago...
I think that we have to make this change even if it _might_ break some
Message
Message-ID: 5150b598.7050...@freebsd.org
Date: Mon, 25 Mar 2013 22:37:44 +0200
From: Andriy Gapon a...@freebsd.org
Subject: Re: kern/122838: [devfs] devfs doesn#39;t handle complex paths (like
zvol/pool/vms) good
Can't believe that we are still where we were more than two years
devfs rules in
devfs_rulesets_from_file()
The rules themselves typically have shell-like patterns and it is incorrect
when they get replaced with matching filesystem entries.
Shell magic by: jilles
diff --git a/etc/rc.subr b/etc/rc.subr
index f37ede7..9952c82 100644
--- a/etc
Hi Kostic and Jaakko,
On Fri, Aug 05, 2011 at 06:45:22PM +0300, Jaakko Heinonen wrote:
On 2011-08-03, Kostik Belousov wrote:
On Wed, Aug 03, 2011 at 02:44:23PM +0900, Kohji Okuno wrote:
devfs_populate(), and the context holds only dm-dm_lock in
devfs_populate().
On the other
On 2011-08-03, Kostik Belousov wrote:
On Wed, Aug 03, 2011 at 02:44:23PM +0900, Kohji Okuno wrote:
devfs_populate(), and the context holds only dm-dm_lock in
devfs_populate().
On the other hand, devfs_generation is incremented in devfs_create()
and devfs_destroy() the context
On Fri, Aug 05, 2011 at 06:45:22PM +0300, Jaakko Heinonen wrote:
On 2011-08-03, Kostik Belousov wrote:
On Wed, Aug 03, 2011 at 02:44:23PM +0900, Kohji Okuno wrote:
devfs_populate(), and the context holds only dm-dm_lock in
devfs_populate().
On the other hand, devfs_generation
On Thu, Aug 04, 2011 at 11:41:39AM +0900, Kohji Okuno wrote:
Hello Kostik,
From: Kostik Belousov kostik...@gmail.com
Subject: Re: Bug: devfs is sure to have the bug.
Date: Wed, 3 Aug 2011 16:50:44 +0300
I think the problem you described is real, and suggested change is right.
Initially
Hello Kostik,
On Thu, Aug 04, 2011 at 11:41:39AM +0900, Kohji Okuno wrote:
Hello Kostik,
From: Kostik Belousov kostik...@gmail.com
Subject: Re: Bug: devfs is sure to have the bug.
Date: Wed, 3 Aug 2011 16:50:44 +0300
I think the problem you described is real, and suggested change
unaware of large changes in devfs between
8.1 and latest stable.
pgpTYJZNBuDhX.pgp
Description: PGP signature
.
I'm sorry.
I need a patch for 8.1-RELEASE. Could you propose patch?
Did you tried to apply the 211628 and the patch I mailed, to 8.1 ?
I am not very interested in porting this stuff for such old system.
On the other hand, I am unaware of large changes in devfs between
8.1 and latest stable
On Wed, Aug 03, 2011 at 02:44:23PM +0900, Kohji Okuno wrote:
Hello,
Hello,
I think that devfs is sure to have the bug.
I found that I couldn't open /dev/XXX though the kernel detected XXX
device.
dm-dm_generation is updated with devfs_generation in
devfs_populate
Hello Kostik,
From: Kostik Belousov kostik...@gmail.com
Subject: Re: Bug: devfs is sure to have the bug.
Date: Wed, 3 Aug 2011 16:50:44 +0300
Message-ID: 20110803135044.gm17...@deviant.kiev.zoral.com.ua
On Wed, Aug 03, 2011 at 02:44:23PM +0900, Kohji Okuno wrote:
Hello,
Hello,
I think
Hello,
I think that devfs is sure to have the bug.
I found that I couldn't open /dev/XXX though the kernel detected XXX
device.
dm-dm_generation is updated with devfs_generation in
devfs_populate(), and the context holds only dm-dm_lock in
devfs_populate().
On the other hand, devfs_generation
Hello,
Hello,
I think that devfs is sure to have the bug.
I found that I couldn't open /dev/XXX though the kernel detected XXX
device.
dm-dm_generation is updated with devfs_generation in
devfs_populate(), and the context holds only dm-dm_lock in
devfs_populate().
On the other
Hello,
From: Kostik Belousov kostik...@gmail.com
Date: Tue, 12 Jul 2011 17:57:53 +0300
On Tue, Jul 12, 2011 at 03:02:44PM +0200, Attilio Rao wrote:
2011/7/12 Kostik Belousov kostik...@gmail.com:
On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
Hello,
I think that devfs has
Hello,
I think that devfs has a problem.
I encountered the problem that open(/dev/AAA) returned ENOENT.
Of course, /dev/AAA exists.
ENOENT was created by the point(***) in devfs_allocv().
I think that the race condition had occurred between process A and
vnlru kernel thread.
Please check
On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
Hello,
I think that devfs has a problem.
I encountered the problem that open(/dev/AAA) returned ENOENT.
Of course, /dev/AAA exists.
ENOENT was created by the point(***) in devfs_allocv().
I think that the race condition had
Hello,
From: Kostik Belousov kostik...@gmail.com
Subject: Re: Bug about devfs?
Date: Tue, 12 Jul 2011 14:19:25 +0300
Message-ID: 20110712111925.gh43...@deviant.kiev.zoral.com.ua
Thank you for the report.
The proposed change would revert r179247, which also caused some issues.
Are you able
2011/7/12 Kostik Belousov kostik...@gmail.com:
On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
Hello,
I think that devfs has a problem.
I encountered the problem that open(/dev/AAA) returned ENOENT.
Of course, /dev/AAA exists.
ENOENT was created by the point
On Tue, Jul 12, 2011 at 03:02:44PM +0200, Attilio Rao wrote:
2011/7/12 Kostik Belousov kostik...@gmail.com:
On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
Hello,
I think that devfs has a problem.
I encountered the problem that open(/dev/AAA) returned ENOENT.
Of course
Hello,
From: Kostik Belousov kostik...@gmail.com
Date: Tue, 12 Jul 2011 17:57:53 +0300
On Tue, Jul 12, 2011 at 03:02:44PM +0200, Attilio Rao wrote:
2011/7/12 Kostik Belousov kostik...@gmail.com:
On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
Hello,
I think that devfs has
Hi,
I have been working on some devfs improvements and I am now posting the
patch for wider review and testing. Especially testing from people using
multiple devfs mounts and/or symbolic links would be useful.
The patch:
http://people.freebsd.org/~jh/patches/devfs.7.diff
Notable
/vfs_mount.c:1201
2nd 0xff000a846638 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1250
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
__lockmgr_args() at __lockmgr_args
to ZFS, are caused by VFS layer,
and I my recollection is that they are false positives.
--
Bruce
lock order reversal:
1st 0xff000a846458 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1201
2nd 0xff000a846638 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1250
KDB: stack
Adding a rule to devfs on current seems broken or at least not in touch with
the man page.
# devfs rule add path acpi mode 660
devfs rule: ioctl DEVFSIO_RADD: Input/output error
Sven Esbjerg
--
http://www.usenet.dk/netikette - på forhånd tak
Hi,
I'm running a jail on -CURRENT with
jail_enable=YES
jail_list=myjail
jail_myjail_rootdir=/home/myjail
...
in /etc/rc.conf. I already filed a PR with a patch:
PR bin/56748: jail devfs handling broken
http://www.freebsd.org/cgi/query-pr.cgi?pr=56748
the problem is that I still can't get
.freebsd-questions
Indeed what Jesse posted worked like a charm:
devfs ruleset 10
devfs rule add path 'ugen*' mode 664
Since the ugen* devices are dynamic, putting entries in /etc/devfs.conf
doesn't work unless you restart devfs once the camera is turned on. Thus, the
rule above works nicely.
He
:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/lo
cal/www/db/text/2003/freebsd-questions/20030622.freebsd-questions
Indeed what Jesse posted worked like a charm:
devfs ruleset 10
devfs rule add path 'ugen*' mode 664
Since the ugen* devices are dynamic, putting
/2003/freebsd-questions/20030622.freebsd-questions
Indeed what Jesse posted worked like a charm:
devfs ruleset 10
devfs rule add path 'ugen*' mode 664
You would need to add the following to /etc/devfs.rules:
[devfsrules_ugen=50]
add path 'ugen*' mode 664
Then add to /etc/rc.conf
[ On Monday, September 1, Scot W. Hetzel wrote: ]
From: John Reynolds [EMAIL PROTECTED]
I
http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/local/www/db/text/2003/freebsd-questions/20030622.freebsd-questions
You would need to add the following to /etc/devfs.rules:
In message [EMAIL PROTECTED], Munehiro Matsuda writ
es:
Hi All,
I just got following DEVFS related message with
this mornings current.
DEVFS Overflow table with 32768 entries allocated when 925 in use
Anybody seen this?
This is mostly harmless.
When DEVFS initially was integrated the locking
} ] jail_devfs=NO:
eval jail_fdescfs=\\$jail_${_jail}_fdescfs\
[ -z ${jail_fdescfs} ] jail_fdescfs=NO
:
if checkyesno jail_devfs ; then
mount -t devfs dev ${jail_devdir}
if checkyesno jail_fdescfs ; then
mount -t
jail_fdescfs=\\$jail_${_jail}_fdescfs\
[ -z ${jail_fdescfs} ] jail_fdescfs=NO
:
if checkyesno jail_devfs ; then
mount -t devfs dev ${jail_devdir}
if checkyesno jail_fdescfs ; then
mount -t fdescfs fdesc ${jail_devdir}/fd
On 04.08.2003 01:04, Mike Makonnen wrote:
On Sun, Aug 03, 2003 at 04:11:12PM +0200, Jens Rehsack wrote:
the patch works for me very well. I've checked what's been done
and had only small recommendations:
- Wouldn't it be better to configure the devfs rules by
/etc/devfs.conf or is it impossible
Hi All,
I just got following DEVFS related message with
this mornings current.
DEVFS Overflow table with 32768 entries allocated when 925 in use
Anybody seen this?
Thanks,
Haro
=--
_ _Munehiro (haro
Scot,
the patch works for me very well. I've checked what's been done
and had only small recommendations:
- Wouldn't it be better to configure the devfs rules by
/etc/devfs.conf or is it impossible?
- Even it would be a good thing, if I could specify a
ruleset for each jail, and fallback
On 03.08.2003 16:11, Jens Rehsack wrote:
On 02.08.2003 01:29, Mike Makonnen wrote:
On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote:
On 29.07.2003 19:21, Mike Makonnen wrote:
On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote:
Yeah, I'll take care of this. I had asked
On Sun, Aug 03, 2003 at 04:11:12PM +0200, Jens Rehsack wrote:
the patch works for me very well. I've checked what's been done
and had only small recommendations:
- Wouldn't it be better to configure the devfs rules by
/etc/devfs.conf or is it impossible?
- Even it would be a good
On 02.08.2003 01:29, Mike Makonnen wrote:
On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote:
On 29.07.2003 19:21, Mike Makonnen wrote:
On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote:
Yeah, I'll take care of this. I had asked scott to mail me his final
patch so I could
]; then
+ debug $_me: devfs rulesets already initialized
+ return
+ fi
+
+ # Hide: Hide all devices
+ #
+ /sbin/devfs rule -s $rsHide delset
+ /sbin/devfs rule -s $rsHide add hide
+
+ # Basic: Basic devices typically necessary
+ #
+ /sbin/devfs rule
Hi all, hi Clement,
I updated the rcng jail start script to mount devfs and procfs
into the jail if wanted. Adding entries to /etc/fstab didn't
work properly, because the jail filesystem wasn't mounted when
the startup process wants to mount it.
Going this way allows us to control which jail
On Tue, 29 Jul 2003, Jens Rehsack wrote:
I updated the rcng jail start script to mount devfs and procfs into the
jail if wanted. Adding entries to /etc/fstab didn't work properly,
because the jail filesystem wasn't mounted when the startup process
wants to mount it.
Going this way allows
On 29.07.2003 18:47, Robert Watson wrote:
On Tue, 29 Jul 2003, Jens Rehsack wrote:
I updated the rcng jail start script to mount devfs and procfs into the
jail if wanted. Adding entries to /etc/fstab didn't work properly,
because the jail filesystem wasn't mounted when the startup process
wants
On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote:
On 29.07.2003 18:47, Robert Watson wrote:
Someone, and unfortunately I appear to have lost track of who, had some
tweaks to the rcNG scripts to set up some reasonable devfs rules for a
jail, and apply them to the devfs mounted
On 29.07.2003 19:21, Mike Makonnen wrote:
On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote:
Yeah, I'll take care of this. I had asked scott to mail me his final
patch so I could commit it, but I never heard back from him. I'll
dig out the revisions from my mail archives and combine
From: Mike Makonnen [EMAIL PROTECTED]
On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote:
Someone, and unfortunately I appear to have lost track of who, had some
tweaks to the rcNG scripts to set up some reasonable devfs rules for a
jail, and apply them to the devfs mounted
Below is my current patch to devfs and jail to support the mounting of devfs
and procfs in jails. This patch also allows a jail to specify what devfs
rule to apply to the jail. As well as defining a default jail devfs rule
in /etc/rc.d/devfs.
Scot
Index: etc/defaults/rc.conf
On Mon, Jul 07, 2003 at 07:57:59PM +0200, Poul-Henning Kamp wrote:
Can you mail me the output of:
diskinfo -v da0
diskinfo -v da0s4
dd if=/dev/da0 count=63 | uuencode - openbsd.sect0
dd if=/dev/da0s4 count=16 | uuencode - openbsd.slice4
Then I'll try to see what
Hi,
After googling and searching in the mailing list archive I still can't
figure out how to make device nodes in -current when devfs doesn't do this
automatically. I have an external USB-drive (external 3.5 case with leftover
1.6 GB HD) from which I want to mount /dev/da0s4h. It works fine
Karel J. Bosschaart wrote:
Hi,
After googling and searching in the mailing list archive I still can't
figure out how to make device nodes in -current when devfs doesn't do this
automatically. I have an external USB-drive (external 3.5 case with leftover
1.6 GB HD) from which I want to mount
Hi.
I've seen the question once before, but it was not answered (on-list ?),
so now that I run in on it, I'd like to know what to do:
On FreeBSD 4.x, without devfs, the following worked:
( echo foo | tee /dev/fd/3 | tr f F ) 31
It should produce both foo and Foo
FreeBSD 5 with devfs, however
On Wed, Jun 04, 2003 at 03:30:19PM +0200, Marc Olzheim wrote:
Hi.
I've seen the question once before, but it was not answered (on-list ?),
so now that I run in on it, I'd like to know what to do:
On FreeBSD 4.x, without devfs, the following worked:
( echo foo | tee /dev/fd/3 | tr f F ) 31
On Wed, 4 Jun 2003, Marc Olzheim wrote:
MOHi.
MO
MOI've seen the question once before, but it was not answered (on-list ?),
MOso now that I run in on it, I'd like to know what to do:
MO
MOOn FreeBSD 4.x, without devfs, the following worked:
MO( echo foo | tee /dev/fd/3 | tr f F ) 31
MO
MOIt
In message [EMAIL PROTECTED], Marc Olzheim writes:
Hi.
I've seen the question once before, but it was not answered (on-list ?),
so now that I run in on it, I'd like to know what to do:
On FreeBSD 4.x, without devfs, the following worked:
( echo foo | tee /dev/fd/3 | tr f F ) 31
It should
here now. Thanks a lot guys !
uname -a:
FreeBSD turtle.stack.nl 5.1-BETA FreeBSD 5.1-BETA #10: Mon May 12 15:30:54 CEST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TURTLE i386
Btw. Why isn't this default mounted together with devfs in /etc/rc.d ?
Is it not yet stable enough ?
Zlo
no error).
Don't know why.
Hmm, it does work for me here now. Thanks a lot guys !
uname -a:
FreeBSD turtle.stack.nl 5.1-BETA FreeBSD 5.1-BETA #10: Mon May 12 15:30:54 CEST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TURTLE i386
Btw. Why isn't this default mounted together with devfs in /etc/rc.d
as they
should.
Is this a bash problem, or something in devfs not working as expected?
That's a good question...
Has anybody found out what the standards conformant thing is for /dev/fd ?
presently we do only 0,1 2, with the std{in,out,err} symlinks.
If we are required to do all
are not being created as they should.
Is this a bash problem, or something in devfs not working as expected?
--
Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
or directory
Apparently, the nodes for the named pipes are not being created as they should.
Is this a bash problem, or something in devfs not working as expected?
That's a good question...
Has anybody found out what the standards conformant thing is for /dev/fd ?
presently we do only 0,1 2
On Tue, 11 Mar 2003 00:38:08 +0100, Poul-Henning Kamp [EMAIL PROTECTED] said:
Has anybody found out what the standards conformant thing is for /dev/fd ?
There is no standard, other than Tenth Edition and Plan 9. Most
programs which use it expect it to behave like one or the other.
-GAWollman
On Mon, 10 Mar 2003 18:47:15 -0500 (EST), Alien Space Bats attacked
and caused me to utter:
There is no standard, other than Tenth Edition and Plan 9. Most
programs which use it expect it to behave like one or the other.
s/one or the other/that/
-GAWollman
To Unsubscribe: send mail to
In message [EMAIL PROTECTED], Simon 'portlint
' Schubert writes:
These files, conventionally called /dev/fd/0, /dev/fd/1, /dev/fd/2,
and so on, refer to files accessible through file descriptors. If file
descriptor n is open, these two system calls have the same effect:
fd =
out with:
diff: /dev/fd/63: No such file or directory
diff: /dev/fd/62: No such file or directory
Apparently, the nodes for the named pipes are not being created as they
should.
Is this a bash problem, or something in devfs not working as expected?
That's a good question...
Has anybody found out
, or something in devfs not working as expected?
That's a good question...
Has anybody found out what the standards conformant thing is for /dev/fd ?
presently we do only 0,1 2, with the std{in,out,err} symlinks.
If we are required to do all filedescriptors, we should do so with
fdescfs
When I add a new slice or partition to a disk, the device files don't
automatically appear in /dev. If I reboot, it shows up, but having to
reboot twice just to add a filesystem to a running disk is absurd. How
do I make /dev automatically add these devices upon creation? Failing
that, how do I
In message [EMAIL PROTECTED], Darren Pilgrim writes:
When I add a new slice or partition to a disk, the device files don't
automatically appear in /dev. If I reboot, it shows up, but having to
reboot twice just to add a filesystem to a running disk is absurd. How
do I make /dev automatically add
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Darren Pilgrim writes:
When I add a new slice or partition to a disk, the device files don't
automatically appear in /dev. If I reboot, it shows up, but having to
reboot twice just to add a filesystem to a running disk is absurd. How
do I
In message [EMAIL PROTECTED], Darren Pilgrim writes:
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Darren Pilgrim writes:
When I add a new slice or partition to a disk, the device files don't
automatically appear in /dev. If I reboot, it shows up, but having to
reboot twice just to
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Darren Pilgrim writes:
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Darren Pilgrim writes:
When I add a new slice or partition to a disk, the device files don't
automatically appear in /dev. If I reboot, it shows up, but
On Sun, 16 Feb 2003 03:09:46 +0100
[EMAIL PROTECTED] wrote:
On the other hand shared libraries are needed (or a port that
supports linking bind statically...)
cd /usr/ports/net/bind[89]
make clean
make CFLAGS+=-static -DPORT_REPLACES_BASE_BIND8
make install
i don't like
On Fri, 14 Feb 2003 09:31:57 -0800
Gordon Tetlow [EMAIL PROTECTED] wrote:
On Tue, Feb 11, 2003 at 06:59:31PM +0100, Alexander Leidinger wrote:
Hi,
/etc/rc.d/named copies /dev with pax to the named chroot directory. This
is obviously wrong with devfs, isn't it?
You should read
On Tue, 11 Feb 2003 [EMAIL PROTECTED] wrote:
/etc/rc.d/named is quite bogus, especially when it comes to running bind
chrooted.
Correct. I'm working on an improved method of dealing with this.
E.g. /dev/null isn't needed by bind8 at all
Incorrect. /dev/null is needed for bind 8. /dev/null
On Sat, Feb 15, 2003 at 05:09:19PM -0800, Doug Barton wrote:
On Tue, 11 Feb 2003 [EMAIL PROTECTED] wrote:
/etc/rc.d/named is quite bogus, especially when it comes to running bind
chrooted.
Correct. I'm working on an improved method of dealing with this.
great!
E.g. /dev/null isn't
On Tue, Feb 11, 2003 at 06:59:31PM +0100, Alexander Leidinger wrote:
Hi,
/etc/rc.d/named copies /dev with pax to the named chroot directory. This
is obviously wrong with devfs, isn't it?
You should read the script a little closer. That code path is only taken
on NetBSD.
-gordon
msg52349
Hi,
/etc/rc.d/named copies /dev with pax to the named chroot directory. This
is obviously wrong with devfs, isn't it?
Bye,
Alexander.
--
Where do you think you're going today?
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518
On Tue, Feb 11, 2003 at 06:59:31PM +0100, Alexander Leidinger wrote:
Hi,
/etc/rc.d/named copies /dev with pax to the named chroot directory. This
is obviously wrong with devfs, isn't it?
/etc/rc.d/named is quite bogus, especially when it comes to running bind
chrooted. E.g. /dev/null isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2003-02-11 at 20:29:17 [EMAIL PROTECTED] wrote:
mafd E.g. /dev/null isn't needed by bind8 at all (also checked with
mafd ktrace), not sure about bind9 though as it uses daemon(3) which
mafd tries to open it.
On my 4.7-STABLE box, bind9 uses
database format. It means timezone code should be integrated
into kernel. And for which reason? Only to heal DEVFS timestamps? Mount
workaround looks more light-weighted.
Please re-read my earlier email on the topic.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
On Sat, Feb 08, 2003 at 09:01:20 +0100, [EMAIL PROTECTED] wrote:
I see no solving way until kernel will understand fully and can handle
timezone database format. It means timezone code should be integrated
into kernel. And for which reason? Only to heal DEVFS timestamps? Mount
workaround
On Sat, Feb 08, 2003 at 16:52:28 +1100, Bruce Evans wrote:
Obvious workaround: could DEVFS be mounted read-only initially and then
re-mounted as read-write after adjkerntz started, in the same manner as /
remounted read-write, i.e. with mount -u ?
No. devfs silently ignores MNT_RDONLY
On Thu, Feb 06, 2003 at 22:10:43 +1100, Bruce Evans wrote:
More precisely: some are mounted, but they are mounted read-only (modulo
the bug that adjkerntz is run a little after mounting filesystems read-write).
Obvious workaround: could DEVFS be mounted read-only initially and then
re
DEVFS be mounted read-only initially and then
re-mounted as read-write after adjkerntz started, in the same manner as /
remounted read-write, i.e. with mount -u ?
Can we stop considering workarounds, and instead work on solving
the problem please ?
--
Poul-Henning Kamp | UNIX since Zilog
into kernel. And for which reason? Only to heal DEVFS timestamps? Mount
workaround looks more light-weighted.
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
* De: Andrey A. Chernov [EMAIL PROTECTED] [ Data: 2003-02-07 ]
[ Subjecte: Re: Wrong date for DEVFS entries ]
On Sat, Feb 08, 2003 at 00:16:24 +0100, [EMAIL PROTECTED] wrote:
Can we stop considering workarounds, and instead work on solving
the problem please ?
I see no solving
1 - 100 of 573 matches
Mail list logo
