Using LinuxDefender Live To Rescue Your Windows NTFS Drive

Hey There,

Did I actually mention Windows and NTFS in the title of this post? It's a good thing I managed to squeeze a little "Linux" in there or I'd commit myself to the nearest convalescent home immediately ;) Actually, though, if the title is a bit off-putting, this post is all about freeware Linux and how to use it to fix NTFS partitions if you need to. Therefore, this post can be reduced to the following rough verbal equation: "You can use Linux to fix Windows" + "A Fixed Windows Box Equals Happy Windows Users" = "Linux is fantastic and makes it easy for you to fix your loved ones' computers when they're crashed and blue-screening, so they'll be able to leave you alone again as soon as possible ;)"

LinuxDefender Live has been around for a long time, and I do have my own set of duplicate boot CD's that I keep handy just in case my family's Windows box can't find the SYSTEM file and insists on a re-install (which, and this is probably true for everyone, just will not do... too much important stuff on the hard drive and no backups of any kind). For those of you who've never used LDL, it's a special distribution of the Knoppix Linux distro which was made specifically to run off of CD. The idea was, anywhere you went that had a PC, you could probably boot up a working Linux system and access the internet (or the information you carry around with you on a USB stick or some other portable HDD). Knoppix is an excellent solution that does what it advertises, and is actually still good enough to allow you to fix FAT filesystems and many other FS types. It's really the ideal combination of on-the-go functionality and miracle-OS-cure in one.

LinuxDefender Live steps it up a notch with their built in support for NTFS filesystem read/write mounting. LinuxDefender Live is more of a compilation of Knoppix and a lot of other programs that they could squeeze onto a boot CD, than a new version of Knoppix. Relative weights and merits aside, it's still great to have around when you want to fix a Windows NTFS filesystem problem quickly (Letting your Recommended Daily Allowance of Television get ripped and torn away day after day is a slippery slope. Granted, the worst that can happen is you might start reading more books, but it's a serious consideration, nonetheless ;)

The procedure for using LinuxDefender Live to fix your Windows NTFS problem is simple enough, with one catch that I can never seem to get around (except for one way, of course, or I wouldn't be writing about this. Some day, for a goof, I promise to write a post where I offer only questions and no answers, promo a few Get-Rich-Quick scams, ramble on about something else completely unrelated to the topic and end it all in mid sentence ;)

Considering that we've got an easy issue (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, which you can't do without practically reinstalling your Windows OS, because it won't boot), these are the steps we'd take to fix it up 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 LinuxDefender Live 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. Knoppix (I mean LDL ;) is unusually pleasant to watch, especially when you're in the company of people who don't know what the Hell any of the boot messages mean (as if I understood them all myself ;).

4. Once you're finished booting up and have either your desktop GUI (Gnome or KDE on my version) or the CLI (if you don't mind huge fonts and screen run-off) 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, but, if you're like most unblessed people, you'll either get errors when you try to mount the disk (complaining about NTFS) or when you try to access it.

5. Here's where the troubleshooting starts. If you open a terminal window in your GUI (so you can keep a decent scrollback buffer and fit more words on the screen), you can try to mount the windows disk to a mountpoint of your own creation, using the specific flags to indicate that you want to mount the disk read/write as filesystem type NTFS. Fortunately, probably, you'll be good to go in a few steps.

6. The first thing to check at this point is that all of the requisite files are available. The NTFS read/write support is provided by the captive project, which requires that you have the ntoskrnl.exe and ntfs.sys files available. You can generally get these by just clicking the huge "Install NTFS Drivers" Icon on your desktop. Alternatively, you can run:

host # sudo captive-install-acquire

from the command line.

7. At this point, if you use wireless networking, you may be in a bit of a jam. I've tried to get around this by creating separate driver floppies but, when all is said and done, the hassle of having to connect an ethernet cable from your router to your PC or laptop is worth the time it takes. If you are already "hard-linked," you shouldn't have any issues with running the command. This problem simply arises from the fact that the LinuxDefender Live CD can't have those two essential Windows files on it for one reason or another (I'm sure it has something to do with licensing costs ;)

