On Mon, 2005-02-14 at 22:10 +0100, Duncan Lithgow wrote: > > /mnt/sysimage does not exist because it was not created. Rescue did not > > know what information to use and since it did not find the system it > > halted before creating the mount point > I thought that might be why > > > You will need to know which partition contains /etc (the one you used > > as / ). > > to find that out, when in rescue mode, first run > > "fdisk -l /devb/hdX" (where hdX is the drive containing your > > installation) > That went fine. > > > Then you can do the following steps to get fstab back > > 1. mkdir /mnt/sysimage > > 2. mount /dev/hdX /mnt/sysimage > > 3. ls /mnt/sysimage (to verify you have the proper partition mounted) > > 4. cd /mnt/sysimage/etc > > 5. mv fstab~ fstab > > (or use cp to make sure you still have the backup) > > then you can do what ever you needed to do to edit it and make it > > proper. > That went fine too. I have now copied the fstab~ file to the fstab > file. That should have got me back to where I started - a full /home > directory but basically a working system. (no, i didn't use mv instead > of cp last time) > > BUT: > When I then reboot it goes quite a long way through, including the > little graphical progress bar... Then: > > "GDM could not write a new authorisation entry to disk. Possible out > of diskspace. Error: No space left on device." > > So I shut down, on the way down I noticed that "halt" and "kill" fail > on HAL, SMB and NMB - does that tell us anything? > > Restart in single user mode and go looking for that fstab file. Yup, > it's there and looks like it used to - so whaddup wi dat? > You appear to indeed be out of space. Find something that should not be there and delete it to clear out space so the system can write the needed temporary files. BTW, this is the reason many of us still use several partitions instead of one big one. If the system cannot write temp files it just dies, and cannot be rebooted until space is made available. /var/log and /tmp are 2 very dynamic areas that often can fill up extra space. But in your case, it is likely the data that was copied over when trying to move stuff to another partition. Use df to see what space is available, then du to see what parts of the directory tree are overloaded. It should not take a lot of space to allow rebooting but probably a lot of careful pruning of the junk to clean up. BTW, congratulations on encountering the "fumble fingers of the administrator" that gets us all in trouble at one time or another, and surviving. At least you did not (yet) get bit by the "rm -rf" bug (er... error) that wipes out an entire system. You can count your blessings there. ;-)
