7z x -oOutputDir LargeLinuxIso.iso
Wednesday, December 09, 2009
Friday, November 20, 2009
$ createrepo -u "media://`head -1 ../.discinfo`" -g repodata/comps-rhel5-server-core.xml .
mkisofs -r -R -J -T -v -no-emul-boot -boot-load-size 4 -boot-info-table -b isolinux/isolinux.bin -c isolinux/boot.cat -x "lost+found" -o ../oel5Custom.iso .
Friday, November 06, 2009
Tuesday, October 06, 2009
Thursday, September 24, 2009
Here’s a simple little script which allows me to use p4.exe from cygwin. Perforce actually releases a p4.exe for cygwin, but I wanted my p4win and p4.exe to be able to use the same client spec. This isn’t possible when one requires a root starting with “C:\” and the other requires “/cygdrive/c/”.
This script works by expanding and window-izing all arguments after the p4 command.
Here is a series which shows the transformation.
- p4 edit README
- p4 edit /home/gwarner/foo/README (where foo is a symbolic link)
- p4 edit /cygdrive/c/perforceRoot/blah/blah/blah/README
- p4 edit C:\perforceRoot\blah\blah\blah\README
2. import sys
3. from subprocess import *
5. def win32Path(path): path = path.replace('/cygdrive/c/','C:\\')
6. path = path.replace('/','\\')
7. return '"%s"' % path.strip()
8. if __name__ == '__main__':
9. p4command = sys.argv
10. fullFiles = 
12. for file in sys.argv[2:]:
13. fullPath = Popen(['readlink.exe -f ' + file], stdout=PIPE, shell=True).communicate()
16. newCommand = 'p4 %s %s' % (p4command, ' '.join(fullFiles))
18. print newCommand
19. check_call(newCommand, shell=True)
20. print 'done.'
Wednesday, September 02, 2009
Tuesday, August 25, 2009
Monday, August 24, 2009
- Boot off of the installation cd using "linux rescue"
- Unmount all of the drives in /mnt/syslinux
- Note: Before unmounting /mnt/syslinux itself, you must unmount all of the mountpoints within it.
Wednesday, August 12, 2009
Wednesday, July 22, 2009
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!
Wednesday, July 15, 2009
Wednesday, June 24, 2009
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 *We can hexdump them to see their contents:
open('2short.bin','wb').write(pack('HH', 0x0102, 0x0304))
open('4char.bin','wb').write(pack('BBBB', 0x01, 0x02, 0x03, 0x04))
$ hexdump 1long.binBefore hexdumping, one might suspect that the outputs would be the same, but they're not. Each gave a diffent ordering.
0000000 0304 0102 (this is the long: 0x01020304)
$ hexdump 2short.bin
0000000 0102 0304 (these are the 2 shorts: 0x0102, 0x0304)
$ hexdump 4char.bin
0000000 0201 0403 (these are the 4 chars: 0x01, 0x02, 0x03, 0x04)
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
$ od -tx1 -w16 -Ax 2short.bin
000000 02 01 04 03
$ od -tx1 -w16 -Ax 4char.bin
000000 01 02 03 04
Friday, March 13, 2009
./TestCppProgram: symbol lookup error: ./TestCppProgram: undefined symbol: _ZN12CppProgramC1EvI searched the internet. Two of the interesting links I found were the following:
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.)
- ► September (2)
- ► 2008 (20)