HDDの状態をSMARTで調べる

整理したら古いHDDがたくさん出てきました。それぞれの状態を見てみたいと思います。
HDDの状態を見るといえばSMARTですが、Linux Mintの「ディスク」ユーティリティでもSMARTの状態を見ることができます。

ディスクユーティリティを起動して、対象とするHDDを選択したところです。ここではeSATAで外付けにしたHDDを選択しています。

右上の方のメニューに「SMARTのデータとセルフテスト」というのがあるので、これを選ぶと、最後に取得したデータが表示されるようです。

このHDD、自分の父がHDDを交換したので処分したい、ということで引き取ってきたものなのですが、どうも過去に温度条件の良くないところに突っ込まれてたのでしょうか。温度自体ではなく、Airflow Temparatureなので、筐体の温度ということではないのかもしれませんので、ファンでも壊れてたんでしょうか？？（西日のあたるところに置かれてたようですが、それでも？？）
それ以外は特に問題はないようです。

簡単に扱うならこれでいいのですが、できれば記録に残したいところです。そういう場合はCLIの方が便利です。

標準ではコマンドラインのツールは入っていないようなので、

としてインストールします。–info オプションをつけて smartctl コマンドを実行すると、デバイスの概要を表示してくれます。型番やシリアルナンバーも表示してくれるので、管理には便利です。今回は対象のデバイスが /dev/sdb ですので実行すると以下のような感じになりました。（他のデバイスで行うときには /dev/sdb の部分は読み替えてください）

最後の行にSMARTが有効かどうか記載されていますが、無効の場合には以下の方法で有効化する必要があります。

デバイスが対応しているテストを調べます。

最後の方に記載されている内容によれば、shortテストは2分、extendedテストは90分、conveyanceテスト（輸送時の影響を調べる）だと6分かかるようです。
90分は長いので、shortテストを起動してみます。

ということですぐ帰ってきます。実際の処理はバックグラウンドで行われるようです。なお、extendedテストを実行する場合は-tの後ろはlong、conveyanseテストを実行する場合はconveyanseを指定します。

テスト結果を表示してみます。

テストは無事にPASSしましたが、Airflow Temparatureのイベントに注意、ということみたいです。

最新のテスト結果のリストを表示してみます。

詳細の情報を表示してみます。

※Arch LinuxのS.M.A.R.T.の項目を参考にしました（というか、概ねそのままです）

WindowsとLinuxで時計が狂うのを直す

昔から Linux と Windows のデュアルブートが可能な環境でOSを行き来すると、時計が大きくずれる現象が発生していました。これは Linux ではPCのハードウェア時計（RTC）が UTC（協定世界時）で動作しているのを前提としているのに対し、WindowsではRTCはローカルタイム（JST=日本標準時）で動作しているのを前提としており、それぞれのOSがNTPを利用して時刻修正を行って、それをRTCに反映していることが原因でした。

以前のバージョンのLinuxでは、 /etc/default/rcS に UTC=no と記載することにより、RTCの設定がローカルタイムであることを設定できたのですが、いつの頃からか /etc/default/rcS は存在しなくなっていました。

最近は Linux を使うことがほとんどで、それでもあまり困らなかったのですが、その修正方法がわかったのでメモしておきます。修正は以前と同様、Linux側で行います。使用するコマンドは timedatectl コマンドです。

ということで、最後の行にRTCがローカルタイムゾーンか否かの記載があります。で、

とするとこの設定を変更することができます。ところでこのコマンド、ハードウェア設定の変更に関わるものなのですが、root権限がなくても設定できてしまいます。（いいのかな？）

設定変更後に再度設定状況を読み出すと、

という感じで、警告が表示されます。

Jumper Ezbook Pro 3にLinuxMint19をインストール

先日購入した Jumper Ezbook Pro 3 に LinuxMint19をインストールしてみました。

LinuxMintは内蔵のeMMCの領域ではなく、増設した32GBのmSATAのSSD（安かった KingDian の JP-N400 32GB）にインストールすることで、Windows10は丸ごと温存します。

１．BIOSでUSBメモリからの起動を選択。

今回は Linux Mint 19 MATE の64bit版をインストールします。ISOイメージをダウンロードしてハッシュ値を検証した後、USBイメージライタでUSBメモリに書き込みます。書き込んだUSBメモリをEzbook3 Proに取り付けて電源投入しますが、すぐにDELキーを連打してBIOSに移行、起動デバイスをUSBメモリに変更してから起動します。

