As of 2016-02-26, there will be no more posts for this blog. s/blog/pba/
Showing posts with label error. Show all posts

I did my weekly system update about 13 hours ago and finally needed to reboot about 2 hours ago. After reboot, I had no X window for almost one hour before I finally found the problem.

At first, I only noticed:
No screens found.
Trying to read forums posts in a 80x24 console using elinks, do you have any idea how hard it is? And it didn't resolve the issue. I tried to downgrade xorg-server, but not xf86-video-ati, which is the actual cause.

I stumbled across the release announcement of version 7.0.0, it says
This is the first KMS only release.  Major changes:
- - Enable 2D tiling by default on r6xx+ asics
  (requires mesa 9.0+).  If you are planning to
  ship xf86-video-ati 7.x with an older version of
  mesa, please disable 2D tiling.
- - xserver 1.13 support including prime
- - glamor support
- - SI support
KMS (Kernel modesetting) only, finally, something makes sense with another message:
[    76.379] (II) [KMS] drm report modesetting isn't supported.
When you put two and two together, it's Eureka! I know my system has no KMS and this must be it, I knew it and I was right.

I re-emerged libdrm with USE flag libkms and rebuilt kernel for necessary changes. Be sure to have framebuffer part done correctly and have firmware installed if you have newer cards, or you will get black console.

After reboot, I can run X again. Somehow, X looks even more beautiful than ever.

You can imagine that I wondered why I didn't get any message from emerging 7.0.0, there should be a small note or an eselect news, but nothing. KMS-only, that's quite a big change.

I guess I am probably a few people who would have encountered this issue, now everyone probably has KMS enabled already. I had been late for many years. Finally, I have KMS, too.

One hour loss, well, not too bad. If anything ever happens again to X Window, I will have 210x65 (1680x1050) console, pretty! But let's hope it won't come to that.

2012-11-21T02:37:36Z: I just noticed that when I booted into X, the memory usage is only 48MB, used to be 72MB. Don't know if that's because of KMS or new X stuff updates.

When I was trying to watch a live streaming, VLC only burped once and no more audio output. The Message dialog spat lots of warning messages:
main warning: audio drift is too big (170368), dropping buffer
main warning: audio drift is too big (147148), dropping buffer
main warning: audio drift is too big (134086), dropping buffer
main warning: output date isn't PTS date, requesting resampling (1536590)
VLC can play other media files normally with default preferences, but not with that live streaming. I searched for the error message and read something about changing audio output module to OSS. Before I tried to re-emerge VLC with pulseaudio USE flag, I changed
  • Audio Output Module from Default to ALSA audio output.
Still no luck with it. At this moment, I had issued re-emerge command for PulseAudio support in VLC, while waiting, I made another change for ALSA audio output's settings
  • Audio Device from Default to HDA Intel: STAC92xx Analog (hw:0,0).
That fixes the problem. Somehow the Default audio device would cause the "audio drift too big..., dropping buffer" error. By specifying the device resolving the issue, I have no clue why this didn't happen on other regular media files.

The live streaming is GOMTV, a stream of GSL, a StarCraft II tournament. Watching GSL requires a Windows-only custom media player. I found a Python script, GOMstreamer, which can extract the streaming URL and feed stream data to VLC automatically using just one command.

I installed VLC just for watching this stream because GOMstreamer only officially supports playing using VLC. I am sure you can play it using MPlayer, but I haven't tried to know what exactly behind the scene. Since VLC also uses Qt as SMPlayer does, so I might keep it on my disk for a while. The interface is quite nice.

I don't know if the error is related to the presence of PulseAudio (PA). I have PA installed months ago, because I need to record the system audio output, my sound card does not provide such recording channel. That's how PA got into my computer, I generally do not want a second program does the same things as ALSA has already taken care all tasks except the recording need.
After the installation of PA, I honestly didn't feel much difference than before as in performance and memory consumption. I kept PA around even I now have no need for recording.

I had a couple of times of this error message while merging packages:

/var/tmp/portage/sys-libs/glibc-2.14.1-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/catgets/gencat.o: file not recognized: File format not recognized
collect2: ld returned 1 exit status
make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.14.1-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/catgets/gencat] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.14.1-r3/work/glibc-2.14.1/catgets'
make[1]: *** [catgets/others] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.14.1-r3/work/glibc-2.14.1'
make: *** [all] Error 2

