Sunday, August 27, 2017

Seven years without KDE (or any other desktop environment)

Recently, I just re-read all my old posts from back in the day, and to my astonishment I realized that it's been more than seven years since I threw all the shininess out of my X. So I thought, "heck, why not write another followup?"

Yes, I still use the setup I described back in 2011. Bare-Metal evilwm with bbrun and, as you may have noticed, xbindkeys. That's about it for convenience. As I write this, I have just taken a look at my .xsession. Boy, that takes me back! It still shows all the hash-scars of past experiments. lxpanel. pidgin. yakuake. osd_clock. I used to hack a lot to get my desktop "just so" back then, but I've given (almost) all of it up. There just wasn't any pressure to get in done. What I've still got are the XOSD volume bars, now reduced to one and back in working order (I promised to write about that, didn't I?)

The bottom line is, I still don't miss all the "goodies" the DEs are trying to bait me with. Window management I can do with some simple commands. The two dozen or so windows I usually have open I can keep track of in my mind without a task bar. Start menu? Who needs that? Any application I might need is just a CTRL+ALT+ENTER and a few keystrokes away. I know the commands for what I need. What I don't need, I don't have to have access to. If I once would need it, I would learn the commands. If I want to know the date or time, all I have to do is type "date" or "cal" in xterm. And believe it or not. I still have an old-fashioned clock on the wall above my desk.

All the automount stuff of gnome et al? Never caused me nothing but trouble. Just type "pmount /your/device". How hard can it be? Nowadays the DEs even have auto-execute features for plug-in devices. It's just a matter of time until we get nice auto-exec trojans for linux. Serves people right. There's that German saying that goes "opportunity makes thieves". Same principle applies to such convenience features. Give such a tool to people who don't realize that it CAN be abused, and it WILL be abused because they leave themselves open. None for me, sir, thank you!!!

Long story short, I'll stay in my digital log cabin, thanks. You guys have fun with your shiny toys and blinkenlights. I'm happy in my simple little world.

How to rescue an electronic device that went swimming



They are by no means fool-proof or guaranteed to work, and THEY CAN MAKE MATTERS WORSE, in other words, they can make reparable damage irreparable. Implementing these procedures can void your warranty or insurance.

I guarantee neither correctness nor completeness nor fitness for any purpose whatsoever of these procedures. If you chose to follow them, you do so AT YOUR OWN RISK, and I accept
NO RESPONSIBILITY WHATSOEVER for the results thereof.

If at all possible, you should always avail yourself of a qualified repair service.

Chapter 1: First aid

These procedures apply to any soaked device accident, no matter where you are and if you have a repair service in range or not, with the possible exception of it being just across the street. 

Step 0:

Before retrieving the device from the water, disconnect any mains cables running into it if it is possible to do it safely, or switch of the circuit breaker if it isn't. DO NOT RISK YOUR LIFE. DO NOT TOUCH WET MAINS CABLES WITH YOUR BARE HANDS. DO NOT REACH INTO ANY LIQUID THAT YOU EVEN SUSPECT MIGHT BE CARRYING MAINS VOLTAGE. YOUR DEVICE IS REPLACEABLE. YOU ARE NOT.

If the device bulges or you notice smoke, bubbles or a chemical smell coming from the device,  or if it's hot to the touch, AVOID HANDLING IT: The battery is damaged and may explode, catch fire or vent toxic fumes. Chances are your device is unsalvageable at this point anyways, no don't endanger yourself in vain.

Step 1:

Disconnect any power source and remove any battery. If your battery is non-removable, pray if you got 'em and continue with the following steps immediately and as quickly as possible. Remain mindful of possible battery damage, leakage, overheating and fire. Do not put the device into your pocket, near flammable material or into a closed container.

Step 2: 

Remove any removable parts like back covers, SIM card trays or other attachments. Try to get as much liquid out of it as possible, by rotating and shaking the device repeatedly.

Step 3:

If the device was immersed in salt water or mineral-rich water like a hot spring, rinse it immediately and repeatedly with lots of fresh water. Distilled water is ideal, but almost any kind of reasonably pure water with the possible exception of water from a mineral spring will do. Almost anything is better than salt water corrosion-wise and short-circuit-wise.

Chapter 2: Decision Time

Congrats, you've given a reasonable first aid to your device, the immediate urgency of the problem is now much relieved. Now it's time to take the next


towards saving it.

Option 1: Rush to the hospital
Do you have a qualified repair shop within an hour or two? Take your device there as quickly as possible. None available? Ok, next option.

Option 2: Field expedient surgery 
Can you get your hands on some supplies reasonably quickly? You will need some isopropyl alcohol and distilled water and a baking oven. In a pinch, methylated spirits instead of isopropyl alcohol and any hot, dry place will do. If all else fails, you can leave out step 6 completely and use only distilled water in step 5. Can do? Proceed to step 4. No such luck? Proceed to option 3

Option 3: Supportive care
Can you get none of the above? Not even distilled water? Ok, there's not much more you can do at this point. Proceed to step 5 and use the most pure, mineral-poor water you can find. Skip step 6 and proceed to step 7. After that you have to keep it as dry as possible until you can get it to a repair shop to keep the corrosion in check. If you have one, put the device in a zip lock bag with a sachet of desiccant. If your device is minus it's battery, it still has a decent chance of survival if you get it to a repair shop in a reasonable time before corrosion gets going in earnest. If the battery is non-removable it all depends on how many electrolytes remain in the device and how well you were able to dry it. Take it to a repair shop as soon as you can and hope for the best, but don't get your hopes too high. The leak currents from a charged battery can really play havoc with a device full of water.

Chapter 3: stabilizing the patient

Step 4:

If you are able, and have the tools to do it, disassemble the device. The following procedures CAN be done in an assembled state, but they work much better if done to the individual pieces. Consult the relevant internet self-repair sites for instructions. Keep in mind that you have to put it back together again afterwards, so don't rush into it. Damaging your device or losing parts will make any cleaning success a bitter, pyrrhic victory.

Step 5:

rinse the device repeatedly in a mixture of 70% distilled water and 30% isopropyl alcohol. If no isopropyl alcohol is available, methylated spirit will do, or even good quality Vodka (without added water). The best way to do it is to fill a pan or flat container with the liquid and immerse the device repeatedly. The more liquid flows through the device, the better. The less liquid flows in and out of your device with each rinsing, the longer you should do it. This is to ensure that as little electrolytes as possible remain in the device. Take your time doing this, if the device can't be disassembled, keep at it for at least one hour.

Step 6: 

give the device a few rinses in 90% isopropyl alcohol (or whatever you could lay your hands on) to displace as much of the water as possible. Try to get as much of it out of the device afterwards, because what you get out now you can re-use (isopropyl alcohol isn't cheap) and don't have to evaporate in the next step. Dry right after this step, because isopropyl alcohol is a solvent and extended exposure might damage the glue in the device.

Step 7:

Place your device in a baking oven at 50°C for several hours to dry. Don't accidentally place it in a grill, that would finish it off. If no baking oven is available, any hot, dry place will do in a pinch. If you don't have a hot dry place (because it's winter and you are out hiking), your best case scenario is where you have an unused desiccant bag and a zip lock bag to put it and your device in.  Keep the device on your body to make use of the body heat. If you don't have any desiccant, (and you probably don't), you might try the old "put it in a bag with dry rice" trick - if the rice is VERY dry, at this point this might actually work!

Chapter 4: Recuperation

Even at this point, it is way better to have the device looked over by a qualified repair shop before using it again. If you absolutely have to, or just feel lucky, proceed to step 8. Be aware that if you turn it on where you shouldn't have, it may cause secondary damage, which means it's probably gone for good. But if you absolutely can't wait...

Step 8:

Reassemble, pray, turn on. Either it works, or it doesn't. If it works, do a victory dance and treat yourself to a nice cold one. If it doesn't, you did everything you reasonably could.
To tell the truth, don't expect it to be 100%. Parts like speakers, etc might need replacing afterwards, but you saved most of your device, and, depending on the situation, now that you saved it, it might save you.
To tell even more truth, things aren't cut and dried just yet. Even if the device is looking to be 100% now, it might still conk out on you later from secondary damage that isn't immediately apparent.

So Have. It. Checked. Soonest. Period.

Chapter 5: Some wet device rescue myths, explained.

Placing a wet device in a bag of dry rice can save it.

That will work only if the liquid in question contains little or nothing in the way of electrolytes and non-evaporating additives, like calcium, potassium, sodium, sugar, food coloring, fats, oils, etc, i.e. if the liquid in question was essentially distilled water and/or pure alcohol, in which case the device never was in any real danger in the first place and only wanted drying.

This myth originates from the fact that dry rice is readily available in the household and, if it was stored in a hot, dry climate, has slightly hygroscopic or deliquescent properties, meaning it will absorb moisture from its surroundings, encouraging the evaporation of liquid water. If the device is merely soaked with distilled water, e.g. after step 5, see above, that actually works. There are much better options available than dry rice however, ones that work reliably for starters. Table salt for instance, or if you don't mind a trip to the drug store, sodium hydroxide or lye would be a very good option. If left open to the surrounding air, the sodium hydroxide will actually dissolve in the water it attracts (so don't throw your wet phone in the bag, or you might get a DOOZY of a surprise). Other hygroscopic materials include zinc chloride, calcium chloride, potassium hydroxide and sulphuric acid.

There is an even better option however: Use a purpose-made desiccant, like silica gel for example. it's sold in little sachets that you can seal in a zip lock bag together with your device and let it absorb the moisture. Some of the sachets are even reusable if you bake the moisture out of them in the oven.

And one more point: As detailed in the next paragraph, just drying your device isn't enough. It might give you a false sense of security now and bite you on the ass later.

If you dry your wet device in the oven or with a hair dryer right away, it will be all right 

That might actually seem to work for a while if you live in a perpetually hot and dry climate. The problem here is, the water will evaporate but leave all the substances dissolved in it behind, some of which will certainly be electrolytes. As long as your phone is really, really bone dry, that actually doesn't matter much, because electrolytes need to be dissolved in water to to conduct electricity. However, many of these salts are at least mildly hygroscopic. That means, if the air humidity is only slightly above the "bone dry" mark, the electrolytes WILL start conducting and corroding away your electronics. Either your phone will become a weather forecast device (if it acts wonky, it's going to rain soon) or it will some day soon just fail on you. Period. With hair dryers, baking ovens, microwaves (people actually do that!!!) and so on, you only get the water out. The water isn't the problem however. The stuff dissolved in it is. That's why you are supposed to rinse your phone with distilled water and isopropyl alcohol.

Placing your device in the freezer lowers the conductivity of the water molecules

First and foremost, water molecules don't conduct. Electrolytes do. Second, your freezer isn't all that cold in the general scheme of things. Freezing your device might slow corrosion down a bit, but it sure won't stop it. If that were true, things wouldn't rust in Siberia. What it MIGHT actually do is weaken the internal battery to a point where it doesn't provide quite as much potential to feed the corrosion.

However, freezing causes other problems that are definitely worse than the ones it MIGHT fix. First and foremost, there's water in your device. Water expands when it freezes. If it cracks pavements and even solid rock, do you honestly think it will have a problem ripping those tiny components off your circuit boards? Also LCD screens are notorious for their susceptibility to cold damage. In the olden days, it was recommended you put your phone in your inner pocket when the temperature dips below freezing, because the lcd might take it roughly. Today's devices aren't quite so fragile, but a night in the freezer might very well put paid to the display like the water never could have.

Soaking your device overnight in pure isopropyl alcohol will get all the water out

Yes, it will. It will also dissolve all the glue holding the device together. "Hey, YOU suggested isopropyl alcohol above!!!"

A quick dip is fine, but soaking for extended periods causes more damage than it cures. The main reason for using isopropyl alcohol is that it evaporates more easily than water, and may take away some more grime. The downside is that the very properties that allow it to wash away the grime also allow it to attack the glue in the device. For short periods that isn't a problem if it is dried right after, but an extended soak might make the glue swell up and/or dissolve, leading to problems with stability, bulging or even electrical problems if the glue was used as electrical isolation. In many phones, the screen is glued to the back of the actual front glass. If that glue is dissolved, it often loses it's clarity, leading to foggy ingressions from the rim or worse.

In a pinch, you can rinse your phone in benzene, acetone or turpentine to get the water out

That won't work at all, because to get the water out, you need something that can mix with water, which all the oily substances in this list can't. The surface tension between the different substances together with the surface adhesion and cohesion between the water molecules will actually prevent the oily substances from replacing the water in tiny nooks and crannies, where it is the biggest problem.

If that isn't bad enough for you, many of these substances can attack plastics, rubber and glue, exactly the stuff that holds your device together and your wires apart. If you soak your device in that stuff, you will get surface degradation, bulging, dissolved glue, short circuits, all kinds of fun stuff. And that's not counting the damage the water, which stays in there, will be doing. Not that that bit would matter any more.

Thursday, June 15, 2017

Emulating the Raspberryp Pi with systemd container integration

If you use the Raspberry Pi a lot, you know all about the usual pitfalls, like a new image having ssh disabled, the resolution is really crappy and the image is stuffed full of useless nonsense that nobody who wants to do any real work with the Pi ever needs.

That means that usually you flash your card, you plug in your monitor, keyboard and pointy device, you run your raspi-config, you setup your wifi if you got a Pi 3 or Pi Zero W, you kick out all the useless stuff, you upgrade everything, you install the stuff you actually want to use... aaaand you watch a lot of youtube and do other goofing-off stuff while you wait for the Pi to churn through all the stuff with its tiny processor.
 Sometimes, while you're waiting for a new Pi being delivered, you sit on the flashed SD card for a few days until it gets here so you can get to the waiting in earnest. 

You know, I've got a crazy idea: What if you didn't need the actual Pi to be physically present to configure it? Sure, sure, you can do a lot with manual config edits and stuff. But installing and uninstalling stuff, try doing that with vim! (or emacs, if you're one of that crowd).

The short of it is: It's possible. It turns out there are two ways to do it: a container, or a fully-fledged emulator. It also turns out there are some pitfalls.

How hard can it be?

The former, being fairly simple, is easy to get to run, but has some limitations - if you see the message "unsupported syscall" while you're installing or uninstalling packages, it does not make you happy. Still, since it is the easier one and suitable for most tasks, It is the one I'll show you for now.

Setting the stage

First, you'll want to install a few packages:
# aptitude install qemu qemu-user-static systemd-container binfmt-support
You might also have to manually update things a bit:
# update-binfmts
but usually the install script will have done that for you.

Then, depending on whether you want to use an image or a pre-flashed sd card, you might have to fiddle around with loop devices a bit:
# losetup -f -P --show 2017-01-01-raspbian-jessie.img
That should leave you with several loop devices, including /dev/loop0 for the whole image, as well as /dev/loop0p1 and /dev/loop0p2, guess what those are?

You can then mount the loop device wherever you want it to live:
# mount /dev/loop0p2 -o rw /thisismypi
And you'll also need
# mount /dev/loop0p1 -o rw /thisismypi/boot
especially if you plan to update/upgrade packages that might rely on the stuff in /boot being where it belongs. If you want to work on a pre-flashed SD card, it would look something like this:
# mount /dev/sdd2 -o rw /thisismypi
# mount /dev/sdd1 -o rw /thisismypi/boot
You get the picture.

Transmogrifying the image

The next thing you have to do is cd into there and edit /thisismypi/etc/ and comment out everything in there. That's highly hardware-specific stuff the emulator can't stomach. If you get really weird errors on starting the container, check that you did that first. On that note, if you get weird stuff like no USB support after putting the card into your real Pi, check you UNcommented everything again.

Last but not least, we're planning on using a chroot (that's what a "container" is, when you scrape off the fancy convenience layers and buzzwords), so whatever's not inside /thisismypi won't be visible from the chroot. This is why we have to copy our ARM binary support magic into the container:
# cp /usr/bin/qemu-arm-static /thisismypi/usr/bin
If you are unsure what to copy over, check
update-binfmts --display | grep arm
for the correct name. If you really, really, really don't want anything in your image you don't absolutely need, copy it somewhere else and mount -b the path in.

Let's roll!

There! We're done! Time to jump into our new spaceship and let 'er rip!
# systemd-nspawn -D /thisismypi
Whut? Doesn't look different... Ok, let's try something.
# uname -a
Linux thisismypi 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 armv7l GNU/Linux
Ok, so we're still on Ubuntu, but our architecture is now armv7l. Bingo! Now, let's get crazy:
root@thisismypi:/# su pi
pi@thisismypi:/ $ exit

But does it WORK work?

# apt-get update
Oh! Strange errors! What happen? Somebody set us up the bomb!
Ok, we're not TOTALLY done yet. One thing I've identified so far is that /var/lock is actually a symlink to /run/lock on the Raspberry Pi, and that doesn't get created. So do a
# cd /run/ && mkdir lock
and apt should run fine, at least I didn't have any issues afterwards. Mind, they're most likely there, waiting for me to discover them, so proceed at your own risk!

What does work, what doesn't?

Removing packages works, raspi-config works, but doesn't offer all options. You can of course edit config files at leisure.

Installing packages, hummm... MOSTLY works, but it breaks stuff if it goes too far down onto machine level, which translates to "Your image is now trash". Installing nginx or php should be fine, but I wouldn't try updating kernel modules or other low-level stuff that relies on hardware-specific quirks. Always remember: You're still on your PC hardware, no matter how much it may look like a Pi right now!

Ok, what DOESN'T work? Well for starters, all the custom hardware of the Pi isn't there, so no GPIO, no I2C, no SPI, no other goodies. Then there's everything specific to the broadcom chip, like the bootloader, etc.

To reiterate, it's still running on the very box you're sitting in front of, only qemu gives it the magic powers to run code of a different architecture, and the chroot makes the code think the world ends at the mountpoint. 

What's the worst that could happen?

Now for the million dollar question: Will it run again on the real Pi? Why yes of course it will! The whole exercise would be a bit pointless if it didn't, wouldn't it now? Now, to answer that question bluntly, the worst that could happen is the image not booting. In that case, mount it up again, back up all the irreplaceable stuff you created there, and start over with a fresh image.

Tuesday, February 10, 2015

Kitten-Proof Mousetrap Mk.II

When I put up my first kitten-proof mousetraps, I quickly found that I had made a mistake. Mousetraps are only effective if approached from the right end, otherwise the mouse can at best escape unscathed and at worst be heavily injured and suffer. Neither would be very desirable, so I modified my design to include a closed end. Here's how to modify a Mk. I to include the closed end. I'm adding the updated size formulas for cutting the cardboard at the end. If you are building from scratch, these instructions go between the folding and the installation of the trap.

1. Mark where your tube should end.
With the tube open, mark that place with a pen. If you cut the long side across the corrugation, it will now make a nice ruler for you.
I left some excess because I had a velcro spot stapled in place that I wanted to preserve. Ideally you can let it end at the end of the trap itself. As always, best leave a little margin.

2. From that point, measure outward a little less than the side's width for the first two sides, that's the inner closing side and the base.

3. Measure out a little more than the sides' width for the remaining three sides.

4. Cut off the excess as shown in the picture. You should get a little step at the second fold:

5. Cut inward as far as your tube end mark from the first step along all four folds. Cut away the part of the outer closing side (that's the fifth side as we're counting here) along the tube end mark.

6. (no picture) Fold in the first two flaps you made along the tube end mark, or whatever corrugation is closest, it's easier that way.

7. Fold in the remaining two flaps one corrugation out from the tube end mark.

8. Glue or staple the lower two flaps together so the inner closing side and the bottom are locked into a right angle.

9. Do the same with the remaining two folds so the back side and the top are also locked into a right angle.

You should now have a construction as shown in the picture, with two right angle half-boxes and a free closing flap. If you did it right, the two closing ends should slide into place nicely without touching.

Congratulations, you now have a cat-safe, mouse-friendly (so to speak) mouse trap.

Last but not least, as promised, the updated size formulas:

Width: unchanged.

Lenght: (L(paws) +L(trap)+Width*1.1) *1.1.

Be sure to include the extra margin as you'll cut some of it back off!

Kitten-proofing mousetraps

Update: This is the Mk.1, which has some flaws which I since identified. Be sure to check out my post on the Mk.II, it will save you some time and effort.

Mousetraps and kittens don't mix. Kittens - or cats for that matter - are curiosity incarnate, and many of the baits we regularly use in mousetraps smell delicious to cats. If your cat gets into your mousetrap, the best case is a broken paw, the worst case is a smashed skull - with all the unpleasant things in between. Now, we have had1 a kitten, and we had a mouse in the larder.

Do not despair, cat lovers, I didn't put my sweet purr machines in danger - and I'd like to share my briliant concept with you, so your cats can purr in safety too. Behold - the kitten-proof mousetrap!

Yeees, the mouse trap is in the tube, got it in one. Here's how to build your own.

1. Measure your cat's arm.

Yes, I'm dead serious. Holes and tubes are even more interesting to cats than anything else, especially if they smell like delicious bacon might be in there, so it has to be long enough and then some, because cats have a strong urge to probe such tubes with their paws. Yes, that could defeat the purpose of the whole project if the tube is too short! 

NOTE: Do I need to mention that if you have more than one cat, you have to measure all of them and use the greatest arm length? Don't guess, cats vary a lot in stance and build. You'd be amazed to find that a 5 lb kitty can actually have a longer arm than a 14 lb tom.

Here's how to measure correctly:

Your cat's arm is built exactly like yours, it has an elbow, a wrist and fingers. Because cats walk on their fingertips basicly the wrist is somewhere in the lower third of the long part of the paw. The wrist is the thing cats sometimes fold under their body when sitting. (See monorail cat pictures for details). Above that comes the elbow. Above that the shoulder.

The best way to get your cat's arm length is to stretch the ellbow with two fingers and your thumb  (don't use excessive force!) and quickly measure from the shoulder to the tips of the (by now probably extended) claws. Make sure your cat is in a good mood, be quick about it and have some bactine or iodine ready just in case. Cats move their arms into this pose when they stretch, so they are not too averse to letting you do it, provided you are polite, quick about it and there's the prospect of some treats.

You will probably have some error in your measurements - try to err on the generous side.

2. Measure your mouse trap.

Mouse traps vary widely in shape and size, so get the measurements of yours lest you complete the project to find out your trap won't work in the tube. The measurements you want are:

  • Width of the trap
  • Total length of the trap
  • greatest height of the trap during the action. Hold the kill bar in place straight up, place the trigger wire across where it would be, measure from the ground. Don't forget the thickness of the base board!

3. Cut some cardboard.

The right material is 3-5 mm corrugated cardboard. It should be strong enough to stand up to some cat attention and mouse teeth, but not so strong you can't get the folds in properly. If possible, cut so the corrugation is parallel to the short side for added stability.

Here's the formulas for the measurements:

Lenghth: (2 * L(paws) + L(mousetrap))*1.1

Note here that I added 10% extra safety margin, because it's amazing how long cats can make themselves if they want something just - out - of - their - reach - almost - got - it...

Width:  5 * (n* 1.1) ,where n is the greater of the width of your mousetrap and the maximum height during action.
Again I added 10% margin, because the folds take up some room and the whole construction gets too tight otherwise.

4. Fold the cardboard.

Corrugated cardboard isn't easy to fold. If you aren't among the few luckies who have a metal folding machine, try the following technique:
 first mark the folds

 then carve in the folds. Use the edge of a two-by-four to hammer in the folds with a rubber hammer (or any other if you're not concerned about the wood)

last, bend the folds carefully. Make sure the bend really follows the pre-cut folds.

repeat for all the other folds. Bend them well to make sure it assembles into a tube flawlessly later. Pro tip: break the folds backward to increase the flexibility.

5. Place the mousetrap

Measure for the middle of the tube you assembled and place the mouse trap there. I like to attach it with velcro spots for easier cleaning/loading etc.

6. Place some velcro spots or strips to hold the tube closed. 

Don't be too sparing with those, that cardboard retains an amazing amount of spring tension and an opened tube defeats its purpose.

Now load the trap and carefully close the tube. There - you're set!

Update: When I designed this, I forgot that mouse traps are kinda directional weapons. Stuff some kitchen tissue paper into the end of the tube that  faces the back side of the mouse trap, or else modify it into a Mk.II which corrects that problem.

1(different story there, not a nice one, gonna spare you)

Saturday, June 29, 2013

Followup on mute/aumix not working on ubuntu 10.10+: error opening mixer

You know, sometimes I feel like crying.

Whenever something just works, somebody comes along and sticks his/her fingers into it until it stops working. Remember when I told you about the convenient little mute command on my Debian Lenny? Well, when I tried it on Ubuntu 11.10, imagine my surprise when it said "error opening mixer: no such file or directory".

A quick glance at the source of /usr/bin/mute revealed it to be a convenience wrapper around amixer - which I also told you about already.

Here's the source of /usr/bin/mute like I found it

volumes=$(aumix -vq |tr -d ,) 
if [ $(echo $volumes | awk '{print $2}') -ne 0 -o \ 
        $(echo $volumes | awk '{print $3}') -ne 0 ]; then 
        aumix -S 
        aumix -v 0 
        aumix -L > /dev/null 
Well, well well, what have we here. They're actually using aumix a lot like I did in my volume bar script, to generate easily-parseable output.

A  quick strace revealed this:

open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 
fstat64(3, {st_mode=S_IFREG|0644, st_size=4443504, ...}) = 0 
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7580000
access("/dev/mixer", F_OK) = -1 ENOENT (No such file or directory) 
open("/dev/sound/mixer", O_RDWR) = -1 ENOENT (No such file or directory) 
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb779f000
write(1, "\n", 1) = 1

So the mixer device is missing. This should in principle be easily fixed by installing the oss-compat package - which unfortunately in my case was installed.

A bit of research helped me understand some of what is going on. oss-compat doesn't do much else but modprobe some oss modules into the kernel, e.g. snd-pcm-oss. Unfortunately, a system- and repository-wide search for said modules came up blank. Without anything to modprobe, the oss-compat package is as useful as a fire hose without water. This link here tells me that the bug was "fixed" by blacklisting whatever stuff - in my book that's sticking your head in the sand if I've ever seen it. Or should I say: abandoning the old and crippled along the path?

So, without going into a lot of background research about the decision-making process and the communication between the relevant groups, in a nutshell, this is what likely happened:

Somebody decided to take the (allegedly) obsolete OSS modules out of Ubuntu 10+, and whoever maintains amixer and mute didn't get the memo - nor did the guys maintaining oss-compat or a number of other packages. Also nobody bothered to check if the removal /dev/mixer and friends  would break anything and take the appropriate action - like notifying the maintainer of the relevant packages and if need be, blacklisting them from release until the problem is fixed.

What's wrong with those guys, can't they communicate? This is the 21st century, people, it's not like you have to rely on mail coaches coming through on treacherous, bandit-ridden roads! Whom did those modules hurt? Well their lack hurts somebody, so I reckon something went wrong there.

OK, no point complaining, less whiney, more fixey.

To my best knowledge and web searching skills, there is currently no trivial way to get those modules short of a custom kernel compile.  A lead to a blacklist file in linux-sound-base didn't yield any results either - whether it's there or not, the result stays the same. Chatting with the guys in #ubuntu-devel on freenode finally yielded something besides heartfelt agreement that it shouldn't be like this either: the hint to use osspd, even if they were their usual grumpy self about it. Installing that instantly got aumix working again in principle - except for the basic functionality of controlling volume output. The reason, as far as I can determine, is that the mixer device provided by osspd affects only programs handled by the osspd-provided emulation, but commands made through it do not distribute up into the "real" sound architecture osspd sits on top - which makes osspd a very poor substitute for a real OSS compatibility layer on top of the sound architecture.

So - how does it all sum up for a bottom line? Realistically speaking, aumix and mute are writeoffs in Ubuntu, together with oss-compat and anything else still depending on OSS architecture. It MAY be possible to get some of it working again by putting in enough work, but again realistically speaking it would probably be more work than to switch to a distro still supporting OSS natively.

Considering the fact that I switched to Ubuntu from Debian originally to get a smoother running distro without so many political snatches, I must say I am not amused. While I agree that sometimes stuff must be phased out to achieve progress, sustainable progress cannot be achieved by trampling any inconvenient stuff underfoot. Smooth running should not be achieved by greasing the brakes. Sometimes (more often actually) I feel more like banging heads together than crying.

As for the practical aspects of the problem, a little more sedding and awking will get equally good results with amixer than with aumix, and eventually, someone will shove a script similar to the one I provided in this article somewhere into the Ubuntu/Debian repos, and we'll have hassle-free muting and unmuting of sound again. Until then you're welcome to stick with me for workarounds.

That's it for today, as always, thanks for reading and have fun.

aumix and mute not working on Ubuntu 10.10+

As I wrote elsewhere, some dunce decided we didn't need /dev/dsp et al any more and failed to notice that several utilities depend on those files being available, among them aumix and mute.

That means among others that my nifty, shiny volume bars described in this post are no longer working. I'm working on a permanent fix, but for now, to replace mute just use this script:
if [ -e $HOME/.mute-save ] ; then #muted
        amixer sset Master,0 $(cat $HOME/.mute-save) #restore
        rm -f $HOME/.mute-save #and delete the storage
else #not muted
        echo $(amixer sget Master,0|egrep 'Playback[[:space:]]+[0-9]+[[:space:]]+\['\
        |sed -r -e 's/.*Playback[[:space:]]+([0-9]+)[[:space:]]+\[.*/\1/') > $HOME/.mute-save #dissect the amixer output and save it
        amixer sset Master,0 0 #and mute
exit 0
Please excuse if I don't go over it line by line today but I've had a bad day so far and it don't look to be getting better. It's a hack, and it's not so different from the original mute script Just the gist of it: the egrep call makes sure we select the right line from the output and the sed call dissects the actual numeric volume value from it. That's all for today folks, enjoy and have a nicer day than me.