テスト [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>704 > いま比較してみましたがOKそう > どのままコピペでもいけそうです おおっ 勝利・友情・愛!www > 今思ったけども、書き換え前に $ sudo cp /mnt/sdb2/@/etc/fstab /mnt/sdb2/@/etc/fstab.org とかしてオリジナルをバックアップしておくと更に良かったかも おれも思った...かも。一瞬。コマンドはわからんけど みなさん、おやすみ これで受け側の@と@homeをマウントしてみて 正常に複製できてるようだったら snap-@とsnap-@homeは 消してしまっていいと思う (送り側のsnapshotはもうしばらく置いといてもいいかも) ----------------------- ここを見落としていた。明日 >>706 マウントもいいがデータ整合性のチェックもしておきましょう ターゲットパーティションを(サブボリュームでもいいので)マウントした状態で、 $ sudo btrfs scrub start ターゲットパーティション $ watch sudo btrfs scrub status ターゲットパーティション (終わったらCtrl+C) こっちでも調べたところ、ハイバネーションのときに どこにデータを退避するかの設定みたいですね こちらの環境でcatしてみたところ RESUME= と値が空白でした ハイバネーションしてなかったから気づかなかった… 完全に環境移行後の書き換えでもいいかもですね 私もハイバネーションは使ってないので「これが適切でないと変なエラー出されるんだろ」くらいの認識しかありませんでした 実際UUIDが違っていると「おまえスワップパーティションのUUID違うじゃねえかコラ」みたいなエラー出されますからね chrootしてgrubインストールの大体の手順はこんな感じかも 652さんのツッコミ待ち 652さんの教えてくれたインストールスクリプトをインストール $ sudo apt install arch-install-scripts ブートローダーインストール用のEFI関係?のカーネルモジュールをロード $ sudo modprobe efivars chrootマウントポイント用の一時ディレクトリを作成 $ sudo mkdir /mnt/chroot ここからは面倒のないように # su - とか # sudo -i とかで rootになってから作業することにすると # mount -o subvol=@ /dev/sdb2 /mnt/chroot # mount -o subvol=@home /dev/sdb2 /mnt/chroot/home # mount /dev/sdb1 /mnt/chroot/boot/efi これで準備完了 >>711 私は似たような事をする時に efivars を明示的にロードしてないんですがいいと思いますよ その方が確実でしょうし あと既にご存知かも知れませんが arch-chroot はこう使います $ sudo arch-chroot ターゲットディレクトリ 実際にchroot # arch-chroot /mnt/chroot grubをインストール sdbのMBRとsdb1以下に書き込まれると思う # grub-install /dev/sdb --bootloader-id Debian11(とかお好みの名前) ほんとにNVRAMにブートエントリーが書き込まれたか確認 # efibootmgr --verbose | grep Debian11(とか上で付けた名前) grubの設定ファイルに変更がなければ要らなそうだけど一応 # update-grub エラーが出なければ完了、chroot環境を抜ける # exit arch-chrootは /dev, /sysとかの類のデバイスファイルを chrootと同時に自動でロードしてくれる…って認識で 合ってるんだろうか…? 手元のメモでは手動で # mount --bind /dev /mnt/chroot/dev # mount --bind /dev/pts /mnt/chroot/dev/pts # mount --bind /proc /mnt/chroot/proc # mount --bind /sys /mnt/chroot/sys とか # for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt/rootfs$i; done ってするようにメモってありました こういうものみたいです chroot - ArchWiki https://wiki.archlinux.jp/index.php/Chroot#arch-chroot_.E3.82.92.E4.BD.BF.E3.81.86 これを使ったchrootでのメンテで不都合を感じたことは私はありませんでした /usr/bin/arch-chroot の実体はただのbashスクリプトなので興味がありましたら何をしてくれるのか読み解くのも面白いかと もっとも、715に書かれた手法がいちばん確実ですがね >>707 > マウントもいいがデータ整合性のチェックもしておきましょう > ターゲットパーティションを(サブボリュームでもいいので)マウントした状態で、 $ sudo mount /dev/sdb2 /mnt/sdb2 $ > $ sudo btrfs scrub start ターゲットパーティション $ sudo btrfs scrub start /dev/sdb2 scrub started on /dev/sdb2, fsid 6f1bbb77-c44c-4e33-9686-de20e121e09c (pid=8099) $ おかしい。一瞬にして終わった。 > $ watch sudo btrfs scrub status ターゲットパーティション (終わったらCtrl+C) Every 2.0s: sudo btrfs scrub status /dev/sdb2 kyo: Tue Nov 23 12:47:40 2021 UUID: 6f1bbb77-c44c-4e33-9686-de20e121e09c Scrub started: Tue Nov 23 12:45:56 2021 Status: running Duration: 0:01:40 Time left: 0:04:05 ETA: Tue Nov 23 12:51:45 2021 Total to scrub: 20.27GiB Bytes scrubbed: 5.86GiB (28.92%) Rate: 60.02MiB/s Error summary: no errors found <<スクラブ中 scrubおわり。おはよー Every 2.0s: sudo btrfs scrub status /dev/sdb2 kyo: Tue Nov 23 12:51:22 2021 UUID: 6f1bbb77-c44c-4e33-9686-de20e121e09c Scrub started: Tue Nov 23 12:45:56 2021 Status: finished Duration: 0:05:13 Total to scrub: 20.27GiB Rate: 66.31MiB/s Error summary: no errors found >>717 > おかしい。一瞬にして終わった。 Btrfs や ZFS のスクラブ(fsckみたいなもん)は進捗状況を見たかったら専用コマンドを使うしか無いんだよ それがこういうの↓ > $ watch sudo btrfs scrub status ターゲットパーティション (終わったらCtrl+C) >>711 > 652さんの教えてくれたインストールスクリプトをインストール > $ sudo apt install arch-install-scripts > > ブートローダーインストール用のEFI関係?のカーネルモジュールをロード > $ sudo modprobe efivars > > chrootマウントポイント用の一時ディレクトリを作成 > $ sudo mkdir /mnt/chroot $ sudo apt install arch-install-scripts arch-install-scripts はすでに最新バージョン (21-1) です。 $ sudo modprobe efivars $ sudo mkdir /mnt/chroot $ >>719 もしかして $ sudo btrfs scrub start /dev/sdb2 scrub started on /dev/sdb2, fsid 6f1bbb77-c44c-4e33-9686-de20e121e09c (pid=8920) $ 最後にドルのマークがついてるけど、終わったのではなく、まさにヤっている状態? かすかにハードディスクがフル回転してる音が聞こえるから >>721 $ sudo btrfs scrub status ターゲットパテ | grep Status $ sudo btrfs scrub status /dev/sdb2 | grep Status Status: finished $ で、ここまでの読み書きで既知のファイルシステムエラーが出ていないか確認 $ sudo btrfs dev stats ターゲットパテ >>712 > ここからは面倒のないように # su - とか # sudo -i とかで おはよう御座います。よろしくおねがいします。以前からずっと疑問。 たとえば # su - と # sudo -i では違いがあるのか?結果は同じに見えるが。 前者は管理者パスワードいる。後者はいらない。 >>724 訓練指導感謝です。よろしくおねがいします。 $ sudo btrfs dev stats /dev/sdb2 [/dev/sdb2].write_io_errs 0 [/dev/sdb2].read_io_errs 0 [/dev/sdb2].flush_io_errs 0 [/dev/sdb2].corruption_errs 0 [/dev/sdb2].generation_errs 0 $ >>726 既知のエラー無し 以後はID:GQJ2ZFSpさんに指導してもらって下さい >>712 > # mount -o subvol=@ /dev/sdb2 /mnt/chroot > # mount -o subvol=@home /dev/sdb2 /mnt/chroot/home > # mount /dev/sdb1 /mnt/chroot/boot/efi > これで準備完了 今からココ。参考ページをググりながら進めてるが、機械翻訳丸投げサイトや、ask ubuntu のような質問・回答サイトしかヒットしない。 今ヤっていることを「教科書的にまとめた」ページはないのかな? そもそも、リナックスというのは、教科書的にまとまった参考ページはめったにない、と考えたほうがいいのか? たとえば https://kledgeb.blogspot.com/2015/11/efibootmgr-1-uefiuefi.html このサイトは「素晴らしくわかりやすく」まとまっていますが。 >>727 はい Btrfsシステムパテのシステムクローン、それもBtrfsモードのtimeshiftを使ってるシステム こんな新しめの構成、検索したって出てこないと思ったほうが良い > su -とsudo -i これは実行結果から言えば変わらないけど、 前者は直接rootでログインするのに対して 後者はsudoを使ってログインするので若干行儀が良いかも? sudo -i の方は、/etc/sudoers* とかのファイルの設定で rootのパスワードではなくログイン中ユーザーの パスワードでroot権限を実行するのと、 あと、sudoだとsudoを実行したログが残るはず $ sudo -i # mount -o subvol=@ /dev/sdb2 /mnt/chroot # ---------------------- なぜ、/mnt/chroot をマウントポイントにして /dev/sdb2 をマウントするんだろう? なぜ、こんなことしないといけないんだろう? >>731 > sudo -i の方は、/etc/sudoers* とかのファイルの設定で rootのパスワードではなくログイン中ユーザーの パスワードでroot権限を実行する << 「/etc/sudoersの設定」 が最悪の結果をまねかないための防御癖になってるのかな?みたいに イメージしました https://www.guri2o1667.work/entry/2020/10/25/%E3%80%90RHEL8%E3%80%91sudo%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%A8/etc/sudoers%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 例えば、一般ユーザにログインしている際に、 rootユーザでしか実行できないコマンドやファイル操作をしたい場合、以下の2つの方法が考えられます。 @ rootユーザにスイッチ A そのコマンドだけrootユーザとして実行 @についてはrootユーザの権限をそのまま渡すことになるため、実行したいコマンド以外にも好き勝手出来てしまい、好ましくない場合があります。(rootユーザのパスワードを教えることにもなります。) Aの方法を採用することで、rootパスワードを必要とせず、あらかじめ定義したコマンドのみの操作を許可することができます。 sudoコマンドはAの方法に該当します。 $ sudo -i # mount -o subvol=@ /dev/sdb2 /mnt/chroot # mount -o subvol=@home /dev/sdb2 /mnt/chroot/home # mount /dev/sdb1 /mnt/chroot/boot/efi # chrootは、うまく言えないけどオンメモリのデータを保持して ハードウェア環境もそのままで、ファイルシステムだけ 一時的に別のファイルシステム上とそっくり そのまま入れ替える感じとかかな… ブラックジャック先生の超絶手技で、意識を保ったまま ブタの頭をヤギの胴体と一時的にすげ替えて手術する感じ…とか >>732 実はDebianやUbuntu等のインストーラは裏でchrootを駆使してシステム設定している よって今やってる事の数々は言ってしまえば「人力インストーラ」みたいなもん >>735 > ブラックジャック先生の超絶手技で、意識を保ったまま > ブタの頭をヤギの胴体と一時的にすげ替えて手術する感じ…とか 治療の目的は、いまの場合「grubの再インストール」? >>736 > 実はDebianやUbuntu等のインストーラは裏でchrootを駆使してシステム設定している よって今やってる事の数々は言ってしまえば「人力インストーラ」みたいなもん chroot というのは、特殊なアイテムではなく、使用頻度極高 の必須アイテム? >>738 chroot が必要になる場面 ・今回の様に別ストレージをシステムとして起こす時 ・ブートしなくなった時などのライブメディアからのメンテ ・ビルド依存パッケージ等で既存環境に余計なものを入れたくない時 (Debian系・Ubuntu系はdebootstrapで簡単にchroot環境を作れる) など 自分はブート関係いじるときの他は あんまり意識して使うことはないですね chroot地獄とかのテクニックは聞いたことだけはあるけど Linuxディストリのインストーラーだけじゃなくて、 Windowsのインストーラーも回復コンソールモードとかでは USBディスク上のファイルシステムからブートして ブートエントリいじったりとか でもこれはchrootというよりマルチブートな感じかも >>738 > ・ビルド依存パッケージ等で既存環境に余計なものを入れたくない時 JDimのビルド環境を作った時の事を思い出してごらん >>743 消したタイミングがタッチの差だった模様 大した意味の無いもの その前のやつはID:GQJ2ZFSpさん用なので見なくても問題ない >>740 > 自分はブート関係いじるときの他は > あんまり意識して使うことはないですね ID:GQJ2ZFSpさんですら、これくらいの理解でいいのですね!安心した > chroot地獄とかのテクニックは聞いたことだけはあるけど chroot jail 、chroot監獄です。chroot地獄のほうがかっこいいけどww 言葉は知ってるけど、じっさいにコマンドでやるときは、まったく使えない... Windowsといえば、メーカー製ノートのプリインストールウイン10をかんぺきに消し尽くして、 どんな方法でもいいから、マイクロソフト純正まざりっけなし、に入れ替える方法をいつか知りたい。 >>741 > > ・ビルド依存パッケージ等で既存環境に余計なものを入れたくない時 > JDimのビルド環境を作った時の事を思い出してごらん もちろん憶えてます。じつはアレを消したいが消し方がわからなくて放置。なかにJDimのビルド環境存在してるし、消していいのかもわからんし。 なぜ消したいかというと、1.9GB消費してるからです。 >>746 今はID:GQJ2ZFSpさんの教えに従い予備環境の構築に集中なさい。 >>739 > chroot が必要になる場面 > ・今回の様に別ストレージをシステムとして起こす時 (起動可能の)システムとして起こす時ですね?ということは、send | rec や btrfs に限らず、 必要なんだね? > ・ブートしなくなった時などのライブメディアからのメンテ これ難しい。今年の初めひとりで2ヶ月がんばったけど、できなかったやつだ。 > ・ビルド依存パッケージ等で既存環境に余計なものを入れたくない時 これはhdd領域を2ギガ費消しても、やる価値があったのか?トレードオフ的観点から見て。 > (Debian系・Ubuntu系はdebootstrapで簡単にchroot環境を作れる) はい。 $ sudo -i # mount -o subvol=@ /dev/sdb2 /mnt/chroot # mount -o subvol=@home /dev/sdb2 /mnt/chroot/home # mount /dev/sdb1 /mnt/chroot/boot/efi # まで終わっています > send | rec や btrfs に限らず、必要なんだね? なんせ「人力インストーラ」ですから > やる価値があったのか? 散々環境を汚したくないってゴネてたでしょうよ なんかおふたりとも前からの知り合い…? 仲良さそうとも見えたり あと残りはほんの少しぐらいだと思う 手順は>>714 で合ってると思うけど、 arch-chrootは実際には試してないので想像です もしうまくいかなかったら # arch-chroot /mnt/chroot の代わりに>>715 の # mount --bind 〜〜 ってのを4つともやってから # chroot /mnt/chroot でもいけると思う >>752 まあちょっとした事がありまして 故に環境を知り過ぎている部分があるので傍から見たら自演に見えなくも無いでしょう と言う事でID:GQJ2ZFSpさんの補佐に戻ります >>752 > あと残りはほんの少しぐらいだと思う > 手順は>>714 で合ってると思うけど、 > arch-chrootは実際には試してないので想像です ああ、もうすでに出ていたとは気づかなかった。まだかなあ、まだかなあとゲームして待って、疲れた。 すいません!1時間以上きゅうけいさせて >>755 はじめての事だらけで結構テンパってるでしょ 一時間と言わず夕食後くらいまで英気を養うといいよ 何かシステム上で大きな変更したり、規模のでかい パッケージをインストールする前とかは ファイルシステムごとイメージバックアップとかで 戻れるようにしとくといいかもですね ましてやBtrfsにはスナップショットって強力な上 手軽な機能が備わってるんだし…! その点では btrfs send スナップショット > ファイル化したスナップショット名 をマスターすればほぼ敵無しですね まあいっぺんに覚えようとすると脳みそ爆発するでしょうからいずれまた、と言う事で >>749 そうそう 今後JDimはsnap版を使うと良い snapはちょっと胡散臭い噂もあるけどあくまで噂に過ぎないと俺は思ってる ビルドいらずなのでこれを使えばもうビルド環境なんか処分しても構わない シャットダウン時に、速く流れて読み取れませんが、赤字で /dev/disk/by-id/ なんたらという メッセージが出ます。UUID を書き換えてから、出るようになりました。助けてっ $ ls -lA /dev/disk/by-id/ 合計 0 lrwxrwxrwx 1 root root 9 11月 23 23:40 ata-HGST_HTS545032A7E680_RB240EMP06TZHH -> ../../sdb lrwxrwxrwx 1 root root 10 11月 23 23:40 ata-HGST_HTS545032A7E680_RB240EMP06TZHH-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 11月 23 23:40 ata-HGST_HTS545032A7E680_RB240EMP06TZHH-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 11月 23 23:41 ata-HGST_HTS545032A7E680_RB240EMP06TZHH-part3 -> ../../sdb3 lrwxrwxrwx 1 root root 9 11月 23 23:40 ata-ST3160815AS_6RX65VV6 -> ../../sda lrwxrwxrwx 1 root root 10 11月 23 23:40 ata-ST3160815AS_6RX65VV6-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 11月 23 23:40 ata-ST3160815AS_6RX65VV6-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 11月 23 23:40 ata-ST3160815AS_6RX65VV6-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 11月 23 23:40 wwn-0x5000cca7fdc31803 -> ../../sdb lrwxrwxrwx 1 root root 10 11月 23 23:40 wwn-0x5000cca7fdc31803-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 11月 23 23:40 wwn-0x5000cca7fdc31803-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 11月 23 23:41 wwn-0x5000cca7fdc31803-part3 -> ../../sdb3 $ あれ、fstabのUUIDは新環境 =sdb2 =ST3160815AS 側の UUIDを書き換えたんじゃなかったでしょうか…? そうなら、移行前の現環境には影響ないはず… $ lsblk -f と $ cat /etc/fstab を出力して、 その内容が食い違ってないか見てみるのはどうでしょう…? あと、/var/log/syslog とかのログファイルを読んでみて ディスク関係のエラー出力はないでしょうか >>760 やるべき事 1. レスを読み返して教わった事と自分のやった事を照合する 2. ソースとターゲットのfstabは適切か確認 3. もしここに書いていない事をやらかしたなら正直に書く ものすごい大不調(やる気がなくなり、ストレス)そのほかで今からです。 ごめんなさい。 >>761 > あれ、fstabのUUIDは新環境 =sdb2 =ST3160815AS 側の > UUIDを書き換えたんじゃなかったでしょうか…? たしかに書き換えました。しかしバックアップを取れなかった。 > そうなら、移行前の現環境には影響ないはず… そ、そうなのですか? > $ lsblk -f と $ cat /etc/fstab を出力して、 > その内容が食い違ってないか見てみるのはどうでしょう…? $ lsblk -f NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT sda ├─sda1 vfat EFI 7AF2-9C57 176.6M 6% /boot/efi ├─sda2 btrfs debian cf82c300-5af6-45d6-a682-1e93b9105cae 268.6G 7% /run/timeshift/backup └─sda3 swap 1297b83d-2c7b-42c4-bc86-9e7d44b87603 [SWAP] # / was on /dev/sda2 during installation UUID=cf82c300-5af6-45d6-a682-1e93b9105cae / btrfs defaults,noatime,subvol=@ 0 0 # /home was on /dev/sda2 during installation UUID=cf82c300-5af6-45d6-a682-1e93b9105cae /home btrfs defaults,noatime,subvol=@home 0 0 # /boot/efi was on /dev/sda1 during installation UUID=7AF2-9C57 /boot/efi vfat umask=0077 0 1 # swap was on /dev/sda3 during installation UUID=1297b83d-2c7b-42c4-bc86-9e7d44b87603 none swap sw 0 0 --------------------------- << 完璧に合致しとります! > あと、/var/log/syslog とかのログファイルを読んでみて > ディスク関係のエラー出力はないでしょうか $ sudo cat /var/log/syslog 略 Nov 24 23:37:26 kyo systemd[1]: packagekit.service: Succeeded. 略 ログが多すぎて分析できない $ journalctl -p 3 -- Logs begin at Wed 2021-11-24 16:30:52 JST, end at Wed 2021-11-24 23:42:46 JST. -- 11月 24 16:30:53 kyo kernel: kvm: disabled by bios 11月 24 16:30:53 kyo kernel: kvm: disabled by bios 11月 24 16:30:53 kyo kernel: kvm: disabled by bios 11月 24 16:30:54 kyo systemd-udevd[283]: Error running install command for rtlwifi 11月 24 23:32:06 kyo wpa_supplicant[646]: dbus: wpa_dbus_property_changed: no property SessionLength in object 11月 24 23:32:16 kyo [7287]: /usr/lib/systemd/system-sleep/xkeyboard failed with exit status 1. 11月 24 23:32:16 kyo wpa_supplicant[646]: dbus: wpa_dbus_property_changed: no property SessionLength in object lines 1-8/8 (END) >>762 > 3. もしここに書いていない事をやらかしたなら正直に書く むき出しの動作してるマザー上に、キーボードとマウスを落っことして、衝撃で メモリが浮いたのか?または損傷を受けたのか?しばらく2ギガしか認識できなかった。 その後メモリ交換で直った。 2. ソースとターゲットのfstabは適切か確認 ソースは適切と確認。 ......... いま、熱い夫婦交換で接続 sdb ├─sdb1 │ vfat EFI 8C89-6ED3 ├─sdb2 │ btrfs debian │ 6f1bbb77-c44c-4e33-9686-de20e121e09c └─sdb3 swap 8c4db4b1-849e-4ba6-ba65-05727e3ece8b $ マウントしてなかったので、マウント $ sudo mount /dev/sdb2 /mnt/sdb2 $ sudo pluma /mnt/sdb2/@/etc/fstab # / was on /dev/sda2 during installation UUID=6f1bbb77-c44c-4e33-9686-de20e121e09c / btrfs defaults,noatime,subvol=@ 0 0 # /home was on /dev/sda2 during installation UUID=6f1bbb77-c44c-4e33-9686-de20e121e09c /home btrfs defaults,noatime,subvol=@home 0 0 # /boot/efi was on /dev/sda1 during installation UUID=8C89-6ED3 /boot/efi vfat umask=0077 0 1 # swap was on /dev/sda3 during installation UUID=8c4db4b1-849e-4ba6-ba65-05727e3ece8b none swap sw 0 0 ----------------------------------------- 目標駆動器もすべて正しいことをかっくにん! >>757 > 何かシステム上で大きな変更したり、 apt と関係ない重要変更でやらかします。その場合、timeshift ではないbtrfs そのものの操作がわかっていれば、対応できるのだが?? > 規模のでかい > パッケージをインストールする前とかは これは自動化されてるのでだいじょうぶですが > ファイルシステムごとイメージバックアップとかで > 戻れるようにしとくといいかもですね > ましてやBtrfsにはスナップショットって強力な上 > 手軽な機能が備わってるんだし…! (このカキコを起点にやってまいります。) >>758 > その点では btrfs send スナップショット > ファイル化したスナップショット名 をマスターすればほぼ敵無しですね > まあいっぺんに覚えようとすると脳みそ爆発するでしょうからいずれまた、と言う事で では、だいぶ以前に示してもらった(本番命令を実行) >>712 > ここからは面倒のないように # su - とか # sudo -i とかで > rootになってから作業することにすると > # mount -o subvol=@ /dev/sdb2 /mnt/chroot > # mount -o subvol=@home /dev/sdb2 /mnt/chroot/home > # mount /dev/sdb1 /mnt/chroot/boot/efi > これで準備完了 # mount -o subvol=@ /dev/sdb2 /mnt/chroot # mount -o subvol=@home /dev/sdb2 /mnt/chroot/home # mount -o /dev/sdb1 /mnt/chroot/boot/efi # mount /dev/sdb1 /mnt/chroot/boot/efi # >>714 実際にchroot # arch-chroot /mnt/chroot # arch-chroot /mnt/chroot root@kyo:/# grubをインストール sdbのMBRとsdb1以下に書き込まれると思う # grub-install /dev/sdb --bootloader-id Debian11(とかお好みの名前) ------------------------------ エラーです! root@kyo:/# grub-install /dev/sdb --bootloader-id Debian10 Installing for x86_64-efi platform. grub-install: warning: Cannot set EFI variable Boot0003. grub-install: warning: efivarfs_set_variable: writing to fd 6 failed: デバイスに空き領域がありません. grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: デバイスに空き領域がありません. grub-install: エラー: failed to register the EFI boot entry: デバイスに空き領域がありません. root@kyo:/# こんばんは、そのwarningやエラーをそのまま読むなら /dev/sdb1かそこらの容量がおかしいということになりますね マウント状態と、現在のブートエントリーの状態が 気になりますので、別のターミナルウィンドウを開いた状態で $ df -h $ sudo efibootmgr とか打ってどう表示されるか見てもらえます…? あと、 $ mount | grep /sd の出力も貼ってもらえるとマウントオプションとかも 確認できていいかもです お世話になります。夜中にすいません。 $ df -h ファイルシス サイズ 使用 残り 使用% マウント位置 udev 1.8G 0 1.8G 0% /dev tmpfs 367M 5.8M 361M 2% /run /dev/sda2 296G 23G 269G 8% / tmpfs 1.8G 0 1.8G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup /dev/sda2 296G 23G 269G 8% /home /dev/sda1 188M 11M 177M 6% /boot/efi tmpfs 367M 36K 367M 1% /run/user/1000 /dev/sda2 296G 23G 269G 8% /run/timeshift/backup /dev/sdb2 148G 21G 126G 14% /mnt/sdb2 /dev/sdb2 148G 21G 126G 14% /mnt/chroot /dev/sdb2 148G 21G 126G 14% /mnt/chroot/home /dev/sdb1 511M 3.3M 508M 1% /mnt/chroot/boot/efi shm 1.8G 0 1.8G 0% /mnt/chroot/dev/shm tmp 1.8G 0 1.8G 0% /mnt/chroot/tmp $ sudo efibootmgr BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0000,0001,0002 Boot0000* debian Boot0001* Hard Drive Boot0002* UEFI: Built-in EFI Shell $ mount | grep /sd /dev/sda2 on / type btrfs (rw,noatime,space_cache,subvolid=4420,subvol=/@) /dev/sda2 on /home type btrfs (rw,noatime,space_cache,subvolid=4419,subvol=/@home) /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) /dev/sda2 on /run/timeshift/backup type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/) /dev/sdb2 on /mnt/sdb2 type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/) /dev/sdb2 on /mnt/chroot type btrfs (rw,relatime,space_cache,subvolid=281,subvol=/@) /dev/sdb2 on /mnt/chroot/home type btrfs (rw,relatime,space_cache,subvolid=282,subvol=/@home) /dev/sdb1 on /mnt/chroot/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) /dev/sda2 on /mnt/chroot/etc/resolv.conf type btrfs (rw,noatime,space_cache,subvolid=4420,subvol=/@) $ >>753 > もしうまくいかなかったら > # arch-chroot /mnt/chroot > の代わりに>>715 の > # mount --bind 〜〜 > ってのを4つともやってから > # chroot /mnt/chroot > でもいけると思う ----------------------------- >>715 > arch-chrootは /dev, /sysとかの類のデバイスファイルを > chrootと同時に自動でロードしてくれる…って認識で > 合ってるんだろうか…? > > 手元のメモでは手動で > # mount --bind /dev /mnt/chroot/dev > # mount --bind /dev/pts /mnt/chroot/dev/pts > # mount --bind /proc /mnt/chroot/proc > # mount --bind /sys /mnt/chroot/sys > とか > # for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt/rootfs$i; done > ってするようにメモってありました << (我)以上を試していません。 いまから 開始。 # arch-chroot /mnt/chroot root@kyo:/# grub-install /dev/sdb --bootloader-id Debian10 Installing for x86_64-efi platform. grub-install: warning: Cannot set EFI variable Boot0003. grub-install: warning: efivarfs_set_variable: writing to fd 6 failed: デバイスに空き領域がありません. grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: デバイスに空き領域がありません. grub-install: エラー: failed to register the EFI boot entry: デバイスに空き領域がありません. root@kyo:/# ----------------------------------------- 以上の変更を加えてしまったのを、どうやって無かったことにして、 > # mount --bind 〜〜 > ってのを4つ を走らすことができますかっ? 見ました。ファイルシステムは正常にマウントされてる気がしますね… chrootした方のターミナルはまだその状態でしょうか そっちのターミナルで # ls -la /dev/ /proc/ /sys/ って打ったら何かずらずらとデバイスファイルが表示されますか? >>780 > chrootした方のターミナルはまだその状態でしょうか > そっちのターミナルで > # ls -la /dev/ /proc/ /sys/ > って打ったら何かずらずらとデバイスファイルが表示されますか? 略 dr-xr-xr-x 9 jin jin 0 11月 24 18:10 1074 dr-xr-xr-x 9 jin jin 0 11月 24 16:31 1084 dr-xr-xr-x 9 jin jin 0 11月 24 18:10 1088 dr-xr-xr-x 9 jin jin 0 11月 24 17:35 1092 略 /sys/: 合計 0 dr-xr-xr-x 13 root root 0 11月 25 02:09 . drwxr-xr-x 1 root root 300 11月 22 23:38 .. drwxr-xr-x 2 root root 0 11月 24 17:00 block drwxr-xr-x 31 root root 0 11月 24 17:00 bus drwxr-xr-x 50 root root 0 11月 24 17:00 class drwxr-xr-x 4 root root 0 11月 24 17:00 dev drwxr-xr-x 17 root root 0 11月 24 16:30 devices drwxr-xr-x 6 root root 0 11月 24 16:30 firmware drwxr-xr-x 6 root root 0 11月 24 16:30 fs drwxr-xr-x 2 root root 0 11月 24 17:35 hypervisor drwxr-xr-x 12 root root 0 11月 24 16:30 kernel drwxr-xr-x 140 root root 0 11月 24 18:12 module drwxr-xr-x 2 root root 0 11月 24 18:32 power root@kyo:/# はい、ずらずら あと、chrootした方のターミナルで # ls -la /boot/efi/ # mkdir /boot/efi/EFI/ && touch /boot/efi/EFI/testfile.test && rm /boot/efi/EFI/testfile.test ってしてみて、エラーは出ないか見てもらえますか root@kyo:/# ls -la /boot/efi/ 合計 8 drwxr-xr-x 3 root root 4096 11月 25 00:30 . drwxr-xr-x 1 root root 472 10月 13 08:44 .. drwxr-xr-x 3 root root 4096 11月 25 00:30 EFI root@kyo:/# mkdir /boot/efi/EFI/ && touch /boot/efi/EFI/testfile.test && rm /boot/efi/EFI/testfile.test mkdir: ディレクトリ `/boot/efi/EFI/' を作成できません: ファイルが存在します root@kyo:/# コマンド見直しましたけど、もしかしたら grub-installのときに "--recheck" オプションが必要だったのかも…? # grub-install /dev/sdb --bootloader-id Debian11 もう一度試しに↑これを↓こう # grub-install --recheck /dev/sdb --bootloader-id Debian11 して実行してみて下さい これで無理だったらもう明日に持ち越しですね… # arch-chroot /mnt/chroot root@kyo:/# grub-install /dev/sdb --bootloader-id Debian10 Installing for x86_64-efi platform. grub-install: warning: Cannot set EFI variable Boot0003. grub-install: warning: efivarfs_set_variable: writing to fd 6 failed: デバイスに空き領域がありません. grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: デバイスに空き領域がありません. grub-install: エラー: failed to register the EFI boot entry: デバイスに空き領域がありません. root@kyo:/# ----------------------------------------- 以上の変更を加えてしまったのを、どうやって無かったことにして、 # grub-install --recheck /dev/sdb --bootloader-id Debian10 を実行するのですか? > これで無理だったらもう明日に持ち越しですね… はい。深夜にお付き合いいただき感謝。 スナップショットなら今日午後3時のモノなどありますが。 慎重を期すために明日また。ID:nM6oTh5vさん、いつも親切にありがとうございます。 目標ドライブを切断します。 多分だけど、エラーが出てまだ何も書き込まれていない 状態だと思います そのまま実行してもらっても大丈夫かと… 同じエラーで失敗したら、終了は普通に電源を切っても いいと思います あと一点、さっきのコマンドの最初の&&以降だけで # touch /boot/efi/EFI/testfile.test && rm /boot/efi/EFI/testfile.test だけならエラーは出ないかも見てもらえますか ではお休みなさい >>789 昨日の晩の手順を私なりに再現してみました わざわざ仮想マシンまで準備するのは面倒だったんでループデバイスにdebootstrapした環境ですが https://i.imgur.com/udrhDDi.png ID:nM6oTh5vさんのご教示は問題無いと思います 今のところ彼所有ターゲットドライブのハードウェア由来によるトラブルでは、と思っております sdb1パーティションの属性に"boot,efi"フラグは正常に設定されているか chrootした状態で / , /boot, /boot/efi 以下の状態はどうなっているか chrootした状態で / , /boot, /boot/efi 上に書き込みができるか とかが気になりますね… エラーメッセージの "grub-install cannot set efi variable" で 検索したら、 ・BIOS(UEFI)の設定が違っている(いったんSecureBootを切るとかで試す) ・マザーボードのBIOS(UEFI)のバージョンが古い ・grub-efiパッケージがおかしい(chroot先で # apt install --reinstall grub-efi) ・/sys/firmware/efi/efivars がロードされていない とかがヒットしましたので、この辺を検証すると解決するかも FAT32フォーマットのスマホSDカードが死にかけてる時に容量エラーが出ることはありましたね その度にddrescueで助ける際不良セクタの山が発覚すると言う 我々の手元には不良HDDが無いので何とも言えないところですが 適切な作業を心掛ける事により切り分けしやすくなるでしょうな ハードウェア不良とか由来のエラーとかがあると 切り分けが確かにすごく難しくなりますね… 今回はなんとなくディスク不良とかではないような 気もしますが…根拠なく もうひとつそれっぽいエラー報告が見つかった https://unix.stackexchange.com/questions/379774/grub-installation-failed#answers-header # mount -t efivarfs efivarfs /sys/firmware/efi/efivars これでエラーが出るので、/sys/firmware/efi/efivars/dump-* って 不要なダンプを消してから同じmountコマンドを再実行して update-grubを先に実行、そしてgrub-installをしたら 成功したってことみたい まあ船頭はひとりの方がわかりやすいと思うので彼にはID:nM6oTh5vさんのご教示に沿って頂きましょう なお普段は私も update-grub してから grub-install してますね Root on ZFS の作り方サイトでgrubの人力処置に触れた際その手順で覚えてしまっているので >>794 それもID:nM6oTh5vさん用だったので別に見る必要なし 「俺は手順にざっと従ったら成功したが」というやつなので ID:nM6oTh5vさんのご教示に沿って作業してね 全体の流れが見えなくなってきて 大段第一 ファイルシステムの移行 とすると、大段第二は なんの作業をしたと記録すればよいか? ひとことでいうと。 (UUIDの書き換え)ですか? >>797 俺は今回Btrfs特有の操作に関してID:nM6oTh5vさんの補佐をする係なので以後多くは書かないからね UUIDはおそらく間違ってないかと思うけども、 いろいろ気になる点が出てきましたので 各種出力を見せてもらえるとありがたいかもです 関係ないと思うけど、今回はarch-chrootの代わりに # mount --bind /dev /mnt/chroot/dev # mount --bind /dev/pts /mnt/chroot/dev/pts # mount --bind /proc /mnt/chroot/proc # mount --bind /sys /mnt/chroot/sys # chroot /mnt/chroot ってやってみてください ・一応移行先環境での/etc/fstabの再確認 $ cat /mnt/chroot/etc/fstab ・lsblkで前に確認した不良セクタ関係3項目の値は増えていないか $ sudo lsblk -a /dev/sdb ・grub-efiのパッケージのインストール状態とバージョン $ apt list --installed grub-efi ・chrootした状態で / , /boot, /boot/efi とか以下はどうなっているか # ls -la / /boot/ /boot/efi/ /sys/firmware/efi/efivars/ ・chrootした状態で /, /boot/efi 以下に書き込みできるか # mkdir -v /--TEST1-- ; rmdir -v /--TEST1-- # mkdir -v /boot/efi/--TEST2-- ; rmdir -v /boot/efi/--TEST2-- ・マザーボードのBIOSのバージョンと設定 マザボの型番とBIOSバージョンを教えてもらえると何かわかるかも それと切り分けで念のためにセキュアブートはOFFにしてあるか → ONの状態なら成功するまで一時的にOFFにする、とか 勘違い、 $ sudo lsblk -a /dev/sdb じゃなくて $ sudo smartctl -a /dev/sdb でした >>801 受け側のsdb2をマウント $ sudo mount /dev/sdb2 /mnt/sdb2 $ sudo apt install arch-install-scripts ブートローダーインストール用のEFI関係?のカーネルモジュールをロード $ sudo modprobe efivars chroot監獄内におけるマウントポイント用の一時ディレクトリを作成 $ sudo mkdir /mnt/chroot 下準備 $ sudo -i # mount -o subvol=@ /dev/sdb2 /mnt/chroot # mount -o subvol=@home /dev/sdb2 /mnt/chroot/home # mount /dev/sdb1 /mnt/chroot/boot/efi ------------------- 準備として以上をすでにやっていますが、どうしましょう? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる