Follow or Lead?

Oct 30

ErinGarbage, Work , , , No Comments

At any given point we are either a follower or a leader. In some rare scenario we fulfill both roles.

I am getting a reputation at work for a troublemaker when in fact I am only clarifying glaring holes in policies that are too specific or useless. These are the same policies that, to paraphrase one of my recent statuses, people wield like a paper shield that wont even muster against the slightest reason. Pitiful that the instigators of these policies are the same people that I should be relying on to look after my welfare as a follower.

In these cases I take up the mantle of being Captain Obvious. It may come across as troublesome but being a leader means you need to take the road that is not going to be comfortable. If nobody complains then it is the same as being complicit to something that you do not believe in.

Follow or lead?  Do you take a chance in participating in a battle that can be the turning point of the war; or sit quietly in the corner reminiscing the “what if” of an opportunity that has long gone by? Choose your own poison.

ciao!

Agaw-liwanag

Oct 18

ErinTop of my head , , No Comments

The camera phone might not have captured it properly but the picture below is meant to capture the dusk of a stormy day.
More

Docker image cleanup

Oct 13

ErinLaboratory, Technology , , No Comments

Running docker frequently can lead to mysteriously disappearing space. I kid, its not mysterious. Each image builds a layer which in turn eats up space. Logical but PITA!

Put this in your .bashrc or run it as cron on your docker host to clean up.


docker rm -v $(docker ps -a -q -f status=exited)
docker rmi $(docker images -f “dangling=true” -q)

or do it in one alias (use at your own discretion)


alias docker_janitor='docker rm -v $(docker ps -a -q -f status=exited);docker rmi $(docker images -f “dangling=true” -q)'

sounds too easy..

ciao!

Ubuntu 15.04 hanging boot-up issue

Oct 07

ErinFLOSS , , , , No Comments

Last weekend I reinstalled my Linux system (and not because I want to rename it as Pyg!) which is a very bad decision as it is the same time that my pitiful internet connection fails to transmit any data beyond a few bytes. The new install to Ubuntu 15.04 (Vivid Verve) gave me the confidence to start using btrfs which is being touted as the next generation file system for linux systems. Bad move and very short-sighted on my part. 🙁

The btrfs is supposed to provide enhancements to ext4 file system since it (btrfs) is built from the ground up but with the useful features already present in ext4. The ext4 filesystem is basically being viewed as an aging hack on a hack since it builds on ext3 which is a tack-on improvement for ext2. Btrfs might be delivering on some of its promised features but those who use it should still be wary of it as it is still not considered as ready for “production” or real-world use[1]. I wish I knew this before I chose it as the filesystem for my home directory. 🙁

For those that will have the misfortune of encountering it, the gist of my predicament follows (which is based on how I remember it):

  • I upgraded my system using dist-upgrade.
  • I encountered a severe freeze which left me with no choice but to reach for the power button.
  • System bootup hangs. The last entry goes something like this:

    • A start job is running for /home… (10s /no limit)

  • Eventually the bootup hangs and it drops the control to an emergency shell.

It was unnerving for me since a reinstall means I would need to re-download the upgrade packages on my #@$@#$ Smart LTE connection. The light-bulb moment for me was that /home is the only partition in the sequence that is using btrfs. The working theory is something borked during the forced shutdown which should have been handled by the journalling features. Thanks to an alternate albeit slow alternative connection, I was able to google enough to do the following:

  • Boot the machine and press F12 after the BIOS/UEFI prompt.
  • Selected the menu option for Ubuntu Advance options.
  • Selected the option for “(recovery)”
  • Selected the “drop to root shell” option.
  • Remounted the root system in r/w mode. I dont think this is needed but this is what I have done and it won’t hurt anyhow.

    • # mount -o remount,rw /

  • Did a btrfs file system check on the home partition

    • # btrfsck /dev/sda4

  • When nothing popped out, I went for the repair option.

    • # btrfsck --repair /dev/sda4

The repair option is always accompanied by a cautionary warning as it can delete information so having a proper backup is recommended. In my situation that is like adding salt to the injury. When I ran the repair option it reported that the cache and super generation areas do not match and that it cleared the space cache. After doing so I ran another btrfsck on the partition and rebooted the system which thankfully landed me on a working system with no (identified) data loss.

The moral of the story is to select btrfs only for the filesystems that you can afford to lose data; or have a good backup scheme. Using it for /tmp is going to be an overkill but to each to his own. Now Im thinking if I want to convert my home partition back to ext4. 😀

ciao!

[1] https://www.wikivs.com/wiki/Btrfs_vs_ext4