２．WiFiの設定（SSID選択、パスワード設定）

起動するとすぐにWiFiを見つけて設定するように促されますが、ここでは設定しません。リリースノートを見るとgrubのインストールに失敗する障害があり、その対策としてインストール時にネットワークに接続しない、というものが挙げられています。これでだいぶ時間を取られてしまいました。

３．内蔵eMMCを禁止。

起動後、ブートローダ等を含めて温存したいので、内蔵eMMCを禁止します。

実行すると、デスクトップ上のSDカードっぽいアイコンが消えます。ひょっとすると（おそらく？）内蔵のMicroSDカードリーダーも見えなくなるかもしれません。この状態でもちゃんと内蔵のMicroSDカードリーダーは見えます。

４．増設したｍSATA SSDを初期化

ディスクユーティリティを使ってSSDを初期化します。初期化しないとこのSSDは全く見えず、インストーラも認識してくれません。

５．インストーラを起動してインストール実行

インストーラを起動、言語は日本語、キーボードレイアウトは 英語（us） を選択。特に難しいところはありません。

６．インストール完了後の設定

まずは誤操作でWindows10のパーティションを壊さないよう、内蔵eMMCを見えないようにします。

/etc/rc.localとして以下の内容のファイルを作成します。

次に、/etc/systemd/system/rc-local.serviceとして以下の内容のファイルを作成します

起動時に自動実行するように設定します。

これで起動後ログインするとeMMCの内容が見えなくなりました。

後は、通常のLinux Mintの設定と大差ありません。

• WiFiの設定
• アップデートの実行
• 言語設定で不足しているファイルをインストール
• 言語設定でIMEを選択。今回はfcitxを選択しました。ibusではUSキーボードで日本語入力モードへ移行するキーバインドが見つかりませんでした。fcitxの場合にはCTRL+SPACEに割り当てられています。

といったところです。

LinuxMint19をAthlon5350マシンにインストール

日本時間で6/30にLinuxMint19がリリースされました。Ubuntu18.04LTSベースなので、長期サポートが期待されます。（Webサイト上でも2023年までサポートって書いてあります）

で、いつものMATE版を以前組んだAthlon5350マシン（メモリ8GB＋SSD64GB）に入れてみます。このマシンはこれまでは32bit版を入れていたのですが、さすがに今回は64bit版をインストールします。

インストールはUSBイメージライタでISOイメージをUSBメモリに書き込んで、そこから起動します。割と短時間で終了します。

インストール完了後、再起動して、アップデートマネージャでアップデートを適用します。その後、言語設定で「言語のサポート」から一番下にある日本語を選んで、「言語パッケージのインストール」を行います。次に入力方法で言語サポートの中から日本語を選んで「インストール」を行います。入力方法はデフォルトのfcitxのままにしました。（fcitxだとメニューの中に簡体中国語の表示のままのツール〔fcitx-qimpanel-configtool〕が出てくるので、ちょっと嫌なところはあるのですが・・）

基本的にはこれでおしまいなのですが、途中でSystem Snapshotを設定しろと煩かった（まあ、無視してもいいんですが）ので、試しにやってみます。System Snapshotを起動すると、スナップショットのタイプとしてRSYNCとBTRFSを選択するよう表示されます。デフォルトの選択はBTRFSの方になっているのですが、よくみると、インストール時点でBTRFSパーティションでないとダメと書いてありましたので、RSYNCの方にしてみます。（BTRFSだとファイルシステム自体の機能により瞬時にスナップショットが取れて、瞬時に戻せるようです）スケジュールは毎週（Weekly）にしてみました。初期状態だと、スナップショットがないので、初回だけCreateを押して、スナップショットを取ってみることにしました・・・・が、途中でクラッシュしてしまいました・・・。ということでヤメヤメ^^;

・・・で、このPCはいろいろ調査（主にWeb上）する際に使っています。以前はLinuxMint17とかLinuxMint18（非力なのでいずれもMATE版）を使っていたのですが、メモリコントローラがシングルチャネルのせいなのか64bit版では重くて、32bit版を入れていました。今回はさすがに64bit版にしたのですが、以前ほど重い感じはなく、ずいぶんと軽快になった印象です。理由はよくわかりませんが、体が慣れたのか、ブラウザが軽くなっているのか、Xサーバーが改善されているのかそれともウインドウデザインがシンプルになっているからなのか・・・？

