Wednesday, July 20, 2022

Docker BadBlocks

I was wanting to run badblocks on a couple of external hard drives before shucking, and of course I had to over-complicate it.

I bought a Lenovo ThinkCentre last year for the express purpose of serving as a Docker server, so other than the tutorial, this is the first thing I’m doing with it.

Writing the Dockerfile was easy enough:

FROM alpine:latest
RUN apk add --no-cache e2fsprogs

Build with sudo docker build -t badblocks . (note the period at the end.)

A docker-compose.yml would probably be the correct thing to do, but for now I’m just going with the following command:

sudo docker run -v "/home/matt/bbout:/home/bb" -v "/dev/sda:/dev/sda" --name bbsda -dit badblocks

This runs in detached mode, but lets me dip in and out as I please. I think the proper way would be to just run the badblocks command in the initial command, but that will be in the next iteration.

Per the documentation: 

To stop a container, use CTRL-c. . . If the container was run with -i and -t, you can detach from a container and leave it running using the CTRL-p CTRL-q key sequence.

Start badblocks with sudo badblocks -c 2048 -sw -o /home/bb/sdaout.txt /dev/sda

I’m getting a response “ash: badblocks: not found” when I run as su. I’m sure it’s something dumb.

I appreciate the lightweightness of Alpine, but sometimes it gets to me when I can't even run man badblocks to see if everything is installed like I expect.

A tiny bit more experimentation also gives me the "badblocks: not found" when I install and run in Alpine via WSL rather than Docker. So I guess it's more likely than not that it's an Alpine problem (or more accurately, a PEBAAC (Problem Exists Between Alpine And Chair)) rather than a Docker problem. In some ways this is frustrating, but at least I have a better idea of where to focus my searches.

I'll just keep flailing in the meantime.

Update 2022-07-21

I got it! Alpine has more than just one e2fsprogs package. And as it turns out, badblocks is only found in e2fsprogs-extra.

So now my Dockerfile is as follows:

FROM alpine:latest
RUN apk add --no-cache e2fsprogs-extra

 Build and run using the same commands, and:

badblocks: Operation not permitted while trying to determine device size
Do some more digging, and aha! I need to set the hard drive up as a device, not a volume. I kind of wondered about this at the beginning, and wasn't sure that /dev/sda would be interpreted correctly. So now my command is:

sudo docker run -v "/home/matt/bbout:/home/bb" --device=/dev/sda --name bbsda -dit badblocks

 And yet another issue!

badblocks: Value too large for data type invalid end block (13672382464): must be 32-bit value

 Update 2022-07-23

Seems like the 32-bit limit is not only a known issue, but also intentional design, at least as of 2021.

Anyways, the workaround I found is to just change the command to actually run badblocks to

sudo docker exec bbsda badblocks -b 4096 -c 2048 -sw -o /home/bb/sdaout.txt /dev/sda

Upping the block size to 4096 lets it run! So now I have it running on both hard drives.

If I feel particularly inspired, I may write a simple bash script that lets me just type badblocks.sh [drive name here] and slot in sda/sdb/whatever to the Docker commands. The way I did it this time leaves a lot of room for error on forgetting to change sda to sdb in all the different places.

But hopefully these drives will all run without errors and I can shuck'n'drive them into my NAS and not worry about it for a few years.

Monday, May 16, 2022

How to Sweep Resistance During Simulation in Altium

I wanted to simulate an op-amp circuit with Altium Designer to determine the Vout as I sweep through RTD (Resistance Temperature Detector) values.

"But Matthew! Why not just use LTspice like all of us cool kids?"

Well first off, LTspice has the most baffling shortcut key setup. I'm sure it made sense in the late 80s or something, but in this century I expect Ctrl+C to be "copy." Also, if my MSRP $8,000 piece of software includes simulation support, seems like it ought to work.

Unfortunately, by default, Altium does not offer an easy way to simulate the response of sweeping a resistor or potentiometer. A parameter sweep is offered, but this essentially runs a new simulation for each parameter change, rather than a continuous, interpolated output curve. This would be handy if I wanted to see what happens when I sweep Vref from 0 V to 5 V, with the RTD at a few values from 1 kΩ to 1.887 kΩ, but that's not what I want here.

BUT! After some searching, I discovered that SPICE does support using DC Sweep Analysis to change a resistor value, even though Altium does not show this as an option.

Here's my solution:

  1. Create a dummy voltage source. I called it Vrtd to keep track of it, but it doesn't really matter.
  2. Note the name of your resistor you want to vary. In my example, I cleverly named it "RTD".
  3. Set up a DC Sweep Analysis, using Vrtd as the primary source.
    1. Set this up to sweep from 1k to 1.887k, with a step size of 443.5.
  4. Save all, validate project.
  5. Go to Design > Netlist for Project > Xspice.
  6. Open the resulting .nsx file.
  7. Find the line that says ".DC Vrtd 1000 1887 443.5".
  8. Change this to ".DC RTD 1000 1887 443.5".
  9. Save.
  10. Run the simulation from the .nsx file.

If all goes well, you should see the voltage curve of your desired net plotted with the resistor value along the X axis, and the resulting voltage along the Y axis.

Huzzah!