MediaInfoのコンパイルエラー

gentooをアップデートしていると、時々思わぬエラーで躓きます。

今回はMediaInfoがemergeに失敗しました。

 

/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../lib64/libmediainfo.so: undefined reference to `ZenLib::Ztring::FindAndReplace(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, unsigned long, ZenLib::ztring_t)'
collect2: error: ld returned 1 exit status
make: *** [Makefile:414: mediainfo] エラー 1
 * ERROR: media-video/mediainfo-0.7.96::gentoo failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info '=media-video/mediainfo-0.7.96::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=media-video/mediainfo-0.7.96::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/media-video/mediainfo-0.7.96/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/media-video/mediainfo-0.7.96/temp/environment'.
 * Working directory: '/var/tmp/portage/media-video/mediainfo-0.7.96/work/MediaInfo/Project/GNU/CLI'
 * S: '/var/tmp/portage/media-video/mediainfo-0.7.96/work/MediaInfo'

 

この、"collect2: error: ld returned 1 exit status"というのは、ほとんどの場合、そんな関数ねえよ!っていうエラーだそうで、どんな関数かは、その前の行を見ると、"undefined reference to `ZenLib::Ztring(以下略)"と書いてあるので、Zenlibという関数がないよ、ということだそうです。

 

で、自分でコードを書いたのなら、「あー、関数のスペルミスか」となりますが、emergeなのでそんなはずはありません。

google先生に聞いてみると、gccのバージョン違いで関数が見つからない場合があるようです。

 

gentoo ~ # emerge -p libzen

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] media-libs/libzen-0.4.35

 

やはりありました!

これをemergeし直してから、MediaInfoをemerge -uするとすんなり通りました。

 

エラー文はよく読んでみるものですね。

MediaInfoのコンパイルエラー

gentooをアップデートしていると、時々思わぬエラーで躓きます。

今回はMediaInfo

Gentooのclamavでclamav-unofficial-sigsを使う

普通に

 

gentoo ~ # emerge clamav-unofficial-sigs

 

と、してインストールすると、現時点ではマトモに使えない3.7.2が落ちてくる。

これでは使えないので、test版を使うことに。

うちは64bit環境なので、

 

gentoo ~ # nano /etc/portage//package.accept_keywords

で、つぎの一行を追加

 

app-antivirus/clamav-unofficial-sigs ~amd64

 

そして、~amd64のテスト版を、バージョンまでしっかりとしていてemerge

 

gentoo ~ # emerge =app-antivirus/clamav-unofficial-sigs-5.6.1

 

続いてclamavアカウントに関する設定。

clamavアカウントがbashを利用できるように設定します。

 

gentoo ~ # usermod -s /bin/bash clamav

 

そして、アカウントをロック

gentoo ~ # passwd -l clamav

 

つづいて、設定ファイルを1カ所だけ変更。コメントアウトをハズします。

 

gentoo ~ # nano /etc/clamav-unofficial-sigs/user.conf

 

user_configuration_complete="yes"

 

最後に、ログのディレクトリを作成します。

 

gentoo ~ # mkdir /var/log/clamav-unofficial-sigs

gentoo ~ # chown clamav:root /var/log/clamav-unofficial-sigs

 

では、手動で実行します。

 

gentoo ~ # su clamav -c /usr/sbin/clamav-unofficial-sigs.sh

################################################################################
eXtremeSHOK.com ClamAV Unofficial Signature Updater
Version: v5.6.1 (2017-03-18)
Required Configuration Version: v72
Copyright (c) Adrian Jon Kriel :: admin@extremeshok.com
################################################################################

(以下、出力省略)

 

あとは、上記コマンドをcronに入れるだけですね。

 

GentooでPerlのコンフリクト

Perlのバージョンが古く、emerge -u worldでアップデートしようにもいろいろなPerlのモジュールがコンフリクトしてアップデートされないとき、

 

gentoo ~ # emerge --with-bdeps=y --backtrack=1000 --nodeps perl

 

 で、perl本体だけをバージョンアップし、さらに、

 

gentoo ~ # perl-cleaner --al

 

 で、perlのモジュールをすべてバージョンが一致したものに変えてくれる。

 

 それからemerge -u worldとか-uDNとかやるといいカンジ。

ディスククローンで複製したWindows7で起動時に0x0000007Bエラー

会社で異動があり、移動先でPCがあたる。

このPC、今時500GBのHDDだ。

WD BlueでAFT仕様。

ここ数年、異動してPCがあたる度に、SSDにディスククローンをして、SSDで利用していた。

