Installing Linux via Bootable USB

Most of my Linux experience has been with Ubuntu. If not Ubuntu, then a relative flavor with Linux Mint and some slight tinkering with elementaryOS. The great thing about these three is that you can easily create a bootable media for either running a live desktop to test or to install thanks to the Startup Disk Creator application that ships with Ubuntu and Linux Mint both (and likely eOS also, but I didn’t check).

If you want to create a bootable media for another distribution, you’re out of luck with Startup Disk Creator. Even Debian distributions, which Ubuntu is derived from and actually show up in the pane listing ISO source images to use in Startup Disk Creator, won’t complete write to the USB drive without spitting out an error right before it would normally queue for password to write the boot record onto the media.

You’ll get a few different opinions on how to create a bootable media when searching online, some of which suggest installing and using additional packages such as UNetBootin or USB Creator. If you’re not comfortable with using terminal, or aren’t familiar enough with mounted drives and devices to make sure you don’t commit an act that will cause you to potentially lose vital data on your computer, then perhaps those are the better options.

For me, I hate installing any applications or packages that I don’t need. Since Ubuntu, and I wager most Linux distributions, ship with dd I prefer to use that. What’s better is its use is fairly straight-forward on top of it. You can get a few ideas of what dd can be used for by viewing its Wikipedia page. It appears to be a relatively easy option for backing up sensitive data, such as the MBR on a drive.

But anyway. If you’re looking to create a bootable media for a non-buntu distro, you can do so with dd with the following command:

sudo dd of=/dev/sd?

If you read up on dd at the Wikipedia page, you’d have seen that there is also an argument you can pass: bs. By default, bs, which defines the block size for reading and writing in dd, is 512 bytes. Some suggestions that I’ve seen online recommend defining the block size to be larger. Larger block size would lean one to believe means less cycles when writing. So, you may want to bump that up to something larger, though staying within appropriate boundaries. Examples online of using dd to create writable USB drives often include a block size of 1MB. So, you could include that in the command:

sudo dd of=/dev/sd? bs=1M

You must also make sure the media you’re writing to isn’t mounted before using dd to write to it:

sudo umount /dev/sd?

So, for example, if you’re USB drive was mounted as device sdc and your Linux distro image was named Linux-LiveUSB.iso (and we’re assuming you’ve navigated terminal to be in the same directory as the ISO image to avoid needing to include the path), you would issue the following to write it to the USB drive:

sudo umount /dev/sdc
sudo dd if=Linux-LiveUSB.iso of=/dev/sdc bs=1M

A brief summary of the commands are

  • if: Input File. This is the location and file that is being read from.
  • of: Output File. This is the location and/or file that is being written to.
  • bs: Block Size. This is the size, in bytes, that each data block is being read and written at. The default is 512, so leaving this undefined will have dd read and write data blocks at 512 bytes.

Lastly, I would say to only use this method if you need to create a bootable USB drive, and there are no other pre-installed software to get the job done. For example, why use this over Startup Disk Creator if you’re in a *buntu OS and need to create a bootable *buntu USB drive? There is no reason to. If you’re writing to a CD/DVD, then I would think the included disk burning software on your system would work just fine. If not, then dd should work fine for that as well. Just use the device name of the disk burner when designating the output file in the command. If the idea of manipulating data via terminal scares you, then I’d say better safe than sorry, and just look around for a fitting application with an easy UI.

BIND Authoritative-Only DNS Server on Ubuntu Server 14.04 or Debian 7

This post will explain how to get a DNS server setup going on Ubuntu Server 14.04 or Debian 7 using BIND. The arrangement assumes the following:

  • You’re using a master/slave configuration.
  • Your server host provides the rDNS for you. Most VPS hosting services handle the rDNS, so you’re not required to configure it on your own DNS server.
  • Your hostnames for the servers have been configured as fully qualified domain names.

For the example, the master server will be located at with an IP address of and the slave server will be located at with an IP address of Our test domain that is being handled by the DNS servers will be and will be configured to point to the same IP address as the master DNS, which is where we would assume the web server servicing the domain will be located.

For the commands shown in the explanations, it’s assumed that you’re logged in or acting as the root user. If not, you need to precede the commands with sudo, this includes when opening configuration files for editing. You’ll get a permissions error when you try to save the file if you don’t.


Start by installing BIND on both servers:

apt-get update
apt-get install bind9 bind9utils bind9-doc

If you’re notified that the file /etc/init.d/bind9 already exists on the server, and asked what you would like to do about it, respond with Y or I to install the version that is included with the package.