When I first saw this error message, I didnt realize it was caused by corrupted object file in ccache, which was resulted from computer crash. I didnt make that connection at first, searched for answers as best as I could, but nothing had helped out until I ran ccache -C to clean up the cache. And the package successfully merged.

So, every time my computer crashed during merging, I cleaned up ccaches cache. If the merging process has only taken a few minutes when crashes, then cleaning up cache would be fine. However, if the process has been going for a half hour, then thats really bad because you have to completely start over the compilation.

Today, I had this case again and yes, my Gentoo does crash. I knew I had to find a way to deal with this, this probably wont be the last time. Disabling ccache certainly isnt the correct resolution, because having the compiled cache in the first is why you use it and since the problem isnt the compilation but crash, therefore no reason to support disabling it.

By the way, though handbook says:

Warning: ccache is known to cause numerous compilation failures. Sometimes ccache will retain stale code objects or corrupted files, which can lead to packages that cannot be emerged. If this happens (if you receive errors like File not recognized: File truncated), try recompiling the application with ccache disabled (FEATURES="-ccache" in /etc/make.conf) before reporting a bug. Unless you are doing development work, do not enable ccache.

I have never had problem with it except this crash issue. If you will re-merge same package and same version (of the package, not of ebuild revision) more than one time, you definitely needs it to cut the compilation time. Re-merging usually happens when you are trying out a new packages and you are not sure what USE flags to use. Its possible that you re-merge with different USEs. Or when a packages ebuild isnt working well like Firefox last month, the source isnt changed but build process in Gentoo side is, this is how the ccache comes in to help a lot.

To resolve the issue, I began with ccaches website, nothing was mentioned about it, then I saw the following section in ccache manpage, which says:

Corrupt object files
It should be noted that ccache is susceptible to general storage problems. If a bad object file sneaks into the cache for some reason, it will of course stay bad. Some possible reasons for erroneous object files are bad hardware (disk drive, disk controller, memory, etc), buggy drivers or file systems, a bad CCACHE_PREFIX command or compiler wrapper. If this happens, you can either find out which object file is broken by reading the debug log and then delete the bad object file from the cache, or you can simply clear the whole cache with ccache -C if you dont mind losing other cached results.

The problem here is I didnt have CCACHE_LOGFILE set up beforehand and since never actually is the problem of ccache, not entirely to say the least. It seems rather ineffective for enabling this debug log. The fact is that its already too late for this incident.

My chance to resolve the problem lies in ccaches cache files, but I look into the problematic file first:

$ file /var/tmp/portage/sys-libs/glibc-2.14.1-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/catgets/gencat.o
/var/tmp/portage/sys-libs/glibc-2.14.1-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/catgets/gencat.o: data

A normal object file gives:

$ file /var/tmp/portage/sys-libs/glibc-2.14.1-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/crtn.o
/var/tmp/portage/sys-libs/glibc-2.14.1-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/crtn.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

So, now I know what I should look in output of file:

$ cd /var/tmp/ccache
$ find -name *.o -mtime 0 -exec file {} \; | grep 'data$' | cut -f1 -d: | xargs ls -l

This should give you a list of files which were modified within 24 hours and file recognizes them as data. Once you are certain one of them are corrupted file by checking the modified time, you remove them all:

$ find -name *.o -mtime 0 -exec file {} \; | grep 'data$' | cut -f1 -d: | xargs rm

Yes, you kill them all. I have no way to tell which one really is corrupted object file. The easier way is to delete all of them. Its cache, if its not there, then the compiler can always compile again. It is better than clean up the whole cache.

Once you remove the files, you resume the merge. The problem should be gone.

There is an error on emerging newly-stabilized-but-failed firefox-10.0.3:

run-mozilla.sh: Cannot execute /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/browser/installer/../../dist/bin/shlibsign.
The more complete build log:

