[solved] js52: /usr/lib/libmozjs-52.so.0 exists in filesystem

Living on the edge in Arch Linux land is a fun activity everyone should try (at least once). However, a full system package upgrade caused the following today:

# pacman -Syyu
error: failed to commit transaction (conflicting files) 
js52: /usr/lib/libmozjs-52.so.0 exists in filesystem

I’m not the only one to have the issue. Seems the official way of getting past this is to rename the file, at least per this bug report.

Update: There’s an Arch news post that adds a modicum more information:

Due to the SONAME of /usr/lib/libmozjs-52.so not matching its file name, ldconfig created an untracked file /usr/lib/libmozjs-52.so.0. This is now fixed and both files are present in the package.

To pass the upgrade, remove /usr/lib/libmozjs-52.so.0 prior to upgrading.

I think this is the first time I’ve needed to do a manual intervention for a package upgrade for the time I’ve been running Arch; so all in all not bad.

[Fixed] MySQL: Table is marked as crashed and last (automatic?) repair failed (+ WordPress)

tl;dr: run myisamchk on the problematic table

I’ve run into the following error in my Apache error.log recently:

Table 'database.tablename' is marked as crashed and last (automatic?) repair failed

Fortunately the fix is simple: run myisamchk on the table which is marked as crashed:

$ sudo su
# service mysql stop
# cd /var/lib/mysql/databasename
# myisamchk -r tablename
MyISAM-table 'tablename' is not fixed because of errors
Try fixing it by using the --safe-recover (-o), the --force (-f)
 option or by not using the --quick (-q) flag
# myisamchk -r -o -f tablename
Data records: 107435
Found block that points outside data file at 16166832
# service mysql start

I’ve run into these errors before due to running out of disk space on the (admittedly tiny) VPS I had.

I also had this problem with a WordPress database able, causing the often-seen and unhelpfully terse:

Error establishing a database connection

Interestingly, this wasn’t getting bounced to error.log, and I had to use the WordPress database repair screen to track down which one needed the fix (which was the same myisamchk).

All sorted now!

[Solved] “Filesystem is already n blocks long. Nothing to do!”

tl;dr: if you’re sure you did everything right, use lsblk or parted (etc) to see if a partition table is present on your logical volume.

So I am in the process of merging the content of two fileservers, and had the need to extend a logical volume to accommodate some additional data. No problem- that’s one of the benefits of using LVM!

Except after resizing, I ran into a problem:

$ lvextend +150G /dev/vg/lvinquestion
$ resize2fs /dev/vg/lvinquestion
> The filesystem is already 268435200 (4k) blocks long. Nothing to do!

Wait, what? Aside from the fact I could have combined the comments by including the --resizefs option to lvextend, why was resize2fs complaining that there was “Nothing to do!”?

Fortunately SE Arquade user ToxicFrog had the answer:

@bertieb parted reports the partition size, not the filesystem size
If it’s a partitioned LV you need to resize the partition after expanding the VL

Ah, whoops! I’m not sure why I partitioned the LV (it only had one partition) but I must have done so.

lsblk confirmed the partition:

sdh                                8:112  0   2.7T  0 disk
??sdh1                             8:113  0   2.7T  0 part
  ??md1                            9:1    0  10.9T  0 raid6
    ??vg-lv                      253:9    0   1.2T  0 lvm
    ? ??vg-lv1                   253:18   0   1.1T  0 part

So, then what? Well, I used dd to copy the filesystem to a new logical volume, then extended that, and finally removed the original:

# dd if=/dev/dm-18 bs=1M | pv -s 1T |  dd of=/dev/vg/lv-new bs=1M
# lvextend --resizefs -L 1.15T /dev/vg/lv-new
# lvremove /dev/vg/lv
# lvrename vg lv-new lv

(pv was included to give a nice progress indicator, rather than faffing around with SIGUSR1)

And that was that. There was a slight problem with removing the original logical volume, but more on that later…

MP4 / H264 Errors in Adobe Premiere Pro / Media Encoder / MainConcept

I’ve been editing together a few gameplay videos recently (eg DayZ Tread Lightly).I came across a rather perplexing error when trying to encode a long video. Basically, I have a few sequences of footage taken with FRAPS that together run to about 2 hours and 45 minutes. I created a project for these to run together as a reference for what a typical DayZ session might look like. I also produced a highlights version which is about 1 hour and 8 minutes long. After the latter, the oddness began.

The first uncut set of footage encoded without issues, coming at around 20GB at a high bitrate. The upload of this to YouTube failed after 40 hours, so I decided to re-encode at a slightly saner bitrate and put in a fancy title rather than the overlaid title cards. Before queuing that to encode, I finished off the highlights video, which has sections sped up (between ~800-1700%) to get rid of the boring stuff. Heres where the encoding problems began.

Encoding the highlights clip took much longer than expected, and it seemed to encode further than the 1hr 8min mark up to 2 hr 45 mins (the uncut length). Subsequently, the encoding of the sightly-modified uncut video produced a file that wouldn’t play. Trying various permutations of codec settings wouldnt produce playable files. None of VLC, ffmpeg or medinfo could identify the problem videos.

Producing short clips (eg a 2 minute sample) from either video worked fine, so I split the highlights video into 10-minute segments to see if there was a problem in a section of the timeline. All segments encoded normally, which was a surprise. What was a bigger surprise was that using Premiere to concatenate those clips failed with a similar problem!

At that stage I gave up on getting these videos to work in Premiere. Other videos, eg my Lets Play of FTL worked fine in the interim. Im now using a frameserver to serve videos to MeGUI to encode using x264. Details will hopefully follow if it works.

[Fixed] FTL – Blank Maps & Invisible Ships Problem

Update: fixed! The recently-released FTL by Subset Games has a problem with the 12.8 AMD Catalyst Drivers, whereby the jump map and enemy ships are not rendered See below) due to an issue with edge detection in anti-aliasing. The fix is to create a custom profile for FTLGame.exe in the Catalyst Control Center to over-ride the settings (support thread with instructions, and setting).


FTL Game - Invisible Ship

Update: Now with video!

(yes the overlaps the menu, but there’s not much interesting there anyway!)

Irritation: Falling back to the standard locale (“C”)

Due to the pressures of university (labs, reports, and a dissertation), coupled with some of the other things I’ve been doing I haven’t posted here in ages. For now I’ll have to give you a post that is as much for you as it is for me.

Occasionally on my debian box I get an error such as:

$ perl: warning: Falling back to the standard locale ("C")

I always forget how to fix this, but the following should work:

# dpkg-reconfigure locales

If you get dpkg-reconfigure: locales is not installed, do an

apt-get install locales

and say yes when it asks you if you want to remove base-config. The functions of base-config have been superseded by locales.

You can also try using localeconf.