まあ、主にWebで使うだけとしては十分なパフォーマンスになったように思います。

Windows10からLinuxMint上のHL2240Dに印刷する

自宅の環境の整理をしているのですが、これまで不便だったのがWindows10からプリンタ（ブラザーのHL2240D）に印刷する時でした。正直、なぜLAN内蔵モデルにしなかったんだろう、というのがこれまでの悩みでした。

が、今回、Windows10からLinuxMintに接続したHL2240DにLAN経由で印刷することができるようになりましたので、メモしておきます。

１．LinuxMint側で印刷できるようにする

これは以前の記事のブラザーのレーザープリンタ買いましたを見て下さい。インストールしたら、「システム管理」→「プリンタ」でHL2240Dを「共有する」にチェックを入れておきます。

２．名前解決できるようにする

LinuxMintのマシンはDHCPでアドレス設定しているので、名前解決できる必要があります。で、簡単なのはavahi(mDNS)なので、そちらの準備をします。
Linux側はavahi daemon（Mintは初めから入っているような気がする）を入れておきます。Windows側は、Appleのサイトから「Bonjour Print Services (Windows)」をダウンロードしてインストールして、Windowsファイアウォールで 5353/UDP を許可しておきます。インストールしたら、Windows10のコマンドプロンプト／Linuxのシェルから「ping 相手のホスト名.local」で応答が返ってくるのを確認します。

３．プリンタの追加

「Bonjour Print Services (Windows)」をインストールした時に追加された「Bonjour プリンターウィザード」を起動すると、勝手にLinuxMint上のプリンタを見つけてくれました。ウィザードに沿って操作していくのですが、Brotherのドライバが同名でたくさんあってよくわかりません。とりあえず、「Brother Laser Type2 Class Driver」の中の一番下のをインストールして、テスト印刷したらうまくテスト印刷できました。印刷結果ではドライバーの種類が「Type 4 – ユーザーモード」となっていました（よくわかりませんが）。

秋月のLPC11U35マイコンボードを動かしてみた

久しぶりに秋月へ行ったら、「ＵＳＢメモリにファイルを書き込むのとほぼ同様の手軽さでプログラムを書き込むことができます」という触れ込みのマイコンボードが安く売っていたので、買ってみました。

で、動かしてみるべく、Linuxマシン（環境はいつものLinux Mintです）へ接続すると、確かにマスストレージデバイスとして認識します。で、秋月のWebサイトにある動作確認用ファームウェアを書き込んで、リセットしてみても、再びマスストレージデバイスとして認識されて、LEDが点滅する気配がありません。

mbedとしても動作する、というのでサンプルプログラムを作って同様に書き込んでみてもサッパリです。linuxではドラッグアンドドロップでの書き込みはうまく行かないのかと思って、コマンドラインで cp コマンドでコピーしてみてもダメです。

で、ぐぐってみたら、どうやら linux ではそもそもファイル書き込みではうまくいかないようで、こちらの情報によると先頭の４ブロック（２キロバイト？）を削ってddで書き込むとうまく行くようです。

ただ、デバイスファイルなんていろんな要因で変わってしまうので、毎回やるのは面倒ですし、事故のもとなので、pythonのスクリプト化しました。

lsblkコマンドで見た時に、転送方法が usb で、モデルが’LPC1XXX IFLASH  ‘となっているデバイスファイルを探して、そのデバイスファイルをアンマウントして、ｄｄコマンドで書き込むだけです。スクリプトファイル⇒mbedにlinuxから書き込むためのスクリプト

ルート権限が必要なのは変わらないので、sudo 付きで python スクリプトを実行します。

みたいな感じで使います。（途中の umount とか dd コマンドの行はこのスクリプトの処理内容を表示しているだけで、書き込みに必要な操作は最初の１行目だけです）

Nexus7(2012)にAndroid 6.0（MarshMallow）をインストール

いまさらながら、Nexus7(2012) 3GモデルにAndroid 6.0（MarshMallow）をインストールしてみました。

１．準備

環境は例によって Linux Mint 18 (64bit)です。 android-tools-adb とか、android-tools-fastboot などのandroid関連のパッケージは apt でインストール済みです。

