Close to impossible to understand, but I just spent quite some time to figure out the package name for the Berkeley DB, libdb on RedHat (RHEL6).
Silly me. I should have known that the package is called “db4” and nothing else. After figuring that out, tacking on a “-devel” to get the headers package was piece of cake.
So, you have correct permissions on your home directory and all the way up to /, with no other-writable directories in the path, as well as correct permissions on the .ssh directory in $HOME, and it still doesn’t work? You probably have SELinux, and need to put the newly created files in the correct security context. Do it with restorecon like this:
chmod 700 ~/.ssh
restorecon -R -v
When performing the db2move load -lo replace to continue the “restore” from my previous post, I failed once more, this time with first SQLSTATE SQL2036N, “The path for the file or device path/device is not valid.”, and later (after chmod o+x on the directory), SQLSTATE SQL1652N, “File I/O error occurred”.
Why does IBM write this kind of misleading error messages? What’s wrong with a simple ENOPERM, ENOENT, “Permission Denied”, or “No such file or directory” message?
I am logged in as user ‘root‘, but the db2move command simply seem to tell another DB2 process to load the import files, and this is probably a privilege separated process that can’t open the directory containing my *.ixf files.
So, chmod o+x on the directory to the rescue! (Solved the SQL2036N) – Only to have it fail with another error when it is the actual files that cannot be opened by the unprivileged user.
chmod o+r on the files to the rescue, then! 🙂 (Solved the SQL1652N).
Yes, both these error messages were due to the fact that the files were not readable by anyone but root. Hope this helps someone! (Feel free to investigate the advertisements if you find any of my tips useful!) Nudge, nudge, know what I mean, know what I mean? 🙂
I created a new db2 database, updated LOGARCHMETH1, LOGFILSIZ and some other things, then tried to import data created with db2move and db2look with a command like this:
db2 -tvf filename.dat
It failed, with SQLSTATE=57019, because of BACKUP PENDING.
I didn’t feel like performing a backup on an empty database, so I did this to solve the problem:
db2dart databasename /CHST /WHAT DBBP off
where “databasename” was obviously the name of my database. This successfully changed the state of the DB Backup Pending flag to “off”, which allowed me to do my import! Yay!
Windows 7 has really nice backup and recovery features. However, they are not as well worked out as the day-to-day windows features, and, hence, lacking in user-friendliness.
I struggled quite some time before I realised the error message 0x800704CF was due to the network chip driver not being loaded. What I had to do to be able to restore the system image over the network, was to first load the network driver from the CD-Rom that came with the motherboard.
What really fooled me the most was the authentication dialog probing for network credentials popping up. Why ask if you don’t have access to the network?
For my new Asus P8Z68-V Pro motherboard, to load the network driver, I had to browse to E:\Drivers\LAN\APPS\SETUP\SETUPBD\Winx64\, and instead of double-clicking on an INF or SYS file, I had to launch the program:
by means of a right click on the SetupBD Application, and then selecting “Run As Administrator”.
Just how much time does Appcelerator spend in bed with Apple?
I understand that iPhone is a nice target platform for selling apps, but Appcelerator markets Titanium much the same way that Sun Microsystems (R.I.P.) marketed Java: Write Once, Run Everywhere.
However, the developers at Appcelerator (who make Titanium) have lots to learn about portability. (How’s that for irony!) Probably everybody in software development has lots to learn from could learn from The Art of Unix Programming and general Unix Philosophy.
To make it work, even in a new Ubuntu, you have to (after installing) actually (re)move the following files from ~/.titanium/runtime/linux/1.0.0/:
libgio-2.0.la libglib-2.0.la libgobject-2.0.la
libgio-2.0.so libglib-2.0.so libgobject-2.0.so
libgio-2.0.so.0 libglib-2.0.so.0 libgobject-2.0.so.0
libgio-2.0.so.0.2200.4 libglib-2.0.so.0.2200.4 libgobject-2.0.so.0.2200.4
After that, at least it starts (albeit with LOADS of messages and warnings on the console).
The cryptic error message that “indicates” the error with the conflicting libraries, removed above, was:
symbol lookup error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_malloc_n
So, if you get the error with titanium and libgdk-x11-2.0.so.0 and g_malloc_n, the solution is to move away the libraries from the runtime directory in your installation folder.