Showing posts with label cd. Show all posts
Showing posts with label cd. Show all posts

Wednesday, October 15, 2008

Installing Darned Small Linux Onto Your Boot Drive

Hey there,

When you hear the "brand" name "Damn Small Linux" these days (note the title of this post has been altered slightly to try and be as non-confrontational as possible. We don't need or want any flack from oversensitive web-monitors, and we'll be damned if we won't do everything possible to stay under the radar ;), you generally think of a bootable USB-stick/flash-card installation, or something of that nature. Damn Small Linux (DSL, from here on out, since I can hear the damn hammer falling already ;) was put together, it seems, for just that specific purpose. It's DSL, which is, by definition pretty DS ;)

Today, we're going to walk though installing it on your bootable hard drive. Sure, sure, it defeats the principal of the whole thing, but you can always just slice up two tiny little partitions and have DSL as a backup for your other OS, which may or may not completely self-destruct at any moment. Plus, it's a great idea when all you've got to work with is an old machine that won't run anything else!

You can pick up the latest version of DSL from their main download site. I'd suggest sauntering over into the "current" directory and checking out the ISO's in there (4.2.5, I believe is the newest stable revision available as of this writing). You'll want to grab an ISO file, so you can burn a CD to boot and install from. Once you've done that, you’re good to go (we've just, in theory, skipped step 1. If there's overwhelming interest, we'll write up a post on burning a bootable ISO, but it probably wouldn't play out well since there are so many programs available to do this with. Googling "burn bootable iso YOUR_HARDWARE_OR_OS_OR_CDROM" should probably get you to a set of instructions that will make this part simple). Another important thing to note is that DSL does provide alternative Floppy Disk images, so (if your hardware's old enough, or you just can't boot from CD-ROM) you can go that route, too :)

So here we go, with step 1 (which is really step 2 ;)

1. Boot from your CDROM or floppy drive and begin a crippled-terminal session (same as a regular one after a full install, except you're limited in what you can do) and run the following to gain the required privileges in the system default shell, and get ready to chunk up your disk with "cfdisk":

host # sudo -s
host # cfdisk /dev/sda


We'll assume, for the purposes of this tutorial, that you can wipe out the whole disk, and lay it out as 2 or 3 new partitions. This way, you'll have /dev/sda1, /dev/sda2, etc and things won't get complicated. Obviously, when you do your own setup, things might be slightly different (/dev/hda or you're adding newer partitions and need to start with those - /dev/sda6, etc), but you should be able to apply these same principles all around; just to different HDD device names.

2. Create at least two partitions with "cfdisk," one for the main filesystem (type 83 for ext3) and one for swap (type 82 for standard Linux swap). We'll assume that partition sda1 is going to be your Linux OS partition and partition sda2 will be your swap partition.

3. Now we're going to reboot (after writing our changes to the partition table with "cfdisk") and start up another crippled-terminal session. To prepare for the DSL installation, we need to set up our swap area:

host # sudo -s
host # mkswap /dev/sda2
host # swapon /dev/sda2


4. Next, in the same crippled-terminal session, we'll run the following script:

Host # dsl-hdinstall

You will be prompted to provide the partition onto which you wish to install your DSL Operating System. In our case this would be sda1 (possibly /dev/sda1, etc).

Next, you'll be prompted about whether or not you want to allow multiple logons simultaneously. It's generally safe to say "yes" to this and, really, is a bad idea not to. If you end up in a situation where one session is hung, if you can't login and start another session, it will be a lot harder to kill the initial "hung" session.

Then, you'll be prompted as to whether you'd like to use ext3fs as your file system. Generally, this is what you want. But, since ext3fs makes use of advanced features like journaling, etc, you may want to choose ext2fs, instead, if your machine is older or is low on resources as it is.

Then, just to keep you in check, you'll get the "Windows Treatment." By which we mean, of course, that you'll be asked if you "really" want to do all this stuff (Technically, for it to be a textbook "Windows Treatment," it would have to ask you several more times ;).

The next thing you'll want to do is kick back while DSL loads and installs itself on your hard drive.

Then, this very same script (all-encompassing as it is) will ask you the standard question about which boot loader you would like to install (and where), if you want to install one at all. Generally, we'd pick grub on the MBR, but you can still use LILO and have either installed on a partition boot-block.

Finally, you'll be asked to reboot. Really, you'll be told to reboot. You don't have to, but if you don't, this has all been for nothing. Don't give up now! :)

5. When the script is all done and you're good to go, you'll want to remove the burned CD from your CD-ROM drive and reboot your machine, making sure that it gets booted from the DSL OS partition you just setup.

