Usually, if udev manages /dev , and dasd entries disappear from the directory, it means udev is unable to detect the partitions on the disks.
If the boot attempt comes up enough to open a shell prompt, first thing to check is "cat /proc/dasd/devices" to verify if the kernel device names are being matched to the expected device numbers. Doing a check with "cat /proc/partitions" can also show whether or not the needed partitions were detected. If everything looks ok, then using a rescue system and ensuring boot.udev is on (chkconfig boot.udev on) may work to clean up some device links. Or the mknod command can be used to manually create device nodes (I believe this still works on SLES-9 SP4 as udev is not yet in full control of all entries). If it seems to be a problem in detecting the partitions themselves, then examing the devices with dasdview (ex: dasdview -x -i -f /dev/dasde; dasdview -l -f /dev/dasde) and fdasd (fdasd -p /dev/dasde) from a working system may yield some clues about the type of formatting and partitioning that was being detected on the devices. The most common issue I've seen when reconfiguring dasd on SLES-9/SLES-10 is when the /etc/sysconfig/hardware/ files are edited with the expectation that it is all that is needed for the dasd list. In that case, the dasd configuration embedded in the initrd may be overlooked and cause confusion. - Mark Ver office: Building 710 / Room 2-RF-10 phone: (845) 435-7794 [tie 8 295-7794] ---------------------------------------------------------------------- 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
