2019-10-16

SDカードリーダーが故障したので買い替え

ハードウェア

SDカードの写真をSDカードリーダーを使ってPCへ取り込もうとしたものの、認識されない。

試しに別なカードをリーダーに挿して試しても、やはり認識されない。

PCのUSBポートを変更してもダメ。

古いノートPCを出して本体にあるSDカードスロットで試したら認識された。

という事で、SDカードリーダーが故障していると判断して、買い換えることにした。

最近のリーダーはUSB3.0 にも対応しているようで、手頃な以下を購入。

バッファローの BSCR27U3BK という製品。

バッファロー USB3.0 microSD/SDカード専用カードリーダー(ブラック)BSCR27U3BK

購入して早速SDカードを読み込んで見ると・・・無事に認識してデータを取り出せた。 USBメモリと同様、キャップを無くさないように気をつけねば・・・。 f:id:savakan:20191009194640j:plain

なお、この製品は、キャップにも本体にもストラップホールはありません。さて、使えなくなった古いSDカードリーダーは、以下の製品。 f:id:savakan:20191009194548j:plain

2008年10月に通販で買ったものらしく、当時の価格で、税込349円（送料別）。裏面には、「撕毀不保」と書かれたシール。翻訳すると、「破れは保証しない」といった内容らしい。

2019-09-28

CentOS 8.0 で dnf.log がUTCで出力される

CentOS8

【環境】
# cat /etc/redhat-release
CentOS Linux release 8.0.1905 (Core)

# rpm -qa | grep dnf
dnf-data-4.0.9.2-5.el8.noarch
python3-libdnf-0.22.5-5.el8_0.x86_64
python3-dnf-plugin-spacewalk-2.8.5-11.module_el8.0.0+180+337688dc.noarch
libdnf-0.22.5-5.el8_0.x86_64
dnf-4.0.9.2-5.el8.noarch
dnf-plugins-core-4.0.2.2-3.el8.noarch
dnf-plugin-spacewalk-2.8.5-11.module_el8.0.0+180+337688dc.noarch
python3-dnf-4.0.9.2-5.el8.noarch
python3-dnf-plugins-core-4.0.2.2-3.el8.noarch

CentOS-8は,、bootイメージから最小構成でインストール。
インストーラで、タイムゾーンをJSTに指定してインストールした。

dateコマンドは、JSTで表示される。

# date
2019年  9月 26日 木曜日 18:36:20 JST

dnf.log へ出力するため、dnf update する。

# dnf update
・・・略

ログを確認。UTCで出力されている。

# tail /var/log/dnf.log
2019-09-26T09:37:06Z DEBUG extras: は 2019年09月21日 22時57分03秒 から取得したメタデータを使用中
2019-09-26T09:37:07Z DDEBUG timer: sack setup: 10304 ms
2019-09-26T09:37:07Z DEBUG Completion plugin: Generating completion 
cache...
2019-09-26T09:37:07Z DEBUG --> 依存関係の解決を開始しました
2019-09-26T09:37:07Z DEBUG --> 依存関係の解決が完了しました
2019-09-26T09:37:07Z DDEBUG timer: depsolve: 117 ms
2019-09-26T09:37:07Z INFO 依存関係が解決しました。
2019-09-26T09:37:07Z INFO 行うべきことはありません。
2019-09-26T09:37:07Z INFO 完了しました!
2019-09-26T09:37:07Z DDEBUG Cleaning up.

/var/log/dnf.rpm.log や /var/log/dnf.librepo.log も同様にUTCで出力。

プラグインは使っていないので、/var/log/dnf.plugin.log は無い。

/var/log/hawkey.log はJSTで出力される模様。

設定に何かあるのかと思い、man dnf.conf で確認したけど、それっぽい設定値は見つからず。

なお、cron や secure など他のログはJSTで出力されている。

# tail /var/log/cron
Sep 26 15:01:01 cent8 run-parts[11234]: (/etc/cron.hourly) finished 0anacron
Sep 26 16:01:01 cent8 CROND[11261]: (root) CMD (run-parts /etc/cron.hourly)
Sep 26 16:01:01 cent8 run-parts[11261]: (/etc/cron.hourly) starting 0anacron
Sep 26 16:01:01 cent8 run-parts[11261]: (/etc/cron.hourly) finished 0anacron
Sep 26 17:01:01 cent8 CROND[11288]: (root) CMD (run-parts /etc/cron.hourly)
Sep 26 17:01:01 cent8 run-parts[11288]: (/etc/cron.hourly) starting 0anacron
Sep 26 17:01:01 cent8 run-parts[11288]: (/etc/cron.hourly) finished 0anacron
Sep 26 18:01:01 cent8 CROND[11321]: (root) CMD (run-parts /etc/cron.hourly)
Sep 26 18:01:01 cent8 run-parts[11321]: (/etc/cron.hourly) starting 0anacron
Sep 26 18:01:01 cent8 run-parts[11321]: (/etc/cron.hourly) finished 0anacron

