tsato
2021年10月7日 10時13分
お世話になります。
Debian GNU/Linuxルートファイルシステムアーカイブの作成をしようとしています。
下記の手順の「dump_rootfsによる方法」を試してますが、ファイルが作成されません。
https://manual.atmark-techno.com/armadillo-guide-std/armadillo-guide-st…
まずdumprootfsパッケージをインストールしました。版数は以下です。
root@armadillo:~# apt list --installed | grep dumprootfs
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
dumprootfs/stretch,now 1.1.0-1 all [installed]
"dumprootfs -c || echo NG"コマンドは応答無しでした。(対応済み？)
保存先はデフォルトの"/dev/sda1"で、FAT32の32GByteUSBメモリを挿入済みです。
ここで"dumprootfs"を実行するとrebootしますが、途中コンソールでエラー？らしき表示後通常のログイン画面になります。
コンソール全てだと長くなるのでとりあえず幾つか抜粋しますと、以下の表示が出てました。
fdisk: cannot open : No such file or directory
dump_rootfs has failed.
まずは上記で何か手順間違いがあるか分かりますでしょうか。
一点気になった点としては、dumprootfsをインストールした際に/etc/dumprootfs/ディレクトリに生成されるのは、
手順にある"do_dump_rootfs"と"dump_excludes"ではなく、代わりに"dumprootfs.conf"と"excludes.list"でした
また、本来ある3つのパラメータと除外設定は"dumprootfs.conf"と"excludes.list"の中に記載されていました。
よろしくお願いします。
コメント
at_akihito.irie
2021年10月7日 16時08分
入江です。
> 下記の手順の「dump_rootfsによる方法」を試してますが、ファイルが作成されません。
ご迷惑おかけして申し訳ございません。
おそらくdumprootfsの不具合です。
ワークアラウンドですが、FAT32のUSBメモリをご使用されている前提でしたら、
/etc/dumprootfs/dumprootfs.confの、force_formatをnoにすることで動作す
るかと思います。
[armadillo]# grep "force_format" /etc/dumprootfs/dumprootfs.conf force_format=no
本不具合は後日修正予定です。
> 一点気になった点としては、dumprootfsをインストールした際に/etc/dumprootfs/ディレクトリに生成されるのは、
> 手順にある"do_dump_rootfs"と"dump_excludes"ではなく、代わりに"dumprootfs.conf"と"excludes.list"でした
> また、本来ある3つのパラメータと除外設定は"dumprootfs.conf"と"excludes.list"の中に記載されていました。
こちらについては参考にされているドキュメントのバージョンが古いようです。
2021/10/07時点で最新版は以下です。
https://manual.atmark-techno.com/armadillo-guide-std/armadillo-guide-st…
tsato
2021年10月22日 9時14分
お世話になります。
その後の展開で追加質問になりますが、
ルートファイルシステムアーカイブ作成後の書き換えについて、説明書の11.2.4章を参考に行ってますが、
アーカイブ作成した同一の端末へは正常に復元が出来ましたが、
別のX-1の端末へこのアーカイブを展開したところ、有線LANのコネクションに"Wired connection 1"と"Wired connection 2"が作成されてしまい、LANケーブルを挿すと"Wired connection 2"がDEVICE”eth0”となってしまいます。
元々のルートファイルシステムアーカイブでは、"Wired connection 1"が"eth0"となっていて、固定IPアドレスの設定に変更していました。
アーカイブ作成時の除外設定excludes.listはデフォルトから変更していません。
確認したところ、"Wired connection 1"のUUIDがアーカイブ元と同じで、別のX-1の端末とUUIDが異なるため"Wired connection 2"が自動作成されたのかとの推測です。
なので/etc/NetworkManager/system-connetions/Wired connection 1を除外リストに加えれば良いかと思いましたが、
そうすると元のアーカイブの固定IPアドレスの設定が引き継がれなくなりそうです。
別のUUIDのネットワーク設定に元の固定IPアドレスの設定のみを展開させるようなシステムアーカイブの作成なんて方法はありますでしょうか。
また、ネットワーク設定は引き継げない(IPアドレス固定化は手動で行う)場合、除外するファイルは上記の/etc/NetworkManager/system-connetions/Wired connection 1のみで良さそうでしょうか。
よろしくお願いします。
at_shinya.koga
2022年1月25日 13時31分
アットマークテクノの古賀です。
tsatoさん（2021年10月22日 9時14分）：
>その後の展開で追加質問になりますが、
>ルートファイルシステムアーカイブ作成後の書き換えについて、説明書の11.2.4章を参考に行ってますが、
>アーカイブ作成した同一の端末へは正常に復元が出来ましたが、
>別のX-1の端末へこのアーカイブを展開したところ、有線LANのコネクションに"Wired connection 1"と"Wired connection 2"が作成されてしまい、LANケーブルを挿すと"Wired connection 2"がDEVICE”eth0”となってしまいます。
>元々のルートファイルシステムアーカイブでは、"Wired connection 1"が"eth0"となっていて、固定IPアドレスの設定に変更していました。
>アーカイブ作成時の除外設定excludes.listはデフォルトから変更していません。
>
>確認したところ、"Wired connection 1"のUUIDがアーカイブ元と同じで、別のX-1の端末とUUIDが異なるため"Wired connection 2"が自動作成されたのかとの推測です。
'Wired connection 2' が作成されたのは、おそらく、UUID が要因ではなく、
/etc/NetworkManager/system-connetions/Wired connection 1
の [ethernet] セクションにある mac-address が要因ではないかと思います。UUID は、同一システム上のコネクション間で重複がなければよく、別の端末で同じ値を使って問題ないはずです：
https://armadillo.atmark-techno.com/forum/armadillo/3367#comment-5674
UUID ではなく、MAC アドレスが要因かどうかは、
/etc/NetworkManager/system-connetions/Wired connection 1
の内容をご覧になってみて下さい。このファイルに次のような行があれば、記載されている MAC アドレスが、別端末の eth0 の MAC アドレスとは異なるために eth0 の設定に反映されず、新たなコネクション（Wired connection 2）を NetworkManager が生成したのでしょう。
[ethernet] mac-address=00:11:0C:xx:xx:xx （※'x' は端末ごとに異なる値） mac-address-blacklist=
>なので/etc/NetworkManager/system-connetions/Wired connection 1を除外リストに加えれば良いかと思いましたが、
>そうすると元のアーカイブの固定IPアドレスの設定が引き継がれなくなりそうです。
>別のUUIDのネットワーク設定に元の固定IPアドレスの設定のみを展開させるようなシステムアーカイブの作成なんて方法はありますでしょうか。
MAC アドレスが要因の場合は、
/etc/NetworkManager/system-connetions/Wired connection 1
にある [ethernet] セクションの mac-address の行を削除すればよいです。このファイルを手作業で編集して当該行を削除するか、または、次のコマンドを実行してみて下さいませ（nmcli が当該行を削除してくれます）：
$ sudo nmcli connection modify 'Wired connection 1' ethernet.mac-address ""
この状態でルートファイルシステムアーカイブを作れば、期待通りに固定 IP アドレスを引き継げるかと思います。
>また、ネットワーク設定は引き継げない(IPアドレス固定化は手動で行う)場合、除外するファイルは上記の/etc/NetworkManager/system-connetions/Wired connection 1のみで良さそうでしょうか。
はい。そのはずです。ちなみに、上記の "Wired connection 2" のコネクション設定ファイルは、
/etc/NetworkManager/system-connetions/
には存在しておらず、
/run/NetworkManager/system-connections/
に存在しているかと思います。こちらのディレクトリは、永続化されておらず、システムの動作中のみ存在しています。
koga
2022年2月13日 9時50分
アットマークテクノの古賀です。
tsatoさん：
>遅くなりましたが、ご回答ありがとうございました。
>まだ実際に試せていないですが、上記方法にて試してみます。
>因みにmac-address-blacklist=の行は残ったままでも差し支え無さそうでしょうか。
>もしくは[ethernet]から3行を全て削除でも良さそうでしょうか。
mac-address-blacklist= の行は、残したままで大丈夫だと思います。ご心配な場合は、
/etc/NetworkManager/system-connetions/Wired connection 1
を手作業で編集せず、以下の手順で nmcli を使って変更してみて下さいませ：
古賀（2022年1月25日 13時31分）：
>…または、次のコマンドを実行してみて下さいませ（nmcli が当該行を削除してくれます）：
$ sudo nmcli connection modify 'Wired connection 1' ethernet.mac-address ""
tsato
2022年3月1日 15時13分
お世話になります。
ようやくシステムアーカイブを作成する機会がありましたので、実際に以下のコマンドを実行してアーカイブを作成してみました。
> >…または、次のコマンドを実行してみて下さいませ（nmcli が当該行を削除してくれます）：
>
> $ sudo nmcli connection modify 'Wired connection 1' ethernet.mac-address "" >
結果、基盤Aで作成したアーカイブを基盤Bに転送したところ、最初から"Wired connection 1"のIPアドレスを固定にすることが出来ましたが、UUIDも基盤Aと同じものとなってしまいました。
UUIDは基盤毎にユニークな文字列でないといけないというルールがあるため、同じUUIDとなるのは都合が悪そうです。
試しに、"/etc/NetworkManager/system-connetions/Wired connection 1.nmconnection"の中のconnection.uuidの行を削除したところ、UUIDは基盤B本来のものらしき文字列に変わりました。
(以下のコマンドではエラー？が発生したため、ファイルの行を直接削除しました)
>
> $ sudo nmcli connection modify 'Wired connection 1' connection.uuid "" >
手順としては結果的にこれで良かったでしょうか。
("Wired connection 1.nmconnection"の中身としては、mac-addressとuuidの項目は永久的に失われますが、nmcliやifconfigのコマンドでは表示されるので差し支えは無さそうということで良いでしょうか)
よろしくお願いします。
at_shinya.koga
2022年3月2日 11時48分
アットマークテクノの古賀です。
tsatoさん：
>ようやくシステムアーカイブを作成する機会がありましたので、実際に以下のコマンドを実行してアーカイブを作成してみました。
>
>>>…または、次のコマンドを実行してみて下さいませ（nmcli が当該行を削除してくれます）：
$ sudo nmcli connection modify 'Wired connection 1' ethernet.mac-address ""
>
>結果、基盤Aで作成したアーカイブを基盤Bに転送したところ、最初から"Wired connection 1"のIPアドレスを固定にすることが出来ましたが、UUIDも基盤Aと同じものとなってしまいました。
>UUIDは基盤毎にユニークな文字列でないといけないというルールがあるため、同じUUIDとなるのは都合が悪そうです。
connection の UUID を、運用上 Armadillo-X1 の個体ごとに違うものにしなければならない、ということなのですね。
>試しに、"/etc/NetworkManager/system-connetions/Wired connection 1.nmconnection"の中のconnection.uuidの行を削除したところ、UUIDは基盤B本来のものらしき文字列に変わりました。
>(以下のコマンドではエラー？が発生したため、ファイルの行を直接削除しました)
$ sudo nmcli connection modify 'Wired connection 1' connection.uuid ""
>手順としては結果的にこれで良かったでしょうか。
そうですね。NetworkManager のリファレンスには明記されていないようですが、 /etc/NetworkManager/system-connections/ にある keyfile (nm-settings-keyfile) に uuid の設定が記載されていない場合は、自動生成するようですから、上記の対応でよいのではないかと思います：
https://people.freedesktop.org/~lkundrak/nm-docs/nm-settings.html
https://people.freedesktop.org/~lkundrak/nm-docs/nm-settings-keyfile.ht…
なお、UUID を NetworkManager が自動生成する場合ですが、MAC アドレスなど、個体（基板）固有の情報を元にして生成するわけではなく、乱数ベースの UUID (UUID Version 4) を生成する仕組みのようです。libnm-util のリファレンスで NMSettingConnection のページにある uuid プロパティの説明を見ると、 nm_utils_uuid_generate() や nm_utils_uuid_generate_from_string() を使って生成すると書かれています：
https://developer-old.gnome.org/libnm-util/stable/NMSettingConnection.h…
NewtorkManager のソースを見ると、nm_utils_uuid_generate() は nm_uuid_generate_random() を呼び出しており、nm_uuid_generate_random() は、UUID Version 4 方式の UUID を生成しています。
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/mai…
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/mai…
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/mai…
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/mai…
結論としては、
>("Wired connection 1.nmconnection"の中身としては、mac-addressとuuidの項目は永久的に失われますが、nmcliやifconfigのコマンドでは表示されるので差し支えは無さそうということで良いでしょうか)
この対応でよいのではないかと思います。
tsato
2021年10月7日 11時39分
お世話になります。
追加情報ですが、dumprootfsのログが出力されてましたので、そちらを添付します。
よろしくお願いします。