DBAN notes

In case  blogspot disappears into the ether, here are some notes if you’re using Unetbootin and a USB key for DBAN in OS X or just happen to run into the “Could not find ramdisk image:/ubninit” error.

  1. If your machine is old you’ll likely need to turn off UEFI/EFI boot and put the BIOS into legacy USB Boot mode.
  2. In OS X using Disk Utility or Terminal wipe your USB key and reformat into a single partition with FAT32/MBR.
  3. Download DBAN’s latest .iso.
  4. Open Unetbootin on the Mac, choose the above .iso and hopefully your USB has mounted as /dev/disk2 or 3 or 4 or whatever to be set as the target destination.
  5. As taken from Stephen Greenhalgh’s DBAN USB Unetbootin Fix Post:

To fix this insert the USB drive back into a computer and open up “syslinux.cfg” in a text editor. Find and replace all occurrences “ubninit” with “ISOLINUX.BIN” and do the same with “ubnkern” with “DBAN.BZI”. Make sure that you match the case.

This worked for me using DBAN 2.3.0.

Consolidating photo libraries from multiple drives

I’m trying out “The Big Mean Folder Machine” version 2.29 to consolidate (or “merge”) various years of photo cruft.  The process of culling and consolidation will hopefully allow me to have a single photo directory backed up to Amazon Glacial forever.  I believe as I mentioned in another post, mechanical disks fail so having a redundant and offsite backup strategy is crucial.  And certainly a key part of of this is limiting the number of places you’re storing your local data so that you can create redundancy.

I’ll write more here when I get all this data and drives sorted out, but so far I was able to run a scan and it the BMFM was able to create a folder hierarchy from multiple drives.   I may need to do some merges first and then a split.

SSH debug


The crux is that SSH even when connecting w/ -vvv  or -vT modes won’t tell you precisely why it’s not connecting for obvious security purposes.  This is presuming you’ve double checked all other obvious issues and your public/private key pairs are setup correctly.

In the linked post above Kent Martin writes, the answer is to bind debug to an alternate port on the server side:
/usr/sbin/sshd -d -p 2222

then similarly from the client machine:
ssh -v -p 2222 user@machine_I_am_trying_to_ssh_to

On the server machine terminal you’ll see a more verbose debug log and hopefully it will tell you exactly why your client machine is being rejected.