Monthly Archives: June 2005

FC4 and CD verification

2 Replies

For the last several versions the Fedora Core (and previously RedHat) distribution has had the ability to verify that the downloaded CD images were successfully transfered to the newly burned discs. For people who download the images and create CDs themselves this is a fabulous feature; I am sure it has saved people from broken installations. However, as I discovered it can also lead a bit of pain.

Last week I downloaded all of the FC4 disc images and preceded to burn them to CD. After rebooting to install using the new media I discovered that the CD verification was failing for three of the five discs. So, I burned them again. Same result. Having used the CD verification for many years I had no reason to doubt it. Eventually I gave up and asked Bob to burn me a copy. Strangely, these CDs failed the verification phase as well.

Realizing that something strange was going on I started googling for similar experiences. It turns out that the CD verification can fail on certain hardware. I had simply never ran into this problem before because this was my first Fedora install on my new computer.

The solution is to boot the installation kernel with an option which tells it not to use DMA for IDE devices. At the GRUB prompt type ‘linux ide=nodma”. After doing this all discs passed their tests. There is one catch though, the Fedora installer is quite smart. If you use a kernel option to do the installation the installer decides this option must be required for successful operation. After installation I had to remove “ide=nodma” from /etc/grub.conf.

If the above wasn’t enough of an adventure I also managed to cause myself some extra pain. When I asked for a copy of FC4 to be created for me I never specified which version. My new computer has a x86_64 processor. The FC4 installation discs I borrowed were for the i386 version. After a day or so of use I realized the mistake and reinstalled with the discs that first caused the problems.

Graduation

Leave a reply

Last Thursday was convocation (graduation) day at UWO. This year convocation turned out to be quite a media event due to the presence of Dr. Henry Morgentaler.

London Free Press article
Article from UWO’s website
Text of Dr. Morgentaler’s speach

Dr. Morgentaler was speaking for the morning convocation ceremony so I did not get to hear his speech. The speaker for the afternoon ceremony was Dr. Bessie Borwein. The full text of her speech can be found here.

“Bachelor of Science – Honors Computer Science with distinction” is what the paper now hanging on my wall says. I also received the University of Western Ontario Gold medal for Honors Computer Science for having the highest average in the program.

I was not planning on attending convocation but I am now glad I did. Missing the ceremony would have probably been a source of regret later in life. It is strange to me how much I now value that piece of paper hanging on the wall.

I have put some pictures from the day in my photo gallery. No, there are no Morgentaler pictures there.

Todays bash lesson

Leave a reply

Today I noticed that a bash script I created a couple of weeks ago to calculate some log file statistics was no longer working properly.

The culprit was the following line:

REGEX=`printf "^%s %i %.2i:%.2i\n" ${MONTH} ${DAY} ${HOUR} ${TMP_MIN}`

This regular expression was designed to match lines that start with a certain date and time. Lines like following:

May 28 12:02

The regular expression was no longer matching the log file entries I wanted it to. The problem was the day value. When I wrote and tested the script the day was double digits. Now, at the beginning of a new month, the days are single digits. The log file I was analyzing pads the day field to always be two digits wide. Thus, the regular expression no longer matched the lines because there was an unexpected space. Figuring out what was broken and fixing the regular expression didn’t take long.

REGEX=`printf "^%s %2i %.2i:%.2i\n" ${MONTH} ${DAY} ${HOUR} ${TMP_MIN}`

The script now worked properly but I noticed something weird. I had added a debugging statement below the REGEX definition.

echo ${REGEX}

This debugging statement was printing the regular expression with one space between the month and day, not the expected two. Yet, the script appeared to work perfectly. What was going on?

In trying to figure this out I went as far as creating a quick C program so that I could see exactly what was being passed in as the arguments.

Of course, it turned out to be something that should have been obvious. The bash echo command prints out each of the passed arguments with a single space between them. The echo command was interpreting each part of the string in the REGEX variable as an individual argument. The ‘fix’ was to enclose the bash variable in quotes so that it would be considered a single argument.

echo "${REGEX}"

Bash programming rule #x:: Always put double quotes around variables.

Vim tips for DOS text files

1 Reply

DOS (Windows) uses CR-LF to mark the end of lines in text files. Unix just uses LF. Wikipedia has a long article on these differences if you are interested.

Viewed in older versions of vim, DOS text files had a ^M at the end of every line. This made identification of text files that had been uploaded via binary mode FTP very easy. It seems recent versions of vim auto-detect the text file type and no longer show the ^M by default.

Vim can be told to not try the DOS text file type with the ‘:set fileformats=unix’ command. If you set this option DOS text files will have the familiar ^M at the end of each line.

The text file type can be changed to Unix for the current buffer (file being edited) by ‘:set fileformat=unix’. Opening a DOS text file, setting the type to be Unix and then saving the file will convert it to a Unix text file.

IPv6 address usage

Leave a reply

I stumbled upon a fabulous article that discusses address utilization in IPv4 and IPv6. Two aspects of this article struck me most: wrapping your head around really big numbers is hard and it is sad to see that some of the same mistakes made during the early days of IPv4 address allocations may be repeated.

Just how big is IPv6?