Warning: package error or possible missing or unnecessary file: bin/libnssckbi.so (package-manifest, 372).
bin/components/pipboot.xpt
bin/components/pipnss.xpt
bin/components/pippki.xpt
Warning: package error or possible missing or unnecessary file: bin/libnss3.so (package-manifest, 376).
Warning: package error or possible missing or unnecessary file: bin/libnssutil3.so (package-manifest, 377).
Warning: package error or possible missing or unnecessary file: bin/libsmime3.so (package-manifest, 378).
Warning: package error or possible missing or unnecessary file: bin/libsoftokn3.so (package-manifest, 379).
Warning: package error or possible missing or unnecessary file: bin/libfreebl3.so (package-manifest, 380).
Warning: package error or possible missing or unnecessary file: bin/libssl3.so (package-manifest, 381).
Warning: package error or possible missing or unnecessary file: bin/libfreebl3.chk (package-manifest, 382).
Warning: package error or possible missing or unnecessary file: bin/libsoftokn3.chk (package-manifest, 383).
Warning: package error or possible missing or unnecessary file: bin/libnssdbm3.so (package-manifest, 384).
Warning: package error or possible missing or unnecessary file: bin/libnssdbm3.chk (package-manifest, 385).
[snip]
Linking .xpt files...
[browser]
Manifest file: ../../dist/firefox//components/interfaces.manifestLinking .xpt files completed.
/usr/bin/python2.7 /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/toolkit/mozapps/installer/link-manifests.py \
  ../../dist/firefox//components/components.manifest \
  ../../dist/manifests/xpcom/components ../../dist/manifests/browser/components
Warning: trying to link manifests in missing directory '../../dist/manifests/xpcom/components'
/usr/bin/python2.7 /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/toolkit/mozapps/installer/link-manifests.py \
  ../../dist/firefox//chrome/nonlocalized.manifest \
  ../../dist/manifests/xpcom/chrome ../../dist/manifests/browser/chrome
Warning: trying to link manifests in missing directory '../../dist/manifests/xpcom/chrome'
/usr/bin/python2.7 /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/toolkit/mozapps/installer/link-manifests.py \
  ../../dist/firefox//chrome/localized.manifest \
  ../../dist/manifests/en-US/chrome
printf "manifest components/interfaces.manifest\nmanifest components/components.manifest\nmanifest chrome/nonlocalized.manifest\nmanifest chrome/localized.manifest\n" > ../../dist/firefox//chrome.manifest
/usr/bin/python2.7 /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/config/optimizejars.py --optimize /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/browser/installer/../../jarlog//en-US ../../dist/bin/chrome ../../dist/firefox/chrome
signing nss libraries

run-mozilla.sh: Cannot execute /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/browser/installer/../../dist/bin/shlibsign.

