FreeBSD's badblocks utility

I had a hard time finding badblocks for FreeBSD 9.2 when Googling for "FreeBSD badblocks": https://google.com/search?&q=FreeBSD+badblocks

pkg_add -r e2fsprogs

If you're in csh or tcsh or zsh, run rehash and you can use badblocks.

Should've realized looking up what package provides it for Linux (also e2fsprogs) would've found me the package for FreeBSD.

Windows 7 "autochk program not found - skipping AUTOCHECK" on cloned drive or resized partition

I cloned my Windows 7 installation using Paragon Partition Manager, Macrium Reflect, and the manufacturer's (Samsung's) bundled migration utility from an HDD to a smaller SSD. Each resulted in booting to a screen that said:

autock program not found - skipping AUTOCHECK

Sometimes I got a Windows logo, and sometimes I got to Startup Repair, but whether they launched automatically or I launched them from a Windows Installation Disc (or USB), they all failed. Sometimes a blue screen (BSoD) appeared shortly after.

It turns out attributes on an MBR disk apply to all volumes on that disk; attributes on a GPT disk apply only to the volumes selected, so this didn't help: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004505

Suspecting the cloning was problematic, I tried shrinking the Windows C volume using Easeus Partition Master, and that resulted in the original hard drive being unbootable as well.

My drive was encrypted with BitLocker, and I decrypted it prior to shrinking as well as prior to cloning. The data was always visible on the partitions. I tried deleting the BLboot partition, which appeared before my "C" partition, but that didn't help at all. It came back with Startup Repair.

Solution:

From here: http://superuser.com/questions/290612/missing-autochk-program-during-boot, specifically this post: http://superuser.com/a/547260, which I saw was posted 23 hours after my ordeal (the following is based on that post):

