ドコモのらくらくスマートフォン ユーザについての設定確認でやったこと


まあ、実家から、ドコモのらくらくスマートフォン F-52Bを自宅のWiFi環境に繋いでからメールが取れなくなってる、というレスキュー要請があったので見に行った。

その際に、いまのアカウント情報とか聞いて見たんだが、そういうのは店の人にやってもらった、というのだが、アカウントに関する資料をもらっていなかった模様。

これは積んだかな?と思いつつ調べていったらなんとかなったのでメモ書きとして残しておく

まず、これだけは最低必要なことは以下の2つ

・スマホをドコモのSPモード接続で使うこと(WiFiでは駄目)
・ドコモのネットワーク暗証番号(数字4桁)が分かっていること

この状態であれば、スマホからdメニューをたどっていくことで、以下を調べることができる。

・dアカウント名
・dアカウントのパスワード(画面に表示されます)
・IMAP接続用ユーザ名
・IMAP接続用パスワード

Googleアカウントについては、gmailの画面などからメールアドレスを確認することができるかと思います。

パスワードは、まずは、dアカウントのパスワードと同じものを入力して通るか確認します。

通らなかった場合は、パソコンなどからgmailにアクセスし、Googleのメールアドレスを入力して、「パスワード不明」を選び、パスワードの再設定を行います。

そうすると、スマホ側に確認がくるので、はい、と答えると、パソコン側でパスワードの再設定ができるようになるので、新しいパスワードを設定します。

これでなんとかアカウントに関する情報を調べることができました。

で・・・冒頭のメールが取れない、という件は、SPモードメールはdアカウントの登録がちゃんとされていないとWiFi経由で取得出来ないから、という話だったようでした。

なので、dアカウントに関する設定を行うことで、メールは復旧しました。

ONTAP Antivirus Connector の接続ステータス確認方法


ONTAP Antivirus Connector でONTAPとアンチウイルスソフトを連携させる場合に、ONTAPからの接続ステータス確認手法がいまいちよく分からなかったのでメモ書き。

基本的な接続状況確認コマンド

「vserver vscan connection-status show-all」で確認する。

netappcluster::> vserver vscan connection-status show-all
                                              Connection
Vserver     Node              Server          Status         Disconnect Reason
----------- ----------------- --------------- -------------- -----------------
svm0        netapp01         192.168.10.110   disconnected   remote-closed
svm0        netapp01         192.168.10.111   connected      na
svm0        netapp01         192.168.10.112   connected      na
svm0        netapp01         192.168.10.113   connected      na
svm0        netapp02         192.168.10.110   disconnected   -
svm0        netapp02         192.168.10.111   disconnected   -
svm0        netapp02         192.168.10.112   disconnected   -
svm0        netapp02         192.168.10.113   disconnected   -
8 entries were displayed.

netappcluster::>

上記の場合、ONTAP Antivirus Connectorがインストールされていて、接続設定されているのは、「192.168.10.110~192.168.10.113」の4台あって、そのうち、192.168.10.110の1台だけ接続できてない、という状態となっている。

「Disconnect Reason」に「remote-closed」とあるため、NetAppと192.168.10.110間の通信は行えるものの192.168.10.110側で接続を切断している、という意味合いとなるようだ。

詳細ログ確認

上記の「remote-closed」だけだと詳細が分からない。

詳細ログはadvanced権限でみれるようになっているため、権限切り替えした上で「vserver vscan show-events」を実行する。

なお、「rows 0」を実行して24行で止める設定を解除している場合、その時に出ているイベントが全件強制表示されてしまうため「rows 24」などで画面を止めるように設定しておくことを推奨。


netappcluster::> set adv

Warning: These advanced commands are potentially dangerous; use them only when
         directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

netappcluster::*>

netappcluster::*> vserver vscan show-events

Vserver     Node            Server          Event Type        Event Time
----------- --------------- --------------- ----------------- -----------------
svm0        netapp01        192.168.10.110  scanner-          1/31/2023
                                            disconnected      18:05:37
svm0        netapp01        192.168.10.110  scanner-connected 1/31/2023
                                                              18:01:45
<略>

上記では簡単な理由しかわからないので「-ins」オプションを付けて実行

