OSAKANA TAROのメモ帳

ボリューム言語切り替えは面倒

NetAppのボリューム言語をja_JP.PCKからutf8mb4に変えたいな、と思うとsnapmirrorでのボリューム以降ではなくて、rsyncやrobocopyなどを使ってコピーする必要がある。

例えば、robocopyでやるなら以下の様なバッチファイルを動かしてコピーする

@echo off
set TIME2=%TIME: =0%
set LOGDATE=%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%-%TIME2:~0,2%%TIME2:~3,2%

robocopy \\netappfs\shares1  \\netappfsnew\shares1 /mir /copyall /R:0 /W:0 /LOG+:D:\LOGS\netappfs-shares1-%LOGDATE%.txt
robocopy \\netappfs\document \\netappfsnew\document /mir /copyall /R:0 /W:0 /LOG+:D:\LOGS\netappfs-document-%LOGDATE%.txt

D:\LOGS に実行ログを吐き出すが、バッチファイルの実行開始時間を元にしたファイル名となるので、ログ確認がしやすい

失敗した切り替え手順

IPアドレスが確保出来なかったということなので、旧NetAppのサービス用IP と新NetAppの仮接続用IPしかない、ということなので

旧NetAppのネットワークケーブル抜いてから
新NetApp側のIPアドレスを切り替えてAD参加
旧NetApp側のIPアドレスを新NetAppについてた仮接続用IPに切り替え
旧NetAppのネットワークケーブルを接続して、AD参加

ということをやればいいかなーと以下の手順で実施した。

が・・・これだと旧NetAppがnetappfsとして参加していた情報の方が勝つらしく、12の段階で旧サーバがnetappfsだとしてAD上のアクセス情報を持っていこうとしているっぽく、問題が発生した。

このため新NetAppをもう１度Active Directoryに参加させるという対処を行う羽目になった。

旧NetAppが ADに netappfs で参加している
新NetAppが ADに netappfsnew で参加してデータ移行
新::> vserver cifs create -vserver netappfs -cifs-server netappfsnew
切り替え日
旧NetAppのADをdown
　旧::> vserver cifs modify -vserver netappfs -state-admin down
新NetAppのADをdown
　新::> vserver cifs modify -vserver netappfs -state-admin down
旧NetAppのネットワークケーブルを外す
　(旧NetAppのIPアドレスは変更していない)
新NetAppでIPを引き継ぎ
新::> network interface modify -vserver netappfs -lif ～ -address サービス用IP
新NetAppをnetappfsとしてAD参加
　新::> vserver cifs modify -vserver netappfs -cifs-server netappfs
新NetAppにクライアントからアクセスできるか確認
　問題ないことを確認
ケーブルを外した状態で旧NetAppのIPを変更
旧::> network interface modify -vserver netappfs -lif ～ -address 別IP1
旧NetAppのネットワークケーブルをつなぐ
旧NetAppをAD再参加
　旧::> vserver cifs modify -vserver netappfs -cifs-server netappfs-old
　　→ クライアントから新NetApp(netappfs)にアクセスできなくなる
　　　新NetAppで「vserver cifs check」コマンドを実行すると
　　　「down SecD Error: no server available」といったエラーが出ている
新NetAppのAD登録名を一時的に別のものに参加したあと、正式名で再参加
　新::> vserver cifs modify -vserver netappfs -state-admin down
　新::> vserver cifs modify -vserver netappfs -cifs-server netappfstmp
　新::> vserver cifs modify -vserver netappfs -state-admin down
　新::> vserver cifs modify -vserver netappfs -cifs-server netappfs
　　→ クライアントから新NetApp(netappfs)にアクセスできるようになる

同じではないが、OUがちゃんと変更されていない場合の再変更手順「Organizational Unit (OU) is not updated in ONTAP after Active Directory object move」を見ると「vserver cifs stop -vserver netappfs」で止めたあと、もう１回「vserver cifs modify -vserver netappfs -cifs-server netappfs -ou OU=NewOU」と実行する、という風になっていた

いつもの切り替え手順

いつもは旧NetAppのサービス用IP と新NetAppの仮接続用IP、旧NetAppの仮接続用IPの３つを用意してもらって切り替えている

1. 旧NetAppが ADに netappfs で参加している
2. 新NetAppが ADに netappfsnew で参加してデータ移行
  新::> vserver cifs create -vserver netappfs -cifs-server netappfsnew