6. The last thing to do is fairly obvious, but we'll include it for completeness' sake. You'll need to create passwords for the users root and dsl (Actually the dsl password isn't all that obvious, because it generally doesn't exist on any other distro than DSL ;)

And you're all set!

For more reference on using "grub," see our previous post on using grub to change root’s password (which links to a few other posts) and, for help with “cfdisk”, check out “Part 4.0” of this Debian Installation Tutorial which includes lots of great examples and references to other sites (even for “fdisk” if you ever need to use that instead).

Have great Damned day ;)

Cheers,

, Mike




Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Wednesday, October 8, 2008

Puppy Linux Live Trumps LinuxDefender In More Ways Than One

Hey There,

More than a few people wrote in to let me know about other interesting "live" distro's of Linux after our post on using LinuxDefender Live CD to Fix NTFS problems ran. I've been a bit busy with my son, now that he's started school and isn't completely exhausted at the end of the day (like I always am ;), but I will post each and every comment I received (at least, with the consent of the commenter's) as soon as I can.

The one thing that blew my mind is that the download links for LinuxDefender Live don't even work any more (One thing you should understand about me is that I'm a pack-rat. If I like something, I make 15 copies of it and hide it in several different counties. My LinuxDefender Live CD was like gold). I knew they'd been swallowed up by BitDefender (or am I getting foggy and not remembering them always being under that umbrella? ;), but I had no idea that the entire project had been trashed. This is why I haven't included any links to the distro in this post, so far. For your amusement, here's the still-live page that has all the download links (On BitDefender's site, no less) you'll ever need. Unfortunately, none of them link to any available content. Check it out. Try and download LinuxDefender Live, I dare ya. Why that page hasn't been scrapped, I can't even begin to waste my time trying to understand ;)

In going over all the alternatives (including a very nice and mature Knoppix that now fully supports NTFS read/write), I settled on Puppy Linux. It seemed to have the best frugal-to-usable ratio out there. And, no surprise here, it's very easy to use. You can download your own copy from the Live-Puppy Download Site. It's completely free of charge (although I'm sure they wouldn't sneeze at a donation ;) and very easy to use.

Even more impressive are some of the little things that differ from my now-seemingly-ridiculous LinuxDefender CD. The Live Puppy OS has three main features that make me like it a lot (although these don't encompass them all):

1. It includes support for NTFS = I can fix my kid's computer and not have to reboot Windows for 17 hours just to reload the corrupted VGA driver.

2. It makes excellent use of RAM-loading the OS after boot from the CD = I don't feel like I'm using a read-only OS.

3. It can save to disk without destroying your resident OS = I can save my personalizations, which makes it feel even more natural. Of course, I can't go so far as to download and install packages (unless I've partitioned my disk in preparation, which defeats the purpose ;), but it's still nice to be able to save my little tweaks.

Considering that we've got the same issue to deal with that we did in our LinuxDefender Live post (like the SYSTEM file, in C:\WINNT\ is corrupted and you just need to be able to copy it off and replace it with SYSTEM.BAK), these are the same steps (but fewer) that we'd take to fix up our NTFS Windows box and make everything better:

1. Pop open the CD tray while the system is still powered on. If that doesn't work, power it down and use the pinhole-method (sticking a pin in the hole in the front of the CD-ROM drive to manually eject it). Place the Live-Puppy CD in there and close it back up. Then power up or restart your machine as your situation dictates.

2. However your system allows you to, push the correct button (f1 or maybe f10/f12) when you power up the machine so that you can get to the system settings and make sure that your CD-ROM drive is listed as a Boot Device and is in the Boot Sequence (preferably first) so that our CD will be able to boot the system from the CD-ROM drive.

3. Power on the machine and kick back. Live Puppy is pretty cool to watch if you've never seen it before. It should work without issue on your box. I've heard reports that it even works on a lot of funky custom AlienWare computers!

4. Once you're finished booting up and have either your desktop GUI or the CLI up and running, just mount the Windows hard drive like you'd mount any Linux hard drive, on a temporary mount point. If you prefer to use the GUI, you can mount the disk just like in Windows; no issues!

5. Skipping about 5 steps from the LinuxDefender Live fiasco, you can mount your Windows drive and access it like any regular Linux drive. Again, be sure to pass the options to mount (man mount) to indicate that you want to mount the disk read/write as NTFS. I'm incredibly paranoid, so I just cd directly into the WINNT directory (in this instance), copy off the bad SYSTEM file, copy the SYSTEM.BAK file to SYSTEM, cd back to where I was and umount. Actually, if I was really bad, I'd just use absolute path names ;)

6. Now, you just exit or reboot and remove the Live-Puppy CD (or vice versa). Windows should come right up and run as poorly as it always has ;)

I can't say enough about this distro. Check out Live-Puppy CD for free!. Even if you can't stand "real" live puppies, you're gonna love this one :)

