- キット各種完売。
- msBerryDAC改造情報
2020/10/04(日)Huawei nova lite に Android 10（LineageOS 17.1）を入れる
前提条件
- Oreo以降にアップデート済
- ブートローダーアンロック済
カスタムカーネルを導入している場合は、作業前に必ずストックROMカーネルに戻しましょう。*1
導入手順
概ねLineageOS 17.1の記事に書いてあるとおりです。
- OS本体とパッチをダウンロードします。
- Honer P9 lite用のTWRPを焼く（相変わらずP8 Lite用はイマイチ）
fastboot flash recovery_ramdisk twrp-3.4.0-0-prague.img
- zipを解凍して出てくるOS本体を焼きます。
fastboot flash system system.img
- リカバリを起動します。
- Wipe → Advance → System → Change File System → Resize File System
- cache等を wipe（消去）します（Wipeデフォルト）。
- 必要に応じてWipeから Format Data します。消去するとアプリ等の情報はすべて消えます。*2
- https://opengapps.org/ から ARM64 10.0 の nano か pico を落とし、TWRPからUSB（MTP）で接続するなどしてSD等に転送します。
- 転送した gapps を焼きます。
- los_patches_prague.zipを焼きます。
- 再起動します。
その他
- data領域の暗号化解除（TWRP用。その後フォーマットが必要）。
関連記事
2020/10/02(金)winscard_wrapper x64
流通しているソースファイルをx64でビルドしたもの。
2020/10/01(木)Sambaでファイルコピーに失敗し 0x80070032 エラーになる
Windows10からファイルをコピーしていると「予期しないエラーのため、ファイルをコピーできません」「エラー 0x80070032: この要求はサポートされていません」と表示される問題。
エラーの状況
- コピー元: Windows 10
- コピー先
- Samba Version 4.9.5 on Linux
- Filesystem NILFS2
この状況で大量のファイルをコピーしていると、一部のファイルやフォルダでエラーが発生します。
ログの調査
- Windows 7では起きていなかった。
- Samba側のファイルシステムがext4だと起きない。
「log level=10」に設定して、ログを確認しみました。
set_ea_dos_attribute: Cannot set attribute EA on file AU.txt: Error = サポートされていない操作です open_file_ntcreate: FILE_OPEN requested for file AU.txt and file doesn't exist.
ファイルの作成に失敗しているような感じです。
原因
Sambaは「store dos attributes = yes」のときに、DOS attributeと呼ばれるファイル属性を維持したままファイルを保存しようとします。
DOS attributeとは、Windows登場前の大昔に存在したファイル属性で、古くは「R,S,H,A」の4種類がありました。Windows時代になって不要となったものだと思っていたのですが、知らない間に拡張され続けていたようです……。
Windows では attrib コマンドによってファイル属性（DOS attribute）を確認または変更できます。*1
このうち、比較的最近拡張された「X, P, U」属性があると、NILFSはこれらの属性値に対応していないためコピーに失敗します。
解決策
smb.confに以下を設定します。
store dos attributes = no
この設定のデフォルトは元々 no だったのですが、Samba 4.9（2018年9月）以降で yes に変更されています。
ext4等のファイルシステムは対応済のようですが、NILFSのようなメジャーではないファイルシステムを使用しているとこの問題に当たるかと思いますので、記録として残しておきます。
雑感
SambaはNTFSのファイルアクセス権限（NT ACL）等、ファイル属性をなるべく維持するように作られていて、ファイルシステム側もそれに対応できるよう拡張されてきた歴史があります。user_xattrでググると色々出てきます。
Linuxのシステム構造の中に、NTのアクセス権限やDOSのファイル属性が残るというのも不思議な感じですが、それが災いしてしまった事件でした。
どれだけ検索しても（海外含め）同じ不具合踏んでる人がいないので苦労しました……。
2020/07/05(日)NILFS使用時にLinux Kernelエラーが起こる問題の解決策
最近の新しいLinux KernelでNILFS（NILFS2）を使用すると、最初の書き込み時に
BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
となるエラーの解決方法（対処療法）。
NILFSとは
ログ構造化ファイルシステムと言われる、ファイルを変更するたびに常にスナップショットを自動的に保存できるLinux標準サポートのファイルシステムです。
/home 以下などをNILFSにしておくと、間違えてファイルを書き換えたときや、間違えてファイルを削除したときに、1時間前や1週間前の状態に遡ってファイルを復元することができます。
間違ってファイルを削除（上書き）してまうこと、ファイルを直接変更してしまってから元に戻したいことは誰しもあると思いますが、NILFSならいつでも元に戻せるため人為的にミスにとても強く重宝しています。
新しいカーネルで動作不安定に
このNILFSですが、最近の（ここ1年ぐらいの）カーネルで動作不安定になる不具合があります。Debian 10.4をインストールした際にこの問題に当たってしまいました……。
調べるとカーネルのファイルキャッシュに対するちょっとした変更（パッチ）が原因となっているようです。解決策はLinux系のMLにありました（そしておそらく投稿者の記事）。
要約すると「NILFSをマウントする前に、ダミー書き込みをすれば良い」とのことです。
簡単な解決策
/etc/fstab では自動マウントせずに（noautoオプションをつける）、rc.localでマウントするように変更します。
dd if=/dev/sda6 of=/dev/sda6 count=1 mount /home
/dev/sda6 やマウント場所は該当のパーティション等に合わせてください。ddコマンドで512バイトほどダミー書き込みをしてからマウントします。たったこれだけで問題は解決します。
やや複雑な解決策
rc.local でマウントする方法では、NILFSパティーション以下にDBデータ等サービスで使用するデータを置く場合や/varがNILFSパーティションだった場合に問題があります。rc.local のタイミングでマウントするのでは遅すぎるからです。
ですので、理想としてはfstabでマウントする直前にダミー書き込みを実行したいのです。
Debian系のsystemd環境では以下のような設定ファイルを置くことで、fstab実行直前にダミー書き込みを実現できます。
# /etc/systemd/system/nilfs2-dummy-write.service [Unit] Description=NILFS2 dummy write DefaultDependencies=no After=local-fs-pre.target Before=local-fs.target [Service] ExecStart=/bin/dd if=/dev/sda6 of=/dev/sda6 count=1 Type=oneshot [Install] WantedBy=sysinit.target
ファイル作成後、サービスとして認識されたか確認します。
# systemctl list-unit-files --type=service | grep dummy nilfs2-dummy-write.service disabled
認識されているようなら、サービスを有効にします。
# systemctl enable nilfs2-dummy-write # systemctl list-unit-files --type=service | grep dummy nilfs2-dummy-write.service enabled
参考文献
まとめ
- NILFS/NILFS2はとても便利なのに利用者が少ない。
- パッチが出てるので、近々修正されるとは思う。
- systemdの勉強になった。
