Category: Computers

Linux network init failures especially in virtual machines

My situation is a virtual machine image that I want to use in multiple places, running it on multiple host systems (it lives on an external disk drive, so it’s easily taken to these various places). The host systems in my experiments are all Windows 7 boxes.

The symptom is that, when booted in a new environment, networking in the guest Linux installation doesn’t come up. Specifically, I see IPv6 addresses assigned but not regular Inet addresses.  Sometimes, the boot brings up the setup utility (but there’s nothing I’ve found to configure the network in a way that’s useful there).

It appears that fairly common network init code in Linux is remarkably unstable when a disk (or disk image) is migrated from one real or virtual system to another.  This code seems to exist in a wide range of Linux distributions, but my actual experiments have been with Centos 6.4 guest systems in a Virtualbox VM.

The root cause seems to be that Linux stores a UUID for the network connection and the MAC address both in  /etc/sysconfig/network-scripts/ifcfg-eth0 and /etc/udev/rules.d/70-persistent-net.rules. When you create a new virtual machine, you get a new MAC address (and it asks you if you want that even if you copy one). And you really don’t want multiple machines with the same MAC address operating in the same LAN segment (or larger bridged network).

The solution is, after booting the new virtual machine from the old disk image, to log in and do some configuration editing.  (Note: Since the network doesn’t come up, you can’t get in via SSH.  And you can’t paste into the Virtualbox console window.  Thus you must know a password for a sudo-capable account, and type it in manually. Given my penchant for 20-character random passwords, this was a royal pain.) Specifically, I deleted the hardware (MAC) address and the UUID lines from ifcfg-eth0, and the entire line referring to etho from 70-persistent-net.rules. I then rebooted the system.  (There are arguments that just restarting the network would suffice, but when I tried that earlier this afternoon it did not appear to work. I have not investigated that bit further.)

I also had a huge amount of trouble finding clear enough discussions on the web, and had to do a lot of experimenting to get this result.  And I had enough cases of a VM that brought up networking one boot but not the next that I’m a bit worried still.

The End of Adobe

Or at least, I hope they finally get some competition.

Because they have just decided that I should pay $360 a year instead of about $200 every two or three years to use Photoshop.  Which is totally out of the question.

Worse, they claim the early response to their subscription model has been highly favorable — when everybody I know absolutely hates the idea, because it means we’ll be paying a huge amount more money.

So; the key features missing from Gimp seem to me to be adjustment layers with layer masks (including 16-bit layers), and plugin integration.  I may have to give up photography and work on photo software development for a while, or something.

(There’s also the same problem with Lightroom, and Bibble sold their great product to Corel who have ruined it and I think made it not an option for bulk processing in the future, so I have problems there, too.  Well, everything will work for a little while, until I get a new camera, at least.)

I would urge everybody to do everything they can to avoid giving Adobe any more of your money, and to support viable competitors.

Every Now and Then Perl Bites You in the Ass

Supposing you want to use a constant, for all the usual reasons, to configure the name of an environment variable you need to check.  So, you say

use const DANGERENV => 'RUN_DANGEROUS_TESTS';

Then, you use it to check existence and pull up the value of the variable

my $dangerEnvVar = $ENV{DANGERENV};

Anybody see this coming without previous experience being bitten on the ass by it?

So far as I can tell, the all-caps bareword in {} gets treated as a literal, rather than expanded as a constant; so it looks for environment variable DANGERENV, not RUN_DANGEROUS_TESTS. And fails to find it, of course. Oops! Perl is sometimes just slightly too smart for its own good.