ArchLinux offline áltelepítés lépésről lépésre

Néhány napja letöltöttem az ArchLinux ISO-t otthoni telepítéshez. Korábban más disztribúciókat használtam, amelyek lehetővé teszik, hogy legalább egy minimális adatbázist telepítsen a CD-ről, valami hasonlót akartam csinálni, de kíváncsiság szerint az Arch telepítési folyamatot nem olyan számítógéphez tervezték, amely nem rendelkezik internet-hozzáféréssel (a fejlesztőktől az első világban).

Esetemben már a lemezemen volt a Windows 7 (a rendszerindító és a rendszerpartícióval) és a Fedora (a cseréjével és a dedikált / indító partícióval). Az ötlet az volt, hogy az Arch-ot telepítsék oda, ahol korábban a Fedora volt, anélkül, hogy közben rombolták volna a Windows rendszert.

ArchLinux offline áltelepítés

Nos, az Arch CD-ről indultam, az x86_64 lehetőséget választva, és minden további nélkül otthagytam egy konzolnál. Arra gondoltam: "Wow, ezek a srácok komolyan gondolják, hogy nem újszülött disztró ... oké, akkor játsszunk végig, és nézzük meg, mi történik."

Felsoroltam a könyvtárat, ahol meg kellett néznem, van-e dokumentáció, és rájöttem, hogy valóban van egy szöveg egy elemi telepítési útmutatóval. Egy darab papírra írtam, ami releváns (nincs otthon nyomtatóm), és nekiláttam a munkának.

Első dologként a billentyűzet elrendezését spanyolra cseréltem Spanyolországból, ami könnyebb volt, mint vártam (van még egy furcsán nevezett us-ékezet is):

loadkeys es

A következő dolog egy külső lemez csatlakoztatása volt, hogy probléma esetén mentse az MBR másolatát, és mellesleg mentse a Fedora-ban lévő fontos információkat:

mkdir -p / mnt / tmp1 && mount / dev / sdb1 / mnt / tmp1 dd, ha = / dev / sda = / mnt / tmp1 / mbr.bin bs = 512 szám = 1

Szerencsére az Arch LiveCD támogatja az NTFS-t és beépített Éjfél parancsnok (MC), így pillanatok alatt befejeztem a többi információ mentését.

Ezután leválasztottam a lemezt, eltávolítottam az ideiglenes könyvtárat, és fizikailag eltávolítottam a külső lemezt a potenciális "katasztrófák" kockázatának csökkentése érdekében.

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

Szóval formáztam a partícióimat, csatlakoztattam a gyökér és a rendszerindító partíciót, és bekapcsoltam a cserét:

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

A következő lépés az első akadályom volt:

pacstrap /mnt base

Arch természetesen megpróbálta megkeresni a tárolók adatbázisát az egyik tükrön, és nem talált mindent pacstrap létrehozott egy könyvtárstruktúrát az / mnt könyvtárban, nagyon rendezett, de nyilván üres.

Telefonon megkérdeztem pár barátot, akik Arch-ot használnak, hogy nincs-e olyan mód, hogy internet-hozzáférés nélkül telepítsünk legalább ugyanazokat a csomagokat, amelyek a LiveCD-n vannak, anélkül, hogy a tároló lemezt is lemásolnák, és azt mondták, hogy legalább nem tudták, hogyan kell csinálni.

Érdekesnek találtam a technikai kihívást, ezért gondoltam: "Ha az Arch képes bejelentkezni LiveCD módban, akkor legalább ugyanabban a módban képesnek kell lennie a merevlemezre történő telepítésre", ezért megpróbáltam kézzel másolni a fájlokat, és követtem az oktatóanyag többi része (páratlan kisebb változtatással), hogy lássa, mi történt:

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

A következő lépés a következő akadályom volt:

mkinitcpio -p linux

Ez a parancs hibákat okozott, miután elolvasta a parancs kézikönyvét és a fájlok tartalmát /etc/mkinitcpio.conf y /etc/mkinitcpio.d/linux.preset, Megértettem, hogy a parancs nem találja a fájlt vmlinuz-linux, ezért megnyomtam a Ctrl + D billentyűkombinációt a chroot környezetből való kilépéshez, és kerestem minden olyan fájlt, amely kinézett:

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

Előfordul, hogy az Arch LiveCD a könyvtárba illeszti a rendszerindító fájlokat / fuss /, ezért úgy döntöttem, hogy átmásolom őket a sajátomba / boot / hogy a kezemben legyenek:

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

Mivel egy másik hiba, amelyet az mkinitcpio-val kísérleteztem, az volt, hogy a gyökérpartíció címkéje nem található, felírtam az UUID-jét (amelyet a blkid paranccsal azonosítottam) a parancshoz használni, amely végül így nézett ki:

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

Ezúttal a felépítés sikeresen véget ért, csak néhány figyelmeztetéssel a modulokról, amelyek nem találhatók, de az én esetemben nem volt szükség. Minden esetre újjáépítettem az fstab-ot, de ezúttal megadtam az UUID-t:

genfstab -U -p / > /etc/fstab

Azt gondoltam: na jó, végre haladás. És folytattam a jelszó megváltoztatását és a bootloader telepítését.

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