なにしろ、セキュリティに厳しい会社なので、あちこちWindows標準のEFSで暗号化がかけられ、さらに、MS-OfficeやPDFなどは、社内からしか開けないような独自の暗号化も掛けている。

ただでさえアクセスが遅いHDDをSSDに載せ替えるだけでも、体感的にだいぶ早くなる。

で、今までAOMEI Backupperでライブクローンをすれば、差し替えるだけですんなり起動していたのだが、今回に限っては「Windowsを起動しています」の画面で再起動を繰り返す。

元のハードディスクにつなぎ替え、通常に起動して、システムエラー発生時「自動的に再起動する」をOFFにした。

 

Windows 7でシステムエラー発生時に自動で再起動しないよう設定する方法

121ware.com > サービス&サポート > Q&A > Q&A番号 013044

 

で、再度クローンしてSSDから起動。

すると、STOP 0x0000007Bと表示された。

このエラーでググっても、ディスク自体が悪いのでCHKDSKしろとか、MBRが壊れているのでbootsectでMBRを書き直せとか出てきますが、どれをやってもエラーは解決せず。

HDDから起動し、SSDをDドライブとして使ってみても、何ら問題なくSSDは使える。

HDDがAFTで物理セクタが4K、SSDが512バイトだから、セクタアライメントのせいか?と思ったけど、どうやらそうではなさそう。

AOMEIが悪いのかと、EASEUS TodoBackupを使ってみるも、症状は同じ。

万事休す。

 

と、英語でWindows7 Clone 0x0000007Bでググると、ありました!

マイクロソフトはもちろん、Acronis、Veritas、Citrixといった、有名どころのバックアップソフトの会社や仮想化ソフトの会社はしっかりと自体を把握しておりました。

 

"Stop 0x0000007B" error after you use a Group Policy setting to prevent the installation of devices in Windows 7 or Windows Server 2008 R2

https://support.microsoft.com/ja-jp/help/2773300/stop-0x0000007b-error-after-you-use-a-group-policy-setting-to-prevent

 

これによれば、グループポリシーエディタで他のデバイスIDやリムーバブルディスクのインストールを防止する設定を入れた場合、クローン後のデバイスからは起動できなくなっているようです。

それがわかるのは、次のレジストリの値が1になっている場合だそうです。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PnP\DisableCDDB

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PnP\DontStartRawDevices

 

で、元のHDDを接続し、起動してregeditで確認してみると、ビンゴ!

両方ともに1になっていました。

これを0に書き換え、念のためControlSet001なども書き換えておきました。

そして、再起動など一切せずにAOMEI Backupperを使ってディスククローン。(再起動するとまた1に戻ります。)

クローンされたSSDにつなぎ直して起動。

 

ちゃんと起動しましたとさ。

 

もしかすると富士通ソフトウェア製のSystemwalker Desktop Keeperがインストールされているので、こいつが起動時(もしくは終了時)に、レジストリの値を書き換えているのかもしれません。

 

なお、元のディスクがもう手元にない場合、Windows PEやインストールディスクを使用して、コマンドプロンプトからRegeditを起動し、\Windows\System32\config\SYSTEM のレジストリハイブを読み込んで、上記の値を直すそうですが、私はこの方法は試していないため、他に譲ります。

 

参考 インストールディスクやWindows PEから、起動できないWindowsディスクのレジストリを直す。

レジストリの修正 - PCと解

 

とりあえず、この件に関する日本語解説がなかったので、備忘録として。

GentooでPythonのアップデートを怠ってしまった時のメモ

まず、誤ってPython-2.7を消してしまったけど、Python-execがブロックしている場合、強制的にPython-2.7をインストール。

 

gentoo ~ # emerge -O =dev-lang/python-2.7.12

 

そして、お互いにブロックしているPython-3.4とPython-execがアップデートできない問題は、Python-3.3をアンマージをすれば解決するらしい。

 

gentoo ~ # emerge -C =dev-lang/python-3.3.5-r1

 

これで、Python-3.4のインストールとPython-execのアップデートが実施できる。

でも、emergeをいろいろ走らせると、最初に必ず

python-exec: Invalid impl in /etc/python-exec/python-exec.conf: python3.3

 と言われる。

これは、Python-3.3がインストールされていないのに、python3.3がコンフィグの中に残っているからだそうだ。

これは、eselectで編集する。

 

gentoo ~ # eselect python edit

 

私の場合はnanoが起動するので、python3.3の文字列を消すだけ。

これで解消!