ダウンロードしておくものは以下のとおりです。Nexus7(2012) 3Gモデルは開発コードが tilapia というらしく、この tilapia 向けのものを用意しておく必要があります。

• TWRP
  Term Win Recovery ProjectというソフトウェアでAndroidに内蔵されているリカバリプログラムを置き換えるものです。ROMイメージはTWRP用の物が多いので、TWRPがないと書き込めません。自分は twrp-3.0.2-0-tilapia.img をダウンロードしてきました。
• ROMイメージ
  tilapia用のイメージを探します。だいたい xda-developper にたどり着くようですが、１つは pure AOSP というものですが、6.0.1 の r46 ベースのようです。もう１つは OmniROM というもので、 6.0.1 の r68 ベースのもののようです。（自信なしｗ）
  これらの記事からリンクされているROMイメージをダウンロードしておきます。
• Gapps
  Google Playを始めとするデフォルトインストールアプリの詰め合わせのようです。Openソース版（かな？）がOpenGAPPSからダウンロードできます。PlatfomはARM、Androidのバージョンは6.0、VariantについてはNexus7(2012)はシステムパーティション（＝リカバリ領域？）が650MBしかないので、最小限のnanoかpicoを選んでダウンロードします。

２．TWRPのインストール手順

音量ダウンボタンを押しながら電源ONしてブートローダを起動します。倒れたドロイドくんが出てくる画面（ブートローダ）になったら、PCと

としてTWRPを書き込みます。書き込んだら、ブートローダを以下の手順で再起動します。
（ここで通常のシステム起動を行うと、リカバリが書き戻されるので、再度最初からやりなおし）

ブートローダが起動したら、音量ボタンでリカバリモードを選択して電源ボタンで選択するとTWRPが起動します。
起動すると、画面上部に「Unmodified System Partition」と表示されて、システムパーティションの内容がTWRPが起動できるようになっていないことが表示されます。下の方の「Swipe to Allow Modification」のところをスワイプして、次へ進みます。（おそらく、この操作で常にTWRPが起動するようにシステムパーティションが修正されます）

次回以降、リカバリを起動すると上記の青字の部分は聞いてきません。（システムパーティションを書きなおしたりすると、デフォルトのリカバリに戻ったりするので、再度インストールする必要がある場合があるようです）

３．ROMイメージの書き込み

今回は、PCからROMイメージを書き込みます。

ブートローダ経由でTWRPを起動します。（ちなみに、充電ケーブルが挿さっていると、ブートローダで音量上下ボタンが効かないようです）
「Advanced」⇒「ADB Sideload」を選択します。ROMイメージを書き込みする場合は「Wipe Dalvik Cache」と「Wipe Cache」にチェックを入れて、「Swipe to Start Sideload」をスワイプすると、ダウンロード待ちになるのでPC側から

として、ROMイメージファイルを書き込みます。（zipファイルがROMイメージファイルのファイル名です。）
完了したら、Android側で「Back」を押して、もう一度「ADB Sideload」を選択します。今度は「Wipe Dalvik Cache」と「Wipe Cache」のチェックは外して、再度「Swipe to Start Sideload」をスワイプします。

として、Gapps を書き込みます。（zipファイルがGappsファイルのファイル名です。）

完了したら、「Reboot System」でNexus7を再起動します。

ESP32を動かしてみた

ふと秋月のWebサイトをみていたら、ESP-WROOM-32が発売になっていました。早速、秋月へ行ってゲットしてきました。

で、とにかく動かしてみます。すでに先達もいるようなので、参考にさせてもらいながら、なるべく手抜きして動かします。開発環境はESP-WROOM-02の時と同様にArduinoで動かします。

使用した部品

使用した部品は以下の通りです。

• ESP-WROOM-32
  まずこれがないと、ですね。
• FT-232RQ USBシリアル変換キット
  最近のお気に入りのUSBシリアル変換基板です。Linuxでも安定して動作するのでGoodです。
• NJU7223DL1
  3.3Vのレギュレータです。データシートの回路図だと入出力のコンデンサが小さくて済みそうなので、選びました。
• 0.1uF 1608 チップコンデンサ✕３
  三端子レギュレータの入出力に各１個、USBシリアルのRTS端子とEN端子の間に１個