ossv0059::*> vserver vscan show-events -ins

                           Node: netapp01
                 Event Log Time: 1/31/2023 18:05:37
                         Server: 192.168.10.110
                     Event Type: scanner-disconnected
                      File Path: -
                Vscanner Vendor: -
               Vscanner Version: -
       Server Disconnect Reason: remote-closed
Vserver LIF Used for Connection: 192.168.10.10

                           Node: netapp01
                 Event Log Time: 1/31/2023 18:01:45
                         Server: 192.168.10.110
                     Event Type: scanner-connected
                      File Path: -
                Vscanner Vendor: vendor not registered
               Vscanner Version: 0.0
       Server Disconnect Reason: -
Vserver LIF Used for Connection: 192.168.10.10
<略>

remote-closedとなる前に「scanner-connected」の時に、「Vscanner Vendor: vendor not registered」という怪しげなステータスとなっている。

じゃあ、各サーバとの接続状態でこの「Vscanner Vendor」の情報を確認する手法はあるか確認するとvscan connection-status で取得出来る情報の中にあった。

「vserver vscan connection-status show-all -fields version,vendor,server-status,connected-since」を実行する

netappcluster::> vserver vscan connection-status show-all -fields version,vendor,server-status,connected-since
node     vserver  server         server-status vendor                     version     connected-since
-------- -------- -------------- ------------- -------------------------- ----------- ------------------
svm0     netapp01 192.168.10.110 disconnected  vendor not registered      0.0         -
svm0     netapp01 192.168.10.111 connected     symantec protection engine 20230130.19 1/31/2023 17:34:33
svm0     netapp01 192.168.10.112 connected     symantec protection engine 20230130.19 1/31/2023 17:35:20
svm0     netapp01 192.168.10.113 connected     symantec protection engine 20230130.19 1/31/2023 17:35:25
svm0     netapp02 192.168.10.110 disconnected  -                          -           -
svm0     netapp02 192.168.10.111 disconnected  -                          -           -
svm0     netapp02 192.168.10.112 disconnected  -                          -           -
svm0     netapp02 192.168.10.113 disconnected  -                          -           -
8 entries were displayed.

netappcluster::>

remote-closedとなっているサーバ以外は正常な製品名と、おそらくパターンファイルのバージョンっぽいのが表示されている。

disconnectedとなっている 192.168.10.110サーバ上で動作しているONTAP Antivirus connectorとアンチウイルスソフト間の通信に問題があり、ONTAP Antivirus connector側で情報がきちんと取得されていないために発生している、ということのようだった。

NetAppでデータSVMにsshの管理アクセスできるようにする


NetAppでファイルサービスを提供するデータSVMにsshで管理アクセスできるようにしてくれ、という要望があった。

普通にマネージメントLIFの管理WebからデータSVMに対して、sshユーザアクセス可能なユーザを追加してみたけど、sshでアクセスできるようになるわけではなかった。

データアクセス用のLIFに対してsshサービスが許可されていないからかな?と思って network interface service-policy の下を見てみるとshowしかなく変更ができないっぽい?

netapp9101::> network interface service-policy ?
  show                        Display existing service policies

netapp9101::>

とりあえず現状のservice-policy定義を見てみる

netapp9101::> network interface service-policy show
Vserver   Policy                     Service: Allowed Addresses
--------- -------------------------- ----------------------------------------
Cluster
          default-cluster            cluster-core: 0.0.0.0/0

netapp9101
          default-intercluster       intercluster-core: 0.0.0.0/0
                                     management-https: 0.0.0.0/0
                                     backup-ndmp-control: 0.0.0.0/0

          default-management         management-core: 0.0.0.0/0
                                     management-autosupport: 0.0.0.0/0
                                     management-ssh: 0.0.0.0/0
                                     management-https: 0.0.0.0/0
                                     management-ems: 0.0.0.0/0
                                     management-ntp-client: 0.0.0.0/0
                                     management-http: 0.0.0.0/0
                                     backup-ndmp-control: 0.0.0.0/0
                                     management-snmp-server: 0.0.0.0/0
                                     management-ntp-server: 0.0.0.0/0

          default-route-announce     management-bgp: 0.0.0.0/0

