X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C76B14.AFC9146B@onstor-exch02.onstor.net>; Tue, 20 Mar 2007 10:24:59 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C76B14.AFC9146B"
Content-class: urn:content-classes:message
Subject: RE: No /dev/bpf files on 2240 system running 2.2.1.0 - case 4472
Date: Tue, 20 Mar 2007 10:24:59 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0A9172@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: No /dev/bpf files on 2240 system running 2.2.1.0 - case 4472
Thread-Index: Acdq+spRYGGcnRjzSzur+H8zaSYjtgAAQg8UAAUWXT0=
References: <200703201419.l2KEJX610049@mailhost-rtp.css.glasshouse.com> <BB375AF679D4A34E9CA8DFA650E2B04E02BFF5F2@onstor-exch02.onstor.net>
From: "Larry Scheer" <larry.scheer@onstor.com>
To: "Carlos Mora" <carlos.mora@onstor.com>,
	"Alan Cooke (Glasshouse)" <acooke@css.glasshouse.com>,
	"dl-cstech" <dl-cstech@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76B14.AFC9146B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You can add a device that way but the device will not be there after a =
re-boot. You cannot permanently add devices to the primary flash because =
/dev is remounted as a ramfs at boot time and it cannot be unmounted. =
The /dev directory on the flash will not be updated the device you =
create exists only in memory.

To permanently add new devices or recreate missing devices you should =
run "MKDEV all" on the secondary flash and then make it the primary =
flash.

Example assuming /dev/wd1 is secondary flash

mount /dev/wd1a /mnt
cd /mnt/dev
./MKDEV all

Then a reboot -s is needed and the same thing should be done to the =
other flash if it is missing devices.

Of course I am not taking into consideration all the details of what =
version of the system is installed on the secondary flash and all of the =
issues getting a system switched over the secondary flash. This should =
be factored into the steps of repairing /dev in the field.

One of the dangers of upgrading the primary flash is devices cannot be =
added or updated. This is one of the main reasons engineering recommends =
an upgrade to the secondary flash as the supported workdflow. The =
upgrade program that ships with 2.2.1 takes this issue of missing =
devices into account and warns the user if ./MKDEV needs to be done and =
an upgrade is being done to the primary flash.


Larry Scheer


-----Original Message-----
From: Carlos Mora
Sent: Tue 3/20/2007 7:33 AM
To: Alan Cooke (Glasshouse); dl-cstech
Cc: Carlos Mora
Subject: RE: No /dev/bpf files on 2240 system running 2.2.1.0 - case =
4472
=20
No idea why they are not there, but they can be recreated if we need the =
/dev/bpf0

mount -uw /
mknod /dev/bpf0 c 12 0

then try the tcpdump again.

Carlos

--
Carlos Mora
carlos.mora@onstor.com
ONStor, Inc.
Sr. Technical Support Engineer
(408)802-5602



-----Original Message-----
From: Alan Cooke (Glasshouse)
Sent: Tue 3/20/2007 10:19 AM
To: dl-cstech
Subject: No /dev/bpf files on 2240 system running 2.2.1.0 - case 4472
=20
Hi All,

Have a customer, WCC, case 4472, where we want to run a tcpdump on their =
system in order to investigate an intermittent loss of access to their =
volumes. The O/S is 2.2.1.0.

When it is run

wccfiler2# tcpdump -i sc1 -vvv -w /tmp/testdump=20
tcpdump: /dev/bpf0: No such file or directory

=20

When the system was looked at there were no /deb/bpf* devices there.

On all the other systems I have looked at there is /dev/bpf0 .. =
/dev/bpf9=20

=20

Anyone got any ideas why these files aren't there?

This customer is not likely to go tinkering around so I think it is =
unlikely they have deleted them though possible of course.

Could they have not got created when the system kernel was built?

=20

Now they are gone should we recreate them? I cannot remember the syntax =
for this.

Or should the O/S be re-installed and if it is are these devices likely =
to be created?

