Mounting CentOS 6 NFS on a CentOS 4 Client

I have a CentOS 6 machine that exports NFS shares for various virtual machines to mount and use as needed (mostly to build code on various platforms and architectures).

One of the problem machines is a CentOS 4 VM that mounts the CentOS 6 NFS share upon boot. I fought with this damn VM for an hour before the simple solution hit me. CentOS 4 uses an older version of NFS (nfs?) than CentOS 6 does by default (nfs4).

Here is the relevant line in the CentOS 6 NFS server machine's /etc/exports file:
/home/sm *(ro,insecure,no_root_squash)

Here is the CentOS 4 NFS client VM's /etc/fstab file (the one that does not work):
mndevtest:/home/sm /mnt/smhome nfs defaults 0 0

And here is the CentOS 4 NFS client VM's /etc/fstab file (the one that does work):
mndevtest:/home/sm /mnt/smhome nfs4 defaults 0 0

Literally a ONE CHARACTER change fixed it. I love computers. /s

Fixing the Reboot Command

Somewhere along the line, my Ubuntu 14.04.3 installation (on a Zotac Z-Box) stopped accepting any typed reboot command. It seems to have happened after I removed gnome-power-manager; but even though I reinstalled it, the reboot command still wouldn't work. I'm not sure whether that was the cause, but I think it has a high chance. Anyway, thanks to http://michalorman.com/2013/10/fix-ubuntu-freeze-during-restart/, this little trick worked...

Edit grub's default configuration:
# vim /etc/default/grub

Add the following to the GRUB_CMDLINE_LINUX_DEFAULT string:
reboot=warm,cold,bios,smp,triple,kbd,acpi,efi,pci,force

The kernel will attempt each type of reboot in that order, until one works.

After saving that file, be sure to run the following command to enact your changes:
# update-grub

Reboot your machine, and the reboot command should now work.

Installing Older or Multiple GCC Versions on Ubuntu 14.04 Trusty

In trying to port my company's software from CentOS 6 to Ubuntu 14.04, it became apparent that I may need to modify the Ubuntu build environment (don't ask... much easier than changing the 15 years worth of software... trust me). Just to give you some idea, the software began in the early 90s with GCC v2 on 32 bit platforms (target was CentOS 4). It then evolved to CentOS 5 and then 6, all the way up though GCC v3.4. To support running our software on the latest hardware, Ubuntu 14.04 LTS release became our desired target.

Ubuntu 14.04 comes with GCC v4.8. The last version of Ubuntu to include GCCv3.4 was Hardy. So we'll need to include that in our repo source list. The problem here was that all the posts I found referenced incorrect old-releases addresses, so here is what I found that worked...

Note, if you haven't done so already, be sure to install the build stuff:

apt-get install build-essential

First add the old repos to the sources file, so apt can find what we need:

vim /etc/apt/sources.list 

deb http://old-releases.ubuntu.com/ubuntu hardy universe

deb-src http://old-releases.ubuntu.com/ubuntu hardy universe

Then get the latest repo data:

apt-get update

Then install the older GCC:

apt-get install gcc-3.4

apt-get install g++-3.4 

Next, we'll need to configure multiple compilers (note, the last number is just an arbitrary priority):

update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 20

update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-3.4 10

After that, just select which compiler you want to use, before you go to compile:

update-alternatives --config gcc

I also found that I had to update the linker's symbolic link, as it was pointing to a non-existent library file (/lib/libgcc_s.so.1):

ln -sfn /lib/x86_64-linux-gnu/libgcc_s.so.1 /usr/lib/gcc/x86_64-linux-gnu/3.4.6/libgcc_s.so

Fix Google Chrome Crashes by Increasing Open Files Limit in Linux Mint

