Hi everyone!

I'm writing a Debian GNU/Linux recovery script. It's primary goal is to fix as much system errors as possible if the system won't boot properly.

What I've already included:

• Complete reconfiguration using 'dpkg' (this will hopefully fix messed up permissions)
• Repair permissions of users' home directories using 'chmod'
• Clear /tmp, /var/tmp, APT cache, ~/.thums, ~/.thumbnails, KDE cache to free up disk space

However, some questions came up while working on it:
First, should it be run from single-user mode (init 1) or from a rescue CD?
Second, is there a safe way to run fsck on the root (/) filesystem if the system is in single-user mode?
And what other common problems can turn up with a Debian system which can be easily fixed from a script?

Thank you for your help in advance.

It's extremely difficult to anticipate all the problems you can run into. That's, of course, the first thing to consider when developing your recovery script.

Do you have a set of "known problems" you encounter repeatedly? Is that what your bullet point list is?

I recommend running it from a rescue CD. You can keep your recovery script directly on it.

You can remount / ro (read-only) in single-user mode, and then fsck it.

What other common problems? Who knows? To be frank, this is what proper root cause analysis is for.

1 members found this post helpful.

Thank you for your answer!

I don't really have a list of "known problems", I'd rather want to make this a script that fixes errors caused by eg. a failed update, user error (for example chmod -R 000 /*), or improper software installation.

I think your goal is a good one, but it sounds (to me) like what you're really interested in is a DR (disaster recovery) solution. To me, filesystem dumps or images are a better, cleaner approach. You recover from the dump / image, and everything's in precisely the state it was at the time it was taken.

2 members found this post helpful.

Well, anomie I know that backups are the most important parts of the recovery, but they require disk space and attention. One would run my program if all else fails and has no backups, so (s)he could give it a try and see if it recovers the system. I'd like to maximize the chance that it fixes the problem.

Before it gets to "before all else fails", check out http://relax-and-recover.org/

Peace.

Don't use bash for scripts, esp. not for something like this. Use Bourne Shell (sh).

I'd prefer Bourne Shell as well, but BASH has more advanced programming features (loop control, logical statements, switches, case-like statements, etc.).

If you need those, pick a real programming language. The difference is small and only few people know about it, so using bash scripts is confusing and errors are likely to happen.

Would love to hear the reasoning behind this. I use bash exclusively and have had zero trouble. Only trouble I have had I caused by not knowing enough, syntax errors and such.

Not even sure what you mean by this...

The Bash delta (ie. what you can do with Bash but not with Bourne) is small, much smaller than the Perl/Python/Ruby/etc. delta. I see little point to learn the extension of a glorified batch language when other languages are so much more powerful. The main advantage for Perl/Python/Ruby/etc. is the availability of huge library collections (CPAN: 124,000, PPI: 38,000, Gems: 60,000).

The small delta leaves at best a small window of usefulness, ie. only a very restricted area where bash scripts fit better than either Bourne or Perl/Python/Ruby/etc. Obviously I don't think that this window exists at all, ie. there is no program that couldn't be written better with either Bourne or Perl/Python/Ruby/etc.

The difference between Bourne and Bash is difficult to detect. That alone would prohibit use of Bash in any environment where you collaborate with others. My blind guess is that the majority of Bash scripts out there are in fact Bourne scripts with the wrong hashbang, because not even the author knows the difference. In fact, I've had a discussion like this one with a colleague in which he mixed up Bourne and Bash consistently.

The knowledge about the Bash delta is also obscure, which aggrevates the previous point. Knowledge about Perl/Python/Ruby/etc. is much more common than knowledge about the Bash delta, and knowledge about pure Bourne is probably even more widespread.

In any kind of heterogenous environment (ie. anything but pure Linux environments) Bash scripts are completely out of the question. (Ksh sadly is not, since it is Posix.) While Bash is probably available for most if not all Unixes, the hassle to install clean versions everywhere is just not worth it.

BTW, I don't use bash regularly, but the same is true for my favorite, Zsh. (Though a case could be made that Zsh would be less confusing on the name alone.)

1 members found this post helpful.

remember, using a (full) backup will allow to restore the full system, using any algorithm to select and save only a small part of the information will restrict you to restore only that part of the system. Any other kind of damage will remain unrecoverable.

Well, I tried to run this exact script with Bourne shell as an interpreter - lot's of errors came up and finally it failed. It included loops, if and case statements. So if sh failed with these - let's say essential - programming expressions, I guess Bourne Shell can only interpret the simplest batch files written in BASH.
Why isn't BASH a real programming language? It's true that it's a scripting language, but Perl, JavaScript, etc. are scripting ones as well.
I know that BASH doesn't have as many libraries as others and it isn't as powerful, but it fully suits my needs, and it's unnecessary to have loads of unused libs, functions, etc.
And one more advantage of BASH: it's found on nearly every Linux box, even the simplest ones. This is not true for Python, Ruby or Pearl.

Not sure what you are trying to say. There is of course an infinite number of Bash scripts that will not run in Bourne.

My point was that there is a huge number of simple scripts hashbanging Bash although they would run just as well in Bourne. Remember that this is only an argument about the confusion, ie. people are not even clear about the difference.

You already know that that is wrong, Bourne has loops and ifs of course. Also, what you call essential, I call tomato. Perl does not have a case keyword, Ruby does not have increment operators. I'm sure all the langauges we mention are turing-complete, so in a sense nothing essential is missing in any of them.

What I call the Bash Delta is also not necessarily about simple differences in syntax. If it can easily be translated from Bash to Bourne, then it's not part of that Bash Delta. That is not a trick, I'm just describing how to go about without Bash.

You mean they are interpreted? I don't see a problem with that, in a comparison a couple of years ago Perl beat C++ in terms of speed for most applications. OTOH, people have put much more brains into speeding up Perl vs. Bash, and I would guess that Bash programmer would exec more often (grep etc.).

No, Bash is just not as powerful as the other languages are. Stuff like inline regexes, OOP, reflection etc. are missing in Bash. Perl's hash structures alone would let me pick it over Bash every time.

Sure, these features may not be required for simple things, but my argument is that you can do most of these simple things in Bourne anyway. If it gets more complicated, you shouldn't pick something that carries you only a couple of baby steps ahead.

This is not necessarily about you. I used to program in C in my spare time (Motif even) for a couple of years, it was fun exactly because it was a puzzle; I still wouldn't pick C to start a new program. If you never use libraries, and won't ever use them in the future, this particular argument does not apply to you, but I still think it applies to Bash in general. In many cases, easy access to RDBMSs alone is reason to pick or drop a language, as is XML handling.

Yes, that particular argument does not apply to highly homogenous environment. From my experience in a heterogenous environment, Perl is more common than Bash however. (I was looking out for Bash because I prefer it very much over Bourne or Ksh as an interactive shell.)

On the other hand, the most common Linux shell might very well be Busybox, which runs Bourne, but not Bash. By using Bash, you give away too much while gaining little.

Hmm , sounds like you surely will cause more problems than can fix !
sometimes recovery scripts worth busting brain for , sometimes not.... if running server with alot of aliases, users , ISP config3 , cpanel , it simply aint worth !
best of it in my experience was to make daily snapshots using dd or mdadm raid in small sizes,, like / partition to have a decent 5 GB , /boot like 50 Megs and /var is the main problem , it is the place where using dd will result in copying alot of useless zeroes ! Another bad but good idea is to mount /var folders into separate folders like logs , www, mail , etc, into another small spaces to make dd faster and more useful , but it could run off available space quickly !

Repairing can consume time , it is nerve wrecking , and except servers , just for desktop PC it is simply not worth ! My desktop has a small SSD 60 gb drive , just clone it to some iso file onto a second 1 TB drive , and this is it , on weekly or monthly bases it is enough !any time can restore it using live cd !

i can show ya my server back-up script comprising main server , back up -server and client side , it is working great but in recovery terms it is a damn pain into the arse ! when sh..t happens it requires lot of work to restore !