ArchLinux offline pseudoinstalace krok za krokem

Před pár dny jsem si stáhl ISO ArchLinux pro domácí instalaci. Když jsem dříve používal jiné distribuce, které vám umožňují instalovat alespoň minimální databázi z CD, chtěl jsem udělat něco podobného, ​​ale kupodivu proces instalace Arch není určen pro počítač, který nemá přístup k internetu (vedlejší účinky vývojářů žijících v prvním světě).

V mém případě jsem na svém disku už měl Windows 7 (s jeho bootovacím a systémovým oddílem) a Fedoru (s jeho swapem a jeho vyhrazeným / bootovacím oddílem). Myšlenka byla pak zvládnout instalaci Archu tam, kde byla dříve Fedora, aniž by došlo k zničení systému Windows.

ArchLinux offline pseudoinstalace

Zavedl jsem z Arch CD, vybral jsem x86_64 a bez větších potíží mě nechal v konzole. Pomyslel jsem si: „Páni, tito kluci to myslí vážně s tím, že nejsou nováčkoví distro ... dobře, pojďme si spolu hrát a uvidíme, co se stane.“

Uvedl jsem adresář, kde jsem měl zjistit, zda existuje nějaká dokumentace, a zjistil jsem, že tam byl opravdu text s elementárním instalačním průvodcem. Napsal jsem, co je relevantní, na kousek papíru (doma nemám tiskárnu) a pustil se do práce.

První věc, kterou jsem udělal, bylo změnit rozložení klávesnice na španělštinu ze Španělska, což bylo jednodušší, než jsem čekal (existuje dokonce zvědavě nazývané us-akcenty):

loadkeys es

Další věcí bylo připojení externího disku pro uložení kopie MBR pro případ problémů a mimochodem uložení důležitých informací, které jsem měl ve své Fedoře:

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

Naštěstí Arch LiveCD podporuje NTFS a má vestavěný Půlnoční velitel (MC), takže jsem okamžitě uložil zbytek informací.

Poté jsem disk odpojil, odstranil dočasný adresář a fyzicky odstranil externí disk, aby se snížilo riziko potenciálních „cagastrophes“.

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

Takže jsem naformátoval své oddíly, připojil kořenový a spouštěcí oddíl a zapnul swap:

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

Dalším krokem byla moje první překážka:

pacstrap /mnt base

Arch se přirozeně snažil hledat databáze úložišť na jednom ze zrcadel a nebyl schopen najít nic, všechno pacstrap bylo vytvořit adresářovou strukturu v / mnt, velmi organizovanou, ale zjevně prázdnou.

Po telefonu jsem se zeptal několika přátel, kteří používají Arch, pokud neexistuje způsob, jak nainstalovat bez přístupu k internetu alespoň stejné balíčky, které jsou na LiveCD, aniž by bylo třeba zkopírovat úložiště na disk, a řekli mi, že alespoň nevěděli, jak na to.

Tato „výzva“ technologie mi připadala zajímavá, a tak jsem si řekl: „Pokud se Arch dokáže přihlásit v režimu LiveCD, měl by být schopen instalovat na pevný disk alespoň ve stejném režimu“, takže jsem to zkusil ručně zkopírovat soubory a podle zbytku tutoriálu (s nějakou další menší změnou) zjistit, co se stalo:

rsync -avl / {bin, etc, home, lib, lib64, opt, root, sbin, srv, usr, var} / mnt arch-chroot / mnt genfstab -p / >> / etc / fstab echo hpc> / etc / hostname ln -sf / usr / share / zoneinfo / Kuba / etc / localtime locale-gen

Dalším krokem byla moje další překážka:

mkinitcpio -p linux

Tento příkaz po přečtení příručky příkazu a obsahu souborů způsobil určité chyby /etc/mkinitcpio.conf y /etc/mkinitcpio.d/linux.preset, Pochopil jsem, že příkaz nemohl najít soubor vmlinuz-linux, tak jsem stiskl Ctrl + D k ukončení chroot prostředí a hledal jakýkoli soubor, který vypadal takto:

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

Stává se, že Arch LiveCD připojí spouštěcí soubory do adresáře / běh /, tak jsem se rozhodl je zkopírovat do mého / boot / mít je po ruce v mém chroot prostředí:

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

Jelikož další chybou, kterou jsem zjistil při experimentování s mkinitcpio, bylo to, že štítek kořenového oddílu nebyl nalezen, napsal jsem jeho UUID (který jsem identifikoval pomocí příkazu blkid) pro použití s ​​příkazem, který nakonec vypadal takto:

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

Tentokrát sestavení skončilo úspěšně, pouze s několika varováními modulů, které nebylo možné najít, ale v mém případě to nebylo potřeba. Pro případ, že jsem znovu vygeneroval fstab, ale tentokrát s uvedením UUID:

genfstab -U -p / > /etc/fstab

Pomyslel jsem si: ach no, konečně pokrok. A pokračoval jsem ve změně hesla a instalaci bootloaderu.

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

