Yes the "/dev/dasdbm1" exist in the "/dev/" directory as well as dasdbn---->>
>From the Japanese post:
<Summary>
SUSE LINUX Enterprise Server which uses the DASD volume 65 or more 9 (below
SLES9) in the system, there is a problem which is not recognized of DASD volume
the partition after 65th PV of LVM2 (Physical Volume) as, (at Bugzilla Bug 9646
report). Especially when the database product and the like which needs the data
area of bulk on SLES9 it is used, note is necessary vis-a-vis this problem.
This in the technical flash we report concerning explanation of this problem
and evasion step.
<Explanation>
LVM2 is offered with SLES9 LVM which was offered before SLES8 (Logical Volume
Manager) as a succession. With LVM2 which is included in the GA edition of
SLES9, there is a bug that you cannot recognize the minor number of the device
node which is allotted to the disk partition which becomes the object of LVM2
normally in regard to those after the 256. The disk partition which concretely
is defined at pvcreate command as PV is registered to " /etc/lvm/.cache " as
valid_devices, but it originates in cannot registering normally in regard to
the partition after the minor number 256. To handle with LVM2 it is not
possible the partition which is not registered to /etc/lvm/.cache.
With zSeries per DASD volume it can allot 4 minor numbers, (volume in the whole
DASD 1, in the one for partition 3). Therefore, 65th DASD volume (/dev/dasdbm)
from the fact that it means that the partition which was drawn up has the minor
number after the 256 it cannot recognize with LVM2, when pvcreate command is
executed, error message below being output, it fails.
/dev/dasdbm1: Couldn't find device.
/dev/dasdbn1: Couldn't find device.
(Or less abbreviation)
<Evasion step>
This problem is corrected the Service Pack of SLES9 1 (SP1) being similar, (at
writing point in time as for SLES9 SP1 it is before GA, but when with SLES9 SP1
Release candidate 3 you verify with Makuhari test environment this problem
being corrected it is the verification being completed). Following, the disk
unit and the middleware which you use being supported with SLES9 SP1 in regard
to verification, please examine application in the brand of each product.
Furthermore, we introduce the evasion step in GA edition below, but please
examine with positioning as a provisional step to SP1 application to the last.
1. Adding the DASD partition after 257th to /etc/lvm/.cache by hand
(Example) /dev/dasdbm1 ~/dev/dasdbz1
persistent_filter_cache {
valid_devices= [
.......
“/dev/dasdbm1”,
“/dev/dasdbn1”,
“/dev/dasdbo1”,
“/dev/dasdbp1”,
“/dev/dasdbq1”,
“/dev/dasdbr1”,
“/dev/dasdbs1”,
“/dev/dasdbt1”,
“/dev/dasdbu1”,
“/dev/dasdbv1”,
“/dev/dasdbw1”,
“/dev/dasdbx1”,
“/dev/dasdby1”,
“/dev/dasdbz1”,
.......
]
}
-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina
Sent: Friday, October 20, 2006 8:18 AM
To: [email protected]
Subject: Re: PVCREATE Problem
Is there anything past dasdbm in the /dev directory? You may need to create
the device nodes, that info is in the device drivers manual.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
