I use chroot all the time to rescue or build a linux machine. One niggling problem is that /dev/ and /proc are not propagated automatically to the chroot environment. To solve this do the following before running chroot


mount --bind /dev /path/to/chroot/dev
mount --bind /proc /path/to/chroot/proc


Then you can chroot:

chroot /path/to/chroot/ bash


Pretty simple trick but a useful one.

I built and installed the latest kernel (2.6.28 as of this writing) and attempted to install the proprietary nvidia driver with this kernel. The nvidia installer (version 177.82) did not detect the kernel headers that were in fact installed.

What I had to do was to extract the installation files from the nvidia installer (you do this with the -x flag). Then I had to apply a patch that I found here.

To apply this patch I cd'd into the nvidia installation directory created by running the installer with the -x flag. I downloaded the NVIDIA_kernel-177.82.diff.txt from the link posted above. The patch syntax was:
patch -p0 < /path/to/NVIDIA_kernel-177.82.diff.txt

Every once in a while I check the motherboard manufacturer's website for bios updates. Usually the BIOS version is listed in one of the first boot screens. There are two problems with this:

First I have to reboot the machine to do this. This is not always a convenient thing to do.

Second I have to be in front of the machine. I maintain a number of servers and workstations that are spread apart geographically.

Fortunately there is a solution if the computer happens to be running Linux. From the command line I type:

sudo dmidecode -s bios-version

Here are some examples from the machines I own/maintain:
ASUS M2A-VM HDMI ACPI BIOS Revision 2101
A11

I came across this little problem today. I had an image of an entire hard drive, but all I wanted was to extract a single partition.

Most of what I wanted to do was described in this post.

First, I needed to see what was on the disk image, using fdisk:

fdisk -lu /path/to/image.bin
Device Boot Start End Blocks Id System
myimage.bin1 * 63 275225579 137612758+ 83 Linux
myimage.bin2 275225580 17117257+ 7 HPFS/NTFS

and so on.

The "u" option tells fdisk to display the results in units of 512 bytes, which should match the block size. This may not be true of disks imaged that are 3 terabytes or larger.

What I then did was use dd to extract only partition 1

Below is a real world example based on the output of dd above.

I now have a second file myimage-1.bin which I can then mount and copy files off of.

Nmap is a commonly used utility in the security world. The default nmap scan is pretty good but there are a number of options to make your scans more informative and or more efficient.

My current set of command line options varies slightly depending on what I am looking for, but it generally starts with something the looks like this:

This scans two networks, 192.168.0.0/24 and 192.168.1.0. In my case I have two subnets at home with routing between them. This would let me see the whole network at a glance.

• The -PN option does not use ping (ICMP) to test to see if a host is alive before scanning it.
• The sU, sS sV option enables UDP service discovery.
• The sS option scans for TCP services using the SYN TCP Connect method. This is pretty reliable as it mimics a legitimate connection attempt.
• The sV option tells nmap to connect to these services and find out what version they are running. This is useful for finding exploitable services.

Every couple of months I keep posting the same links to a couple of different mailing lists and forums.

One of the problems that new users encounter with open source operating systems is that some hardware is not well supported. The problem is not with the developers of these open systems, but with the manufacturers themselves.