svm0
          default-data-blocks        data-core: 0.0.0.0/0
                                     data-iscsi: 0.0.0.0/0

          default-data-files         data-core: 0.0.0.0/0
                                     data-nfs: 0.0.0.0/0
                                     data-cifs: 0.0.0.0/0
                                     data-flexcache: 0.0.0.0/0
                                     data-fpolicy-client: 0.0.0.0/0
                                     data-dns-server: 0.0.0.0/0

          default-data-iscsi         data-core: 0.0.0.0/0
                                     data-iscsi: 0.0.0.0/0

          default-data-nvme-tcp      data-core: 0.0.0.0/0
                                     data-nvme-tcp: 0.0.0.0/0

          default-management         data-core: 0.0.0.0/0
                                     management-ssh: 0.0.0.0/0
                                     management-https: 0.0.0.0/0
                                     data-dns-server: 0.0.0.0/0
                                     management-http: 0.0.0.0/0
                                     backup-ndmp-control: 0.0.0.0/0
                                     management-snmp-server: 0.0.0.0/0
netapp9101::>

LIF のサービスポリシーを設定」を見るとadvanced権限であれば変更できるらしい

とりあえずsvm0の「default-data-files」に「management-ssh」を追加してみた。

netapp9101::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when
         directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

netapp9101::*> network interface service-policy add-service -vserver svm0 -policy default-data-files -service management-ssh

netapp9101::*> 

変更した結果が反映されているかを確認

netapp9101::*> network interface service-policy show -vserver svm0 -policy default-data-files

                   Vserver: svm0
               Policy Name: default-data-files
         Included Services: data-core, data-nfs, management-ssh,
                            data-fpolicy-client, data-dns-server
Service: Allowed Addresses: data-core: 0.0.0.0/0
                            data-nfs: 0.0.0.0/0
                            management-ssh: 0.0.0.0/0
                            data-fpolicy-client: 0.0.0.0/0
                            data-dns-server: 0.0.0.0/0

netapp9101::*>

これでsvmのデータLIFにsshでログインできるようになった

Orange Pi 5でChromium OS(openFyde)を動かす


Orange Pi 5のCPUパワーがあればChrome OSが動くんじゃないかと検索してみると、Chromium OSベースのFydeOSのオープンソース版openFydeOrange Pi 5向け移植があるのを発見した。

なんと5日前に最初のコードが公開されて、3日前にイメージファイルが公開されたばかりというもの。

ChromiumOSはディスクI/Oが多いのでmicroSD起動ではなく、M.2 NVMe SSDかM.2 SATA SSDで使うことを推奨されている。

とりあえず、M.2 SATA SSDに書き込んで見ます。

orangepi@orangepi5:~$ ls
Desktop    Downloads  Orangepi5_1.1.0_ubuntu_jammy_desktop_xfce_linux5.10.110.img  Pictures  Templates
Documents  Music      orangepi5-openfyde-r102.img                                  Public    Videos
orangepi@orangepi5:~$ sudo dd if=orangepi5-openfyde-r102.img of=/dev/sda bs=4M conv=fdatasync status=progress
6933184512 bytes (6.9 GB, 6.5 GiB) copied, 16 s, 433 MB/s
1766+1 records in
1766+1 records out
7407221248 bytes (7.4 GB, 6.9 GiB) copied, 19.8569 s, 373 MB/s
orangepi@orangepi5:~$ sudo fdisk -l /dev/sda
GPT PMBR size mismatch (14467228 != 1000215215) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Kingchuxing 512G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0A2133E6-2262-584F-8E41-66BED45870B0

Device       Start      End Sectors  Size Type
/dev/sda1  6078464 14467180 8388717    4G Linux filesystem
/dev/sda2    69632   135167   65536   32M ChromeOS kernel
/dev/sda3   499712  6078463 5578752  2.7G ChromeOS root fs
/dev/sda4   135168   200703   65536   32M ChromeOS kernel
/dev/sda5   495616   499711    4096    2M ChromeOS root fs
/dev/sda6    65600    65600       1  512B ChromeOS kernel
/dev/sda7    65601    65601       1  512B ChromeOS root fs
/dev/sda8   200704   233471   32768   16M Linux filesystem
/dev/sda9    65602    65602       1  512B ChromeOS reserved
/dev/sda10   65603    65603       1  512B ChromeOS reserved
/dev/sda11      64    65599   65536   32M unknown
/dev/sda12  364544   495615  131072   64M EFI System