8. Even if you are connected to the network successfully, the command may not work the first time. If it cannot complete, it will let you know (in detail) what you need to do. This can be as easy as just typing another command line first, to (this happens often) making "real" disk space available to write the two Windows NTFS drivers to. I usually go with a floppy. My floppy actually already has the two files from 3 different versions of Windows on it, but that's just me ;)

9. When captive is finished installing, 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 ;)

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

The biggest pain is that, since LinuxDefender Live is on CD (read-only media), you won't have the two NT drivers the next time you have to save your machine. If you know you're always going to be working on the same machine( and it's possible), carve out a tiny partition (not NTFS) and put them there so they're easily accessible the next time you have to go round and round. Otherwise, copy them to floppy before you quit. Then again, as a third option, you can just copy them to a floppy, or anywhere, after you've got Windows back up and running. I prefer to stick with the versions captive grabs, since they're more likely to be absolutely compatible (strange things change between Service Pack Versions :). Plus, if you have the files on floppy, you won't have to depend on an internet connection to get the files (or other more convoluted methods like booting off of a DOS disk and grabbing them from your hard drive that way... there's always a way!)

Hope this little walk-through was of some help to you. Tons of extra information can be found at the links to the products listed on this page. They're straight-up links to the distro's and company web pages (No sales involved since it's all free ;)

Next up in our "avoiding Windows support" series: How to train yourself to screen calls from friends and family ;)

Cheers,

, Mike

---

Thanks to an intrepid reader who found this "working" link to the last release of LinuxDefender Live!

---

http://ftp.linux.org.tr/pub/pub/mirrors/linuxdefender/LinuxDefender_Live!_v1.5.6_CeBIT.iso

---

---

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

---

Emergency Booting RedHat Linux With USB

Hey there,

This post is for any Linux admin out there, who uses RedHat (or any similar distro, really - the differences are generally minor) and works in a shop outfitted with the latest and greatest hardware to "drive the network." I'm not sure what that expression means, but I heard it in a meeting once and it seemed vaguely motivating ;) It's also the first post on using grub since our post on using grub to change the root password.

If you do use RedHat Linux and run it on hardware that's new or "newer," you probably have a couple of servers (or, possibly, even regular PC's) running RedHat that don't have those good old-fashioned PS/2 keyboards and mice (mouses ?? I'll puzzle over that for my remaining years). You may even, in some instances, find yourself in a situation where you're booting a server from a USB drive. You won't see that too often (especially not in enterprise systems), but you'll catch it here and there in development environments with bizarre quadruple-boot configurations. You may not, technically, support them, but (since you're the sys admin) you support them ;)

Basically, today, we're going to take a look at a way you can protect yourself against disaster in the former situation (No PS/2 Keyboard or mouse) and assume that your server is running RedHat Linux and only has USB keyboard and mouse connectors (Really, you don't need the mouse. That's for the GUI, and the GUI shouldn't have anything to do with an "emergency" recovery. If your GUI works, things can't be all that bad, and, if it doesn't, you won't be using it ;). We'll assume also, that you'll need them to work properly when you boot from a disaster situation. This, as most RedHat Linux users and/or admin's can attest to, is an issue directly related to the default OS setup. The issue is that the USB drivers generally (or, by default) get loaded up after the system has begun booting. Since the USB drivers are treated as ancillary, if your machine is completely screwed and you need to do some minimal CLI work (just interacting with "grub" at a high level), having a USB keyboard as your only option means you're screwed, too, unless you get creative and connect to the box via ALOM or Serial or can jerry-rig some other form of TTY connection to emulate keyboard interaction (You'll discover amazing things you never knew you knew when an important box goes down and the boss is building up to a Grand Mal seizure while he breathes down your neck ;)

