On 2/23/10 9:05 AM, "van Sleeuwen, Berry" <berry.vansleeu...@atosorigin.com> wrote:
> Actually, different LPAR but the same CPU, same DASD box, same DASD > devices, same minidiskextents, same minidisks. So other than the LPAR-ID > for this VM it should be identical. I don't know for sure is the by-uuid > and/or by-id would be the same between the two LPARs. There are a bunch of components that go into the id; don't remember whether LPARid is one of them, but it would make sense since this has to work on bare metal too. That said... > Indeed, the > by-path is the same. I would also expect the dasdxx to be the same. > Meaning, dev 200 is dasda, 201 is dasdb and so on. I've never found this to be reliable with SLES 9. 10 and higher mostly get it right, but as Rick commented, udev has come a long way since then. > When I look in the /dev/disk/by-path it links to the /dev/dasdxx > devices. So in that case once again, if /dev/dasde1 is not available, > how can /dev/disk/by-path find it's volumes? In fact, listing the > directory (yes we DDR'ed the / disk before fixing the errors) I can't > find neither /dev/dasde1 nor /dev/disk/by-path/ccw-0.0.0204*. And > /dev/dasdkk1 doesn't exist, so ..by-path/ccw-0.0.0328p1 shows a broken > link. Hmm. That somehow seems backwards, IMHO. I only have one SLES 9 system left and it has the links the other way (dasdxx --> by path), but I could have done something weird to that system (it's a dev box). I believe one of the German IBMers commented that there are races in the udev code; possibly this is one of them? ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