make[1]: *** [stage-package] Error 1
make[1]: Leaving directory `/var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/browser/installer'
make: *** [install] Error 2
emake failed
 * ERROR: www-client/firefox-10.0.3 failed (install phase):
 *   emake install failed
 * 
 * Call stack:
 *     ebuild.sh, line  85:  Called src_install
 *   environment, line 6495:  Called die
 * The specific snippet of code:
 *       MOZ_MAKE_FLAGS="${MAKEOPTS}" emake DESTDIR="${D}" install || die "emake install failed";
 * 
 * If you need support, post the output of 'emerge --info =www-client/firefox-10.0.3',
 * the complete build log and the output of 'emerge -pqv =www-client/firefox-10.0.3'.
 * The complete build log is located at '/var/tmp/portage/www-client/firefox-10.0.3/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/www-client/firefox-10.0.3/temp/environment'.
 * S: '/var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10'

 * Messages for package www-client/firefox-10.0.3:

 * You are enabling official branding. You may not redistribute this build
 * to any users on your network or the internet. Doing so puts yourself into
 * a legal problem with Mozilla Foundation
 * You can disable it by emerging firefox _with_ the bindist USE-flag
 * Fallback PaX marking -m
 *      /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell
 * ERROR: www-client/firefox-10.0.3 failed (install phase):
 *   emake install failed
 * 
 * Call stack:
 *     ebuild.sh, line  85:  Called src_install
 *   environment, line 6495:  Called die
 * The specific snippet of code:
 *       MOZ_MAKE_FLAGS="${MAKEOPTS}" emake DESTDIR="${D}" install || die "emake install failed";
 * 
 * If you need support, post the output of 'emerge --info =www-client/firefox-10.0.3',
 * the complete build log and the output of 'emerge -pqv =www-client/firefox-10.0.3'.
 * The complete build log is located at '/var/tmp/portage/www-client/firefox-10.0.3/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/www-client/firefox-10.0.3/temp/environment'.
 * S: '/var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10'
The problem seem to be path issue and only on x86_64 arch (because this arch is only one got stabilized). Someone unmasked 11.0 to skip the issue, but I don't want to build again, ccache already have cache for 10.0.3. Another 2 hours for 11.0? Not gonna do it. I will wait for a fix.

Firefox building has become a monster, long build time and huge memory usage during linking stage. 64% of 2GB more. A few version after, I might need to user firefox-bin, just like libreoffice-bin.

I looked into Changelog and saw this is actually something called 10.0.3 ESR (Extended Support Release), which is begun with Firefox 10. And this is why there is an "esr" string in "mozilla-esr10." I don't know if this ESR has different build process or because 10.0.3 is a planned security update, therefore the Gentoo dev rushed to mark 10.0.3 as stable.

I can't remember I have ever had Firefox failed to emerge before. When some big update is included, I always wait for a while, monitor the forums. I forgot that this time. Everything has its first, doesn't it?

Anyway, be sure to subscribe to RSS feed of firefox package updates, so you don't need to keep watching for the fix.

The workaround is here (2012-03-24T04:47:15Z)

A workaround was posted and I wish I had read it soon enough. It basically bypasses the non-existing executable file, shlibsign, by changing && to ;. If you know shell scripting, you know what that does.

The comments in the bug report also reported that this is not x86_64 only, you other arch users, we, x86_64 users, are your lab rat! ;p

I actually tried to symlink to actual shlibsign was when I was trying to resolve the issue, but it was actually a directory not an executable file. I was hoping the build script would somehow pick it up and build that build. It didn't work.

Now I know, I can bypass it, I bet you you can do the following to bypass while emerging:
ln -s shlibsign /bin/true
But there is no need, because the patch is in the Portage tree. Resync and emerge again, you will have a successful emerge this time.

The problem here is it does not resolve the issue as the patch submitter said it's a workaround. There is a reason why the build script wants to run that file, even it seems that we don't need that process.

As I said in My weekly Gentoo update process:

When you have doubts or you are nervous about an update, do a search for those guides. Or wait for a little bit, say a few days, then search on forums to see if there is any victims :)

No need to rush for an update, let others be your lab rats! xD

I think many Blogger users have been waiting for such improvements, the most useful option probably is the robots settings for me.

Robots header tags


I used to have my template with a special meta tag, so search engines won't index archive pages or search results pages. Now, I have set up this option:


You can read this page for details of those options. The robots tags is also available in per post basis, you can change for specific post.

The result is in HTTP Response Header, not in HTML (Response Body):

robots.txt

(added at 2012-03-27T10:35:58Z)

I noticed that there are some entries of Dynamic Views from search result, and I do not want those, so I customized the robots.txt based on current default robots.txt on Blogspot:
User-agent: Mediapartners-Google
Disallow: 

User-agent: *
Disallow: /search
Disallow: /view
Allow: /

Sitemap: /feeds/posts/default?orderby=update

404


There is also a new setting for writing your own message for 404. The text (HTML is allowed) is basically put into a small message box, the one like the No Found message when you search something not in your blog.

I wrote a 404 message, I think it fits this blog's style. Try to put something in URL and see by yourself.

There seems to have a new data:blog.pageType value error_page, if you customize your template, this may come in handy when you want to have totally different layout for error page.

Redirection


The last one I think is useful is the Custom Redirection. I used to have a page call Selections, but I never updated it after I created it, so I deleted a while ago. If I want, now I can set up a redirection for it.

The other scenario is typo in post title. We all make mistakes, and sometimes you want to fix it. If you post a blog post, then you finally notice there is a typo in your blog post. It may be too late to delete it and recreate a new post with correct post title. You can not change post slug URL, you must re-post in order to fix it.

The post probably is already indexed by search engine and even shared by your readers. If you delete it, whoever follow the link will not find it.

With this new redirection feature, there is no problem. Just post and set up a redirection, then redirect from the embarrassing one to the new one.

Search Description

To be honesty, this is not so practical in my opinion. For homepage,


Even you can see Google use posts contents to describe, I don't really care because it does not read like globgrubglab.

As for posts:


The first one should not have post title and time tag in the description, but second one is correct.

With Search Description feature, the issues above can be avoid. The question is are you willing to and can you remember to write a short description for each post? I am not and probably can't. But that's just me.

Still, this is a good addition, it's good to have even I don't need it. You can never know if someday this may save your life.

This is a good example why that's good idea to check bug reports or forums before emerge/upgrade big package (long build time or long list of upgrading dependencies).

I had been holding up on libreoffice since version 3.3.4, the next stable version 3.4.x which I masked because it has long dependencies list which was required by 3.3.4. But yesterday, I decided to upgrade libreoffice to 3.4.5.2 even the dependencies list is still long.

Almost 20 packages were new installs on my system and I have to have CUPS and gstreamer and all other sorts I don't use. Merging from the source is too overwhelming for me. The last version I built was openoffice-3.0.0, 3 hours, 30 minutes and 12 seconds.

After finished, I did not run it right away and I just knew it has a bug report (and a thread) which you will see this error message:
~ $ loffice 
/usr/bin/loffice: line 2: 29884 Illegal instruction     /usr/lib64/libreoffice/program/soffice "$@"

Apparently, it only affects AMD64 arch and I am using that.

For now, I am uncommenting this line in /etc/portage/packages.mask:
=app-office/libreoffice-bin-3.4.5.2

and re-emerging for downgrading. Shouldn't have commented out that line. ;)


I was trying to read an issue from a link, but Google Code Issue Trackers seemed to be down.

I have seen this error page many many times, it's quite general on Google's products. But I have never really read it.

There is an error, but I am not talking about Error 502.

Can you find it?

Sorry, no prize, just for fun.

Either Google employees are elite or it just is, well, a tiny error.

Some common errors can be easily resolved on Fedora.

Error: Missing shared library
ALSA lib pcm.c:2162:(snd_pcm_open_conf) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
Resolution
The missing file in what package can be queried by running yum provides "*/libasound_module_pcm_pulse.so".

I keep my experiences on compiling in this blog post, the compilation is the standard ./configure && make. The resolutions listed here is for Fedora.

Error
checking for GTK... configure: error: GTK+-2.8 is required to compile gtk-engines
Resolution
gtk2-devel package is not installed or too old.

Error
configure: error: No C++ compiler found
Resolution
gcc-c++ package is not installed.

Error
$ make
[snip]
gcc "-Wall" "--std=c99" "-Os" "-s" -o ".pm-cache/34-1-utils" ".pm-cache/1-utils.o" ".pm-cache/2-main.o" ".pm-cache/3-lua.o" ".pm-cache/4-word.o" ".pm-cache/5-bit.o" ".pm-cache/6-screen.o" ".pm-cache/32-31-7-_prologue.o" ".pm-cache/33-dpy.o" "-lm" "-lncursesw" "-llua5.1"
/usr/bin/ld: cannot find -llua5.1
Resolution
If you are sure you have installed the library, then this is usually caused by the different naming (convention) of /usr/lib[64]/*.so on different distributions or you are compiling on x86_64 but the compiling script find the wrong directory for *.so and can't find a such name (If found, the error message should be about ELF Class is not compitable). You may need to open Makefile and change -llua5.1 to -llua whereever you find.

This blog post is a collection of Yum/RPM errors and their resolutions on Fedora. They may not be happened on me, so I can ensure that does work or will the resolutions be harmful.

Error
Loaded plugins: refresh-packagekit
rpmdb: Thread/process 3198/3087034048 failed: Thread died in Berkeley DB library
error: db4 error(-30975) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db3 - (-30975)
error: cannot open Packages database in /var/lib/rpm
Traceback (most recent call last):
[snip]
TypeError: rpmdb open failed
Resolution [1, 2]
rm -f /var/lib/rpm/__db*
db45_verify /var/lib/rpm/Packages
rpm --rebuilddb
yum clean all
yum update