Of course, the easiest thing to do (in almost any case, for any problem) is to use up that ounce of prevention (If you encounter resistance, you can always spin this as something that will "save the company a pound of cure" ;). And the easiest way to do that in RedHat Linux is to just create an alternate boot image that includes USB drivers (you saw this coming from a mile away, I know). And RedHat (as with most other distro's) makes this very easy to do. Given the version of RedHat Linux you're running, the switches/arguments you have to pass to the various commands may be slightly different, so I'm including multiple options in some cases where only a few (or one) are actually relevant. Check the man pages on your system to see which one works for you and/or if that option even exists. Who knows, you may have more options on your version than I do on mine, which could, potentially, be even better :)

The first thing to do, would be to figure out what USB drivers you have loaded on your system. A simple find command like this, should give you a general idea (use "lsmod" and grep that output if you want to do things "the right way," but you may miss a few things ;)

host # uname -r
2.4.21-37.ELsmp
host # find /lib/modules/`uname -r`/kernel/drivers/usb -type f -name "*usb*"
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/host/usb-ohci.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/host/usb-uhci.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/dabusb.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/serial/ir-usb.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/serial/kl5kusb105.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/serial/usbserial.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/hpusbscsi.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/storage/usb-storage.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/usb-midi.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/usbcore.o
/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/usbnet.o

and this one, just because it's always nice to have (details on down the page):

/lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/host/ehci-hcd.o

The second thing to do would be to cozy up your "mkinitrd" command and get comfortable with it ;) On RHEL4 (RedHat Enterprise Linux Release 4), you can get away with the following command line to create a new bootable USB-friendly kernel boot image (Note that the release in these examples is RHEL3):

host # mkinitrd --with=ehci-hcd --with=uhci-hcd /boot/newinitrd-`uname -r`.img `uname -r`

If you're using an older, or different, version of RedHat, check out the options you have available to your "mkinitrd" command. Generally, you'll find at least one of these:

--with-usb
--without-usb (completely contrary to this post, but, included for completeness for those folks who want to make sure they boot with NO USB support ;)
--with=MODULE_NAME
--preload=MODULE_NAME

For instance, this would work on most servers:

host # mkinitrd --preload=ehci-hcd --preload=usb-storage --preload=scsi_mod --preload=sd_mod /boot/usbinitrd.img `uname -r`

From my little find investigation, I found that this would probably work well for my particular server:

host # mkinitrd --preload=ehci-hcd --preload=usb-storage --preload=usb-uhci --preload=usb-ohci --preload=scsi_mod --preload=sd_mod /boot/usbinitrd.img `uname -r`

And, then we'd add a new entry in /etc/grub.conf and give it a test the next time we can sneak in a clean boot up (For those last few examples of "mkinitrd" entries, of course, I'd be doing them all with `uname -r` instead of the actual value of that command, but you don't want to put those backticks in your /etc/grub.conf). A new entry, considering our command above, might look something like this:

title USB RHEL3 (2.6.9-1.667smp)
root (hd0,0)
kernel /vmlinuz-2.6.9-1.667smp
initrd /usbinitrd.img 2.6.9-1.667smp

...basically, if you're just created a different "initrd" image for your same kernel, just copy those lines, change the title slightly and alter the line that begins with "initrd" to point to the file you created with "mkinitrd." Simple :)

and, just in case you're curious about any of the modules we've suggested possibly adding to your new USB boot image, you can usually find out as much about them as you want to know using the modinfo command, like so (I'm leaving out the usb-storage, etc, ones since their name's pretty much say it all :)

host # modinfo ehci-hcd
filename:    /lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/host/ehci-hcd.o
description: "2003-Jan-22 USB 2.0 'Enhanced' Host Controller (EHCI) Driver"
author:      "David Brownell"
license:     "GPL"
parm:        log2_irq_thresh int, description "log2 IRQ latency, 1-64 microframes"

host # modinfo usb-uhci
filename:    /lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/host/usb-uhci.o
description: "USB Universal Host Controller Interface driver"
author:      "Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber"
license:     "GPL"

host # modinfo usb-ohci
filename:    /lib/modules/2.4.21-37.ELsmp/kernel/drivers/usb/host/usb-ohci.o
description: "USB OHCI Host Controller Driver"
author:      "Roman Weissgaerber <weissg@vienna.at>, David Brownell"
license:     "GPL"

Here's hoping you either never have to use this, or that you have it ready to roll if you ever do :)

Cheers,

, Mike

---

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

---

Disabling Network Devices in the Solaris Boot PROM

There are quite a few bugs out there on SunSolve, regarding system crashes due to this or that network device failure (or driver issues, depending on how you look at it). Most of the time, the advice is to disable the network device as non-destructively as possible. That can be difficult, given the right circumstances. Of course, I'm talking about the "non-destructive" part. Disabling an interface is easy. Lots of people who don't know the first thing about Solaris can do it, if they bang enough keys and have the proper system privilege ;)

