Unable to Mount USB Thumb Drive in Nautilus - Physical Block Size Mismatch

Before I can proceed to setup my tiny homelab machine, Kabini, I need to burn the installation media to the USB thumb drive. However, when the thumb drive was plugged in, Nautilus can't seem to mount it although the kernel message did indicate device `/dev/sdc` did exists and mounted.

Checking through GParted, the default GUI partition tool in GNU/Linux shown that "The driver descriptor says the physical block size is 2048, but Linux says it is 512 bytes"


As usual, SO gave us the root cause and solution to rectify this block size error issue. It seems that I may accidentally wrote to the USB thumb drive using the wrong parameter through `dd` command. To fix this, we need update the thumb drive's partition to the right block size. Running the command below did resolve the issue for me.
$ sudo dd if=/dev/zero of=/dev/sdc bs=2048 count=32
32+0 records in
32+0 records out
65536 bytes (66 kB, 64 KiB) copied, 0.00655332 s, 10.0 MB/s

Once the corrupted block issue have been resolved, go back to GParted and refresh the thumb drive. GParted will prompt you to create a new partition table.


After we have created the partition table, Nautilus will show a proper mounted thumb drive. See screenshot below.


Download the Ubuntu installation ISO file. I'm downloading both the mini and Ubuntu server 17.04 ISO file. This is the time where torrent really shine where I can achieve the speed of 3.02 MB/s, a feat not doable even using parallel HTTP connection using download manager like Aria2.



Next, burn the ISO using the Startup Disk Creator. Load the ISO file as the source disc image and burn it to your thumb drive.


In the past I always used dd command line utility to burn ISO. Little I realized once you've done burning, you can test the thumb drive.


Verification is done by QEMU, hosted hypervisor. If you can see below installation menu, then the thumb drive have been burned and can boot up correctly.


You can achieve similar result through the command line command below. X is the alphabet of your thumb drive.
$ qemu-system-x86_64 -hda /dev/sdX

This Week I Learned - 2017 Week 15

Last week post or you can browse through the whole series.

While debugging a Makefile, I accidentally `rm -rf` my home folder. Lesson learned, always backup and sync your changes regularly. Nevertheless, it's always a good fresh start when your home folder contains not a single file or folder. Good that you have a weekly clean up of your machine, review, keep, or remove. Otherwise, there will be a lot of pending left over files.

It has been a while since I work on weekend. The serenity of the environment did improve your productivity ten-folds. There is no sounds other than the air-con, traffic, and your typing sounds. You're basically in the zone, focus solely on the task at hand. No more stupid shenanigan. In hindsight, you have to find or create your own optimal environment and zone. It all starts with a system that leads to a habit, good habits.

#1 How to read more books? Lots of good tips and increasing the volume of books you can read. It's already early April and I only managed to finish 2 books. Not really on track on finishing 12 books this year. Thinking back, reading style, book choices, timing, and context are what causing the slowness. One of the best strategy is to switch different books if you're stuck or bored. Some books need more mental energy to go through it. While reading 2 pages per day can develop a good habit, it's not sufficient fast enough to catch up with my pilling reading list.

#2 Engineer's Disease. The unconscious thought that can lead to arrogant and condescending personality. Maybe because such behaviour "stems from the OCD and emotional detachment our peoples tend to have, mixed in with a good dose of raging insecurity"? Good forum discussions to ponder upon, especially by those working in software development.

#3 Does teenager and adult have different learning capability? Time, available perceived time. Also discipline, attention, and focus. The discussion at HN gave a lot of strategies to attack the problem. Simple daily practice and learning together with different learning strategies. What to learn then? Fundamental. There is an interesting discussion on software development being a dead-end job after 35-40.

#4 On understanding the fundamental of Vim. Before you install any Vim's plugin, best to learn what the default features exists or not.

#5 System Design Primer. If you want to learn how to design large scale systems. However, premature optimization is still evil. Knowing something can be done right doesn't means it should be done now. There are always contexts and constraints. Solutions looking for problems always end up wasting everyone resources. This HN user's experience on scaling your system accurately illustrates such scenario.

#6 Looking busy at work?. Most people don't realize that pretend to work and look busy is actually far more harder than doing the actual work. Faking will deplete you psychologically as your thoughts, actions, and words are not in sync. However, there are always exception. Certain group of people thrive on such behaviour without caring for any forms of repercussion. While some just stuck with mind-numbing boring job. There is a saying by Napoleon Hill which states "If you are not learning while you’re earning, you are cheating yourself out of the better portion of your compensation.” Unless you're stuck with certain constraints, move on. You're not a tree!

#7 LXD finally available for Fedora. Not as native RPM package but through Snap. I'm going to reformat another workstation and install Fedora with it. One less reason to stick with Ubuntu. Only left the DEB package, which I believe, no way Fedora/CentOS/Red Hat is able to dethrone the number of available packages provided by Debian. I'm not looking for rolling release like Arch but availability of different software. Maybe Snap, the universal GNU/Linux package can change that?