• 22uF 1608 チップコンデンサ✕１
  ESP-WROOM-32の資料では電源入力に10uFが付いているので、手持ちの22uFのチップコンを使用
• 10kΩ 1608 チップ抵抗✕２
  １個はEN端子のプルアップ、もう１個はIO0端子のプルアップ
• 0.022uF 1608 チップコンデンサ✕１
  EN端子の入力とGND間に接続
• 適当なタクトSW✕１
  IO0端子をGNDに落としてダウンロードモードに移行させるのに使います
• ユニバーサルプリント基板
  これを使いました。最近は軽量化を目指して薄めの基板を使ってます。この基板は両面なのですが、内面がスルーホール処理されていないので表裏の接続ができていない箇所があってハマリました。
• その他
  適当なピンヘッダ・ピンソケット、ポリウレタン被覆線、スズメッキ線

ハードウェアの組み立て

こちらの回路を参考に手抜きして作りました。

• GND端子はUSBシリアル基板のGNDに接続
• 3V3端子は三端子レギュレータの出力端子に接続
• EN端子は10kΩでプルアップ、GNDとの間に0.022uF、USBシリアル基板のRTS端子との間に0.1uFを接続。この0.1uFによりPC側でRTSを制御するとESP-WROOM-32側にリセットがかかります。
• IO0端子はプルアップ、および、タクトスイッチを接続して、ボタン押下でGNDに落ちるようにします。ボタンを押しながらArduino IDEで書き込み操作をすることで、書き込みモードへ移行できます。
  （注：IO0のプルアップは不要らしい。タクトスイッチによるIO0のコントロールがうまく行かなかった際につけたが、外してOKかは試していない。ちなみに、タクトスイッチでIO0がコントロールできなかった原因はノンスルーホール基板を使ったので基板の表裏で接続ができてなかったため。）
• TXD0端子はUSBシリアル基板のRXDへ接続
• RXD0端子はUSBシリアル基板のTXDへ接続

回路図はこんな感じです。１５ピンのGNDは手抜きで接続していませんが、動いています。

こんな感じになりました。

ESP-WROOM-32は裏返しに両面テープで基板に貼り付けてあります。基板を作りなおす時も多分無事に剥がせると思います。

無計画に作ったので、裏側は汚いですｗ。左上のレギュレータ周りがどうしようもないですね。

まずはハードウェアの動作確認

Arduinoで書き込みをする前に、ハードウェアの動作確認をしておきます。
といっても、よくよく結線を確認した後、電源を投入（USBケーブルで接続）するだけです。
電源を投入したら、スマートフォンのWiFiアナライザなどアプリケーションで、「ESP-xxxxxx」というSSIDが見えることを確認しておきます。SSIDが見えればとりあえずESP-WROOM-32はアクセスポイントとして動作しているはずです。（注:Arduino環境の構築ができていれば、Arduinoのシリアルモニタで /dev/ttyUSB* を115200bpsでモニタすればブートローダなどの表示も確認できます）

Arduino開発環境の構築

PCはLinux Mint 18の64bit版です。

まず、arduino IDE をインストールします。その前に、古いバージョンをアンインストール。

arduino.cc から最新版の arduino-IDE をダウンロード。今回ダウンロードしたファイルは arduino-1.8.1-linux64.tar.xz です。

次に、arduino-esp32 をインストール。このページのコマンドをコピペ。

いよいよ起動します。デスクトップ上のArduino IDEのアイコンをダブルクリックして、Arduino IDEを起動。
起動したら、「ツール」→「ボード：xxx」→「ESP32 Dev Module」を選択でESP32モジュールを選択します。

サンプルを動かしてみる

次にサンプルを動かしてみます。シリアルに結果が表示されるものが良いと思うので、WiFiScanを動かしてみます。
「ファイル」→「スケッチ例」→ESP32 Dev Module用のスケッチ例の下の「WiFi」→「WiFiScan」選択すると、サンプルプログラムが表示されます。「ツール」⇒「シリアルポート」⇒「/dev/ttyUSB0（環境によって変わります）」でシリアルポートを選択した後、「ツール」⇒「シリアルモニタ」でシリアルモニタを起動しておきます。

準備ができたら「⇒」ボタンをクリックして、書き込んでみます。「⇒」をクリックする際にはIO0に接続したタクトスイッチを押しながらクリックすることでダウンローダを起動します。「Wrting … 」という表示が出たら、タクトスイッチのボタンを離します。