Nakonec a abych byl metodický, znovu jsem stiskl Ctrl + D, abych opustil chrootované prostředí, vše rozebral a restartoval, abych viděl, co se stalo:

umount / mnt / boot umount / mnt restart

Počítač se restartoval a zobrazil nabídku Grub s Archem (Windows se nikde neobjevil), tak jsem to vybral a všechno se zdálo, že se načítá dobře, dokud ... systém neuvedl, že došlo k chybám, které bych měl zkontrolovat pomocí následujícího příkazu:

journalctl -xb

Při analýze chyb jsem viděl, že většinu lze ignorovat, ale ta poslední byla neobvyklá a říkala mi, že plymouth nelze najít.

Okamžitě jsem si pomyslel: ‚Plymouth ??? Proč sakra potřebuje zaváděcí prostředí konzoly něco takového? To se nezdá být moc polibek. Rozhodně jsem to neřekl, ani to nepotřebuji. “

Ale aby to bylo praktické, myslel jsem si: „No, ale alespoň by to mělo být zmíněno v nějakém souboru, uvidíme ...“:

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

Překvapivě se v konfiguračním adresáři neobjevil žádný soubor s textovým řetězcem „plymouth“. Pak jsem si pomyslel: «Ach, takže ... nutíš se mnou? pak se podívejme, jak asimilujete „dělo“ “(jak říkáme na Kubě) a„ Postavil jsem “plymouth od nuly:

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

Pro ty z vás, kteří se zajímají, co jsem vložil do tohoto souboru, je zde obsah v celé jeho nádherné celistvosti:

#! / bin / sh výstup

Znovu jsem restartoval a očekával nějakou chybu a ... překvapivě byl systemd rád, že našel tu „základní součást“, protože dokončil proces spouštění a bez dalšího zpoždění mě nechal v konzole. Protože jsem nemohl uvěřit vlastním očím, rozhodl jsem se „odinstalovat“ plymouth a restartovat, abych viděl, co se stane:

restartování rm -fr / usr / bin / plymouth

Kupodivu systém tentokrát začal potichu, aniž by mě otravoval Plymouthovou nepřítomností. (Bez komentáře)

Přidání Windows do GRUBu

Bylo to přidat položku Windows do GRUBu. Protože tradiční trasy nefungovaly (kombinace grub-mkconfig s os-prober Zdálo se, že nefunguje dobře), rozhodl jsem se vytvořit položku ručně, pro kterou jsem potřeboval detekovat řetězec bootloaderu Windows a UUID bootovacího oddílu:

mkdir -p / mnt / winboot && mount / dev / sda1 / mnt / winboot grub-sonda --target = hints_string / mnt / winboot / bootmgr grub-sonda --target = fs_uuid / mnt / winboot / bootmgr

To mi vrátilo tyto dva řetězce:

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

Tímto způsobem jsem ověřil, že vrácený UUID byl stejný jako ten, který byl pro daný oddíl získán při provádění příkazu blkid. Poté bylo nutné vygenerovat vlastní položku grub s uvedenými daty:

vi /etc/grub.d/40_custom

Ve svém obsahu:

#! / bin / sh exec tail -n +3 $ 0 # Tento soubor poskytuje snadný způsob, jak přidat vlastní položky nabídky. Jednoduše zadejte # položky nabídky, které chcete přidat po tomto komentáři. Dávejte pozor, abyste nezměnili # řádek „exec tail“ výše. 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}

Jakmile byl tento krok dokončen, rozhodl jsem se nastavit Windows jako výchozí operační systém, aby moje žena nepanikařila a moje neteř mohla hrát své Barbie, když přijde. Za tímto účelem jsem soubor jednoduše upravil / etc / default / grub a ve výchozím nastavení jsem nastavil spuštění vstupu a časový limit na pouhé 3 sekundy.

GRUB_DEFAULT = 2 GRUB_TIMEOUT = 3

Zbývalo pouze znovu vygenerovat konfiguraci GRUB a restartovat:

restart grub-mkconfig -o /boot/grub/grub.cfg

Naštěstí vše proběhlo podle očekávání. Vybral jsem položku Windows a začalo to šťastně.

Jak tedy vidíte, pokud můžete provést alespoň offline pseudoinstalaci ArchLinuxu krok za krokem, aniž byste byli online pouze s CD, i když je zřejmé, že to, co bude nainstalováno na pevný disk, je v zásadě LiveCD, ale alespoň to může spusťte systém, zkopírujte soubory a spusťte některé aplikace.

Naštěstí se u nás zastavila Sandy (KZKG ^ Gaara) a zkopírovala Arch repo (za což jsem mu velmi vděčná), takže plánuji brzy dokončit skutečnou offline instalaci, ale to by už byl jiný příběh. Mohu vás ujistit, že už dlouho mi tento zábavný experiment trochu chybí. Ve skutečnosti, kdybych měl čas, konektivitu v domě a zajištěné určité materiální podmínky, pravděpodobně bych se pokusil udělat vlastní distribuci založenou na LFS, což by byl mnohem zábavnější projekt. 😉