Once the installation is complete, you already have a DNS server running on your Ubuntu installation. We only have to make some configuration changes to ensure master and slave servers are communicating with each other and that the master has been configured with the zone information for the domains being serviced by the DNS servers.

First, open /etc/bind/named.conf.options for editing. You should have something like the following:

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        // };

        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See
        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };

We need to add the following two lines anywhere within the brackets defining the options block:

recursion no;
allow-transfer { none; };

Example with added lines:

options {
        directory "/var/cache/bind";

        recursion no;
        allow-transfer { none; };

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        // };

        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See
        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };

Save the changes and close the file.

Next, we need to configure the local file to point to the zone files for the domains that will be serviced by the DNS servers. Assuming that we’re servicing a domain called, open /etc/bind/named.conf.local and add the following – as designated for master and slave configurations:


zone "" {
        type master; also-notify {; };
        file "/etc/bind/zones/";


zone "" {
        type slave; masters {; };
        file "/etc/bind/zones/";

Since the zone block within the local file is pointing to a sub-directory within BIND’s primary directory to house the zone files, we need to create the zones directory and change its owner to the bind user. This needs to be done for both the master and slave servers:

mkdir /etc/bind/zones
chown bind: /etc/bind/zones

Now, you can create the zone file for the domain. For the example, we called the file, and configured BIND to look for the file in the /etc/bind/zones directory.

An example of our zone file would look like:

$TTL 1800
@       IN      SOA (
                        2015010101              ; serial number
                        3600                    ; refresh
                        900                     ; retry
                        1209600                 ; expire
                        1800                    ; ttl
; Name servers
                    IN      NS	; master DNS
                    IN      NS	; slave DNS

; A records for name servers
ns1                 IN      A		; master DNS IP
ns2                 IN      A		; slave DNS IP

; Additional A records
@                   IN      A		; www IP

; CNAME records
www                 IN      CNAME	; www IP

The settings above are fairly straightforward for configuring a zone with NS records and records to point to a web server for serving pages. Just be aware that the value for serial needs to be changed every time the zone file is updated, otherwise the DNS server will not update other servers. For the appended www, you could include an A record that points to the web server’s IP address, just like the origin does, but I believe it is more appropriate to point it to the origin with a CNAME record, as I updated this example to do. Feel free to correct me if you know better.

Check Configurations

At this point, all configuration is done. You simply need to check the configuration and zone files for errors, and then restart the servers.

You can check the local configuration by issuing:

named-checkconf /etc/bind/named.conf.local

If it returns nothing (line-breaks directly back to the command prompt), then everything checked good.

You can then check the zone configuration with (on the master server):

named-checkzone /etc/bind/zones/

If all checked well, it should return something like:

zone loaded serial 2015010101

Now, simply restart the two servers.

service bind9 restart

After waiting for the configurations to propogate (varies in time – could be over 24 hours), you can pull up a prompt on your local linux machine and issue the following to see if the DNS has updated the domain to point to your master DNS server’s IP address:


A successful setup should return something similar to:

Non-authoritative answer:

An unsuccessful setup would return something more like this:

** server can't find SERVFAIL

If you get an error, it could be that you didn’t give the servers enough time to update the information for the domains. Either way, you can view the system log on the servers to see if there are any errors:

tail -f /var/log/syslog

Look for the following to indicate successful zone information loading and communication between master and slave servers:

named[4215]: zone loaded serial 2015010101
named[4215]: zone sending notifies (serial 2015010101)

Anything else, pertaining specifically to the domain you configured, might indicate there is a problem with either the zone file or that the master and slave are not communicating. Ensure your firewall is allowing traffic on port 53.

HostUS VPS Specials

These are two specials that HostUS is offering on their OpenVZ VPS services. It hasn’t been stated when the specials will end, but I’d grab them while they’re available if you’re in the market. Beyond the specials, they appear to have very affordable VPS options available, and I believe they’re in the process of adding KVM options as well. Worth a look if you are considering purchasing a VPS.

768MB RAM / 768MB vSwap
1 vCPU Core (Fair Share)
20 GB Disk Space
2048 GB Bandwidth / 1Gbit Uplink (Fair Share)
1x IPv4 address / 4 x IPv6 Addresses
OpenVZ/In-House Panel
$10/year (Click Here)

6GB RAM / 6GB vSwap
4 vCPU Cores (Fair Share)
150GB Disk space
5TB Bandwidth / 1Gbit/s port
3 x IPv4 address / 4 x IPv6 Addresses
OpenVZ/In-House Control Panel
$18/quarter or $65/year (Click Here)


Re-Formatting a USB Drive with GTP Data (Mac) in Ubuntu

I ran into a problem the other day when I decided to create a bootable USB drive for upgrading my fiancée’s Mac to OSX Yosemite.

After creating the drive with the bootable upgrade data, I decided to reformat the USB drive back for my typical use. This particular USB drive is one that I’ve used primarily for installing OS’s, so I regularly wipe it and use it to boot as a live USB for various Linux distros whenever I want to test something or (re)install it. However, I found that I couldn’t format this drive and use it to boot an OS as I had done before. GParted would perform the formatting action and partition the drive, but I could not get it to mirror the same Partition Type of W95 FAT32 (LBA) as the other drives I had. Whatever the problem was, it also caused Ubuntu’s Startup Disk Creator to be unable to perform the Erase Disk function on the drive without giving a long error that ended with the explanation of an invalid UUID. Searching for this error came up with nothing. So, snooping around, I decided to try formatting the drive via terminal, and that’s when fdisk gave me an error stating the the drive had GPT data, which is’t supported by fdisk.

A little more snooping online led me to this page, where an explanation of removing GPT data (used by Mac) was given. Following the steps outlined on that page using gdisk, and then following up with formatting via terminal with fdisk to reformat the drive as W95 FAT32 (LBA) type, the problem was finally resolved.

I’ll outline the steps, from beginning to end, for removing the GTP data and formatting back to FAT32, which I assume is how most USB flash drives are formatted by default.

First, issue the following command:

sudo fdisk -l

Note that you must issue the command with sudo, or else it will output nothing. Find your drive in the list of devices and it should have a line similar to:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdX1               1  4294967295  2147483647+  ee  GPT

The values for Device, Start, End and Blocks will vary, but the value for Id and System will be ee and GTP as shown. Make note of the device’s designation, as it is important that you perform the next tasks on the correct device to avoid data loss or compromising your PC. Also be aware that some external hard drives are formatted this way (the above output that I used is of an external drive that I have that happened to be formatted to fit the example), so make sure you don’t mistake the wrong device for the one you’re meaning to format.

Now that we know the device we need to reformat, we have to use gdisk to remove the GPT data for us. fdisk does not support GPT data types.

gdisk /dev/sdX

I decided to call my device for the example sdX, where X would be the letter assigned to your device. In most cases, unless you’re performing this on the drive that your PC boots from, you’ll likely not be using sda or sdb. Otherwise, you may want to refer to Rod Smith’s steps that explain how to backup the drive’s MBR data. Since this post is meant to cover an external USB flash drive (per my personal situation), I won’t include those steps.

The above command will output something similar to:

GPT fdisk (gdisk) version 0.7.2

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer:

In my case, I wasn’t asked which partition table to use, because MBR was restricted – causing GPT to be the only one available. However, it doesn’t matter which one you choose, if asked, since we’re wiping the GPT data and not looking to convert or salvage data.

You’ll be presented with a command prompt:

Command (? for help):

The remainder of the command prompts should be issued as:

Command (? for help): x

Expert command (? for help): z
About to wipe out GPT on /dev/sdX. Proceed? (Y/N): y
Blank out MBR? (Y/N): n

Make sure you answer n when asked if you want to blank out the MBR. This may not be as crucial for a USB flash drive, but wiping the MBR on a drive that you use to boot from would be disastrous (especially if you didn’t back it up beforehand).

The next steps are actually formatting the drive using fdisk. Substituting in sdX for your drive’s device, enter the following commands when prompted in the order shown to perform the format of the drive. Note: output has been omitted. Where no response is shown for command prompt, simply hit enter.

sudo fdisk /dev/sdX
Command (m for help): p
Command (m for help): d
Command (m for help): p
Command (m for help): w
sudo fdisk /dev/sdX
Command (m for help): n
Command (m for help): p
Partition number (1-4): 1
First cylinder (1-1020, default 1):
Last cylinder, +cylinders or +size{K,M,G} (?-????, default ????):
Command (m for help): t
Hex code (type L to list codes): L

At this point, you’ll be presented with a list of all device types you can format the drive to using fdisk. In this case, I wanted W95 FAT32 (LBA), so I chose b

Hex code (type L to list codes): b
Command (m for help): a
Partition number (1-4): 1
Command (m for help): p
Command (m for help): w

Finally, we can format the drive:

sudo mkdosfs -F 32 /dev/sdX1

The last command could technically be handled via Disk manager or GParted, if you wanted a user interface instead of terminal, but it would make sense to just issue the command in terminal since we’re already working in terminal for the rest of the steps.