I found myself frequently having Google Chrome crash when opening many tabs across several windows (don't judge me) on my Linux Mint 17 Cinnamon desktop.

Upon further investigation, I found that Chrome was throwing some error about too many open files.

 ~ tail -f ~/.xsession-errors 

The error, I can't remember, but was something in shared_memory_posix about /dev/shm/.com.google.Chrome and Too many open files.

If you look at the configured default open limit, it's very low (like 1024).

~ ulimit -n

The fix (so far, so good) seems to be editing /etc/security/limits.conf and adding the following line at the end of the file:

* hard nofile 65535

* soft nofile 65535

Reboot the machine, and should be all good.

Note: I saw several people modifying their fs.file-max settings, but that made Cinnamon not even want to load and played hardcore shenanigans with my machine, overall.

 

Verizon Samsung Galaxy S4: Installing a Custom ROM (Hyperdrive RLS10)

(This is a continuation of my previous post: Link)

Preface: Following the problems I had updating my rooted ME7 to an MI1 build, my stubborn mind is finally convinced that OTA and root NEVER go well together. So, having said that personal disclaimer, let's jump into the custom ROM world for the S4. Currently, I'm running Hyperdrive RLS10 on my S4 ~ and I'm generally quite happy with it; but here's a little bit about how I got here, and some of the issues I've found.

Samsung's Galaxy S4 has a ton of features ~ many as a result of software, though. Even my AOSP-loving mindset has to admit that Touchwiz is a (dare I say it) good thing with this phone. But it does greatly complicate things if you want a custom ROM.

For example, you like air gestures? You know, those cool things that let you make iSheep hang their head in jealous shame? Well, you better make sure your new custom ROM has the kernel modules necessary to drive that. Same can be said for any other hardware, too... the RGB sensor, even WiFi. As with any computer, the drivers need to work; and many of these (driver and hardware) are not exactly open source.

So, how do you choose a custom ROM without losing TW? It turns out, that's not very difficult with the S4 (even the S3 - might have to try this with my wife's S3, soon). But, the list does (currently) narrow down once you factor in Verizon... and even more once you factor in your current firmware build (MDK, ME7, or MI1). I narrowed my list down to three possibilities, based on my Verizon S4 running MI1 firmware (it's a SCH-I545):

1. Hyperdrive (http://forum.xda-developers.com/showthread.php?t=2301724)
2. Jeally Beans (http://forum.xda-developers.com/showthread.php?t=2307357)
3. Eclipse (http://forum.xda-developers.com/showthread.php?t=2351840)

I ended up going with Hyperdrive, because it seemed to be very well supported by the developer & community, everybody said it's stable and pretty much everything works because it's based on the stock TW stuff. I also like the included AROMA installer, which gave me the option of how much AOSP vs TW I wanted (it's an installer shell that lets you customize the ROM before it's installed).

Honestly, it was a close toss-up between Hyperdrive and Jelly Beans. The only reason I went with Hyperdrive was a couple of posts talking about how MI1 owners were happily working with it... I might yet still want to try Jelly Beans, though (possibly a future post).

Anyway, here's how I installed it:

1. I rooted my MI1 firmware, using the "Root de la Vega" method:
• http://forum.xda-developers.com/showthread.php?t=2487142
2. I then installed "Safestrap" recovery using a sideloaded APK:
• http://forum.xda-developers.com/showthread.php?t=2441441
• Safestrap is really neat... you'll be right at home, if you're familiar with hard drive partitioning or dual/multi-booting operating systems!
• Also be sure to get the right kernel-modules file (you'll need it right after you install Hyperdrive)... Note: the Safestrap site above only had ME7 modules, I had to go out and find MI1 modules on XDA:
• Direct download: http://omniimpact.com/android/roms/myfishbear/GS4/jfltevzw-MI1-modules.zip
• XDA thread: http://forum.xda-developers.com/showthread.php?p=46832728&postcount=7
• NOTE: put this on the memory card like you do with the ROM file!
3. In Safestrap, I created a new ROM slot (it's like a partition) for my Hyperdrive installation to go in... all I did was increase the sizes a bit for system, data, and cache - per my own preference.
4. From there, it's Hyperdrive flashing time... just install from the ROM file like you would any other (using Safestrap). I followed the instructions for "ME7" at http://forum.xda-developers.com/showthread.php?t=2301724.
• An important note about AROMA... just customize to your own preference... only be sure to choose the "safestrap kernel" toward the end.
• Once the ROM is installed (do NOT reboot yet), tap the 3-dot little menu icon to go back to the safestrap menu. Click through to install another ZIP, and choose the kernel modules zip file that you copied to your memory card in step 2 above.
5. Now, you may reboot... everything should now work. Enjoy!

NOTE: The only thing I've found that doesn't work is auto-rotate. This is a common problem, and is likely due to the fact that we're using a ME7 based ROM (which Hyperdrive RLS10 is) but began with a MI1 firmware and are using MI1 kernel modules. Until Hyperdrive is based on MI1, this probably won't work? Unless we can make an easy modification to the kernel modules ZIP file... perhaps using the ME7 module, specifically, for the rotate feature?

Verizon Samsung Galaxy S4: Problems Updating a Rooted ME7 to MI1 Firmware

Before my current Verizon Samsung Galaxy S4, I dealt with an old Motorola Droid X2 for a few years. If you don't know, it was a phone that had less than 512MB of usable RAM ~ actually, effectively less than 384MB (in other words, it lagged like a bitch). So, to squeeze as much life out of it as possible, I used the Eclipse ROM on it. I've used custom ROMs before, but that was the first time I really saw a performance improvement because of one... you know, getting rid of bloatware is always a good thing.

Fast-forward to my newer S4... with 2GB of RAM and 4 CPU cores, it hardly needs a performance improvement -- and their TouchWiz actually seemed good on this one (AOSP blasphemy?). So, for a while, I happily used stock Samsung Android (VRUAMDK) -- unrooted, even.

Then the VRUAME7 OTA came, and I immediately updated to it... something I would come to regret. That update ensured I would not be able to root for at least 2 more months until a bounty on XDA got up to a few thousand dollars and someone found an exploit (albeit, still with a locked bootloader). What can I say? After the old Moto DX2, I was giddy about ANY newer version of Android! Lesson learned: heed the warnings about accepting OTAs... do NOT do them if you're rooted!!! Period!

So, when VRUDMI1 was recently available OTA, I was a lot more hesitant to accept the update; but after several days of being nagged by it (and not finding any major issues about it, in my searches online), I finally pulled the trigger and did an OTA update for the MI1 firmware....

Enter:  "Firmware Update Error" (and a dead Andy lying on his back). Awesome. Could it be because I had rooted ME7? Probably. So, after doing a full factory reset - and then doing the update, it seemed to work.

But now, I have a completely blank factory-image phone... it might be the time to pull the trigger on a custom ROM.

To be continued.....

Setting Up RAID-1 on Linux Mint 15, Revisited using manual commands

So, after I ran the raider program a while back, I had to do some other things with my machine ~ and long story short, I had to run raider once again. Only this time, I didn't do it right (I used the machine for a full day after running the initial raider setup and before swapping the drives - meaning that when I finally got around to completing the "raider --run" step, things were out of sync and crapped out)...

Originally, I started with my /dev/sda having all my stuff on it and /dev/sdb being the blank drive I wanted to add as a new member of a RAID-1 array... but, instead, (thanks to my screw-up) I ended up with /dev/sdb getting my system (thanks to raider's first step) and /dev/sda getting completely erased. Not a complete disaster, since I still had all my stuff on at least one of the drives, but I didn't have the time to wait for two more rebuilds, nor the patience to swap drives and stuff. So, I decided to jump in and try to figure out mdadm, proper... at least this was a good introduction to a little bit of the utility.

Since my mdraid had already been created (again, thanks to raider), all I needed to do was manage the array. So, the first thing I wanted to do was copy sdb to sda. This turns out to be pretty easy:

• First, copy the partition table from your source drive to the new RAID member drive:
  # sfdisk -d /dev/sdb | sfdisk /dev/sda
• Then, add the erased disk to the raid array:
• Add /boot partition
  # mdadm --manage /dev/md0 --add /dev/sda1
• Add / partition
  # mdadm --manage /dev/md1 --add /dev/sda3
• Add /home partition
  # mdadm --manage /dev/md2 --add /dev/sda4

At this point, I checked the array (# cat /proc/mdstat) and discovered, to my surprise, that the array was already rebuilding (i.e. copying stuff from my sdb to my sda)!

Mission accomplished: I can now continue using my machine while the array rebuilds in the background. Since that will take another day or so, I'll continue this if there are other issues.....

To be continued?!