Partition table entries are not in disk order.
orangepi@orangepi5:~$

ちなみにAndroidを書き込んだ場合は下記の様なパーテーション構成だったので、似た構成ではある、ってところですね。

orangepi@orangepi5:~$ sudo fdisk -l /dev/sda
Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Kingchuxing 512G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1B040000-0000-4531-8000-2CDC00004E46

Device       Start        End   Sectors  Size Type
/dev/sda1     8192      16383      8192    4M unknown
/dev/sda2    16384      28671     12288    6M unknown
/dev/sda3    28672      36863      8192    4M unknown
/dev/sda4    36864      45055      8192    4M unknown
/dev/sda5    45056      53247      8192    4M unknown
/dev/sda6    53248      55295      2048    1M unknown
/dev/sda7    55296     137215     81920   40M unknown
/dev/sda8   137216     333823    196608   96M unknown
/dev/sda9   333824    1120255    786432  384M unknown
/dev/sda10 1120256    1906687    786432  384M unknown
/dev/sda11 1906688    1939455     32768   16M unknown
/dev/sda12 1939456    1941503      2048    1M unknown
/dev/sda13 1941504    8314879   6373376    3G unknown
/dev/sda14 8314880 1000215151 991900272  473G unknown
orangepi@orangepi5:~$

つづいて、今回はM.2 SATA SSDなので、ssd-sataドライバを読み込ませる設定をします。

ただ、/dev/sda1をマウントして stateful_partition/unencrypted に Env.txt を作る、とあるのにディレクトリがない?

orangepi@orangepi5:~$ sudo mount /dev/sda1 /mnt
orangepi@orangepi5:~$ ls /mnt
dev_image  lost+found  unencrypted  var_overlay  vmlinuz_hd.vblock
orangepi@orangepi5:~$ ls /mnt/unencrypted/
import_extensions
orangepi@orangepi5:~$ ls /mnt/stateful_partition/unencrypted
ls: cannot access '/mnt/stateful_partition/unencrypted': No such file or directory
orangepi@orangepi5:~$

とりあえず書いてあるコマンドを実行してみる

orangepi@orangepi5:~$ echo overlays=ssd-sata | sudo tee /mnt/stateful_partition/unencrypted/Env.txt
tee: /mnt/stateful_partition/unencrypted/Env.txt: No such file or directory
overlays=ssd-sata
orangepi@orangepi5:~$ cat /mnt/stateful_partition/unencrypted/Env.txt
cat: /mnt/stateful_partition/unencrypted/Env.txt: No such file or directory
orangepi@orangepi5:~$

まあ、エラーになりますね

stateful_partitionは不要なのかな?と削った /mnt/unencrypted/Env.txt でファイルを作ってみた。

orangepi@orangepi5:~$ echo overlays=ssd-sata | sudo tee /mnt/unencrypted/Env.txt
overlays=ssd-sata
orangepi@orangepi5:~$ cat /mnt/unencrypted/Env.txt
overlays=ssd-sata
orangepi@orangepi5:~$

また、再起動前にmtdblock0にSATA用イメージを書き込みます。

orangepi@orangepi5:~$ sudo dd if=/usr/share/orangepi5/rkspi_loader_sata.img of=/dev/mtdblock0 status=progress
13894144 bytes (14 MB, 13 MiB) copied, 1 s, 13.9 MB/s
32768+0 records in
32768+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 246.949 s, 67.9 kB/s
orangepi@orangepi5:~$

で、Linuxをshutdown してから、microSDを抜き、電源を入れると、openFydeが起動しました。

Fyde OSのオリジナルアカウントかGoogleアカウントでログインすることができます。

Googleアカウントでログインする場合は、普通のChrome OSと同じようにセットアップしていきます。

セットアップが終わるとまあ、普通のChromeOSです

Linux環境も使えます。

ブラウザでWebアクアリウムを動かしてみると10000匹でfps:38となかなかいい感じで動いている。この値はUbuntuでGPU有効で動かした場合より良いものになっている。

また、youtube再生した場合の動作も、openFydeで動かした方がよい感じになっている。

音声再生もきちんと動いている。

ブラウザで日本語入力を試みたところ、日本語入力モードへの切り替えはできたのですが、変換機能がうまく動いていないようで…

