ArchLinux offline pseudo-installation trin for trin

For et par dage siden downloadede jeg ArchLinux ISO for at lave en hjemmeinstallation. Efter at have tidligere brugt andre distributioner, der giver dig mulighed for at installere mindst en minimal database fra cd'en, ville jeg gøre noget lignende, men mærkeligt nok er Arch-installationsprocessen ikke designet til en computer, der ikke har internetadgang (bivirkninger af udviklere, der lever i den første verden).

I mit tilfælde havde jeg allerede Windows 7 (med sin boot- og systempartition) og Fedora (med dens swap og dens dedikerede / boot-partition) på min disk. Ideen var derefter at administrere at installere Arch, hvor Fedora tidligere var, uden at ødelægge Windows i processen.

ArchLinux offline pseudo-installation

Nå startede jeg fra Arch-cd'en ved at vælge x86_64 og efterlod mig uden en masse problemer ved en konsol. Jeg tænkte: "Wow, disse fyre er seriøse over at ikke være en rookie-distro ... okay, lad os spille sammen dengang og se hvad der sker."

Jeg oplistede biblioteket, hvor jeg skulle se, om der var nogen dokumentation, og jeg opdagede, at der faktisk var en tekst med en elementær installationsvejledning. Jeg skrev, hvad der var relevant, på et stykke papir (jeg har ikke en printer derhjemme) og kom på arbejde.

Den første ting, jeg gjorde, var at ændre tastaturlayoutet til spansk fra Spanien, hvilket var lettere end forventet (der er endda en nysgerrig kaldet us-accenter):

loadkeys es

Den næste ting var at montere en ekstern disk for at gemme en kopi af MBR i tilfælde af problemer og i øvrigt gemme de vigtige oplysninger, som jeg havde i min Fedora:

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

Heldigvis understøtter Archs LiveCD NTFS og har indbygget Midnatskammerat (MC), så på ingen tid var jeg færdig med at gemme resten af ​​informationen.

Derefter afmonterede jeg disken, fjernede den midlertidige mappe og fysisk fjernede den eksterne disk for at reducere risikoen for potentielle "cagastrofer."

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

Så jeg formaterede mine partitioner, monterede rod- og bootpartitionen og tændte 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

Det næste trin var min første forhindring:

pacstrap /mnt base

Arch forsøgte naturligvis at kigge efter databaserne på en af ​​spejlerne og ikke kunne finde alt pacstrap Det gjorde var at oprette en katalogstruktur i / mnt, meget organiseret, men åbenbart tom.

Over telefonen spurgte jeg et par venner, der bruger Arch, om der ikke var nogen måde at installere uden internetadgang i det mindste de samme pakker, der er på LiveCD, uden at have et arkiv kopieret til disk heller, og de fortalte mig, at i det mindste de vidste ikke, hvordan de skulle gøre det.

Jeg fandt den tekniske 'udfordring' interessant, så jeg tænkte, 'hvis Arch er i stand til at logge ind i LiveCD-tilstand, skal den være i stand til at installere på en harddisk i mindst den samme tilstand', så jeg prøvede ved manuelt at kopiere filer og efter resten af ​​selvstudiet (med den ulige mindre ændring) for at se, hvad der skete:

rsync -avl / {bin osv., hjem, lib, lib64, opt, root, sbin, srv, usr, var} / mnt arch-chroot / mnt genfstab -p / >> / etc / fstab echo hpc> / etc / værtsnavn ln -sf / usr / share / zoneinfo / Cuba / etc / localtime locale-gen

Det næste trin var min næste forhindring:

mkinitcpio -p linux

Denne kommando producerede nogle fejl efter at have læst kommandovejledningen og indholdet af filerne /etc/mkinitcpio.conf y /etc/mkinitcpio.d/linux.preset, Jeg forstod, at kommandoen ikke kunne finde filen vmlinuz-linux, så jeg trykkede på Ctrl + D for at afslutte chroot-miljøet og ledte efter en fil, der lignede den:

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

Det sker, at Archs LiveCD monterer startfilerne under biblioteket / løb /, så jeg besluttede at kopiere dem til min / støvle / at have dem handy i mit chroot-miljø:

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

Som en anden fejl, som jeg fandt ud af at eksperimentere med mkinitcpio, var at etiketten på rodpartitionen ikke kunne findes, skrev jeg ned dens UUID (som jeg identificerede ved hjælp af blkid-kommandoen) til brug sammen med kommandoen, som endelig så ud som dette:

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

Denne gang sluttede bygningen med succes, kun med et par advarsler om moduler, der ikke kunne findes, men i mit tilfælde ikke var nødvendige. Bare hvis jeg genopretter fstab, men denne gang angiver jeg UUID:

genfstab -U -p / > /etc/fstab