Next up in our "avoiding Windows support" series: How to disappear in the jungles of uncharted Africa ;)

Cheers,

, Mike




Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Thursday, February 28, 2008

Finding and Reading Files In The Shell When Your System Is Hung

Howdy,

Today we're going to look at a situation that occurs probably more often than it should ;) If you've done your fair share of system administration on Linux or Unix, you've probably run into a predicament where you got paged, called, etc, to look at a machine that was hanging on the brink, only to find that (asssuming you could log in at all) it was so completely trashed that it couldn't even muster up the strength to run the simple system commands you needed to diagnose the problem before just giving up and rebooting.

Typical errors you'd get at the command line, in this sort of situation, would be similar to:

host # ls /tmp
Insufficient Memory!


or

host # cat file
Cannot fork new process!


Basically, you're stuck in a situation where you can't do anything that relies on executing anything other than the login shell that you're lucky you got in the first place ;)

The good news is that you can, quite possibly, get as much information as you need before rebooting by simply using your shell and it's built-ins. All of these examples should work for sh, ksh, bash, etc (Possibly not in csh, but, hopefully that's not your system default root shell). If you have a good idea what's wrong before your machine goes down entirely, they can even help you decide what you want to do before you boot the system back up (Check out this post for some simple tricks to figure out what commands are available to you in Solaris' PROM).

Here are the things I try to do when I find myself in that sort of situation (in no order of importance ;)

1. Move around the filesystem.

Luckily, the "cd" and "pwd" commands are built into the shell, so you can always move around your filesystem (even if you are, figuratively, in the dark) and get to the hot spots you want to check. For instance:

host # cd /var/log

will work just fine. This is the most obvious thing you can do, but cd (on its own) depends on you to know where you're going. You can't cd to a directory that doesn't exist even when things are up and running perfectly ;)

If you happen to get lost, you can figure out where you are, using the built-in "pwd," like so:

host # pwd
/var/log


2. Take a look at the contents of your filesystem.

This is actually pretty obvious, as well, once you realize how to do it. You won't be able to use "ls" any more, since that is a command that the shell invokes outside of itself, but you can always use the built-in "echo" command, like so:

host # echo *
bin opt sbin usr tmp var


Note that this output won't usually be so pretty. If there are 50 files and/or directories in the directory you're in, you'll just get 50 filenames in a row on one line. But, it's better than nothing :)

3. Capture the contents of critical files that can help you troubleshoot and/or find your root cause so this won't ever happen again (hopefully).

This last one is slightly less obvious, but can be done in a variety of ways. The first two ways are messy, but they work. Simply read your file as though you were sourcing it, using either the "source" or dot "." built-ins. The reason I don't prefer these two methods is that your screen fills up with a lot of garbage and you may hang your system by sourcing the contents of a file that contains executable statements or commands. For our example here, we'll assume a file named BOB with one line in it that says "hi":

host # source ./BOB
-bash: hi: command not found


or

host # . ./BOB
-bash: hi: command not found


You've gotten your output, but you can see where the potential problem would lie. What if "hi" was a command and your "source" directive tried to run it on your already half-dead machine? It might put it all the way down right then and there.

In these instances, I think output redirection is your best bet. You can read the contents of a file by simply executing a new file descriptor and reading from that with "echo." You can use pretty much any number that works (although, try to stay away from 0, 1 and 2 as these are your system's STDIN, STDOUT and STDERR file descriptors), you won't have to read your file through the clutter of a bunch of error messages and you will be insulating yourself from accidentally executing any commands. For instance, the following would get you much better results:

host # exec 7<BOB <--- Execute new file descriptor 7 and redirect the output of your BOB file to it.
host # while read -u7 line; do echo $line; done <--- Then, just read from the file descriptor.
hi

And that's about it. If you use all 3 of these methods in whatever combinations are necessary, you should be able to collect most of the information you need to assess your situation and/or provide root cause.

For one last example that uses all 3, this is how I would go about getting the contents of my /var/log/syslog file (I'll shorten the output to only include the relevant stuff) - Note that I'm also doing the syslog reads in a command line "for loop" because I want to get all the information I can with as little typing as possible:

host # pwd
/home/mydirectory
host # cd /var/log
host # echo *
sysylog syslog.1 syslog.2
host # for x in syslog.2 syslog.1 syslog; do exec 7<$x;while read -u7 line;do echo $line;done;done
blah....
<--- All of the sylog files' output. Notice that I did them in reverse, so that the output would be from oldest to newest. It's also a good idea (if possible) to either log your terminal session or set your terminal client's buffer to a very large number so that you can cut and paste this output into your desktop editor.

Hope this helps you out :)

Best wishes,


, Mike