ArchLinuxオフライン疑似インストールステップバイステップ

数日前、ホームインストールを行うためにArchLinuxISOをダウンロードしました。 以前、CDから少なくとも最小限のデータベースをインストールできる他のディストリビューションを使用していたので、同様のことをしたかったのですが、不思議なことに、Archのインストールプロセスは、インターネットにアクセスできないコンピューター用に設計されていません（開発者の副作用最初の世界で）。

私の場合、ディスクにはすでにWindows 7（ブートパーティションとシステムパーティション）とFedora（スワップと専用/ブートパーティション）があります。 そのときのアイデアは、プロセスでWindowsを破壊することなく、Fedoraが以前あった場所にArchをインストールすることでした。

ArchLinuxオフライン疑似インストール

さて、私はArch CDから起動し、x86_64を選択しましたが、あまり苦労せずにコンソールに残りました。 「うわー、これらの人たちは新人ディストリビューションではないことに真剣に取り組んでいます...さて、一緒に遊んで、何が起こるか見てみましょう」と私は思いました。

ドキュメントがあるかどうかを確認するディレクトリをリストしましたが、基本的なインストールガイドが記載されたテキストが実際にあることがわかりました。 私は関連するものを一枚の紙に書き（私は家にプリンターを持っていません）、仕事に取り掛かりました。

私が最初にしたことは、キーボードのレイアウトをスペインからスペイン語に変更することでした。これは予想よりも簡単でした（不思議なことに私たちのアクセントと呼ばれることさえあります）。

loadkeys es

次のことは、問題が発生した場合にMBRのコピーを保存するために外部ディスクをマウントし、偶然に私のFedoraにあった重要な情報を保存することでした。

mkdir -p / mnt / tmp1 && mount / dev / sdb1 / mnt / tmp1 dd if = / dev / sda of = / mnt / tmp1 / mbr.bin bs = 512 count = 1

幸い、ArchのLiveCDはNTFSをサポートしており、 真夜中のコマンダー （MC）だから、すぐに残りの情報の保存を終えました。

次に、ディスクをアンマウントし、一時ディレクトリを削除し、外部ディスクを物理的に削除して、潜在的な「カガストロフ」のリスクを軽減しました。

umount /mnt/tmp1 && rmdir /mnt/tmp1

そこで、パーティションをフォーマットし、ルートパーティションとブートパーティションをマウントして、スワップをオンにしました。

mkfs -t ext4 / dev / sda3 mkfs -t ext4 / dev / sda6 mount / dev / sda6 / mnt mkdir -p / mnt / boot mount / dev / sda3 / mnt / boot swapon / dev / sda5

次のステップは私の最初のハードルでした：

pacstrap /mnt base

Archは当然、ミラーのXNUMXつでリポジトリデータベースを探しようとしましたが、すべてを見つけることができませんでした。 パックストラップ / mntにディレクトリ構造を作成し、非常に整理されていましたが、明らかに空でした。

電話で、Archを使用している数人の友人に、インターネットにアクセスせずに、少なくともLiveCDにあるのと同じパッケージをインストールする方法がなく、リポジトリをディスクにコピーしないかどうかを尋ねたところ、少なくとも彼らはそれを行う方法を知りませんでした。

技術的な「チャレンジ」が面白いと思ったので、「ArchがLiveCDモードでログインできれば、少なくとも同じモードでハードドライブにインストールできるはずだ」と思ったので、手動でファイルをコピーしてみました。チュートリアルの残りの部分（奇妙な小さな変更を加えたもの）に従って、何が起こったかを確認します。

rsync -avl / {binなど、home、lib、lib64、opt、root、sbin、srv、usr、var} / mnt arch-chroot / mnt genfstab -p / >> / etc / fstab echo hpc> / etc /ホスト名ln-sf / usr / share / zoneinfo / Cuba / etc / localtime locale-gen

次のステップは私の次のハードルでした：

mkinitcpio -p linux

コマンドマニュアルとファイルの内容を読んだ後、このコマンドはいくつかのエラーを生成しました /etc/mkinitcpio.conf y /etc/mkinitcpio.d/linux.preset、コマンドがファイルを見つけられなかったことを理解しました vmlinuz-linux、そこでCtrl + Dを押してchroot環境を終了し、次のようなファイルを探しました。

find / -type f -iname "*vmlinuz*"

ArchのLiveCDがディレクトリの下にブートファイルをマウントすることが起こります /実行/、だから私はそれらを自分のにコピーすることにしました / boot / それらを私のchroot環境内で便利にするために：

cp /run/archiso/bootmnt/arch/boot/[memtest,intel_ucode.img} / mnt / boot / cp / run / archiso / bootmnt / arch / boot / x86_64 / * / mnt / boot / arch-chroot / mnt

mkinitcpioを試してみた別のエラーとして、ルートパーティションのラベルが見つからなかったため、コマンドで使用するUUID（blkidコマンドを使用して識別）を書き留めました。これは最終的に次のようになります。

mkinitcpio -p linux -k /boot/vmlinuz root=UUID=d85938aa-83b8-431c-becb-9b5735264912

今回はビルドが正常に終了し、モジュールの警告がいくつか見つかりませんでしたが、私の場合は必要ありませんでした。 念のため、fstabを再生成しましたが、今回はUUIDを指定します。

genfstab -U -p / > /etc/fstab