3. 切り替え日
4. 旧NetAppのADをdown
　旧::> vserver cifs modify  -vserver netappfs -state-admin down
5. ケーブルを外した状態で旧NetAppのIPを変更
  旧::> network interface modify -vserver netappfs -lif ～ -address 旧NetAppの仮接続用IP
6. 旧NetAppをAD再参加
　旧::> vserver cifs modify  -vserver netappfs -cifs-server netappfs-old
7. 新NetAppのADをdown
　新::> vserver cifs modify  -vserver netappfs -state-admin down
8. 新NetAppでIPを引き継ぎ
  新::> network interface modify -vserver netappfs -lif ～ -address サービス用IP
9. 新NetAppをnetappfsとしてAD参加
　新::> vserver cifs modify  -vserver netappfs -cifs-server netappfs
10. 新NetAppにクライアントからアクセスできるか確認
　問題ないことを確認

メモ

secd logにログが出ているらしい？

/mroot/etc/log/mlog/secd.log というパス？ (Overview of ONTAP Logs)

SVMのマシンアカウントのパスワードを再設定する「vserver cifs domain password reset」を実行することで解消する？

2023年5月11日2023年5月15日

Active Directoryサーバのセキュリティ強化アップデート(CVE-2022-38023)に伴うONTAPファイルサーバへの影響についてのメモ

Check

WindowsのActive Directoryサーバに対してセキュリティ攻撃ができることが判明したため、Active Directoryサーバに対してセキュリティ強化がWindows Update経由で2022年11月に配布されている。

このときのアップデートで対応されたのは下記の3点

・KB5021131: CVE-2022-37966 に関連する Kerberos プロトコルの変更を管理する方法
・KB5020805: CVE-2022-37967 に関連する Kerberos プロトコルの変更を管理する方法
・KB5021130: CVE-2022-38023 に関連する Netlogon プロトコルの変更を管理する方法

CVE-2022-37966とCVE-2022-38023はどちらも暗号化方式として脆弱なRC4-HMACを使用するのをやめてAESに変更する、というものとなっている。

このため、Kerberos/NTLMv2のどちらを使っていてもRC4-HMACを使用している場合は、このWindows Update適用後に問題が発生する、ということになる。

Windows サーバで構成されているActive Directoryサーバ側での対応については以下にまとめられている

・CVE-2022-37966 への対応とその影響について
・CVE-2022-37967 への対応とその影響について
・CVE-2022-38023 への対応とその影響について

いろいろ書いてあるが、Windowsサーバのレジストリ設定をすることで、強制適用を延期できるけど、最終的にはアクセスできなくなるよ、ということになっている。

で・・・どういう場合に問題が発生するのか？というところが問題となる。

問題が発生するもの

・Active Directoryサーバに対してRC4-HMAC暗号化を使ってKerberos認証を行う場合
・Active Directoryサーバに対してRPC署名を使ってNTLMv2認証を行う場合
・Active Directoryサーバに対してRPCシールとRC4-HMAC暗号化を使ってNTLMv2認証を行う場合

問題が起こらないもの

・Active Directoryサーバに対してAES暗号化を使ってKerberos認証を行う場合
・Active Directoryサーバに対してRPCシールとAES暗号化を使ってNTLMv2認証を行う場合
　(NTLM/Netlogon Secure Channel は同じ意味)

(他にも大丈夫な場合はあると思います)

具体的な環境

2023年5月時点で適切にWindows Updateが実施されているWindows 7 / Windows Server 2012以降のマシンで、Active Directoryに参加している場合はKerberos/AESなので問題ない

Windowsであってもworkgroupとして認証を行う場合はNTLMv2となる場合があるので注意が必要

Linuxからcifs-utilsを使ってCIFS領域をマウントする場合、標準設定ではNTLMv2を使用するため注意が必要

LinuxをActive Directoryに参加させる場合、注意が必要
　Microsoft の 2022 年 11 月の更新により Active Directory の統合が中断される
　 Red Hat Enterprise Linux and Microsoft security update of November 2022

ファイルサーバでの問題発生例

Active Directoryに参加しているファイルサーバでは以下のような形で認証が行われる模様

・[クライアント]→Kerberos認証→[ファイルサーバ]→Kerberos認証→[Active Directory]
・[クライアント]→NTLMv2認証→[ファイルサーバ]→NTLMv2認証→[Active Directory]

クライアントからどちらの形式でアクセスをしてくるかで、ファイルサーバ側からActive Directoryへの問いあわせ手法も変わる、ということになる。

このため、ファイルサーバの仕様で問題が発生することとなるため各社がお知らせを出している

・sambaでの問題 RC4/HMAC-MD5 NetLogon Secure Channel is weak and should be avoided Samba 4.15.13/4.16.8/4.17.4以降で対応
・NetAppでの問題 SU530: [Impact Critical] NTLM authentication fails due to enforcement of Netlogon RPC sealing (Microsoft CVE-2022-38023) ONTAP 9.7以降の2023年4月中旬以降提供バージョンで対応
・RedHat/samba CVE-2022-38023
・DELL PowerScale/iSilon PowerScale: Isilon: Netlogon RPC Elevation of Privilege Vulnerability (CVE-2022-38023) OneFS 9.5.0以降で対応
・DELL Unity Dell Unity: Is Unity affected by CVE-2022-38023? (User Correctable) Unity OE 5.1.0以降で対応

・Synology Synology-SA-22:24 Samba AD DC 2023/05/11時点では未提供だが対象リストを見ると通常のファイルサーバ用途では対応不要?
　QNAP,バッファローなども特にお知らせは無し

NetApp ONTAPでの対応

対応が必要であるかの調査

NetApp ONTAPでは、ファイルサーバ=>Active Directoryの通信をRC4-HMACで行ってたということで修正がONTAP OSの修正がリリースされています。

2023年4月後半以降にリリースされたONTAP 9.7以降のパッチリリースのみが今回の問題に対応しています。

詳細については富士通が見える状態でリリースを置いてくれています

「ETERNUS AX/HXシリーズ, ETERNUS NR1000シリーズにおける WindowsのNetlogon脆弱性対応(CVE-2022-38023)による影響(CIFS接続不可)について」

いろいろ書いてありますが、とりあえず、今使ってるNetAppファイルサーバにNTLMv2を使ってアクセスしてきてるユーザがいるのかを確認しましょう

「vserver cifs session show -fields auth-mechanism,protocol-version,windows-user,address」を実行して、auth-mechanismに「NTLMv2」がいる場合は対処が必須です。

netapp9101::> vserver cifs session show -fields auth-mechanism,protocol-version,windows-user,address
node          vserver session-id           connection-id address       auth-mechanism windows-user  protocol-version
------------- ------- -------------------- ------------- ------------- -------------- ------------- ----------------
netapp9101-01 svm0    14421088956793749524 535041285     172.17.44.173 Kerberos       VM2\testuser1 SMB2_1
netapp9101-01 svm0    14421088956793749539 535041298     172.17.44.174 NTLMv2         VM2\testuser1 SMB3
2 entries were displayed.

netapp9101::>

このテスト環境では、172.17.44.173はWindows 7 SP1クライアント、172.17.44.174はRHEL 7.6からCIFSマウントしている環境でした。

このRHEL7.6は「mount -t cifs //svm0.adosakana.local/testutf /mnt2 -o user=testuser1@adosakana.local,password=パスワード,vers=3.0」と実行してマウントしているもので、sec=オプションを付けていない場合はNTLMv2を使用しているようでした。

この「vserver cifs session show -fields auth-mechanism,protocol-version,windows-user,address」はCIFS接続が継続している間は表示される、というものになっているため、数分間アクセスを行わないとリストから消えます。

このため、NTLMv2でアクセスしているかどうかが分からない機械がある場合は、アクセス操作を行ってみた直後にコマンドを実行してみる必要があります。

必要な対応

ONTAP OSのバージョンアップが必要な場合はアップデートを行います。

2023/05/11時点ではCVE-2022-38023に対応するアップデートとして以下が提供されています。

　ONTAP 9.7P22 (End of Limited Support 2025/07/31)
　ONTAP 9.8P18 (End of Limited Support 2025/12/31)
　ONTAP 9.9.1P15 (End of Limited Support 2026/06/30)
　ONTAP 9.10.1P12(End of Limited Support 2027/01/31)
　ONTAP 9.11.1P8 (End of Limited Support 2027/07/31)
　ONTAP 9.12.1P2 (End of Limited Support 2028/02/28)

