Slashdot Mirror

← Back to Stories (view on slashdot.org)

System Recovery with Knoppix

Posted by michael on from the handy-stuff dept.

An anonymous reader writes "This article shows how to access a non-booting Linux system with a Knoppix CD, get read-write permissions on configuration files, create and manage partitions and filesystems, and copy files to various storage media and over the network. You can use Knoppix for hardware and system configuration detection and for creating and managing partitions and filesystems. You can do it all from Knoppix's excellent graphical utilities, or from the command line."

7 of 270 comments (clear)

  1. Oldie but a goodie by ozmanjusri · · Score: 5, Informative

    This one's been around for a while. It's a useful resource, but some of the more specialised distros are easier to use for rescue disks.
    http://www.frozentech.com/content/livecd.php has a good list of them.

    --
    "I've got more toys than Teruhisa Kitahara."
  2. Re:Yes, but.... by Anonymous Coward · · Score: 5, Informative

    For those not in the know, "Knoppix is a GNU/Linux distribution that boots and runs completely from CD." (Source: www.knoppix.net).

    So it is kind of hard for a Knoppix installation to become corrupt; worst case scenario is you just burn new copy of the Knoppix CD. :-) The parent comment is in fact funny (and quite so!), rather than insightful as it's currently moderated. ;-)

  3. Yes, you can: knx-hdinstall by RealProgrammer · · Score: 5, Informative

    "You can't install it to your hard drive."

    Yes, you can: knx-hdinstall.

    --
    sigs, as if you care.
  4. Re:Yes, but.... by the_shaitan · · Score: 5, Informative

    Umm... Knoppix can be installed on to the hard disk and many people actually do so because then they get a Debian-like OS on their hard-disk.

    Knoppix itself ships with a hard-disk install script. See this page for more info - http://www.knoppix.net/docs/index.php/HdInstallHow To

    Regards,
    The Shaitan

  5. One thing your missing.. by msimm · · Score: 5, Informative

    As a computer networking student I'm absolutely AMAZED this hasn't gotten more attention then it has.

    Under your MS stuff (I know, I know, but in industry it really is a necessary evil) you should definitely have a Windows Boot CD. And I don't mean a DOS floppy! Its basically a live, say Windows XP disk with preinstalled software (virus scan, adware removers, registry editors, complete networking setup). It really has all the tools you commonly use when fixing the obligatory windows box and probably a few you've never even known you'd need.

    I highly recommend you build one, and if the directions sound a little complicated, just take your time and reread them, there's about 3 step and none of the are actually complicated.

    The worst thing you can do is boot a infected PC from an infected hard drive, not to mention the trouble accessing NTFS with FULL read-write.

    --
    Quack, quack.
  6. First rate device detection by Anonymous Coward · · Score: 5, Informative

    Luckily I haven't had to use Knoppix to recover any crashed systems...

    However I did use it to tweak the device settings on my install of FreeBSD. Knoppix has always detected anything I threw at it, while FreeBSD isn't quite up to the same level (but getting better). So, I gave Knoppix a whirl and got enough driver info for the noname videocard that shipped in the used computer I was setting up as a server.

    Rock on Knoppix!

  7. Better safe than sorry by Deorus · · Score: 5, Informative

    First of all, there are a couple of basic steps people can take to ensure their systems are rescuable and secure regardless of any patches they have applied.

    • Make sure your root filesystem is as small as possible to minimize the chances of corruption there and that you can have it mounted read-only. This not only improves your security (since you can simply remove CAP_SYS_ADMIN from all your daemons and they won't be able to remount anything), but also makes it even harder to corrupt the root filesystem. Your user and group information files will need to be moved to /var and appropriate symbolic links created in /etc so that users can still change user and group passwords and you can create accounts without remounting the root filesystem read-write.
    • Never remove your legacy device inames from /dev, ever! Even if you use devfs or udev, a new /dev is mounted over the original one, so the legacy inames disappear magically from VFS. The legacy device inames may come in handy in a system recovery later. If you use devfs or udev, make sure your /dev filesystem is mounted with the noexec option enabled for security reasons.
    • Make sure your /var is always mounted noexec and nodev. If you use qmail, switch to Postfix (yes, I've done it, DJB is such a dumbass with his lack of respect for standard directory hierarchies).
    • Make sure your /tmp is not in your root filesystem. You can mount a tmpfs for your /tmp and point /usr/tmp, /var/tmp, and /anything-else/.../tmp to your /tmp with a symbolic link. If you do mount a tmpfs or any other kind of filesystem, make sure you do it with the noexec and nodev options enabled. If you can't or are not willing to use another filesystem for /tmp (tmpfs sometimes is too small for CVS, and you may not have enough space for a dedicated /tmp), use /var/tmp instead (assuming you've mounted /var according to my instructions above).
    • Grab a copy of the GNU fileutils from a mirror close to you, compile it statically, and install the resulting binaries in /sbin (not /bin). If anytime later something terrible happens to your libc, you can always make /sbin have precedence over /bin in your $PATH and use the static binaries in /sbin instead for recovery. Always remember to make add /sbin first in your $PATH if you ever upgrade your libc from the sources, especially if it is your first time doing so (believe me, everyone I know, including me, had problems with their first libc installations from the source). Doing this can save you from a lot of trouble.
    • Even when you know your kernel binary will boot perfectly (because perhaps you used the same configuration file to compile the same kervnel version), make a backup of your old kernel by renaming (not copying) it and specifying the new name in lilo.conf. LILO knows nothing about filesystems (never used grub, so I can't talk about it, but I suspect the same thing happens with it), so if your kernel, for some reason, gets fragmented in your filesystem, you will be in trouble to boot from it, since LILO assumes the kernel is never fragmented.

    Following above steps is usually enough to prevent rescue situations because the root filesystem is vital, so protecting it is the first line of defense, but if the worse comes to worst and you ever get into trouble, you must learn with the problem. If the kernel loads and init doesn't, it may be a libc problem. Try booting with init=/bin/sh, remount your filesystems read-write, examine the problem, umount them (or remount them read-write, when unmount is not possible), sync, reboot and watch the changes. If the kernel does not load, you may need a