Végül, és hogy módszeres legyek, ismét megnyomtam a Ctrl + D billentyűkombinációt, hogy kilépjek a fonott környezetből, szétszedtem mindent és újraindítottam, hogy lássam, mi történt:

umount / mnt / boot umount / mnt újraindítás

A számítógép újraindította az Arch archív Grub menüt (a Windows nem jelent meg sehol), ezért kiválasztottam, és minden rendben volt, amíg ... a rendszer jelezte, hogy voltak hibák, amelyeket a következő paranccsal ellenőriznem kell:

journalctl -xb

A hibákat elemezve láttam, hogy a legtöbbet figyelmen kívül lehet hagyni, de az utolsó szokatlan volt, mondván, hogy a plymouth nem található.

Azonnal arra gondoltam: 'Plymouth ??? Miért kell a konzol indító környezetéhez ilyesmi? Úgy tűnik, ezt nem nagyon KISS mondani. Biztosan nem tettem fel, és nincs is szükségem rá. "

De hogy praktikus legyek, azt gondoltam: "Nos, de legalább valamilyen fájlban hivatkozni kell rá, nézzük meg ...":

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

Meglepő módon egyetlen fájl sem jelent meg a "plymouth" karakterlánccal a konfigurációs könyvtárban. Akkor gondoltam: «Ó, szóval ... kényszeríted magad velem? akkor nézzük meg, hogyan asszimilál egy „ágyút” (ahogy Kubában mondjuk), és a semmiből „építette” a plymouth-ot:

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

Azok számára, akik kíváncsiak arra, mit raktam bele a fájlba, íme a tartalom dicsőséges teljességében:

#! / bin / sh kilépés

Ismét újraindítottam, és némi hibára számítottam, és ... meglepő módon a systemd örült, hogy megtalálta ezt az "alapvető összetevőt", mert befejezte az indítási folyamatot, és további késedelem nélkül a konzolon hagyott. Mivel nem hittem a szememnek, úgy döntöttem, hogy "eltávolítom" a plymouth-ot és újraindítom, hogy lássam, mi fog történni:

rm -fr / usr / bin / plymouth újraindítás

Furcsa módon ezúttal a rendszer csendesen elindult, anélkül, hogy tovább bosszantotta volna Plymouth távollétét. (No comment)

A Windows hozzáadása a GRUB-hoz

Ezután maradt a Windows bejegyzés hozzáadása a GRUB-hoz. Mivel a hagyományos útvonalak nem működtek (a grub-mkconfig a os-prober úgy tűnik, hogy nem működik jól), úgy döntöttem, hogy manuálisan készítem el a bejegyzést, amelyhez fel kell derítenem a Windows bootloader karakterláncát és a rendszerindító partíció UUID-jét:

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

Ez adott nekem vissza ezt a két húrt:

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

Így ellenőriztem, hogy a visszaküldött UUID megegyezik-e az adott partícióval kapott blkid parancs végrehajtásakor. Ezután létre kellett hozni egy egyedi grub bejegyzést az említett adatokkal:

vi /etc/grub.d/40_custom

Tartalmában:

#! / bin / sh exec tail -n +3 $ 0 # Ez a fájl egyszerű módot kínál az egyedi menübejegyzések hozzáadására. Egyszerűen írja be a megjegyzés után hozzáadni kívánt # menüpontot. Vigyázzon, ne változtassa meg a fenti "exec tail" sort #. 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}

Miután ez a lépés befejeződött, úgy döntöttem, hogy a Windows-t állítom be alapértelmezett operációs rendszerként, hogy a feleségem ne essen pánikba, az unokahúgom pedig eljátszva játszhassa Barbie-jait. Ehhez egyszerűen szerkesztettem a fájlt / Etc / default / grub és úgy állítottam be a bemenetet, hogy alapértelmezés szerint elinduljon, és az időtúllépés csak 3 másodperc legyen.

GRUB_DEFAULT = 2 GRUB_TIMEOUT = 3

Csak a GRUB konfiguráció újbóli regenerálása és újraindítása maradt:

grub-mkconfig -o /boot/grub/grub.cfg újraindítás

Szerencsére minden a vártnak megfelelően alakult. Kiválasztottam a Windows bejegyzést, és boldogan indult.

Tehát, amint láthatja, ha legalább egy offline ArchLinux áltelepítést megtehet lépésről lépésre anélkül, hogy online lenne csak a CD-vel, bár nyilvánvaló, hogy a merevlemezre telepített lényegében LiveCD, de legalábbis képes indítsa el a rendszert, másolja a fájlokat és futtasson néhány alkalmazást.

Szerencsére Sandy (KZKG ^ Gaara) megállt és lemásolta az Arch repót (amiért nagyon hálás vagyok), ezért azt tervezem, hogy hamarosan befejezem egy igazi offline telepítést, de ez egy másik történet. Amit biztosíthatok önökről, hogy egy ideje hiányzik egy kicsit ez a fajta szórakoztató kísérletezés. Valójában, ha lenne időm, a házon belüli kapcsolódás és bizonyos anyagi feltételek biztosítottak, valószínűleg megpróbálnék egy egyedi disztribúciót készíteni az LFS alapján, ami sokkal szórakoztatóbb projekt lenne. 😉