It wasn't quite the blue screen of death. The system wanted me to fix some errors on the disk partition manually. I was uncomfortable. Just two weeks earlier,
the same thing had happened. Thejsck-y command had fixed all the errors! At the end, the only visible directory was lost+jound.

Even if I booted from another partition, I couldn't mount the partition and take a back-up till I cleaned up the partition withjsck. I had already changed the SATA data cable on the previous occasion, which seemed to have fixed the problem. At the suggestion of the hardware supplier, I changed the power cable as well. The system seemed more stable now. It was no longer grinding to a near halt with a log reporting: "ata4: hard resetting link". However, it was too soon to rejoice.

I finally gave in and ranjsck. It cleaned up quite a few files/directories. It booted with errors and X wouldn't run. It was just the system partition with nothing more than the Fedora 9 installation. I had added a fair number of additional packages. It probably would have been faster to just reformat the partition and reinstall the as. This time, I had taken the precaution of caching the downloaded RPMs on a different partition! So, the 24-hour download time would not be needed for the updates and the additional packages.

Name: Automate system recovery by writing s321.jpg Views: 50 Size: 39.9 KB

However, it seemed that this was an interesting problem. Could I recover a system which was so badly trashed? Based on the problems noticed, I used rpm-V on some packages and found that some libraries were missing. Some packages were trying to access information beyond the partition. To make matters worse, I had been in the middle of an update (to which my wife would say When are you not The first step was to at least measure the scope of the problem. I took a list of all the packages installed:

I wasn't about to manually verify each one of the 1,500 or so packages! So, a small Python script would be useful It was a relief to know that only about 400 packages were in a damaged state! Even this was too large a number to handle manually. Surprisingly, there were some version issues. This turned out to be because there were multiple entries for some packages, thanks to the failed update.