set -g -s escape-time 0
21 October 2020
I’ve occasionally been using a SSH session from my Pixel phones for years to login to my servers and write Clojure code in Emacs. I’d often run into an issue where I find myself having a weird time switching between NORMAL and INSERT modes when I’d hit ESCAPE quickly and try to move the cursor.
Googling my random problems
is a favorite pastime,
and I’ve finally stumbled
upon an article about
tmux and vim escape key.
that it’s probably been
sporadically eating my ESCAPE key,
so I’ve tried disabling the built-in delay
by adding to my
set -g -s escape-time 0
07 January 2018
A couple years ago, I replaced my old spinner drives with matching SSDs. I left the old drives mounted but disconnected the cables. I’ve been watching my photo collection grow and consume about half my live storage, so I figured it was time to bring those slower spinning drives back online, so I can move my archive of old photos off my fast drives and get a little extra room.
I plugged in the first drive,
and observed that it fortunately did not try
to join the existing RAID arrays.
lsblk showed me a list of drives and partitions
and how they were currently used,
so I could confidently
to wipe and recreate 1 primary partition on the drive
fd (Linux raid autodetect).
I rebooted to see the new partition table,
and then installed and did the second drive
/dev/sdb in my case).
I setup the new drives in a mirror:
# create a new RAID1 mirror out of those new partitions: mdadm --create /dev/md2 --level 1 --raid-devices=2 /dev/sda1 /dev/sdb1 # to ensure it's still called md2, and not md127 on reboot update-initramfs -u # create a filesystem mkfs -t ext4 /dev/md2 # mount it to copy mkdir /mnt/new mount /dev/md2 /mnt/new # migrate all my photos rsync -av /home/john/Photos/ /mnt/new
After the initial migration, I tested it:
Checked that the array is there with the same name:
(It initially had not kept the name,
and that’s when I learned
Mounted the new array as
Checked that Digikam still works.
That looked good, so it’s time to make it permanent:
Unmounted the new filesystem
Deleted all the old contents of
Added the new array to the
/etc/fstab to mount it automatically
05 January 2016
I’ve moved the blog to a static site generated by JBake. The source for the content lives in my techblog project in Github, so I have a full versioning of my content for the small price of a git workflow.
I installed JBake using the familiar SDKMan that I already use to manage my Grails and Groovy installations. I initialized it with the Groovy templating engine and have started customizing the templates.
To make sure this thing is easy to update, I keep a local clone of the repo, so I can update it any time and push whenever I’m ready. I have a shell script scheduled to run on the server which basically does:
cd techblog git fetch git merge | grep "Already" > /dev/null || jbake
That little bit of code
git pull doesn’t say "Already up-to-date".
That provided me a simple little "continuous integration" hook
that polls git for changes to trigger the build.
I’ll probably use this trick in other places.
I brought all my old content from my old database into the new platform using a quick little Groovy script to dump out an HTML file for each article including the header of metadata for JBake’s use. While most of these old articles will remain HTML, I intend to use AsciiDoctor format for all the new stuff.
I’ve been collecting a long list of (mostly technical) articles to write, but replacing the old platform kept trumping my attempts to write. Hopefully, this move can open the flood gates, and eventually, I’ll break out another instance of it for the photography blog. JBake should make it easy and interesting to continue the blogs.
13 December 2012
I realized upon trying to replace a drive in my Linux software RAID, that I had never previously documented this process.
The power failed a couple days ago, and sitting around for 10 hours not spinning was bad for my one Western Digital 500GB drive, so it never came back online, but the computer booted up just fine with 2 of the 3 drives. I ordered a new 1GB drive to replace it within 2 hours of the problem.
When the new drive arrived, I shutdown the computer, unplugged the failing SATA drive, and replaced it with the new one. Linux again booted up with only 2 drives active.
To ensure that the partitions matched, I did an
sfdisk -d /dev/sda | sfdisk /dev/sdb.
cfdisk was unhappy with the drive initially, but
fdisk was happy to read the table and write it back cleanly. Then I could open it again in
cfdisk and add one more primary partition to use the extra non-redundant 500G on the new drive.
With the partitions in place, it was time to insert the new
partitions back into the RAID devices:
mdadm /dev/md0 --add /dev/sdb1,
mdadm /dev/md2 --add /dev/sdb5, etc, until all the drives were re-established. Watching
/proc/mdstat, I could see that the RAID started recovering the devices, and I could go to bed.
I did manage to do something wrong at one point, so a quick
mdadm /dev/md0 --fail /dev/sdb1
mdadm /dev/md0 --remove /dev/sdb1 allowed me to fail and remove a partition, fix it up, then add it back when I was done. All this could be done with the system up and running—that's pretty convenient.