2019/9 末時点で、ネット上に同様の情報がなく、対処方法も不明。

2019-07-20

Java Update でスクリプトエラーが出る

Windows Java

◆環境
Windows 10 1903
Java SE8 Update 211 → Update 221 への自動更新通知

更新通知が出たので、更新を試みると次のようなエラーが発生。

f:id:savakan:20190720103923p:plain

スクリプトエラー

！このページのスクリプトでエラーが発生しました。

ライン: 1
文字: 1
エラー: ')'がありません。
コード: 0
URL:

このページのスクリプトを実行し続けますか？

はい(Y)  いいえ(N)

対応としては、Oracleのサイトからインストーラを入手して、インストール。

インストール中に、古いバージョンを削除するか尋ねられるので、予め古いバージョンを消す必要は無い。

2019-05-25

ThinkPad SL300 のHDDをSSDに換装

Windows ハードウェア

4月に部屋を片付けていたら、古いノートPCが出てきた。

ThinkPad SL300 ってノートPCで、ITmedia に2008年の記事があった。
www.itmedia.co.jp

Windows Vistaだったが、暫く前に使わなくなり、遊びでUbuntuを入れたものの、そのまま片付けられていた。

f:id:savakan:20190427142650j:plain

過去の注文メールで確認すると、CPUはCore 2、メモリ2GB、HDD160GBだった。

2009年2月に買ったもので、86000円ぐらい。

f:id:savakan:20190427142704j:plain

特に故障もせずしまい込んでいたので、これはまだ使えると思い、HDDをSSDへ換装することにした。

まずは楽天でSSDを発注。安定のSanDisk。

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

120GB SSD SanDisk サンディスク SSD PLUS 2.5インチ内蔵型 SATA3 6Gb/s R:545MB/s W:310MB/s SLC-Caching 海外リテール SDSSDA-120G-G27 ◆メ
価格：2599円（税込、送料無料) (2019/5/25時点)

やっぱりSSDは重さも軽い。 f:id:savakan:20190427142726j:plain

Thinkpadは、部品の交換が容易な構造なのが良い。

さっそくHDDを抜こうと黒いラベルを引っ張るが、相当硬い。

とにかく抜けない(´・ω・`)

諦めかけていた、その時！！！

やっぱり抜けない(´・ω・`)

滑らない軍手を持ち出して、何とか抜いた。

f:id:savakan:20190427151224j:plain

HDDを外してSSDへ交換し、差し込んで電源を投入。

BIOSで認識したので、あとは適当なOSをインストールして再利用することにする。

2019-05-11

CentOS 8 リリースまでのタイムライン

CentOS8

ついにRHEL8がリリースされ、CentOS 8のリリースが待たれる。

いつ頃かな？と思っていたら、以下に情報があるとアナウンスされたのでメモ。

wiki.centos.org

2019-05-11

yum update を途中で終了してしまい、エラーになった後の対処

CentOS7

【環境】
CentOS Linux release 7.6.1810 (Core)