FAS2520/2552/2554,FAS8020/8040/8060/8080 は ONTAP 9.9.1 までサポート
FAS2620/2650 は ONTAP 9.11.1 までサポート
FAS2720/2750などの現行機種は制限なし

アップデート先は、同じONTAP OSバージョン内の最新にするか、ハードウェアがサポートされている範囲の新しいバージョンにするかはご自由に

ONTAP OS 9.6などのアップデート提供がバージョンを使用している場合は、ONTAP 9.7以降にアップデートする必要があります。

古いONTAPを新しいONTAPにアップデートする場合、状態によっては複数回のアップデートが必要となります

詳細は「どのバージョンの ONTAP にアップグレードできますか。」を参照してください

例えばONTAP 9.11.1へアップデートする場合、下記のような手順となります。

　　ONTAP 9.4→(9.5+9.7)→9.9.1→9.11.1
　　ONTAP 9.5→(9.7+9.9.1)→9.11.1
　　ONTAP 9.6→9.8→9.11.1
　　ONTAP 9.7→(9.8+9.11.1)

(9.5+9.7)というのはONTAP 9.5とONTAP 9.7のアップデートファイルを読み込ませてONTAP 9.7のアップデートとして実行すると、内部的に自動的にONTAP 9.5の適用を行ったあとに9.7適用を行ってくれる、ということをします。

どんな感じでアップデートするか、というのは「この記事」から持ってきた下記画面を参照してください。

1)「イメージの追加」からアップデートするファイルを２つ登録する

2) 新しいバージョンを選択して「更新」

3) まずは古いバージョンの方の適用が開始される

4) 続いて新しいバージョンの方が適用される

5) 終了

NetAppでの調査/対応に関するメモ

NetAppでサポートする認証方式の変更

Set the SMB server minimum authentication security level

「vserver cifs security show -fields lm-compatibility-level」で現在設定されている認証方式を確認

netapp9101::> vserver cifs security show -fields lm-compatibility-level
vserver lm-compatibility-level
------- ----------------------
Cluster -
Snapmirror-WAN
        -
netapp9101
        -
netapp9101-01
        -
svm0    lm-ntlm-ntlmv2-krb
svm2    lm-ntlm-ntlmv2-krb
svm3    lm-ntlm-ntlmv2-krb
7 entries were displayed.

netapp9101::>

値の意味は下記

Value	Description
`lm-ntlm-ntlmv2-krb` (default)	The storage virtual machine (SVM) accepts LM, NTLM, NTLMv2, and Kerberos authentication security.
`ntlm-ntlmv2-krb`	The SVM accepts NTLM, NTLMv2, and Kerberos authentication security. The SVM denies LM authentication.
`ntlmv2-krb`	The SVM accepts NTLMv2 and Kerberos authentication security. The SVM denies LM and NTLM authentication.
`krb`	The SVM accepts Kerberos authentication security only. The SVM denies LM, NTLM, and NTLMv2 authentication.

標準ではLM, NTLM, NTLMv2, Kerberosに対応している、ということになっている。

NetApp側で強制的にLM,NTLM,NTLMv2クライアントを排除する、という場合は「krb」に変更する

Kerberos接続時のAES暗号化を有効化

Enable or disable AES encryption for Kerberos-based communication

「vserver cifs security show -fields is-aes-encryption-enabled」を実行して確認。ONTAP 9.12.1以降は「true」が標準値となる。

netapp9101::> vserver cifs security show -fields is-aes-encryption-enabled
vserver is-aes-encryption-enabled
------- -------------------------
Cluster -
Snapmirror-WAN
        -
netapp9101
        -
netapp9101-01
        -
svm0    false
svm2    false
svm3    false
7 entries were displayed.

netapp9101::>

なお設定を変更する場合は、ドメイン認証を求められるので注意

netapp9101::> vserver cifs security modify -vserver svm0 -is-aes-encryption-enabled true

Info: In order to enable CIFS AES encryption, the password for the CIFS server
      machine account must be reset. Enter the username and password for the
      CIFS domain "ADOSAKANA.LOCAL".

Enter your user ID: administrator

Enter your password:

netapp9101::> vserver cifs security show -fields is-aes-encryption-enabled
vserver is-aes-encryption-enabled
------- -------------------------
Cluster -
Snapmirror-WAN
        -
