投稿者: osakanataro

投稿日:

RHEL6のkickstartでPV/VGの名前に_が使えない？

最近、RHEL6/CentOS6の構築自動化手法をいろいろ検討中。

インストール時のkickstartファイルの編集中に初めて認識した仕様。

Logical Volumeの名前は自由に指定できる。
Volume Groupの名も自由に指定できる。
Pythical Volumeの名前はある程度制限される。

「fedora project:Anaconda/Kickstart:part or partition」
kickstart内でパーテーション作成をする際、命名法則により使用用途が決定される、という仕様になっている。
LVMで使用するためにPVを作成する場合は「pv.～」という命名規則で作る必要がある。
（pv.以降は好きに名前をつけられる）

というわけで、自動生成された「pv.0083」とかいう感じのPVを「pv_vol1」とかに名前変更しようとして失敗したのは、この仕様のせいで、「pv.vol1」とかにすれば問題ない、ということでした。

投稿日:

RHEL6インストールガイドの「EFI用のPXEブートの設定」の記述が嘘っぱちな件

PXEブートを使ってRHEL6/CentOS6のインストールを行おうとしたら、RHEL6の公式ドキュメントに騙された・・・

参照にしたドキュメントは「インストールガイド EFI 用の PXE ブートの設定」
(英語版の「30.2.2. Configuring PXE Boot for EFI」も誤っている)

(2015/04/07 英語版/日本語版共に、３の記述は修正されたことを確認)

誤っているところは、以下のところ

3. tftpboot 内に EFI ブートイメージ用のディレクトリパスを作成して、ブートディレクトリからブートイメージをコピーします。
mkdir /var/lib/tftpboot/pxelinux
mkdir /var/lib/tftpboot/pxelinux/bootx64.efi
cp /boot/efi/EFI/redhat/grub.efi /var/lib/tftpboot/pxelinux/bootx64.efi

上記手順だと、grub.efiを/var/lib/tftpboot/pxelinux/bootx64.efi/grub.efiに置くことになる。

5. pxelinux 内に pxelinux.cfg ディレクトリを作成します。
mkdir /var/lib/tftpboot/pxelinux/pxelinux.cfg

6. このディレクトリに設定ファイルを追加します。ファイル名は、efidefault とするか、または IP アドレスにちなんだ名前を付けます。例えば、マシンの IP アドレスが 10.0.0.1 の場合には、ファイル名を 0A000001 とします。
/var/lib/tftpboot/pxelinux/pxelinux.cfg/efidefault にあるサンプルの設定ファイルは以下のようになります。

何が間違っているか？

「ファイルを置くパス」

正しい手順は、以下の通り

3. tftpboot 内に EFI ブートイメージ用のディレクトリパスを作成して、ブートディレクトリからブートイメージをコピーします。

mkdir /var/lib/tftpboot/pxelinux
cp /boot/efi/EFI/redhat/grub.efi /var/lib/tftpboot/pxelinux/bootx64.efi

grub.efiをbootx64.efiという名前で/var/lib/tftpboot/pxelinux/に置く。

5. pxelinux 内に pxelinux.cfg ディレクトリを作成します。
mkdir /var/lib/tftpboot/pxelinux/pxelinux.cfg

EFIの場合は、/var/lib/tftpboot/pxelinux/pxelinux.cfg/というディレクトリを作る必要は無い。

6. このディレクトリに設定ファイルを追加します。ファイル名は、efidefault とするか、または IP アドレスにちなんだ名前を付けます。例えば、マシンの IP アドレスが 10.0.0.1 の場合には、ファイル名を 0A000001 とします。
/var/lib/tftpboot/pxelinux/efidefault にあるサンプルの設定ファイルは以下のようになります。

default=0
timeout=1
splashimage=(nd)/splash.xpm.gz
hiddenmenu
title RHEL
        root (nd)
        kernel /rhel6/vmlinuz
        initrd /rhel6/initrd.img

efidefaultというファイルは/var/lib/tftpboot/pxelinux/というディレクトリに置く。
なぜか「/rawhide-x86_64/」と記載されているが、後の記述をみると「/rhel6/」であるべきもの。

参考にしたページ
・Grokbase:[CentOS] PXE booting UEFI
・fedora project:QA:Testcase UEFI pxeboot

投稿日:

Bcrodcom BCM23550採用でAndroid 4.4(KitKat)対応のもの

Coviaのtwitterアカウント曰く、「CP-F03aにAndroid 4.4 KitKatを入れると、メモリは512MBのままで、動作サクサクに。」とのこと。

CP-F03aのAndroid 4.4へのアップデータ提供がいつかわからないので、他の機種からぱくってこれないか調べてみた。

まず、前回調べた「Broadcom BCM23550チップ採用のAndroid機種のメモ書き(2014/04/01)」に掲載している機種を確認したところ、アップデータは無かった。

では、前回対象外とした、怪しげメーカ群を探してみることにした。

・YUHUA TELECOM(雨桦通信)社取扱品全般
Alibabaにもサイトを持っているYUHUA TELECOM(雨桦通信)社
「Alibabaの企業ページ」
上記ページを見てみると、Broadcomチップ採用のスマホをいろいろ扱っている模様。

「EOS J??」という名称のバリエーションモデルと、HTC ONE風の「ORION J??」というモデルがあるようなんだが、各モデルの違いがわかりにくいという・・・
EOS J15 BCM23550 1.2GHz Quad Core (Cortex A7) 4.5″ HD (1280*720) IPS Android 4.4 (KitKat)
ORION J01 BCM23550 1.2GHz Quad Core 5″ HD (1280*720) IPS NFC Phone

