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:
> > >
> > > https://www.freebsd.org/cgi/man.cgi?query=devfs.conf&
> 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&apropos=0&sektion=5&manpath=FreeBSD+12-current&arch=default&format=html
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&apropos=0&sektion=5&manpath=FreeBSD+12-current&arch=default&format=html
>
> I see in
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&apropos=0&sektion=5&manpath=FreeBSD+12-current&arch=default&format=html
I see in the man page:
FILES
/etc/devfs.conf
/usr/shar
On Wed, Feb 18, 2015 at 9:53 AM, Damjan Jovanovic 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!
___
sr/src/sys/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 v
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 db_trace_self_wrapper+0x2b/fr
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
___
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
vised the patch slightly:
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/lis
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
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
> >...
> >
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
f18efa472c1ab14999247c
> Author: Andriy Gapon
> Date: Sat 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
>
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 so
d like to commit the following 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.
Th
gt; Original Message
> Message-ID: <5150b598.7050...@freebsd.org>
> Date: Mon, 25 Mar 2013 22:37:44 +0200
> From: Andriy Gapon
> Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like
> zvol/pool/vms) good
>
>
> Can't believe t
25 Mar 2013 22:37:44 +0200
From: Andriy Gapon
Subject: Re: kern/122838: [devfs] devfs doesn'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 s
, but I shouldn't have to do
it, because the pattern is for /dev/ entries, not arbitrary files in the
filesystem namespace.
commit 7ce5e9ca5c107e2669f18efa472c1ab14999247c
Author: Andriy Gapon
Date: Sat Mar 23 10:29:39 2013 +0200
rc.subr: disabling globbing while processing devfs rul
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 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 han
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_destro
stable/8, then the patch I posted yesterday
>> > should be compilable.
>>
>> 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 stuf
ed 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.
pgpTYJZNBuDhX.pgp
Description: PGP signature
Hello Kostik,
> On Thu, Aug 04, 2011 at 11:41:39AM +0900, Kohji Okuno wrote:
>> Hello Kostik,
>>
>> From: Kostik Belousov
>> Subject: Re: Bug: devfs is sure to have the bug.
>> Date: Wed, 3 Aug 2011 16:50:44 +0300
>> > I think the problem you descri
On Thu, Aug 04, 2011 at 11:41:39AM +0900, Kohji Okuno wrote:
> Hello Kostik,
>
> From: Kostik Belousov
> 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.
>
Hello Kostik,
From: Kostik Belousov
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,
>>
>>
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.
> >
> >
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_populat
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
Hello,
> From: Kostik Belousov
> 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 :
>>> > On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
>>> >> Hello
Hello,
From: Kostik Belousov
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 :
>> > On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
>> >> Hello,
>> >>
>&
On Tue, Jul 12, 2011 at 03:02:44PM +0200, Attilio Rao wrote:
> 2011/7/12 Kostik Belousov :
> > 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 ope
2011/7/12 Kostik Belousov :
> 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.
>>
>&g
Hello,
From: Kostik Belousov
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
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_al
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
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
d?
The LORs are not specific 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) @ /
c/sys/kern/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 __lo
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?p
[ 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:
>
> [
etch=1203173+1206388+/usr/local/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
>
You would need to add the following to /etc/devfs.rules:
[devf
ser, I
> came across this posting to -questions:
>
>
> 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
> de
.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
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
-z ${jail_devfs} ] && jail_devfs="NO":
eval jail_fdescfs=\"\$jail_${_jail}_fdescfs\"
[ -z ${jail_fdescfs} ] && jail_fdescfs="NO"
:
if checkyesno jail_devfs ; then
mount -t devfs dev ${j
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
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 i
vfs="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
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 impo
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 sc
it goes?
Cheers.
Hi Mike, hi 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
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 c
ugh this only once
+ if [ -n "$devfs_rulesets_init" ]; then
+ debug "$_me: devfs rulesets already initialized"
+ return
+ fi
+
+ # Hide: Hide all devices
+ #
+ /sbin/devfs rule -s $rsHide delset
+ /sbi
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
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
&
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 the
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,
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 pro
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
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
On Mon, Jul 07, 2003 at 10:15:27AM -0700, walt wrote:
> 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
> >a
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 se
In message <[EMAIL PROTECTED]>, "Karel J. Bosschaart"
writes:
>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.
You can't. If
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
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
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 ?
There is no reason not to, but there seems, on the other hand, to
not be enough reason to do
then (although it gives 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 def
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
On Wed, 4 Jun 2003, Marc Olzheim wrote:
MO>Hi.
MO>
MO>I've seen the question once before, but it was not answered (on-list ?),
MO>so now that I run in on it, I'd like to know what to do:
MO>
MO>On FreeBSD 4.x, without devfs, the following worked:
MO>( echo foo | t
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:
> (
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 ) 3>&1
It should produce both "foo" and
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 standard
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
s 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
t;(cat file1) <(cat file2)
errors 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 go
< 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
< 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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe fre
: 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
the named pipes 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
[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
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
[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
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 automaticall
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
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
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
> >
>
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/nul
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 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
-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 /de
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
chro
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 fingerpr
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"
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
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 looks more light-weighted.
Please re-read my earlier email on the topic.
--
Poul-He
gt;
> 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 and doesn't support MNT_UPDATE.
Bruce
* 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
>
1 - 100 of 596 matches
Mail list logo