証明書をSHA-1からSHA-2へ移行

自分のサーバーにスマホChromehttps接続するとエラーになる現象に遭遇。

エラー内容は「NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM」

ほっとこうと思ったら、影響が大きかった。

詳細を見ると、SHA-1をサポートしていないとのこと。

対処方法はSHA-2:256bit証明書の再発行しかないようです。

私が使っているのはRapidSSL

再発行するために、RapidSSLユーザーページに行きます。

 

GeoTrustのユーザーページ

https://products.geotrust.com/orders/orderinformation/authentication.do

 

ものすごく素っ気ないページが出てくるので、対象ドメインと登録してあるeメールアドレス、そして、ロボット対策の数字を入れます。

すると、3分ほどでログインページのURLがメールが返ってくるので、メールから該当ページを開きます。

 

アクセスするとこんな感じ。こちらも素っ気ない

f:id:naoyukinagano:20170626224508p:plain

 

左にあるReissue Certificateが再発行なので、これをクリック。

 

f:id:naoyukinagano:20170626224758p:plain

 

「Hashing Algorithm:」の選択を、必ず「SHA-256 with RSA and SHA-256 root」にして、CSRを貼り付けます。

って、ホントはCSRの作成方法も書くといいんでしょうけど、256bit用のCSRはだいぶ前に作成してあったので、ここでは割愛。

サーバには"rapidssl_sha256.csr"というファイル名で保存してあったようで、それを貼り付けるために、

gentoo csr # cat rapidssl_sha256.csr

で、CSRファイルの内容をTermに表示させて、それをコピペしました。

注意点として、CSRは、

-----BEGIN CERTIFICATE REQUEST-----

という文字列で始まり、

-----END CERTIFICATE REQUEST-----

という文字列で終わります。

opensslで生成する際には拡張子は自由につけられるため、ファイル名や拡張子を誤ると、なんだかわからなくなりますが、catで先頭の文字列を確認するとわかりますね。

 

規約に同意してSubmitを押すと、またもやメールが飛んでくるそうです。

RapidSSL Certificate Request Confirmation」というタイトルのメールです。

すべて英語ですが、メールの中程にあるURLをクリックすると、承認画面が現れます。

スクショ取り忘れましたが、最下部の「承認」をクリックします。

オーダーが承認されましたというページが現れます。

証明書はメールで届いていますので、差し替えます。

 

証明書のファイルがどれなのかわからないときは、Apache2のコンフィグを見るとわかります。

SSLCertificateFileで始まる行がそれです。

 

gentoo # cat /etc/apache2/vhosts.d/00_default_ssl_vhost.conf | grep SSLCertificateFile

SSLCertificateFile /etc/ssl/csr/rapidssl.crt

 

では、rapidssl.crtを書き換えます。

gentoo # nano /etc/ssl/csr/rapidssl.crt

すべての文字列を消して、メールで来た証明書文字列の

-----BEGIN CERTIFICATE-----
から
-----END CERTIFICATE-----
までを貼り付けて保存します。
そうですね、さっきのcsrファイルと違って、証明書は-----BEGIN CERTIFICATE-----で始まっているんですね。

これだけで再起動したら動きそうですが、GeoTrustのSSLチェッカーで中間証明書が違うと怒られてしまいました。

GeoTrust SSL Checker

https://cryptoreport.rapidssl.com/checker/views/certCheck.jsp

 

では、中間証明書も入れ替えます。

中間証明書の場所を調べましょう

SSLCertificateChainFileの行です。

gentoo # cat /etc/apache2/vhosts.d/00_default_ssl_vhost.conf | grep SSLCertificateChainFile

SSLCertificateChainFile  /etc/ssl/csr/intermediate.crt

では、intermediate.crtを書き換えます。

 

RapidSSLの256bit rootのcrtは次のURLにあります。

https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO28590

 

上のリンク先にある

-----BEGIN CERTIFICATE-----
から
-----END CERTIFICATE-----
までが中間証明書ですので、これを貼り付けて保存します。

(中間"証明書"と、証明書の一種なので、サーバー証明書同様、-----BEGIN CERTIFICATE-----で始まってますね。)

 

gentoo # nano /etc/ssl/csr/intermediate.crt

中をすべて消して、上記の新たな中間証明書に書き換えます。

 

Apacheを再起動しましょう。

gentoo # # /etc/init.d/apache2 restart
 * Stopping apache2 ...                                                                                        [ ok ]
 * Starting apache2 ...                                                                                        [ ok ]

 

これで無事にアクセスできるはず。