とりあえず、全部Android 4.4(KitKat)のモデルということになっているらしい。

ざらっと探したけど、

・Overmax Vertis Expi
ドイツのOvermaxというところが扱っている「Overmax Vertis Expi」はBCM23550搭載だが、現状Android 4.2.2まで。

・Lava QPAD e704
インドの7インチタブレット
Broadcomのプレスリリースで紹介されている「Lava Selects Broadcom Quad-Core HSPA+ Turnkey Platform to Power New QPAD Tablet」

投稿日:

Covia FleaPhone CP-F03aの近況

Covia FleaPhone CP-F03aが届いて１ヶ月。いろいろありました。

いろいろ問題があったりしましたが、先日リリースされた「firmware ver 20140415」でひとまず落ち着いた感じです。

いままで私の端末で発生した問題として、以下のものがあります。

1. CP CRASHと表示され再起動する
2. いきなり再起動し、ブラックアウト。電源ボタンを押しても何も反応しない
3. CP CRASH毎に/data領域が圧迫されていく

これらについて、Coviaのサポートに連絡し、クラッシュダンプの送付などを行い、調査・対応を行ってもらいました。

1番は、「firmware ver 20140315」で解消されたように見えたのですが、入れ替わって、2番の現象が発生するようになりました。

2番は、実はブラックアウトしても内部的にはクラッシュダンプ処理をしていて、１５分ぐらいたつと電源ボタンが使えるようになります。
最初はあまりこの現象が発生していなかったのですが、4/7ぐらいから発生率が急上昇し、最盛期には１時間に１回ぐらい発生していました。
最新のfirmware ver 20140415でこれが発生しなくなったような感じです。

3番は、CP CRASHすると/data/dontpanicディレクトリにクラッシュダンプデータが書き込まれていくことで、発生していました。
これは、「firmware ver 20140327(2014/04/01リリース)」で修正されました。

これで一通り問題があったところが解消したかなぁ・・・というところではあります。

投稿日:

Outlookの.msgファイルをOutlook無しで読むMSGViewer

Outlookの内部ファイル形式であるところの拡張子.msgのファイルをOutlookを使わないで読み取るツールが必要になったので、探した。

由来があやしいsoftnicとかは使いたくないので、そこそこ由来が追えるものを探していったところ、SourceForgeにて「MsgViewer」というものを発見した。

Javaで動作し、GPLv3ライセンスのソースコードが公開されているものだった。
Windows向けのインストーラと、Linux用のrpmパッケージも用意されていた。

これは、Outlook .msgの他にもThunerbirdの.emlとUNIXのmbox形式も読み込める、とのこと

sourceforge上でのversion1.6の日付は2014/03/16となっていますが、これは、soureforgeに移転してきた日であり、実際には2012/11/30リリースのようです。(changelogより)

最新は、画面表示の仕組みを変更する作業を実施しているようで、そのうち、新しいバージョンが登場するかもしれません。

日本語の表示に関しては、今回届いたメールが英語のものだったので、ちょっとわかりません。
試してみてください。

2019/06/13追記

現在は2015年4月23日リリースのv1.9が最新のようです。

2020/10/12追記

OpenJREをインストールしている環境で「java -jar MSGViewer.jar」という感じで起動して使います。

また、公式が更新してくれないので、https://github.com/lolo101/MsgViewer でforkした開発を行っている人もいます。

最新の2020/08/02更新バージョンでは印刷のサポートなどを行っているようです。

2021/04/05追記

MSGViewer 1.9を使ってみたところ、きちんと日本語も表示されました。

「java -jar MSGViewer.jar」で起動したウィンドウにemlファイルをドラッグ＆ドロップで表示されました。

ここにemlファイルをD&Dすると、文面が表示されます

2022/04/15追記

古いJavaが入った環境でMSG Viewer ver 1.10を実行したら、新しいJavaバージョンを要求された。

C:\tmp>java -version
java version "1.8.0_211"
Java(TM) SE Runtime Environment (build 1.8.0_211-b12)
Java HotSpot(TM) Client VM (build 25.211-b12, mixed mode)

C:\tmp>java -jar X:\tmp\windows\msgviewer.jar
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: net/sourceforge/MSGViewer/ModuleLauncher has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$100(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

C:\tmp>j

このような新しいJavaが入ってないWindows環境で一時的に試すのであればMicrosoft Build of OpenJDK から「Windows X64 zip」のファイル、例えば microsoft-jdk-17.0.2.8.1-windows-x64.zip をダウンロードし、適当なフォルダに展開。

中にあるbin\java.exe をフルパスで指定して実行するとよい。

下記はMicrosoft OpenJDK 17.0.2.8.1 で MSGViewer ver 1.10を実行した例

C:\tmp>X:\tmp\windows\jdk-17.0.2+8\bin\java.exe -version
openjdk version "17.0.2" 2022-01-18 LTS
OpenJDK Runtime Environment Microsoft-30338 (build 17.0.2+8-LTS)
OpenJDK 64-Bit Server VM Microsoft-30338 (build 17.0.2+8-LTS, mixed mode, sharing)

C:\tmp>X:\tmp\windows\jdk-17.0.2+8\bin\java.exe -jar X:\tmp\windows\msgviewer.jar
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
HSWShellExec_amd64.dll loaded via tmp generated pathname: C:\Users\xxxxxxxxxxxxxxx\AppData\Local\Temp\HSWShellExec-12653163171875368309.dll
All Windows closed, normal exit

C:\tmp>