私は思った：まあ、ついに進歩。 そして、パスワードを変更してブートローダーをインストールしました。

passwd grub-install --target = i386-pc --recheck / dev / sda grub-mkconfig -o /boot/grub/grub.cfg

最後に、整然と、Ctrl + Dをもう一度押して、chrootされた環境を終了し、すべてを逆アセンブルして再起動し、何が起こったかを確認しました。

umount / mnt / boot umount / mnt再起動

コンピュータが再起動し、ArchでGrubメニューが表示されたので（Windowsはどこにも表示されませんでした）、それを選択すると、次のコマンドで確認する必要があるエラーが発生したことがシステムに示されるまで、すべてが正常に読み込まれているように見えました。

journalctl -xb

エラーを分析すると、ほとんどが無視できることがわかりましたが、最後のエラーは異常で、プリマウスが見つからなかったことがわかりました。

私はすぐに思った、「プリマス??? なぜコンソールブート環境にこのようなものが必要なのですか？ それは言うのはあまりキスではないようです。 私は確かにそれを置いていませんし、私もそれを必要としません。」

しかし、実用的であるために、私は考えました：「まあ、しかし、少なくともそれはいくつかのファイルで参照されるべきです、見てみましょう...」：

find /etc -type f -print0 | xargs -0 grep -i "plymouth"

驚いたことに、「plymouth」というテキスト文字列のファイルが構成ディレクトリに表示されませんでした。 私はその時考えました：«ああ、それで…あなたは私と一緒にあなた自身を強制しますか？ 次に、「大砲」（キューバで言うように）と「私が作った」プライマウスを最初からどのように吸収するかを見てみましょう。

vi / usr / bin / plymouth chmod 755 / usr / bin / plymouth

私がそのファイルに何を入れたか疑問に思っている人のために、ここにその輝かしい全体の内容があります：

＃！ / bin / sh exit

いくつかのエラーを予期して再起動しましたが...驚くべきことに、systemdは起動プロセスを終了し、さらに遅れることなくコンソールに残ったため、この「必須コンポーネント」を見つけて喜んでいました。 自分の目を信じることができなかったので、プリマスを「アンインストール」して再起動し、何が起こったのかを確認することにしました。

rm -fr / usr / bin / plymouth再起動

不思議なことに、今回はプリマスの不在で私をさらに悩ませることなく、システムは静かに起動しました。 （コメント無し）

GRUBへのWindowsの追加

その後、WindowsエントリをGRUBに追加する必要がありました。 従来のルートが機能しなかったため（ grub-mkconfig とともに os プローバー うまく機能していないようです）、エントリを手動で作成することにしました。そのために、Windowsブートローダー文字列とブートパーティションのUUIDを検出する必要がありました。

mkdir -p / mnt / winboot && mount / dev / sda1 / mnt / winboot grub-probe --target = Hints_string / mnt / winboot / bootmgr grub-probe --target = fs_uuid / mnt / winboot / bootmgr

これにより、それぞれ次のXNUMXつの文字列が返されました。

--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
DC788F27788EFF8E

このようにして、返されるUUIDが、blkidコマンドの実行時にそのパーティションで取得されたものと同じであることを確認しました。 次に、上記のデータを使用してカスタムgrubエントリを生成する必要がありました。

vi /etc/grub.d/40_custom

その内容：

＃！/ bin / sh exec tail -n +3 $ 0＃このファイルは、カスタムメニューエントリを追加する簡単な方法を提供します。 このコメントの後に追加する＃メニューエントリを入力するだけです。 ＃上記の「exectail」行を変更しないように注意してください。 menuentry "Microsoft Windows 7 SP1" --class windows --class os {insmod part_msdos insmod ntfs insmod search_fs_uuid insmod ntldr search --fs-uuid --set = root --hint-bios = hd0、msdos1 --hint-efi = hd0、msdos1 --hint-baremetal = ahci0、msdos1 DC788F27788EFF8E ntldr / bootmgr}

この手順を完了した後、妻が慌てず、姪が来たときにバービーをプレイできるように、Windowsをデフォルトのオペレーティングシステムとして設定することにしました。 このために私は単にファイルを編集しました / etc / default / grubの 入力をデフォルトで起動し、タイムアウトをわずか3秒に設定しました。

GRUB_DEFAULT = 2 GRUB_TIMEOUT = 3

GRUB構成を再生成し、再起動するだけでした。

grub-mkconfig -o / boot / grub / grub.cfg再起動

幸いなことに、すべてが期待どおりに進みました。 Windowsエントリを選択すると、問題なく起動しました。

ご覧のとおり、少なくともXNUMXつのArchLinuxオフライン疑似インストールはCDだけでオンラインにすることなく段階的に実行できますが、ハードディスクにインストールされるのは基本的にLiveCDですが、少なくとも起動は可能です。システム、ファイルのコピー、およびいくつかのアプリケーションの実行。

幸い、Sandy（KZKG ^ Gaara）が立ち寄ってArchリポジトリをコピーしたので（私はとても感謝しています）、すぐに実際のオフラインインストールを終了する予定ですが、これは別の話になります。 私があなたに保証できるのは、私は長い間、この種の楽しい実験を少し逃してきたということです。 実際、時間、家の接続性、特定の材料条件が確保されていれば、LFSに基づいてカスタム配布を作成しようとするでしょう。これははるかに楽しいプロジェクトです。 😉