発端は、、、
yum update している途中で、うっかりターミナルを閉じてしまった(´・ω・`)

再びログインして、 yum update するとエラーが発生した。

# yum update
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.yz.yamagata-u.ac.jp
 * epel: ftp.yz.yamagata-u.ac.jp
 * extras: ftp.yz.yamagata-u.ac.jp
 * updates: ftp.yz.yamagata-u.ac.jp
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ glibc.x86_64 0:2.17-260.el7_6.4 を 更新
--> 依存性の処理をしています: glibc = 2.17-260.el7_6.4 のパッケージ: glibc-common-2.17-260.el7_6.4.x86_64
---> パッケージ glibc.x86_64 0:2.17-260.el7_6.5 を アップデート
--> トランザクションの確認を実行しています。
---> パッケージ glibc.i686 0:2.17-260.el7_6.4 を インストール
--> 依存性の処理をしています: libfreebl3.so(NSSRAWHASH_3.12.3) のパッケージ: glibc-2.17-260.el7_6.4.i686
--> 依存性の処理をしています: libfreebl3.so のパッケージ: glibc-2.17-260.el7_6.4.i686
---> パッケージ glibc.x86_64 0:2.17-260.el7_6.4 を 更新
--> トランザクションの確認を実行しています。
---> パッケージ nss-softokn-freebl.i686 0:3.36.0-5.el7_5 を インストール
--> 依存性解決を終了しました。
エラー:  Multilib version problems found. This often means that the root
        cause is something else and multilib version checking is just
        pointing out that there is a problem. Eg.:

          1. You have an upgrade for glibc which is missing some
             dependency that another package requires. Yum is trying to
             solve this by installing an older version of glibc of the
             different architecture. If you exclude the bad architecture
             yum will tell you what the root cause is (which package
             requires what). You can try redoing the upgrade with
             --exclude glibc.otherarch ... this should give you an error
             message showing the root cause of the problem.

          2. You have multiple architectures of glibc installed, but
             yum can only see an upgrade for one of those architectures.
             If you don't want/need both architectures anymore then you
             can remove the one with the missing update and everything
             will work.

          3. You have duplicate versions of glibc installed already.
             You can use "yum check" to get yum show these errors.

        ...you can also use --setopt=protected_multilib=false to remove
        this checking, however this is almost never the correct thing to
        do as something else is very likely to go wrong (often causing
        much more problems).

        Protected multilib versions: glibc-2.17-260.el7_6.5.x86_64 != glibc-2.17-260.el7_6.4.i686

/var/log/yum.log を確認しても、更新がインストールされたログは記録されていない。

パッケージを確認してみると、

# rpm -qa | grep glibc-common
glibc-common-2.17-260.el7_6.4.x86_64
glibc-common-2.17-260.el7_6.5.x86_64

のように、glibc-common が2つ入った(?)状態になっている。

よりによって glibc とは・・・。

重複したパッケージの整理を試みる。
（package-cleanup コマンドは、yum-utils パッケージに入っている）

# package-cleanup --cleandupes
読み込んだプラグイン:fastestmirror
Not removing glibc-common-2.17-260.el7_6.4.x86_64 because it is required by 1 installed package
No duplicates to remove
Warning: Some duplicates were not removed because they are required by installed packages.
You can try --cleandupes with --removenewestdupes, or review them with --dupes and remove manually.

オプションが足りないらしいので、追加してもう一度。
新しいバージョンのほうだけ削除されそうに見えるので、y を押して続行。

# package-cleanup --cleandupes --removenewestdupes
読み込んだプラグイン:fastestmirror
読み込んだプラグイン:fastestmirror
--> トランザクションの確認を実行しています。
---> パッケージ glibc-common.x86_64 0:2.17-260.el7_6.5 を 削除
--> 依存性解決を終了しました。

依存性を解決しました

=========================================================================================================
 Package                  アーキテクチャー        バージョン              リポジトリー        容量
=========================================================================================================
削除中:
 glibc-common             x86_64                  2.17-260.el7_6.5        installed           115 M

トランザクションの要約
=========================================================================================================
削除  1 パッケージ

インストール容量: 115 M
上記の処理を行います。よろしいでしょうか？ [y/N]y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
警告: RPMDB は yum 以外で変更されました。
  削除中                  : glibc-common-2.17-260.el7_6.5.x86_64          
                                                                          
                                                             1/1
  検証中                  : glibc-common-2.17-260.el7_6.5.x86_64          
                                                                          
                                                             1/1

削除しました:
  glibc-common.x86_64 0:2.17-260.el7_6.5

完了しました!

パッケージの確認

# rpm -qa | grep glibc-common
glibc-common-2.17-260.el7_6.4.x86_64

1つになっていて良さげ。

yum update で再び更新すると問題なくアップデートされた。

yum.log を見てみると、

# tail /var/log/yum.log
・・・
 5月 11 08:58:42 Erased: glibc-common-2.17-260.el7_6.5.x86_64
May 11 08:59:52 Updated: glibc-common-2.17-260.el7_6.5.x86_64
May 11 08:59:54 Updated: glibc-2.17-260.el7_6.5.x86_64

という感じで大丈夫そうに見える。

2019-04-20

date コマンドで令和から紀元前まで

CentOS7 シェル

Windowsが元号関連で色々と話題なっているなか、Linuxではどうなっているか？

glibc をupdateすると、新元号にも対応するとの事で、前後の結果をメモしておく。

新元号に対応前

$ LC_ALL=ja_JP.utf8 date +%EY -d 20190501
平成31年

yum updateした後

# grep glibc /var/log/yum.log
Apr 13 08:08:41 Updated: glibc-common-2.17-260.el7_6.4.x86_64
Apr 13 08:08:43 Updated: glibc-2.17-260.el7_6.4.x86_64
Apr 13 08:09:21 Updated: glibc-headers-2.17-260.el7_6.4.x86_64
Apr 13 08:09:21 Updated: glibc-devel-2.17-260.el7_6.4.x86_64
Apr 13 08:09:30 Updated: glibc-2.17-260.el7_6.4.i686

新元号に対応後

$ date +%EY -d 20190501
令和元年

おぉ、令和になった！

%EY オプションを使う事があまりないので、他の引数も試してみる。

$ date +%EY -d 00010101
西暦1年

うっかり桁数を間違えたら、、、紀元前（´・ω・｀）？

$ date +%EY -d 0001101
紀元前1年

少し変えてみたら平成に。

$ date +%EY -d 000110
平成12年