いや、ブラウザのURL入力欄では日本語入力ができないだけでした。

FydeOS App Storeを開くと「Android apps」という項目があるのですが、どういうチョイスかよくわからないものがインストールできるようです。

Orange Pi 5でAndroid/Linux共にM.2 SATA SSDから起動できるようになった


Orange Pi 5の中国語DownloadページのAndroid镜像リンクをたどってみたところ、SPIFlash-SATA SSDというディレクトリが・・・

え?と思って、ダウンロードしてRKDevToolを使って書き込みを試して見るも「Switch into SATA storage Fail, did not support to switch in」というエラーで成功しない。

改めて中国ページの官方工具にあるマニュアルを確認してみると「OrangePi_5_RK3588S_用户手册_v0.7.pdf」と英語ページにあるマニュアルよりだいぶバージョンが上がっている。

ただ、M.2 SATA SSDからAndroidを起動する場合の書き込み手順について違う点はなく、原因は不明・・・

(注:最終的にはLinux側でSPIFlashを書き換えるとAndroidの書き込みが成功するようになりました。)

LinuxをM.2 SATA SSDから起動

その他にないかマニュアルを読み直すとM.2 SATA SSDからLinuxを起動する手順が掲載されているので、そちらを試行してみた。

マニュアル上の重要なポイントは以下

実際にやってみる。

まずSPIFlashの書き換えに使うファイルを確認

orangepi@orangepi5:~$ ls -ld /usr/share/orangepi*
drwxr-xr-x 2 root root 4096 Dec 22 19:36 /usr/share/orangepi
drwxrwxr-x 2 root root 4096 Dec 12 17:58 /usr/share/orangepi5
orangepi@orangepi5:~$ ls -l /usr/share/orangepi
total 4
-rw-r--r-- 1 root root 3269 Dec 22 19:34 boot.cmd
orangepi@orangepi5:~$ ls -l /usr/share/orangepi5/
total 16384
-rw-rw-r-- 1 root root 16777216 Dec 12 17:58 rkspi_loader_sata.img
orangepi@orangepi5:~$

SPIFlashを書き換えます。

orangepi@orangepi5:~$ sudo dd if=/usr/share/orangepi5/rkspi_loader_sata.img of=/dev/mtdblock0
[sudo] password for orangepi:
32768+0 records in
32768+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 244.953 s, 68.5 kB/s
orangepi@orangepi5:~$

現状のM.2 SATA SSD上のブートローダ、パーテーションをddでzeroを書き込んで消します。

orangepi@orangepi5:~$ sudo dd bs=1M if=/dev/zero of=/dev/sda count=2000 status=progress
1754267648 bytes (1.8 GB, 1.6 GiB) copied, 2 s, 877 MB/s
2000+0 records in
2000+0 records out
2097152000 bytes (2.1 GB, 2.0 GiB) copied, 5.5852 s, 375 MB/s
orangepi@orangepi5:~$
orangepi@orangepi5:~$ sudo fdisk -l /dev/sda
Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: WT M.2 512G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
orangepi@orangepi5:~$

次にmicroSD上にコピーしておいたLinuxイメージをM.2 SATA SSDに書き込みます。

orangepi@orangepi5:~$ sudo dd if=Orangepi5_1.0.8_ubuntu_jammy_desktop_xfce_linux5.10.110.img of=/dev/sda bs=1M status=progress
8129609728 bytes (8.1 GB, 7.6 GiB) copied, 119 s, 68.3 MB/s
7800+0 records in
7800+0 records out
8178892800 bytes (8.2 GB, 7.6 GiB) copied, 121.861 s, 67.1 MB/s
orangepi@orangepi5:~$

書き込み完了後のパーテーションはこのようになります

orangepi@orangepi5:~$ sudo sync
orangepi@orangepi5:~$ sudo fdisk -l /dev/sda
GPT PMBR size mismatch (15974399 != 1000215215) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: WT M.2 512G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 58FCCC02-859A-5041-ADA7-14802AADF341

Device      Start      End  Sectors  Size Type
/dev/sda1   61440   585727   524288  256M Linux extended boot
/dev/sda2  585728 15974366 15388639  7.3G Linux filesystem
orangepi@orangepi5:~$

書き込んだM.2 SATA SSDの/dev/sda1 にあるorangepiEnv.txtを書き換えるためにマウントします。