Jeg tænkte: Nå ja, endelig fremskridt. Og jeg fortsatte med at ændre adgangskoden og installere en bootloader.

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

Endelig og for at være metodisk trykkede jeg igen på Ctrl + D for at forlade det rodede miljø, adskillede alt og genstartede for at se, hvad der skete:

umount / mnt / boot umount / mnt genstart

Computeren genstartet med Grub-menuen med Arch (Windows dukkede ikke op nogen steder), så jeg valgte den, og alt syntes at indlæse fint indtil ... systemet angav, at der havde været fejl, som jeg skulle kontrollere med følgende kommando:

journalctl -xb

Ved at analysere fejlene så jeg, at de fleste kunne ignoreres, men den sidste var usædvanlig og fortalte mig, at plymouth ikke kunne findes.

Jeg tænkte straks, 'Plymouth ??? Hvorfor i helvede har et konsolstartmiljø brug for noget lignende? Det synes ikke meget KISS at sige. Jeg har bestemt ikke sagt det, og jeg har heller ikke brug for det. "

Men for at være praktisk tænkte jeg: "Nå, men det skal i det mindste refereres til i en fil, lad os se ...":

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

Overraskende nok opstod der ingen fil med tekststrengen "plymouth" i konfigurationsmappen. Jeg tænkte da: «Åh, så ... tvinger du dig selv med mig? så lad os se, hvordan du assimilerer en 'kanon' "(som vi siger på Cuba), og" jeg byggede "plymouth fra bunden:

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

For de af jer, der spekulerer på, hvad jeg lægger i den fil, her er indholdet i dets strålende helhed:

#! / bin / sh exit

Jeg genstartede igen og forventede en fejl og ... overraskende var systemd glad for at have fundet den "vigtige komponent", fordi den afsluttede opstartsprocessen og uden yderligere forsinkelse efterlod den mig i konsollen. Da jeg ikke kunne tro mine øjne, besluttede jeg at "afinstallere" plymouth og genstarte for at se, hvad der ville ske:

rm -fr / usr / bin / plymouth genstart

Mærkeligt nok startede systemet denne gang stille uden yderligere at irritere mig med Plymouths fravær. (Ingen kommentarer)

Tilføjelse af Windows til GRUB

Det var derefter at tilføje Windows-posten til GRUB. Da de traditionelle ruter ikke fungerede (kombinationen af grub-mkconfig med os-prober syntes ikke at fungere godt), besluttede jeg at oprette posten manuelt, som jeg havde brug for til at registrere Windows bootloader-strengen og UUID for bootpartitionen:

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

Dette gav mig henholdsvis disse to strenge:

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

På denne måde bekræftede jeg, at UUID-returneringen var den samme som den, der blev opnået for denne partition, når jeg udførte blkid-kommandoen. Det var derefter nødvendigt at generere en brugerdefineret grub-post med nævnte data:

vi /etc/grub.d/40_custom

I dets indhold:

#! / bin / sh exec tail -n +3 $ 0 # Denne fil giver en nem måde at tilføje brugerdefinerede menupunkter på. Indtast blot de # menuposter, du vil tilføje efter denne kommentar. Pas på ikke at ændre linjen 'exec tail' ovenfor. menuindlæg "Microsoft Windows 7 SP1" - klassevinduer - klasse 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 - tip-baremetal = ahci0, msdos1 DC788F27788EFF8E ntldr / bootmgr}

Når dette trin var afsluttet, besluttede jeg at indstille Windows som standardoperativsystem, så min kone ikke får panik, og min niece kan spille sine barbies, når hun kommer. Til dette redigerede jeg blot filen / Etc / default / grub og jeg indstiller input til start som standard og timeout til kun 3 sekunder.

GRUB_DEFAULT = 2 GRUB_TIMEOUT = 3

Det forblev kun at regenerere GRUB-konfigurationen igen og genstarte:

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

Heldigvis gik alt som forventet. Jeg valgte Windows-posten, og den startede lykkeligt.

Så som du kan se, kan mindst en ArchLinux offline pseudoinstallation udføres trin for trin uden kun at være online med CD'en, selvom det naturligvis er, hvad der vil blive installeret på harddisken i det væsentlige en LiveCD, men i det mindste kan den starte et system, kopier filer og kør nogle applikationer.

Heldigvis kom Sandy (KZKG ^ Gaara) forbi og kopierede Arch Repo (som jeg er meget taknemmelig for), så jeg planlægger snart at afslutte en rigtig offlineinstallation, men dette ville være en anden historie. Hvad jeg kan forsikre dig om er, at jeg i lang tid har savnet denne form for sjov eksperimentering lidt. Faktisk hvis jeg havde tid, tilslutningsmuligheder i huset og visse materielle forhold sikret, ville jeg sandsynligvis forsøge at lave en brugerdefineret distribution baseret på LFS, hvilket ville være et meget sjovere projekt. 😉