netapp9101
        -
netapp9101-01
        -
svm0    true
svm2    false
svm3    false
7 entries were displayed.

netapp9101::>

2023年5月9日2023年5月9日

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

Check

Orange Pi 5上で動くChromium OSカスタマイズのopenFydeにR108ベース版が登場した。

商用版のfydeOSの方でもFydeOS for YouとしてOrange Pi 5向けがダウンロードできるようになった。

openFydeではR108版ではAndroidアプリが動作するようになった模様(fydeOS v16.1リリースノートにはAndroidに関する記載はない)

Add Android 11 support implemented by project ARCHERO(Alpha test status).
Upgrade Android 11 subsystem ArcHero.

どういう仕組みで動かしているのかな？と調べてみるとFydeOSの「Chromium OS Archero Developer Guide」というページを発見。

Google Chrome OSでのAndroidアプリはGoogle ARC++(Android Runtime for Chrome)を使って動かしているものを、anboxベースで置き換えた、というものであるようだ。

Orange Pi 5へのインストール

openFyde R102でのインストール手法から変更となっている。

1) orangepi5-openfyde-r108-r1.run をダウンロード
2) orangepi5-openfyde-r108-r1.run をインストール先M.2 SSDに合わせたオプション付きで実行してimgファイルを出力
3) imgファイルをmicroSDに書き込む
4) 書き込んだmicroSDとインストール先のM.2 SSD(NVMe or SATA)をOrange Pi 5に取り付け
5) Orange Pi 5の電源をつないでopenFyde起動してM.2 SSDにインストール
6) インストール完了後、自動的に電源は切れる
7) microSDはさしたままOrange Pi 5の電源を入れるとM.2SSDからopenFydeが起動

最初、Linux環境から直接imgファイルをM.2 SSDに書き込んでみたり、microSDで起動してM.2 SSDにインストールした後はmicroSDを抜くものだと思っていたので、起動してこなくて悩みました。

現状のOrange Pi 5だとオンボードSPIにブートローダ書き込んだ場合の動作調整が面倒なので、どのような設定でも最優先されるmicroSDにブートローダを書き込んでしまうのが確実、ということで、常時microSDをさしたままの状態とする、ということのようです。

現状のAndroid互換レイヤーではストアとして中国CoolAPKのみが登録されているので、中国圏のアプリは簡単にインストールできる状態でした。

原神のアイコンがあったのでインストールしてみたところ、インストールに成功し、ログイン時のあの音楽も流れてきましたが、中国アカウントを求められてそれ以上は進めませんでした。

2023年5月8日2023年5月12日

WiMAX HOME 02をジャンク500円で手に入れたのでドコモSIMで使った(楽天モバイルは不可

Check

秋葉原でUQ WiMAX HOME 02が本体のみ(電源無し) 500円で売っていた

裏面を見てみると製造年2020年7月、8月、12月などいろいろタイプがあった

電源は12V1.5Aなのだが、極性統一 EIAJ #4 というタイプのコネクタとなっている。

買った時はバッファローWiFiの12Vが使えるだろう、と軽く考えてたのですが駄目でした。

別途、5.5mm/2.1mmから極性統一#4(5.5mm/3.3mm センターピンあり)に変換するコネクタを調達しました。

変換コネクタが届くまでとりあえず手元にあった極性統一#4の12V 0.7Aのアダプタを使って起動テスト

nanoSIMをスロットに入れて電源ON

特に問題なくルータの管理画面にアクセスできたが、ドコモSIMで電波を掴むにはAPN設定以外にも設定が必要だった

[ネットワーク設定]-[基本設定]にある「通信モード」を「ハイスピードプラスエリアモード」に変更する必要がありました。

IIJmio SIMでAPNを設定する場合、[ネットワーク設定]-[プロファイル設定]にある「プロファイルリスト」で「no setup」となっているものを「選択」してから設定します。

このとき、IIJmioのページには「認証タイプ PAPまたはCHAP」と書いてあるのですが、HOME 02では「PAP」と設定しなければつながりませんでした。

また、設定後、5分ぐらい待たないと接続状態とならないようです。

2023/05/11追記

楽天モバイルSIMを入れて設定を試みたところ、ユーザ名とパスワードを未設定、ということはできませんでした。

ただ、適当な値を入れても大丈夫らしいので、設定してみたのですが、接続出来ず

よくよく使用できる電波仕様を確認してみると楽天モバイルが使用しているバンド3(LTE 1.7GHz)は非対応でした。

2023/05/12追記: 楽天モバイルでのau回線利用が拡大されるっぽいですが、au基地局側で設定されている場合のみ使えるって感じなので、基本的には使えないと思っておいた方がいいでしょう

／
📢#楽天モバイルの新プラン
「Rakuten最強プラン」発表✨
＼

パートナー回線エリア内のデータ容量制限を撤廃し、日本全国の通信エリアでデータ高速無制限に📱

お申し込みは6/1(木)から▶https://t.co/V1TzAKyjLG
※既存ご契約者様は自動移行 pic.twitter.com/b1MFwgqvCB
— 楽天モバイル (@Rakuten_Mobile) May 12, 2023

2023年5月8日2023年5月17日

Win10 2.5インチSATA起動ディスクをNVMe起動ディスクに移行した

Check

元々は、Intel CPUのNEC Mate でインストールしたWindows 8.1 ProのシステムディスクがWindows 10 Proになったあと、AMD Athlon 220GEのmicroATXマザーパソコンに移動して使用していた。

Beelink SER5 Proに移行するにあたり、引き続きこのシステムディスクが利用できないかを実験した。

さすがに元の起動ディスクをそのまま実験するのは怖かったので、別のディスクにコピーしてから実施した。

1) 元環境をClonezillaで起動してシステムディスクをコピー

