It isn't often that I find myself checking snopes before posting about something that happened to me. As in never. Until now.
I was heating filtered water in the microwave oven for tea, in a glass mug. It seemed to be taking a long time to boil (I wanted strong tea, so I was going to steep it just off boiling). As I peered through the microwave's window, there was a muffled explosion, and boiling water and steam spewed out of the microwave. I immediately turned off the microwave and tentatively opened the door. 90% of the water was no longer in the mug. Some of it was still in the microwave; the rest was on the cupboards and floor.
I immediately googled "microwave exploding water" and found that the first hit was a snopes page (True!), the second a link to Steve Spangler Science with more confirmation, and the third hit was a mythbusters video showing exploding water in slow motion.
Wow, I'm glad that happened before I opened the microwave door. It was more likely to have happened when I moved the mug or dropped tea into the water, so I count myself lucky.
So, a Public Safety Announcement: If you are microwaving water, especially filtered water, add a wooden stir stick or some other non-metallic object to provide a nucleation site to prevent superheating and possible subsequent scalding.
posted at: 21:15 | path: /psa | permanent link to this entry
My wife and I had everything planned for Halloween; I would take the girls trick-or-treating and she would hold down the fort. My first hint that the evening might take an unexpected turn was when she called to mention that she smelled something funny, and she thought that this time it probably was natural gas, not a stale dishrag like last time. I was skeptical, until she called me a few hours later to say that the smell was a lot stronger in the (gas) furnace room, that the kids were buckled into the car, and that I was going to be coming home to deal with this while she and the kids went to supper.
She was right. The smell was obvious. Being a hands-on kind of guy, I decided to investigate this myself. I made some soapy water and spread it on the place I thought was most likely to be leaking: a set of pipes around the main stepdown regulator. After half an hour or so of unfruitful exploration, I grew a clue, gave up, turned off gas to the whole house at the meter, and called in the gas company (PSNC).
I learned two new things:
The technician called me to apologize for having to finish up one emergency call before coming to handle my emergency. Not a problem! He arrived just after the first trick-or-treaters came by. He "clocked" the leak by marking and watching the meter with no appliances running, and I got my first indication that this was not trivial when after only a minute his eyebrows went up and he said, "Oh, that's really leaking!" I was gratified to see that the first thing he tested in the house was the exact same place I had started looking, but no bubbles showed up with his soap either.
The investigation continued for something like an hour and a half. We pulled out suspended ceiling. We turned different parts of the system on and off. Finally, he started putting high-pressure air into different parts of the system -- and in the first place that both of us had looked, bubbles started forming as a joint started hissing. The leak was found!
Unfortunately, when the contractors (Yellow Dot, as far as I can tell) installed the gas lines in our house, they hadn't followed code. And the Wake County inspector didn't call them on it. There was no union joint to make it easy to fix the leak. So instead of the technician turning his wrench a few more turns and swabbing on some more joint compound, I paid for an hour of overtime to do the fix right and bring the house into compliance with code. A small price to pay for a fixed gas leak right away, and hot water in the morning! When he was done, the meter didn't budge during a 20-minute test, whereas before it had moved perceptibly within a minute.
The technician explained to me that when the weather gets cold, they inject a lot more mercaptin oderant into the natural gas supply to make it more likely that people will discover leaks in time to fix them before they cause trouble. He said it makes for more repair calls as the cold weather starts -- and they really don't mind...
The fast response, the thorough investigation, and the quality fix done quickly and correctly made me feel good about paying the gas bill. As a bonus, while he was doing all this investigation and repair, he was assiduous about wiping off his feet to keep the carpet clean and closing the doors to keep out mosquitoes.
posted at: 17:46 | path: /psa | permanent link to this entry
I've been an old-school die-hard gimme-those-old-time-primary-partitions kind of geek for a long time now. Even extended partitions bother me, especially when partial drive failure makes otherwise unaffected partitions disappear. So while the flexibility that LVM provides was enticing, I was frankly a little uncomfortable putting LVM on my system, especially after a hard drive crash.
Some months ago (I really don't remember exactly when), I experienced a third drive failure on my old PATA-backed RAID1 array on my home system. I then discovered that Linux software raid has the ability to grow the device, and so I switched to larger SATA devices merely by adding the SATA devices to the RAID1, waiting for resync, removing the remaining functional PATA device, and then growing the new RAID1. Impressive and convenient, all except that installing grub by hand on Linux software RAID1 is still not an unadulterated pleasure.
While recovering from my most recent hard drive crash onto a temporary drive, I set up some filesystems on LVM, I seem to recall because at least one of the filesystems was likely to grow to require some unknown amount of disk space. I then ordered a larger drive to move my data onto. After the new drive arrived, I discovered the pvmove program and was very impressed that I should be able to add another physical volume to a volume group, then cause all the logical volumes in that group to be migrated from the temporary drive to the new physical volume. Google then helped me interpret the error message that I got, and modprobe dm-mirror got pvmove working. As I watched the output of pvmove -v /dev/hdc4 scroll past, telling me percent complete every 15 seconds and occasionally informing me that it had checkpointed progress in case my system were to halt before progress was finished, I wandered around the office telling everyone about how cool LVM was.
Not merely pride, but also enthusiasm goeth before a fall. I was in a hurry to remove /dev/hdc from my system and use only my new /dev/hda4 physical volume. Lost in a twisty maze of lvm utilities, all slightly different, I tried to remove the /dev/hdc4 physical volume. I ran pvremove /dev/hdc4 and had the command tell me that it wouldn't succeed until I ran it with the -ff argument. By now, I was conditioned that LVM occasionally asks for confirmation of remotely-possibly-dangerous actions, and so just hit up-arrow, added -ff, and hit y to accept. Of course removing a physical volume is a little dangerous, but I knew I wanted to do it, and I had run pvdisplay first to ensure that the volume was empty. I removed the temporary drive and rebooted.
The LVM-savvy are shaking their heads now. Of course, I should have guessed that I would have to run vgreduce first. And, indeed, all the data that I had copied over -- my home directory, my development environment, everything except the root partition -- was now inaccessible, and /dev/hdc4 lived on as a phantom. The LVM commands complained about a missing uuid, and the solution wasn't immediately obvious. "I lost my /home!" I cried, prompting anxious questions among my colleagues as to whether I had started to forward some of my more salacious spam to my wife. After about 5 minutes of careful (pvdisplay made it clear that space on my /dev/hda4 LVM partition was still reserved by something) experimentation (and no despair; I had just completed a current backup before starting the whole process), I resorted to reading the lvm man pages, one by one, until I understood the problem and the solution.
First of all, the fact that I couldn't get at my data was (perversely enough) a good thing. It was because LVM was being conservative. It didn't have all the physical volumes (as identified by UUIDs) required to complete the volume group, and so it was possible that the logical volumes were incompete. Trying to mount or otherwise manipulate a potentially incompete logical volume could be a disaster, so I'm glad LVM tried to protect me from my own stupidity. It was preserving my data.
The solution to the problem I had created was to run vgreduce (the same program that I should have run in the first place, had I only known) with the --removemissing option, because I knew that all data had been migrated off the physical volume I had removed from the system: vgreduce --removemissing vg0 rendered my data accessible again.
posted at: 18:11 | path: /psa | permanent link to this entry