Log

I tripped on this issue awhile back (when a lightning strike killed one of my nics), but in all the recovery chaos I neglected to document the issue.  And so I tripped on it again just yesterday when I juggled nics between two machines.

The issue is that udev makes a note to itself of which mac addresses correspond to which ethernet device indicators (eth0, eth1, etc..), when they're initially discovered.  And then it 'reserves' that indicator, so if, say, you pull out the nic that was eth0 and put in a new one, it won't get eth0, which is non-intuitive (at least if you've been installing nics for years).

The fix is easy, though.  Just edit the following file:

/etc/udev/rules.d/70-persistent-net.rules

You can either delete the line that contains the indicator that you want to reassign, or you can just edit the mac address itself.  A reboot (or possibly even a restart for udev - I don't know I didn't try) will get the new nic exposed as expected.

It can also be helpful to just run: 'ifconfig -a' if you're not sure which nic got assigned which ethernet device indicator.

Apparently some of my video cards are now officially decrepit.  A recent world emerge broke X for me because my two nvidia geforce FX5500 cards are now on nvidia's 'legacy' list, and no longer supported by the latest (or future) drivers.  It's nothing a quick edit to /etc/portage/package.mask didn't fix:

>=x11-drivers/nvidia-drivers-177.0.0

Then the following steps got me back up and running:

• emerge -avt nvidia-drivers

• update-modules

For reasons that I'm sure involve lawyers, VirtualBox OSE requires some human intervention to correctly install.  The 'additions' iso is flagged as unfetchable by emerge, so it must be downloaded manually and put into /usr/portage/distfiles.

http://download.virtualbox.org/virtualbox/1.6.6/VBoxGuestAdditions_1.6.6.iso

Obviously, '1.6.6' should be changed to the version du jour.

Once you've moved it to /usr/portage/distfiles, be sure to correct the file settings:

• chown portage:portage /usr/portage/distfiles/VBoxGuestAdditions_1.6.6.iso

• chmod 664 /usr/portage/distfiles/VBoxGuestAdditions_1.6.6.iso

The issue only manifests if you've got the 'additions' use flag enabled for app-emulation/virtualbox-ose, which you probably do because it's neato.

Oops -- apparently a well-known ~x86 dependency 'bug' was allowed to surface in stable gentoo.

Here's a forum post and a bug report.

Here's the recipe I used to get around the recent shenanigans associated with e2fsprogs-libs going stable.

1. emerge -uDavft world

• That ensures that the packages are pre-fetched,which is critical to this recipe working.  The unmerge that happens below temporarily eliminates the ability to fetch portage packages.
  

2. emerge -avt1 --nodeps e2fsprogs-libs

3. emerge -avt --unmerge com_err ss

4. emerge -avt1 --nodeps e2fsprogs-libs

5. emerge -avt1 --nodeps e2fsprogs

6. emerge -avt1 --nodeps mit-krb5

7. emerge -avt1 --nodeps e2fsprogs-libs

8. emerge -avt1 --nodeps e2fsprogs

9. revdep-rebuild -v

Then world updates can proceed, or whatever else you planned on doing.

I run nightly backup scripts, which email me a summary report that includes, among other things, information on disk usage.

I'd been watching the percentage creep steadily up on my main (root) mount drive with increasing concern, but not sufficient concern to actually investigate what the culprit was and whether or not it was a legitimate use of drive space.

Except the other day the percentage finally got dangerously close to 100%, so I finally had to stop putting it off and figure out what was going on.

Turns out it was embarrassingly simple.  MySQL was happily generating binary log files which tracked Every Single Thing it did, ever, all the time.  Just like it was told to do by my /etc/mysql/my.cnf file (via the 'log-bin' option).  Only apparently the files never go away and don't participate in the normal logrotate process (for obvious reasons, once you understand the purpose of the binary logs).  So they just keep piling up, indefinitely.  To the tune of ~25GB, in my case, for a small set of low-footprint MySQL databases running since about 2006.

Once I understood the situation, it was easily remedied by adjusting the options I supplied to the nightly run of mysqldump (which is what I employ as my MySQL backup method):

--flush-privileges
--flush-logs
--delete-master-logs
--master-data=2

The critical one was '--delete-master-logs', not surprisingly, but the other ones came along for the ride as I waded through the mysqldump man pages.

"Why not just disable binary logging", you ask.  Because they're actually a good thing, which is why they're enabled by default.  In a disaster recovery scenario, they let you bridge the gap between your last full backup and whatever transactions occurred until the point of the disaster.  The issue wasn't that they were being generated, it was that they weren't being cleaned up each time I did a full backup (at which point they become superfluous).

So.. the moral of the story is the age-old lesson that computers always do precisely what you've told them to do, whether you actually want what you asked for or not.

There are lots of ways to capture image buffers in an X-Org based environment, but I found one that I preferred, and it's ImageMagick's 'import' utility.  Very flexible, and more importantly, well documented and maintained.  Out of the box, it does time-lapse multi capture, which is generally what I'm after when I'm playing games (which I'm doing more and more of on Linux and not on Win32) and I want to have a framegrabber running in the background taking periodic grabs.  A line like the following will get the job done adequately:

import -depth 32 -pause 10 -quality 100 -silent -snaps 5 -window "Foo Bar" foobar.png

I'm probably going to cook up a little python script that leverages import, rather than relying on just the command line, since it will provide greater control and flexibility for a session-based use of the tool, and because it looked like import keeps all the grabs in memory until it's done, which isn't suitable for accumulating a lot of images in one session.

This worked a lot better than other attempts with things like scrot, fbgrab, etc..  xv is good for one-off manual grabs, but doesn't provide any automated time-lapse feature, which is what sent me googling in the first place.