While experimenting with editing video with Kino on 9.3, I moved some files and the machine froze. A reboot halted at the GRUB announcement. Rebooting into Installation -> Rescue Installed System said sda2 (root dir) and sda7 (a data dir) were corrupt, and suggested repairs, which I accepted. It also said that sda10 (another data dir) had an unknown filesystem on it. All dirs on the disk use Reiserfs. However, the app then hung at the stage where it attempts to mount fstab dirs. Accessing the system via Rescue System from the CD allowed me to mount all dirs except sda2 and sda10, and the data on them *appears* to be OK and accessible. Reiserfsck --check /dev/sda2 just gives up and says there must be bad blocks on the disk. At the minute the most likely option seems to be a reinstall on sda2 (assuming that the disk isn't totally kaputt), but that will lose my email and a couple of files I'd like to keep, including a small db I forgot to back up. Is there any option other than this nuclear one? Hoping someone can help ... Kevin Donnelly
Hi Kevin, On Wednesday 31 May 2006 14:31, Kevin Donnelly wrote:
While experimenting with editing video with Kino on 9.3, I moved some files and the machine froze.
What size were the files? What format(s)? From the desktop in Konqueror or from the command line? How long did you wait to see if the system would 'gather it's wits?' Were you able to reach a console? (Ctl+Alt+F1 to F6)? Did you check the kernel messages screen (Ctl+Alt+F10)?
A reboot halted at the GRUB announcement. Rebooting into Installation -> Rescue Installed System said sda2 (root dir) and sda7 (a data dir) were corrupt, and suggested repairs, which I accepted. It also said that sda10 (another data dir) had an unknown filesystem on it.
Just a comment:
All dirs on the disk use Reiserfs.
Try not to confuse "directories" with "partitions". Drives contain partitions which contain filesystems that are organized into directories which hold files. :-) (10 points will be deducted from your score if you slip and utter the word "folder".)
However, the app then hung at the stage where it attempts to mount fstab dirs.
Accessing the system via Rescue System from the CD allowed me to mount all
Keep a notepad at your desk so you can write down error messages when you can't copy/paste them into a text file. The actual messages convey a lot more information than imprecise 'paraphrased' descriptions. partitions
except sda2 and sda10, and the data on them *appears* to be OK
In other words, all partitions *but* sda2 and sda10 appear to be OK.
Reiserfsck --check /dev/sda2 just gives up and says there must be bad blocks on the disk.
Again, exact error messages would be preferable to paraphrased remarks. The fact that sda2 was already "repaired" (a few steps back) and still reads bad is not a good sign at all. Please tell me /home is on it's own partition? If not, this is the reason why organizing your system that way is a good idea. you can grab images of sda2 and sda10 *if* you've got space on another drive. dd if=/dev/sda2 of=/path/sda2.img noerror dd if=/dev/sda10 of=/path/sda10.img noerror Then you can try to repair/recover the originals while keeping the images as backups. Have you ruled out basic hardware problems like a marginal power supply or lower quality memory? When a system generally runs OK but suddenly 'stumbles' during high data transfer rates and/or high volume ram/swap utilization, two common causes are insufficient supply voltages and marginal memory. hth & regards, Carl
Hi Carl On Wednesday 31 May 2006 23:16, Carl Hartung wrote:
On Wednesday 31 May 2006 14:31, Kevin Donnelly wrote:
While experimenting with editing video with Kino on 9.3, I moved some files and the machine froze.
What size were the files? What format(s)? From the desktop in Konqueror or from the command line?
I was moving 1.6Gb of raw DV files via Konqueror from one location to another.
How long did you wait to see if the system would 'gather it's wits?'
Quite a while!
Were you able to reach a console? (Ctl+Alt+F1 to F6)? Did you check the kernel messages screen (Ctl+Alt+F10)?
No, couldn't reach any of them - the whole system had frozen.
A reboot halted at the GRUB announcement. Rebooting into Installation -> Rescue Installed System said sda2 (root dir) and sda7 (a data dir) were corrupt, and suggested repairs, which I accepted. It also said that sda10 (another data dir) had an unknown filesystem on it.
Just a comment:
All dirs on the disk use Reiserfs.
Try not to confuse "directories" with "partitions". Drives contain partitions which contain filesystems that are organized into directories which hold files. :-) (10 points will be deducted from your score if you slip and utter the word "folder".)
Yes, I meant to say partitions.
However, the app then hung at the stage where it attempts to mount fstab dirs.
Keep a notepad at your desk so you can write down error messages when you can't copy/paste them into a text file. The actual messages convey a lot more information than imprecise 'paraphrased' descriptions.
No, that's all it said. If you run Rescue Installed System on your own PC, you'll see it checks the partitions, then checks the fstab. With this, it says it has found x number of partitions, and then says it's attempting to mount them. I suspect it can't mount sda2, because it's so badly scrambled, and that's why it hangs.
Accessing the system via Rescue System from the CD allowed me to mount all
partitions
except sda2 and sda10, and the data on them *appears* to be OK
In other words, all partitions *but* sda2 and sda10 appear to be OK.
Yes.
Reiserfsck --check /dev/sda2 just gives up and says there must be bad blocks on the disk.
Again, exact error messages would be preferable to paraphrased remarks.
It's quite a long paragraph that says that it is unlikely that this disk is worth your time or money trying to repair, so just get a new one!
The fact that sda2 was already "repaired" (a few steps back) and still reads bad is not a good sign at all. Please tell me /home is on it's own partition? If not, this is the reason why organizing your system that way is a good idea.
I don't keep /home on a separate partition, because of possible issues with old config files when I upgrade. But I do keep all my data in /home/data, which is a symlink to another partition. Except for mail, which I should have symlinked in there, and of course the small database, which a separate /home wouldn't have dealt with anyway.
you can grab images of sda2 and sda10 *if* you've got space on another drive.
dd if=/dev/sda2 of=/path/sda2.img noerror dd if=/dev/sda10 of=/path/sda10.img noerror
Then you can try to repair/recover the originals while keeping the images as backups.
I may try that, though I think they're both so comprehensively trashed that it'll be pointless.
Have you ruled out basic hardware problems like a marginal power supply or lower quality memory? When a system generally runs OK but suddenly 'stumbles' during high data transfer rates and/or high volume ram/swap utilization, two common causes are insufficient supply voltages and marginal memory.
No, I think these are OK. It has pretty good Crucial memory, and a 450W power supply. I suspect I just have to bite the bullet and reinstall, but thanks anyway. Kevin -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Hi Kevin, On Thursday 01 June 2006 04:00, Kevin Donnelly wrote:
I was moving 1.6Gb of raw DV files via Konqueror from one location to another.
Note: The point of these questions is that it would be very helpful to find the underlying cause of this problem. I can copy a 4.3 GB contiguous file without my system locking up. Reliably. You should enjoy the same. Were you copying the data from one partition to another on the same drive? Or from one drive to another? When I move CD sized and larger files from one partition to another *on the same physical drive* it takes significantly longer than copying the data to another drive. Disk to disk transfer speeds benefit from concurrent reads and writes... one drive reads while the other writes. It's significantly faster. The workload (defined as 100% of the spindle revolutions and actuator steps) is distributed across the two drives. These benefits are missing during data transfers on the same physical drive.
How long did you wait to see if the system would 'gather it's wits?' Quite a while!
Too subjective... how about a rough time estimate, instead? In my experience, you can many times differentiate between a true "lock up" and a "busy system" in the following manner: Move the mouse. If it stays in the same spot but eventually "jumps" to the new location, there's a good chance the system is just "busy" (as in cases during very large file transfers.) In both cases, your keystrokes will appear to be ignored. In one case, they never 'play out' because the system is truly locked up. In the other, the keystrokes are buffered until sufficient resources become available to process them. Also, if you happen to start a very large file transfer when the system is already juggling 'find' and 'sort' during a filesystem indexing operation, you may find yourself waiting for the system to become responsive again for several minutes. Go make some coffee, take a little break and come back to try the mouse move again. I'm only 'hammering down' this point in exhaustive detail because I've helped many people get past the tendancy to expect too much from their system. I am *constantly* reminding my significant other that we're not attached to the net by fiber optics and we're not running mainframes! She has a very 'twitchy' reset button finger and is not a patient person, btw. I doubt you're in that league, but this possibility must be addressed if you want to avoid traumatic filesystem failures in the future.
Were you able to reach a console? (Ctl+Alt+F1 to F6)? Did you check the kernel messages screen (Ctl+Alt+F10)?
No, couldn't reach any of them - the whole system had frozen.
Per the above, keystrokes appear to be buffered for longer periods of time than pointer activity... move the mouse a short distance and observe it for at least a minute or two before you even think about a hard reset.
I don't keep /home on a separate partition, because of possible issues with old config files when I upgrade.
You might think about adopting my 'upgrade in stages' approach. Keep /home on a separate partition, install 'fresh' and use a temporary variation of your 'daily' username. For example, I now have carl93, carlh and carl10-1. Each user environment is 'native' and 'fresh'... not upgraded. 9.3 is my fallback Linux, 10.0 is my 'daily' workspace and 10.1 is in the 'pre-deployment & tweaking' phase. When 10.2 comes out, 9.3 will drop off, 10.0 will takes it's place as my fallback, 10.1 will become my 'daily' and 10.2 takes the 'pre-deployment & tweaking' slot. If this is too much for your tastes, keep a separate /home partition and *backup*... then rename (mv) your existing user directory, i.e. from /home/kev to /home/.kev before the upgrade. If the partition containing your core system takes a dive, your chances of losing data are significantly reduced.
But I do keep all my data in /home/data, which is a symlink to another partition. Except for mail, which I should have symlinked in there, and of course the small database, which a separate /home wouldn't have dealt with anyway.
I've been very lucky... knock knock... but I've also taken reasonable precautions. It only takes one incident of significant data loss to change your perspective. Designing a system to safely backup your data is much less of a chore than recovering that data.
... I think they're both so comprehensively trashed that it'll be pointless. ... I suspect I just have to bite the bullet and reinstall, but thanks anyway.
I concur with this assessment. I hope you can put some of these ideas or similar to good use when you install this time. regards, Carl -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-06-01 at 09:00 +0100, Kevin Donnelly wrote:
I suspect I just have to bite the bullet and reinstall, but thanks anyway.
Just make sure first that your HD is physically sound. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEfydItTMYHG2NR9URAhUqAJ9ZMsz/kd4eLpRj5lbXc1Evkl6iJwCfQVFq N7wRrmB9K7fzakIQKg2Gbfo= =iuWy -----END PGP SIGNATURE----- -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
participants (3)
-
Carl Hartung -
Carlos E. R. -
Kevin Donnelly