• Boot into Windows Installation Disc (or USB) or WinPE
• At "Install Windows" screen, click "Next", then press Shift+F10 to launch a command prompt
• Type "diskpart" to launch diskpart, the Windows CLI disk manager
• In diskpart, type "list volume" to show you what volumes the installer sees
• You should be able to identify your real "C" volume by its size even if it bears a different letter, e.g, "D"; note this down
• If you have a BLboot partition, it'll be 100MiB to 2GiB in size, so relatively small
• Exit diskpart (type "exit") and launch "regedit" (if you lose your terminal, Shift+F10 will get you another)
• Select "HKEY_LOCAL_MACHINE"
• Click "File" > "Load Hive" and open the Windows\system32\config\SYSTEM file on your "C" drive and title it "MyOpenHive" (regardless of what letter your installer thinks your "C" drive currently is, remember what you saw in diskpart---if you don't, Alt+Tab to your command prompt and use diskpart to show you what volumes are present; in my case, the BLboot partition was seen as "C" and the "C" partition was "D" to the installer)
• Expand "HKEY_LOCAL_MACHINE" by clicking the "+" to its left
• Within you'll see a folder called "MyOpenHive"; another is called "SYSTEM"
• "MyOpenHive" shows you what your OS thought it saw (not the installer!), while SYSTEM tells you what the installer sees
• They both have a directory called MountedDevices; check what device in SYSTEM > MountedDevices corresponds to the drive letter your C partition should bear
• Going by its ID hex letters and numbers, figure out what volume your C drive is
• Press F2 on an entry to edit its name; if the wrong drive or partition is listed as "\DosDevices\C:", change its letter to something unused, e.g., "\DosDevices\Z:"
• Ensure the proper volume (comparing volume IDs and whatever else you can) is named "\DosDevices\C:" (it might be named "\volume{volume_id_of_some_sort}\")
• Click "MyOpenHive" on the left pane and "File" > "Unload Hive"
• Exit regedit and reboot your system and go through Startup Repair (it might take a few iterations); make sure to remove the installation disc or USB stick

Some posts suggested deleting all the entries found in the "MyOpenHive" hive I opened; that definitely didn't help. Getting the volume ID from the "mountvol" command didn't work either; the correct IDs (or any semblance of a unique ID based on other columns) are best extracted from regedit.

Python: apply method or function in string format to a string

StackOverflow came in very handy for this: http://stackoverflow.com/questions/3061/calling-a-function-from-a-string-with-the-functions-name-in-python

If you wish to apply a method or function call that is currently in string format (e.g., you got an option with optparse) and wish to apply that method or function to another string, use getattr.

getattr(your_string, method_you_want_to_apply)()

The parentheses at the end apply the function or method rather than merely trying to obtain the attribute. 

Check for Kerberos ticket or authentication

Some commands require a valid Kerberos ticket, but if you want to integrate a check for a ticket yourself, try this:

/usr/kerberos/bin/klist -5 -c -s 2

Swap keys and values in a Python dictionary

Many options exist to swap or exchange keys and values in a Python dict() object (dictionary). Prior to creating a new dictionary of (value, key) pairs, it's worthwhile to check that


len( set( d.values() ) ) == len( d.values() )

Anyway, options: 

1. pairs = zip(d.values(), d.keys())
2. pairs = zip(d.itervalues(), d.iterkeys())
3. pairs = [(v, k) for (k, v) in d.iteritems()]

And to create a dictionary, just throw dict() around the zip() or list brackets. 

Source: http://docs.python.org/library/stdtypes.html#dict.items

"ERROR 2006 (HY000) at line 43: MySQL server has gone away" when importing MySQL dump

Having created a nice 1.6MiB SQL dump using Python, I ran into this nifty little error when importing it into MySQL 5.5:


ERROR 2006 (HY000) at line 43: MySQL server has gone away


Line 43 was where my giant INSERT was. Googling didn't help much. Importing a mysqldump-exported dump file worked fine, so after manually importing my data, I took a look at my Python-generated dump:

# wc asdf.sql
56 103353 2158554 asdf.sql

Versus the official MySQL dump: 


# wc sql/rhel_errata_2012-06-24.sql
57 213 2025975 sql/rhel_errata_2012-06-24.sql

Line 44 in the MySQL-generated dump was the extra line. It was another INSERT statement. The bulk_insert_buffer_size was way larger than my file, so what was wrong? 

mysql> SHOW VARIABLES LIKE 'bulk_insert_buffer_size';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| bulk_insert_buffer_size | 8388608 |
+-------------------------+---------+
1 row in set (0.00 sec)

Googling for (no quotes) "mysql maximum values in insert" (https://www.google.com/search?&q=mysql+maximum+values+in+insert) pointed me to the max_allowed_packet variable: 

# mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

+--------------------+---------+
|Variable_name       | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

1048576 bytes is exactly 1MiB, so raising it to something larger than intended dump file size suffices: 

# mysql -e "SET GLOBAL max_allowed_packet = 8388608;"
# mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"
+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 8388608 |
+--------------------+---------+

Don't forget to add it to /etc/my.cnf for persistence.

Show Linux or *nix permissions in octal

Like many others before me, I briefly Googled for "ls show octal permissions" (without quotes) and got next to nothing immediately useful: https://www.google.com/search?q=ls+show+octal+permissions

I would've written the solution to this thread since I got this idea from there, but unfortunately, it's closed: http://www.unix.com/unix-dummies-questions-answers/119538-ls-switch-view-octal-permissions.html

Solution: ditch ls and use stat instead---stat can format its output similar to date.

$ stat -c %a "${filename}"
644

Removed LUN and multipath reports "tur checker reports path is down"

When removing a LUN from a Red Hat Enterprise Linux 5 (RHEL 5) server, I ran into this interesting issue:

[root@server ~]# multipath -ll
sdat: checker msg is "tur checker reports path is down"
sdbt: checker msg is "tur checker reports path is down"
sdct: checker msg is "tur checker reports path is down"
sdt: checker msg is "tur checker reports path is down"

This is annoying and problematic since running pvs or something similar will cause the system to hang as it tries to access the missing LUN. It's briefly covered below, but see also the official documentation: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/removing_devices.html

1. Stop using the volume and umount
2. Remove it from software RAID or LVM volume group
3. Use multipath -l to get the block devices names (e.g., sda, sdb, etc.)
4. Use multipath -f mpathX
5. To flush outstanding I/O ("sync"), use blockdev –flushbufs device

6. Make sure applications and things are no longer referencing the device(s)
7. echo 1 > /sys/block/device-name/device/delete

multipathd -k results in ux_socket_connect error

On Red Hat Enterprise Linux 5 (RHEL 5), when trying to enter the multipathd shell using multipathd -k, I ran into the following error:

ux_socket_connect: No such file or directory

Because running multipath -ll generated the desired output I assumed (and we all know what assuming does!) and began Googling a solution... and it turned out multipathd was not actually running or even set to start on boot. Solution:

chkconfig multipathd on
service multipathd start
multipathd -k

Lesson learned.

Cron not working for normal user

Recently I ran into an interesting "issue" where a user's cron job wouldn't work and restarting the cron daemon did no good. Having checked the /etc/cron.allow and /etc/cron.deny files, I found nothing relevant, and so I Googled the error found in /var/log/messages:

Apr  9 12:31:01 server crond[8993]: Authentication token is no longer valid; new one required.

No password was necessary for this account, so to the system, it was a "locked" account, whereas to me, it was a service account.

[root@server ~]# grep username /etc/shadow
username:!!:13306:0:90:14:::

 Setting a password resolved this.

MaxRequestLen

The following error:

[Sat Jun 11 14:33:51 2011] [warn] [client 98.30.32.199] mod_fcgid: HTTP request length 131533 (so far) exceeds MaxRequestLen (131072)

Requires a review of the FcgidMaxRequestLen or MaxRequestLen parameter:

http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen

Fix: set value (in bytes) for FcgidMaxRequestLen inside httpd.conf or apache2.conf.

Renovatio

The original ErrorLog page grew rather long, and as a Wiki, made maintenance a big of a pain, seeing as all content went into the same page. This format strives to be a little different. Chronology is easier to maintain, and tags allow for easier sorting than do "folder" like structures of headings or titles.

Original: http://code.google.com/p/sna/wiki/ErrorLog

Rest of the wiki: http://code.google.com/p/sna/wiki/