1776

Source: 1776 p 271

"Will it not be possible": Joseph Reed to George Washington, December 22, 1776 in PGW, VII, 415

It was time something was done. Something aggressive and surprising.  Even failure would be preferable to doing nothing.

Move /var to its own (logical) partition in LVM

(all this using Oracle EL 5, aka RHEL 5...)

From memory, so there may be errors:

1. Boot off of the installation cd using "linux rescue"
2. Unmount all of the drives in /mnt/syslinux
• Note: Before unmounting /mnt/syslinux itself, you must unmount all of the mountpoints within it.
3. $ resize2fs /dev/VolGroup00/ 5G
4. ... boot back into regular linux ...
5. $ lvreduce -L 6GB /dev/VolGroup00 (answer yes)
6. $ lvcreate -L 10G -n var VolGroup00
7. ... boot back into rescue mode ...
8. mkdir /mnt/var
9. mkfs -t ext3 /dev/VolGroup00/var
10. mount -t ext3 /dev/VolGroup00/var/ /mnt/var
11. mv /mnt/syslinux/var* /mnt/var
12. (edit fstab so that it mounts the new logical volume to /var)
13. resize2fs /dev/VolGroup00/LogVol00 (remember how I made this 5Gb when the LV was 6GB?)
14. reboot!

On rebooting, syslogd had a problem starting. (Running in debug mode, it would complain of "permission denied" to /var/log/secure and all other log files).  It was an SELinux problem and was remedied by relabeling the filesystem.

Basic .hgignore for web2py

This should do the trick!

syntax: glob

*.pyc

syntax: regexp

^errors

^languages

^sessions

^static/output

^cache

^cron

Restoring a USB disk

The other day, I imaged a USB disk to do a linux install.  The image was only a few hundred megabytes.  When I was done, I couldn't get the USB drive to reformat to anything other than the size of the image. (thus wasting a large portion of the disk).

Killdisk (http://www.killdisk.com/) was a tool I found that pretty much writes the usb drive with zeros.  I believe you only need to do so for a few minutes to overwrite the table which holds the partitions and then cancel it and upon reformatting it in windows, you'll discover that you've got all your space back!

Beautiful Auburn

See http://picasaweb.google.com/jnewarner for more

Byte ordering endianness mayhem! Aahh!

Working with (binary) data structures written to files can be difficult due to the fact that a hexdump of a binary file may appear to be out of order.

The following example may illustrate the source of confusion. This simple python script will create three binary files. To each file we will write 01 02 03 04 split up in different ways.

from struct import *
open('1long.bin','wb').write(pack('L', 0x01020304))
open('2short.bin','wb').write(pack('HH', 0x0102, 0x0304))
open('4char.bin','wb').write(pack('BBBB', 0x01, 0x02, 0x03, 0x04))

We can hexdump them to see their contents:

$ hexdump 1long.bin
0000000 0304 0102 (this is the long: 0x01020304)
0000004

$ hexdump 2short.bin
0000000 0102 0304 (these are the 2 shorts: 0x0102, 0x0304)
0000004

$ hexdump 4char.bin
0000000 0201 0403 (these are the 4 chars: 0x01, 0x02, 0x03, 0x04)
0000004

Before hexdumping, one might suspect that the outputs would be the same, but they're not. Each gave a diffent ordering.

These examples were run on a regular run-of-the-mill 32-bit Intel machine. These machines have a 16-bit word size (weird, yeah, I know) and use little-endian byte ordering. Little endian byte ordering means that the lest sigificant byte of any given data type, will go in the lowest-addressed memory space (or slot in a file on disk).

The least significant byte of the long 0x01020304 is the "04". Why doesn't it appear on the far left in the hexdump such as this: 04 03 02 01?

.... Need to finish writing in here ....

Diagram that I drew showing how reordering address so they increase from right to left can help understand little-endian byte ordering:




After googling around a bit, I found a thread which talks about how to reformat your hexdump so it is in big endian format (I believe). It's quite useful:

$ od -tx1 -w16 -Ax 1long.bin
000000 04 03 02 01
000004
$ od -tx1 -w16 -Ax 2short.bin
000000 02 01 04 03
000004
$ od -tx1 -w16 -Ax 4char.bin
000000 01 02 03 04
000004

c++ runtime "symbol lookup error"

I was working on a c++ project. Everything linked and compiled fine. Upon running the executable, I got the following error:

./TestCppProgram: symbol lookup error: ./TestCppProgram: undefined symbol: _ZN12CppProgramC1Ev

I searched the internet. Two of the interesting links I found were the following:

• http://osdir.com/ml/gcc.g++.general/2005-02/msg00061.html
• http://www.linuxquestions.org/questions/linux-software-2/undefined-symbol-cout-263568/

For me it ended up being a bad LD_LIBRARY_PATH. The path I intended the executable to find it's needed shared library was in the LD_LIBRARY_PATH, it just wasn't before a different path which had an older version of the needed shared library. (This happened to me when I updated by bashrc with a library path and just re-sourced it).

Some cool commands in the debugging process:

• ldd TestCppProgram (Shows you where your program is getting it's libraries from. An early-on careful inspection of this would've quickly let me to my problem!)
• ldd -d -r TestCppProgram (Shows you any undefined symbols. There shouldn't be any undefined symbols for an executable, but there will be for a shared lib if it depends on another shared lib. Somebody please correct me if I'm wrong)
• nm TestCppProgram | c++filt (displays unmangled symbol information)
  
• nm TestCppProgram (Displays mangled symbol information. Ie: You should be able to find stuff like ZN12CppProgramC1Ev in here. In my problem above, I found which line number the undefined symbol in question was on, and then looked it up in the unmangled version to see what function it was trying to resolve. It let me know, but it didn't really help me find out what my problem was.)
• readelf -d TestCppProgram (Shows library dependencies. similar to ldd.)