SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I mean, like, preventing crashes/misbehavior before updates. Something like backup tools/scripts. I would say something like Windows's system restore. I am asking this because I am trying to use Slackware as my main desktop for the first time ever and, since I don't know much, I am afraid of breaking my system or having it acting weird (like this) after so many hours spent configuring it the way I want.
For the "saved configuration" part of Windows System Restore, know that your system configuration files are saved mostly in /etc, sometimes in /usr/etc and /usr/local/etc as well depending on how you update. Per-user settings are stored in the home directories, usually in folders that start with a dot, such as .kde or .openoffice.org. These are shown by the `ls -a` command.
To backup, you can use tar, maybe use getfacl to back up ACLs separately (if you use ACLs). If you're using XFS as your filesystem, xfsdump works much better than tar.
If you have to absolutely wind everything back to a certain point, though, you might consider using a filesystem that supports snapshots, such as btrfs or NILFS2. Keep in mind that btrfs is a moving target and NILFS2 lacks fsck: A healthy backup regimen is helpful when using both filesystems. Both filesystems have learning curves associated with them, but at the end of the day, any filesystem you use will have a learning curve.
I use a 50/50 approach to updates. If everything is on fire after 4 of 12 updates, and each one is getting harder and requires more and more reading, I'm going to resort to backup. If everything is on fire after 9 of 12 updates, I'll probably update my way through it, apply updates 13-16 that always seem to be required, and do another backup once everything is *perfect*. Keep in mind that I update a bit using source code.
Reports vary. On one hand, the btrfs developers classify the filesystem layout as stable, but the code always improves, and it's best to keep up using the latest kernel. On the other hand, at least SuSE was considering it for a default file system. In playing with it, I'm almost certain that you'd be better off using it in a redundant RAID configuration, so that btrfs can compare both sides of the mirror for data/checksum errors. [At last check, the fsck tool was not 100% foolproof.] IOW, it helps to have two or more hard drives in your PC, and let btrfs use a partition off of each one for a filesystem.
btrfs not much harder overall than some other filesystems, but it requires more reading up front--mostly for the "btrfs" command--and the handling of subvolumes means making more mistakes up front as well.
...and you can start deciding whether it's just what you're seeking or simply too much work.
Note that, theoretically, you can do snapshots with LVM for any filesystem, and the RAID stuff I've described can be done using mdadm or LVM; so this stuff isn't exclusive to btrfs. However, LVM snapshots seem like a crude hack compared to btrfs snapshots...or at least my attempt was an exercise in frustration whose conclusion was "I did that much work and reading for that?!?"
No matter which way you go, just consider "Backups! Backups! Backups!" to be your mantra. A full install of Slackware should back up to a 16 MB USB stick, and those are anywhere from $7 to $14 in my local stores. If you have extra hard drives, you can reserve space for those "in-between" backups on much faster storage.
On Windows, System Restore can be used in any number of ways. I've even seen it used because it's faster than a virus scanner for undoing virus damage: The only problem is that it doesn't necessarily do so, maybe get rid of it, maybe hide it, maybe include a virus in the restore point. There are times when System Restore rollbacks can imperfect and introduce glitches, and it's not always fun to deal with Windows Registry issues. I hope that even on Windows, you practice "Backups! Backups! Backups!" for those situations that System Restore doesn't quite fix.
This is probably overkill, but I used to have multiple boot options like this.
1. ubuntu with clonezilla installed for creating and unpacking backups
2. linux distro of the day...
3. same linux distro for testing and breaking...
4. another linux distro?
4. various linux livecd's... (forgot how I did this, but was able to with grub2, twas useful)
I would keep all data worth saving (music, documents) in a seperate partition. If it was worth backing up, it went on a flash drive.
Before I did much work with my linux distro of the day, I would back up that partition, and image it to the testing partition. I would try out what I wanted to do there, if it worked, great, if not, reboot, re-image and try again. I want to say it took only about 10-15 minutes to backup and image as such. This was a while ago, back when grub2 first came out, my memory isn't all that great.
Nowadays, I just take notes on how to do the install quickly and what programs i need to install afterwards. That text file goes on a flash drive, and when I really break stuff, I get more practice reinstalling.
In my personal opinion, the best way to learn how to work on something and fix it, is to break it, and then repair it. Backup all important docs and such, keep a few livecd's handy in case of emergencies, and go play.
Goes back to my first reply. If by "they," you mean someone else, reference a backup of home directories. If by they, you mean "you," you can reference either a backup of /etc or a full backup. If you're just upgrading binary packages, you have to re-upgrade back to the older packages. Sometimes, you can get away with, say, upgrading prerequisite libraries in order to upgrade a program, then the program is a dud and has to be backleveled. Sometimes you have to re-upgrade back.
You can look for fancy backup tools, and perhaps somebody knows of one here. However, if it comes down to a data partition and I can make a disaster mistake at any time and need to go back, I deploy a NILFS2 partition and keep regular backups of it (for lack of fsck). It keeps checkpoints on a per-synchronous-write basis, which you can change to snapshots at any time with the chcp command. Old checkpoints are deleted over time. Any snapshot can be mounted read-only so I can get that last bit of correct data off of it. The main tools to learn are lscp, chcp, and rmcp, and they're fairly similar. NILFS2 got the EXPERIMENTAL tag removed from it recently in the kernel config, but your mileage may vary nonetheless.
Always keep an up to date backup of at least /etc and /home, but preferably everything if you have the space. After that, only download/build/install software in the package format that Slackware understands (like from Slackbuilds.org). If you do this then the chances are close to zero that a software installation/removal will trigger a need to reinstall Slackware. I can only remember one official package update that was built improperly, but it just installed some files into /tmp instead of the correct directory (I was a couple versions behind the current Slackware and Pat still released a fix within 24 hours).
When you make changes to configuration a file, just make a backup copy before editing the file.