On Friday 24 December 2010 7:44 am, Jon Peatfield wrote: > On Thu, 23 Dec 2010, Larry Linder wrote: > > During the Boot process the files in /etc contain init files such as > > "fstab" file system table. If a disk listed in this file is not > > available it drops you to run level 1. You used to be able to modify > > the init data files used during boot. Enter the root "passwd", modify > > files, save and reboot. Now when you enter your root "passwd" you get > > two notices and it fails. At this point not even the rescue stuff works. > > To demo problem - load SL 5.5 on a disk and load your apps on a second > > disk. Once it is up and running shut it down, remove the data connection > > to the second disk. On boot up it fails and drops you to a run level of > > 1. At this point you are done. This only happens on SL systems. SUSE > > and others work fine. > > I'm not sure if this is a troll. > > It seems to work for me. Disks die and we have had our share of them. > When a non-boot disk dies the boot fails to mount the fs and we end up > (after a prompt for the root pw) in a shell where we can fix fstab etc. That is the way it always had worked for the last 20 years.
> Note: apart from /boot/ we pretty much use LVM for all fs these days. Plan to try it when new system is built and SL 6 is ready. > If recovery from a failed 'data disk' didn't work there would be many more > people complaining. Maybe your setup is unusual in some way. I can reproduce the problem in at least two systems running SL5.6 one a 32 bit system with a large number of SCSI disks and a 64 bit MATX with 4 SATA disks. Same problem. > Booting from the install media should allow access to all the file-systems > as long as the kernel support is present. Again it all seems to work as > expected for me. A new install always works. > -- Jon The problem with setting user to root must have crept in sometime after SL 4 and SL 5.2. All other systems in shop are SL 5.6 both 32 and 64 bit and they do the same thing. Its not unique to hardware.
