Not sure what happened, but here is how I fixed it. Maybe...

I was downloading the new Fedora Core 5 disk images to my 160GB USB drive yesterday. Using wget, I let it run overnight. Well, I come in the next morning to find the disk unresponsive and giving weird errors.
(From the download directory):

root@newt ~
> ls
FC5blahblahblah: File not found

(or something like that)

In any case, I unmounted the thing, and then couldnt remount it at all. Got the following error:

root@newt ~
> mount /dev/sda1
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Well, hush my puppies!

In the past, I have seen this error when fstab is given the wrong file type somehow or "auto" is used as the filetype. So I tried giving the correct filetype (what I thought was correct). Waitaminnit, where did I get the correct filetype from?

root@newt ~
> fdisk -l

Disk /dev/hda: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1        2040    16386268+  83  Linux
/dev/hda2            2041        2958     7373835    7  HPFS/NTFS
/dev/hda3            2959       10011    56653222+   5  Extended
/dev/hda5            2959        3098     1124518+  82  Linux swap / Solaris
/dev/hda6            3099       10011    55528641   83  Linux

Disk /dev/sda: 163.9 GB, 163928604672 bytes
255 heads, 63 sectors/track, 19929 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       19929   160079661    c  W95 FAT32 (LBA)

So it is a FAT32 partition? I don't think so... I really remember formatting this thing as ext3, but, you know, it came out of the box as FAT32, so maybe I'm wrong. Let's try it.

root@newt ~
> mount -t vfat /dev/sda1 /mnt/temp
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Same error. Tried "-t ext3" -- same error. I serached Google a bit, and came up with some suggestions:

• Try changing the partition type "back" to Linux (type 83). Use fdisk.
• Try running fsck to fix the partition table.
• Use an alternate superblock.
• Use the command "mke2fs -n /dev/sda1" to get a list of alternate superblocks

So I tried these ideas. "fsck -b 32768 /dev/sda1" is running right this minute. Hopefully it will work!

I was struggling with a problem related to the different way different browsers normalize (or don't normalize) color definitons. I just wanted a background table cell to toggle color on click of a checkbox! Here is my solution...

The problem I was having seems similar in scope to that described here:

Thread in Google Groups (aka Usenet)

My problem is this: How can you compare the current background color value of an item on a page to the color you want as a highlight color, and toggle between the two?

The DOM provides access to page object CSS style properties such as background colors and whatnot. In this case, I had a table cell and I wanted to highlight the cell if the checkbox living in the cell was checked, and turn off the highlight if not checked. As with any programming problem, there is more than one way to do this, but my way is a fairly simple idea -- use a function that checks the current state of the cell and toggles the highlight to the other state. For this function, I used a couple of techniques, the ternary operator (love the ternary operator!) and JavaScript DOM methods.

It should be as simple as (in pseudocode):

if the current_bg_color equals highlight_color
  then the new_bg_color is set to the non_highlight_color
  otherwise it is set to the highlight_color

The problem I was having was specifically in comparing the value returned for the DOM functions that get the CSS property "background-color'. For example, if the background color of the cell is set, in the CSS Stylesheet, to "#FFFFFF" (white), FireFox's DOM interpretation was returning a literal value of "rgb(255,255,255)". That is to say, I was getting a string of the rgb() value. The problem with that, then, was that I couldn't compare it to my manually-set hexadecmial values for background color and do a meaningful comparison -- the string, "#FFFFFF", is never equal to the string, "rgb(255,255,255)"!

So I decided to create an empty throwaway element, assign the values I needed to to that, and thus automatically normalize the values that I am comparing to the same thing, no matter what they are getting converted to internally by the browser's DOM implementation.

Example:

function toggle_highlight_section(section_name, notoggle){
    // "hidden_element" is an empty .
    document.getElementById("hidden_element").style.backgroundColor = highlight_bg;
    highlight_bg = document.getElementById("hidden_element").style.backgroundColor;
    current_bg = document.getElementById(section_name).style.backgroundColor;
    if ( notoggle ){
        document.getElementById(section_name).style.backgroundColor = notoggle;
    } else {
        document.getElementById(section_name).style.backgroundColor = ( current_bg == highlight_bg ? default_bg : highlight_bg );
    }
    document.getElementById("person_fname").value = document.getElementById(section_name).style.backgroundColor;
    return false;
}