ArchLinux離線偽安裝逐步

幾天前，我下載了ArchLinux ISO進行家庭安裝。 以前曾使用過其他發行版，使您可以從CD上安裝至少一個最小的數據庫，但我想做類似的事情，但是奇怪的是，Arch的安裝過程不是為無法訪問Internet的計算機設計的（開發人員的副作用在第一世界）。

就我而言，我的磁盤上已經裝有Windows 7（具有引導和系統分區）和Fedora（具有交換和專用/引導分區）。 當時的想法是設法將Arch安裝在Fedora以前的位置，而不會破壞Windows。

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），所以我很快就完成了其餘信息的保存。

然後，我卸載了磁盤，刪除了臨時目錄，並物理刪除了外部磁盤，以減少潛在的“ catroptrophes”風險。

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

所以我格式化了分區，掛載了根分區和啟動分區，並打開了swap：

mkfs -t ext4 / dev / sda3 mkfs -t ext4 / dev / sda6 mount / dev / sda6 / mnt mkdir -p / mnt /引導安裝/ dev / sda3 / mnt /引導swapon / dev / sda5

下一步是我的第一步：

pacstrap /mnt base

Arch很自然地嘗試在其中一個鏡像上尋找存儲庫數據庫，但是卻找不到任何內容 包子 它確實是在/ 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可能將啟動文件掛載在目錄下 / 跑 /，所以我決定將它們複製到我的 /啟動/ 使它們在我的chroot環境中方便使用：

cp /run/archiso/bootmnt/arch/boot/[memtest,intel_ucode.img} / mnt /引導/ cp /運行/ archiso / bootmnt /拱/引導/ x86_64 / * / mnt /引導/ 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 /啟動umount / mnt重新啟動

計算機重新啟動，顯示帶有Arch的Grub菜單（Windows沒出現在任何地方），因此我選擇了它，並且一切似乎都可以正常加載，直到...系統指出我應該使用以下命令檢查錯誤：

journalctl -xb

分析錯誤後，我發現大多數錯誤可以忽略，但是最後一個錯誤，告訴我找不到普利茅斯。

我立刻想到，“普利茅斯？？？ 為什麼控制台啟動環境需要這樣的東西？ 這似乎不太吻。 我當然沒有說，也不需要。”

但實際上，我想：“嗯，但至少應該在某些文件中引用它，讓我們看一下……”：

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

令人驚訝的是，配置目錄中沒有出現帶有文本字符串“ plymouth”的文件。 我當時想：“哦，所以……你強迫我自己嗎？ 然後讓我們看看您是如何吸收“大砲”的（就像我們在古巴所說的），然後“我從頭開始建造”普利茅斯：

vi / usr / bin /普利茅斯chmod 755 / usr / bin /普利茅斯

對於那些想知道我在該文件中放入什麼內容的人，這裡是其光輝的整體內容：

＃！ / bin / sh退出

我再次重新啟動，並期望出現一些錯誤，並且……令人驚訝的是，systemd很高興找到該“基本組件”，因為它完成了啟動過程，並且沒有再拖延，將我留在了控制台中。 由於我不敢相信自己的眼睛，我決定“卸載”普利茅斯並重新啟動，以查看發生了什麼事情：

rm -fr / usr / bin /普利茅斯重啟

奇怪的是，這一次系統安靜地啟動，而沒有因為Plymouth的缺席而使我煩惱。 （沒有意見）

將Windows添加到GRUB

然後將Windows條目添加到GRUB。 由於傳統路線無效（ grub-mkconfig 同 操作系統探測器 似乎運行不正常），我決定手動創建該條目，為此我需要檢測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

這分別將以下兩個字符串返回給我：

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

這樣，我驗證了返回的UUID與執行blkid命令時為該分區獲得的UUID相同。 然後有必要使用所述數據生成一個定制的grub條目：

vi /etc/grub.d/40_custom

在其內容中：

＃！/ bin / sh exec tail -n +3 $ 0＃該文件提供了一種添加自定義菜單項的簡便方法。 只需在此註釋後鍵入要添加的＃菜單項。 注意不要更改上面的“ exec尾”行。 菜單項“ Microsoft Windows 7 SP1” --class windows --class os { hd0，msdos1-提示裸機= ahci0，msdos1 DC0F1EFF788E ntldr / bootmgr}

完成此步驟後，我決定將Windows設置為默認操作系統，這樣我的妻子就不會驚慌，當我的侄女來時，侄女可以玩她的芭比娃娃。 為此，我只是編輯了文件 在/ etc /默認/蠐螬 並且我將輸入設置為默認啟動，並且超時僅為3秒。

GRUB_DEFAULT = 2 GRUB_TIMEOUT = 3

只需要再次重新生成GRUB配置，然後重新啟動即可：

grub-mkconfig -o /boot/grub/grub.cfg重新啟動

幸運的是，一切都按預期進行。 我選擇了Windows條目，然後它愉快地啟動了。

因此，您可以看到，至少一個ArchLinux脫機偽安裝可以逐步進行，而不必僅與CD聯機，儘管顯然，硬盤上安裝的本質上是LiveCD，但至少可以引導系統，複製文件並運行某些應用程序。

幸運的是，桑迪（KZKG ^ Gaara）停下來複製了Arch存儲庫（對此我非常感激），因此我計劃盡快完成真正的脫機安裝，但這將是另一個故事。 我可以向您保證的是，一段時間以來，我一直在丟失這種有趣的實驗。 實際上，如果我有時間，可以保證房子的連通性並確保某些材料條件，我可能會嘗試基於LFS進行自定義分發，這將是一個更加有趣的項目。 😉