書き込み完了後はこんな感じ。

書き込みが終わると、シリアルモニタの方に表示が始まります。

こんな感じでSSIDのリストが表示されれば成功です。

ESP8266でSmartConfigを試してみた

長らく放置していたESP8266基板ですが、やっと動かしました。前回の記事から数えて約１年（ぉぃ）。回路図の定数に不適切な部分があってブートローダから先に進んでなかったのと、秋月のFT234X搭載の超小型UART変換基板だとなぜかLinux側が固まってしまうという事象に悩まされたためです（汗）。

で、まだ最低限の機能しか試してないのですが、回路図はこんな感じです。回路図の電源周りにいろいろわけのわからないFETが入っていますが、これはソフトウェア制御で電源OFFできるようにするのと、電池使用時に電源電圧を自身で測定できるようにするためです。電池を使えば Amazon Dash Button 相当のことができる予定です。

UART変換基板は結局秋月のAE-TTL-232Rを使いました。

開発環境はArduino IDE 1.6.12を使っています。昔調べた方法でボードマネージャでESP-8266を使えるようにして、ボードはGeneric ESP8266 Module、FlashメモリサイズはESP-WROOM-02に合わせて1M(64K SPIFFS)を選択しました。

さらに１年間の進化は素晴らしいもので、smartconfigというWiFi周りの設定をAndroidスマートフォンでやる仕組みが登場していました。ArduinoのコードはGitHubのここから持ってきました。少しこの基板にあわせて修正したのが以下のファイルです。

修正したのは起動時のGPIO12のLEDの点灯と、ステータスのGPIOをGPIO16からGPIO13に変更、初期化が完了したら電源OFFする制御を追加したことです。これをコンパイルしてボードに書き込んでやります。

シリアルモニタで動作を確認しながら、スマートフォンで「ESP8266 SmartConfig」というアプリを動作させてESP8266モジュールに接続させる先のSSID（スマートフォンがつながってるSSIDが勝手に表示されます）と、パスワードを入力してCONFIRMを押してしばらく待つとESP8266側の接続設定がされるという便利なものです。

設定したSSIDとパスワードはフラッシュメモリ内に保存されて、次回は勝手にロードしてくれます。（上記のソースでは、起動後２秒たった瞬間にGPIO0がLレベルだと設定をクリアして再度設定待ちになります）

上記は電源投入〜SmartConfigによる設定〜APへの接続〜シャットダウンまでのシリアルコンソールのログです。楽でいいですね！

普通にはadbで認識できないAndroid機を認識させる

通常のAndroid機は /etc/udev/rules-d/51-android.rules にベンダIDを追加してやるとadbで操作できるようになるのですが、coviaのFLEAZ F4s/F4s+は認識することができません。いろいろ試してみたところ、わかってきたことをメモしておきます。環境は LinuxMint18 MATE edition 64bit です。

まずはUSBのデバイスIDを調べます。（必要なもの以外は結果から削除しています）

BroadcomのチップのベンダIDそのままのようです。（これはF4sのもの。F4s+はデバイスIDはe681になるようです）
とりあえず、/etc/udev/rules-d/51-android.rules にベンダIDを記載して再読み込みさせてみます。

この状態で、USBを抜き差ししてから adb コマンドを叩いてみても、

となって、デバイスが見つかりません。
いろいろググると、~/.android/adb_usb.ini にベンダIDを書くとよい、というような記載をいくつか見つけたので試してみます。

状況が変わりました。この状態で TCP/IP 接続でデバッグする設定にしてみます。

パーミッションで蹴られてしまいました。ルート権限で試してみます。

端末上にデバッグ接続可否のダイアログが出ていたので、許可してみます。

となって無事にインストールできました。

改めて /etc/udev/rules-d/51-android.rules を削除してやってみました。
どうも、/etc/udev/rules-d/51-android.rules は必要ないようです。
一般ユーザー権限では、

となってパーミッションエラーになりますが、通常の Android機はルート権限で adb server を起動すると認識できるようです。

さらに、今回の covia FLEAZ F4s/F4s+ のようになにもしないと認識しない機種でも、 ~/.android/adb_usb.ini にベンダIDを書いてやれば認識できるようです。

ここで F4s+ を外して F4s を接続してみます。

となり、無事に認識しました。