The first thing to do is incredibly obvious. Just take out any references to the network device on the host. Say, if you are using ce0 and ce1 and no longer want to use ce1, you could just do the following and you'd be good from that point on and for future reboots:

ifconfig ce1 down
ifconfig ce1 unplumb
rm /etc/hostname.ce1
vi /etc/hosts <--- Optional, to remove ce1 host name/IP entry
vi /etc/netmasks <--- Optional to remove ce1's netmask setting (unless it's on the same subnet as ce0!)
vi OTHER_FILES <--- Any pertinent files were you may have inserted special route commands, etc, that are no longer applicable

The second thing to look for would be OS operations you could perform (perhaps during boot up). As a "For Instance," certain Sun machines, running certain patch levels, have an issue with the hme0 network device (it's technically a device driver) if it's not connected to the network. Even if you aren't using it. This is somewhat annoying because, if you don't set up the configuration to plumb the network device and bring it up, it shouldn't give you any errors. You should only know hme0 exists by looking in a system file like /etc/path_to_inst. But the hme0 device causes the following error to post constantly during boot up and for a while after:

SUNW,hme0:Parallel detection fault

Working around this bug is fairly simple. In this case (and each case will probably be slightly different - troubleshooting can be long and hard some times), you could run the first two lines below, to stop the activity immediately, while logged in. The second line could be added to /etc/system so that the problem wouldn't recur on reboot. It is strongly recommended to backup, or copy off, /etc/system before changing it, so you can use "boot -a" at the PROM level to boot using your old version if the new one causes your future boots to fail!

ndd -set /dev/hme instance 0
ndd -set /dev/hme adv_autoneg_cap 0
set hme:hme_adv_autoneg_cap=0 >>/etc/system

The third, and most drastic, way you'd go about this is to disable the problematic network device at the Solaris PROM level. Before you bring the machine down, run this (we're still using hme0 as an example and note the output by copying and pasting into notepad, or even writing it down:

grep hme /etc/path_to_inst
"/pci@1f,4000/network@1,1" 0 "hme" <--- This is the device (instance 0 of hme, or hme0) that we want to disable!
"/pci@1f,4000/SUNW,hme@5,1" 1 "hme"

Assuming we've already executed something like "init 0" as the root user, we could do the following to disable hme0 from the PROM "ok" prompt. Note that if you run "show-nets" at the PROM level and see truncated information, use it to compare with the device you have listed from before and use the most similar (just slightly clipped) entry in your future arguments.

If none of the patterns match at all, you may have gotten the wrong info from /etc/path_to_inst or your device tree is screwed up beyond what we're specifically dealing with here today. At this point you should be absolutely certain you know which network device to disable at the PROM level. Now, run the following to make the PROM disable, and Solaris forget all about, hme0:

ok nvedit
0: probe-all install-console banner
1: " /pci@1f,4000/network@1" $delete-device drop
2:
ctl-c <--- Typing the control key and the c key together will break you out of nvedit and put you back at the ok prompt
ok nvstore
ok setenv use-nvramrc? true
use-nvramrc? = true
ok reset-all <--- Make sure you enter a line with "set auto-boot? false" before you run this command, if you want your system to stay at the PROM after it resets.

Now, the hme0 network device should finally be completely disabled at the OS level. Solaris should not even know it exists! You may want to consider doing a reconfigure boot ("init 0" followed by "boot -r" at the PROM "ok" prompt or "reboot -- -r" from the OS -- there are a few more ways to do it, but I digress).

And, to answer the inevitable, and reasonable, question: How can I re-enable my network device on Solaris' PROM once I've disabled it?, here's how:

ok setenv use-nvramrc? false
ok nvedit
0: " /pci@1f,4000/network@1"
delete-device
ctrl-u <--- Hitting the control key and u key together will delete the current line from the nvedit buffer. You only need to do this for the device you previously wanted to ignore.
ctrl-u <--- You usually won't have to type this twice. This is just to demonstrate that you can erase as many lines in the buffer as you want before exiting your nvedit session. In this case, you must delete two lines since the device and delete-device instruction are on separate lines.
ctrl-c
ok nvstore
ok reset-all
ok boot -r

Hopefully this has saved you more headaches than it can potentially cause :)

, Mike

linux unix internet technology