=20

Any info appreciated.

=20

Thanks . Alan.




------_=_NextPart_001_01C76B14.AFC9146B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: No /dev/bpf files on 2240 system running 2.2.1.0 - case =
4472</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>You can add a device that way but the device will not =
be there after a re-boot. You cannot permanently add devices to the =
primary flash because /dev is remounted as a ramfs at boot time and it =
cannot be unmounted. The /dev directory on the flash will not be updated =
the device you create exists only in memory.<BR>
<BR>
To permanently add new devices or recreate missing devices you should =
run &quot;MKDEV all&quot; on the secondary flash and then make it the =
primary flash.<BR>
<BR>
Example assuming /dev/wd1 is secondary flash<BR>
<BR>
mount /dev/wd1a /mnt<BR>
cd /mnt/dev<BR>
./MKDEV all<BR>
<BR>
Then a reboot -s is needed and the same thing should be done to the =
other flash if it is missing devices.<BR>
<BR>
Of course I am not taking into consideration all the details of what =
version of the system is installed on the secondary flash and all of the =
issues getting a system switched over the secondary flash. This should =
be factored into the steps of repairing /dev in the field.<BR>
<BR>
One of the dangers of upgrading the primary flash is devices cannot be =
added or updated. This is one of the main reasons engineering recommends =
an upgrade to the secondary flash as the supported workdflow. The =
upgrade program that ships with 2.2.1 takes this issue of missing =
devices into account and warns the user if ./MKDEV needs to be done and =
an upgrade is being done to the primary flash.<BR>
<BR>
<BR>
Larry Scheer<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Carlos Mora<BR>
Sent: Tue 3/20/2007 7:33 AM<BR>
To: Alan Cooke (Glasshouse); dl-cstech<BR>
Cc: Carlos Mora<BR>
Subject: RE: No /dev/bpf files on 2240 system running 2.2.1.0 - case =
4472<BR>
<BR>
No idea why they are not there, but they can be recreated if we need the =
/dev/bpf0<BR>
<BR>
mount -uw /<BR>
mknod /dev/bpf0 c 12 0<BR>
<BR>
then try the tcpdump again.<BR>
<BR>
Carlos<BR>
<BR>
--<BR>
Carlos Mora<BR>
carlos.mora@onstor.com<BR>
ONStor, Inc.<BR>
Sr. Technical Support Engineer<BR>
(408)802-5602<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Alan Cooke (Glasshouse)<BR>
Sent: Tue 3/20/2007 10:19 AM<BR>
To: dl-cstech<BR>
Subject: No /dev/bpf files on 2240 system running 2.2.1.0 - case =
4472<BR>
<BR>
Hi All,<BR>
<BR>
Have a customer, WCC, case 4472, where we want to run a tcpdump on their =
system in order to investigate an intermittent loss of access to their =
volumes. The O/S is 2.2.1.0.<BR>
<BR>
When it is run<BR>
<BR>
wccfiler2# tcpdump -i sc1 -vvv -w /tmp/testdump<BR>
tcpdump: /dev/bpf0: No such file or directory<BR>
<BR>
<BR>
<BR>
When the system was looked at there were no /deb/bpf* devices there.<BR>
<BR>
On all the other systems I have looked at there is /dev/bpf0 .. =
/dev/bpf9<BR>
<BR>
<BR>
<BR>
Anyone got any ideas why these files aren't there?<BR>
<BR>
This customer is not likely to go tinkering around so I think it is =
unlikely they have deleted them though possible of course.<BR>
<BR>
Could they have not got created when the system kernel was built?<BR>
<BR>
<BR>
<BR>
Now they are gone should we recreate them? I cannot remember the syntax =
for this.<BR>
<BR>
Or should the O/S be re-installed and if it is are these devices likely =
to be created?<BR>
<BR>
<BR>
<BR>
Any info appreciated.<BR>
<BR>
<BR>
<BR>
Thanks . Alan.<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C76B14.AFC9146B--