USBメモリにClonezillaを書き込んで「device-device」でシステムディスクを別の2.5インチSSDにコピーした。

(最初はdevice-imageでNASにバックアップしようとしてたのだが、何故か途中で失敗することが多発したのでdevice-deviceに変更した)

以降の作業はコピーしたSSDで実施した。

2) 元環境でMBR変換

Windows 10のインストールUSBを用意して、リカバリモードのコマンドプロンプトを開く

「mbr2gpt /convert /disk:0 /allowfullos」を実行

最後が「failed」と出ていたが、追加対処が必要という意味

普通に再起動して、Windows10を起動

管理者権限でコマンドプロンプトを開いて「reagentc /disable」「reagentc /enable」を実行してシャットダウン

BIOS設定を変更してUEFI onlyで起動する設定に変更して、起動してくることを確認

参考にしたページ:ライフボードBLOG「MBR OSをGPT OSに変更する方法(Windows10　64bit)」
(The BASIC/ざべで知った会社、まだあったんだ、と思ったなど)

3) 元環境でchkdsk実行

clonezillaでファイルシステムの問題が出ることがあったので、「chkdsk /f /b」を実行して再起動

再起動時にちょっと長めのファイルシステムチェックが行われるので、終わるまで待つ

4) 新環境をClonezillaで起動してシステムディスクをコピー

まず、ClonezillaのUSBメディアで起動したあと、元環境の2.5インチSSDをUSBケースに入れて接続

「device-device」で2.5インチSSDからnvme SSDへのコピーを実施

5) 新環境を内蔵NVMeのみで起動

USBメディアを取り外して、コピーしたNVME SSDのみで起動。

起動後、足らないデバイスドライバがあれば追加

投稿

NetApp 切り替え時メモ書き

ボリューム言語切り替えは面倒

失敗した切り替え手順

いつもの切り替え手順

メモ

Active Directoryサーバのセキュリティ強化アップデート(CVE-2022-38023)に伴うONTAPファイルサーバへの影響についてのメモ

問題が発生するもの

問題が起こらないもの

具体的な環境

ファイルサーバでの問題発生例

NetApp ONTAPでの対応

対応が必要であるかの調査

必要な対応

NetAppでの調査/対応に関するメモ

NetAppでサポートする認証方式の変更

Kerberos接続時のAES暗号化を有効化

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

Orange Pi 5へのインストール

WiMAX HOME 02をジャンク500円で手に入れたのでドコモSIMで使った(楽天モバイルは不可

Win10 2.5インチSATA起動ディスクをNVMe起動ディスクに移行した

1) 元環境をClonezillaで起動してシステムディスクをコピー

2) 元環境でMBR変換

3) 元環境でchkdsk実行

4) 新環境をClonezillaで起動してシステムディスクをコピー

5) 新環境を内蔵NVMeのみで起動

6) 作業終了