orangepi@orangepi5:~$ sudo mount /dev/sda1 /mnt
orangepi@orangepi5:~$ df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       256M   95M  162M  37% /mnt
orangepi@orangepi5:~$ ls -l /mnt
total 96104
-rwxr-xr-x 1 root root   230456 Dec 22 19:39 boot.bmp
-rwxr-xr-x 1 root root     3269 Dec 22 19:34 boot.cmd
-rwxr-xr-x 1 root root     3341 Dec 22 19:51 boot.scr
-rwxr-xr-x 1 root root   215221 Dec 22 18:24 config-5.10.110-rockchip-rk3588
drwxr-xr-x 3 root root     4096 Dec 22 19:36 dtb
drwxr-xr-x 3 root root     4096 Dec 22 19:36 dtb-5.10.110-rockchip-rk3588
-rwxr-xr-x 1 root root 33915392 Dec 22 18:24 Image
-rwxr-xr-x 1 root root 11119990 Dec 22 19:54 initrd.img-5.10.110-rockchip-rk3588
-rwxr-xr-x 1 root root      154 Dec 22 19:51 orangepiEnv.txt
-rwxr-xr-x 1 root root     1542 Dec 22 19:48 orangepi_first_run.txt.template
-rwxr-xr-x 1 root root  7853912 Dec 22 18:24 System.map-5.10.110-rockchip-rk3588
-rwxr-xr-x 1 root root 11120054 Dec 22 19:54 uInitrd
-rwxr-xr-x 1 root root 33915392 Dec 22 18:24 vmlinuz-5.10.110-rockchip-rk3588
orangepi@orangepi5:~$

orangepiEnv.txtの最後に「overlays=ssd-sata」を追加します。

orangepi@orangepi5:~$ sudo cp /mnt/orangepiEnv.txt /mnt/orangepiEnv.txt.org
orangepi@orangepi5:~$ sudo vi /mnt/orangepiEnv.txt
orangepi@orangepi5:~$ cat /mnt/orangepiEnv.txt
verbosity=1
bootlogo=true
overlay_prefix=rk3588
fdtfile=rockchip/rk3588s-orangepi-5.dtb
rootdev=UUID=5ead0754-b05b-4f29-8170-b0620e7ae6d2
rootfstype=ext4
overlays=ssd-sata
orangepi@orangepi5:~$

書き込んだらumount

orangepi@orangepi5:~$ sudo umount /mnt
orangepi@orangepi5:~$

このあと、microSDを抜いて、M.2 SATA SSDのみで電源を入れると、M.2 SATA SSDから起動しました。

orangepi@orangepi5:~$ sudo fdisk -l /dev/sda
Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: WT M.2 512G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 58FCCC02-859A-5041-ADA7-14802AADF341

Device      Start       End   Sectors   Size Type
/dev/sda1   61440    585727    524288   256M Linux extended boot
/dev/sda2  585728 990183423 989597696 471.9G Linux filesystem
orangepi@orangepi5:~$

Android再挑戦

Linux側でSPIFlashを書き換えたあとであれば成功するかな?と試してみたところ、これまで失敗していたところは問題無く終了し、書き込みが実行されるようになりました。

(microSDをさしっぱなしにしていると途中で失敗するので注意)

Androidの書き込み完了後は自動的に再起動されAndroidが起動します。

なお、起動したAndroidは、WiringOPアプリが追加されている以外はあまり違いがないような感じでした。


2023/01/12追記

新しいM.2 SATA SSDが届いたので、Androidイメージを書き込むべく、とりあえず「sudo dd if=/usr/share/orangepi5/rkspi_loader_sata.img of=/dev/mtdblock0」を行ったあとに、RKDevToolで書き込みを実施してみましたが、書き込みはfailしました。

「sudo dd if=Orangepi5_1.0.8_ubuntu_jammy_desktop_xfce_linux5.10.110.img of=/dev/sda bs=1M status=progress」でLinuxイメージを書き込み、一度起動させたあとで、RKDevTool書き込みを試すと、成功しました。

(このとき、Linuxを書き込んだあとのorangepiEnv.txt 修正を忘れたので、Linux起動が途中で失敗してinitramfsで止まりましたが、電源強制オフのあと、Android書き込みには問題ありませんでした。)