Adventures in Cloning

Last week, I started seeing the emails from my server: the disk hardware early failure detection system, known as SMART, was beginning to spot errors on a disk in the server that powers this domain (and a few others). I sort of plan for disk failures, but I hate … hate … hate them. It’s not just because of the obvious time it takes to replace the drive, but because even with backups I have NEVER in 24 years of using Linux succeeded in completely cloning, copying, and spinning up on new hardware an old drive.

This time I did it. But it was NOT without drama. Here is a small how to on the following:

  • Cloning a hardware disk image to a software disk image;
  • Writing the disk image to new hardware and dealing with the consequences;
  • Reinstalling the ability to boot the drive (my failed disk was the boot disk on the server)
  • Swapping the old and new drives.
Continue reading “Adventures in Cloning”

Fall down, go Vroom

Like many institutions, I’m using a video conferencing client whose name rhymes with “Vroom” in order to conduct classes. Things were going great for the first 2 weeks. Last Friday, things took a serious turn.

It all started with a long-standing problem on my home desktop machine. I run Ubuntu Linux 18.04 on a hand-built computer. The board is an Intel motherboard from about 5-10 years ago. I use an NVIDIA-based graphics add-on card, and like all Linux users who employ NVIDIA technology, I have made a Faustian bargain. NVIDIA cards are cheap and faster than their competitors, like AMD, for the same price point. But, their drivers are closed-source. Sure, I can use the “Nouveau” open-source driver… but then I cannot have two monitors connected to the card, and I need two monitors for work reasons (not the least of which is the utility of having two monitors when teaching with Vroom).

So I use the proprietary driver. But this seems to make my desktop graphics unstable. The old symptom was that the KDE window environment’s graphics compositing system would reset, usually at least once an hour (it doesn’t matter if I use XRender, OpenGL2, or OpenGL3… for those of you who care about the details). If I were running a lot of programs that take advantage of graphics capabilities (and I don’t mean anything fancy here, just a web browser and a code editor will do the trick) the compositing system resets happened more often. Sometimes, the graphics shell freezes and needs to be restarted; sometimes, the window manager crashes.

I tried buying and installing an AMD card on my system (they play nice with open-source), but the easiest cards to get are of a generation that doesn’t work with my motherboard (too new). The past generation cards are used and expensive, with worse graphics memory than my NVIDIA card. So that didn’t work for a bunch of reasons, not the least of which was the system would not even boot up!

I’ve tried using different generations of the NVIDIA drivers for Linux (there are BUNCH). I tried older generations, which seemed to help the graphics resets… but didn’t completely stop the problem.

Then, on Friday (on top of all of this!), all hell broke loose with Vroom. Suddenly, the client couldn’t stay up for more than 10 minutes at a time. It would crash and completely interrupt a meeting or class. It happened again tonight during Honors Physics. It was MADDENING.

I realized that although I updated the Vroom client about 10 days ago, a new version is already available. I upgraded that tonight. Who knows if that will solve it?

Bottom line: I have to have my laptop up and running as a backup teaching system in case the desktop goes down in flames. Vroom is another kind of Faustian bargain [1]: easy-to-use video teaching and conferencing capability, at the expense of no clear control over privacy and identity and a closed-source software architecture, which invites flaws by accident and design.

Sigh. When the smoke clears on all of this, I hope to have some time to slow down and think about the long chain of technology issues that are piling up at home. But there is no time to think now…

[1] See Doc Searls’s excellent series of posts about Vroom and all the good and bad it can do:

P.S. There is no Linux PPA to automatically install the latest Vroom (THANKS, Vroom). I wrote a cron script that others might find useful to check for a new version and install it if one exists)


if [ ! -e "/var/spool/zoom" ]; then
   mkdir -p /var/spool/zoom

cd /var/spool/zoom/

if [ -e "zoom_amd64.deb" ]; then
   rm -f zoom_amd64.deb

wget ''

old_version=$(dpkg -s zoom | grep '^Version:' | cut -d ' ' -f 2)
new_version=$(dpkg-deb -f zoom_amd64.deb Version)

if [ $old_version == $new_version ]; then

while fuser /var/lib/dpkg/lock; do
    echo "Waiting for dpkg lock to be released..."
    sleep 30

dpkg -i zoom_amd64.deb

What I learned this week

I have really thrown myself into physics, since I am stuck at home (a) because there is a pandemic and (b) because SMU won’t let me on campus until tomorrow (because I was abroad when they ended work-related international travel 2 weeks ago). This has been a grand opportunity. Here are some things I learned this week.


UPROOT is awesome. It lets me utilize natively in Python files created in ROOT. No more do I need to have ROOT compiled in the background, along with its Python interfaces. I can just import UPROOT and load ROOT files into Python Pandas dataframes, which anyway are how I prefer analyzing data these days.

UPROOT was introduced to me by my former PhD student Matthew Feickert and my current PhD student Chris Milke. I’ve been using it for several weeks to work on a project with one of my undergraduate research students. However, for high-level physics operations, like dealing with four-vector mathematics, ROOT is hard to beat. Turns out, there is a solution.

UPROOT-methods! These are implementations of interfaces akin to C++ classes in ROOT that do cool physics things… like vector arithmetic! I just learned about this today and already did some Lorentz Transformations on particle vectors. I’m pretty happy about this.

MatPlotLib Subplot Gridding!

Sometimes you just want to layout a bunch of graphs in a single plot in a non-uniform way. Consider the following graph:

An analytic model is fitted to data from a muon detector at SMU. The top plot is the number of muon candidates vs. their measured lifetime. The bottom plot is the “model pull” – the difference in each bin of the lifetime measurement between the real counts and the fitted model prediction, divided by the standard deviation of the counts in the bin.

I need to show the fit of an analytic model (an exponential lifetime model) to the data coming from a muon detector in the basement of Fondren Science Building at SMU; below that, I need to show how well the model describes the data after optimizing the model parameterization to reproduce the data. To do this, I need a big plot at the top and a short plot at the bottom. I needed plot grid layouts!

I found this article extremely helpful: (it’s how I made that figure above!)

Online Teaching Tips

How do you mute all those jerks with hot mics in Zoom? WHY WON’T MY F**KING MAC LET ME SHARE MY DESKTOP?!?!?!

Check out these tweets.

Planning new experiments and particle colliders is fun

I’ve been participating in a workshop (online only) hosted by Temple University on physics and detector design ideas for the Electron-Ion Collider, a project planned for construction at Brookhaven National Accelerator Laboratory. I’m still just beginning to think about bottom quarks and how to use them to probe structure in protons and nuclei, and the discussions at this workshop have got me thinking about how this problem changes when going from the LHC to a different collider designed to probe such matters with high precision.

What have I learned? I have a lot to learn.

A Trip to the National Video Game Museum

Thanks to a visit from an old friend (now Prof. Katherine Rawlins at the University of Alaska in Anchorage), we discovered the existence of and visited the National Video game Museum (NVM) last weekend. It was awesome. It was a tour of the computers and games of my youth; a reminder of how I got into computation in the first place; and a fun excuse to play old video games.

Continue reading “A Trip to the National Video Game Museum”