- iPad topik
- Milyen videókártyát?
- Apple asztali gépek
- Nyaralás előtti hardverszemle
- Bluetooth hangszórók
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen notebookot vegyek?
-
PROHARDVER!
Arch Linux topik
Új hozzászólás Aktív témák
-
Archttila
veterán
Szerintem a conf fájlok kavarnak be... a systemd-boot nem közvetlenül listázza a törölt kerneleket, hanem azokat a bejegyzéseket jeleníti meg, amelyek az EFI partíción található konfigurációs fájlokban vannak definiálva. Ha a kernel és az initramfs fájlokat eltávolítottad, de a hozzájuk tartozó .conf fájlok megmaradtak, akkor a törölt kernelek továbbra is megjelenhetnek a listában.
Listázd már az alábbi fájlokat:
boot/efi/loader/entries -
attilav2
őstag
Igazad van, amíg a systemd-boot konfigban nem engedélyeztem hogy a LUKS engedje át a discard-ot, addig az fstrim -v / parancsra azt írta nem támogatott. Amint engedélyeztem reboot után működött az fstrim, kb 300gb-ot trimmelt. sd-encrypt -et használok a rendszerpartíció felcsatolásához, ilyenkor a /boot/loader/entries/arch.conf a következőképp néz ki:
title Arch Linux NVME
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options rd.luks.name=UUID=sn580_cryptroot root=/dev/mapper/sn580_cryptroot rw
options rd.luks.options=UUID=discardAz UUID helyére a rendszerpartíció UUID-je kell. Az utolsó sor engedélyezi a trim-et.
Az sn580_cryptroot helyére lehet tetszőleges nevet írni, praktikusan a meghajtónk típusát.Kísérletképp az fstab-ba beraktam a discard-ot, kíváncsi vagyok néhány hét múlva belassul e a rendszer, ha igen akkor marad a periodic trim mint lehetőség. A crucial mx500-on és a samsung QVO 860-on gyakorlatilag nem nagyon működött a continous trim, az fstrim-el indőnként be kellett segíteni. Van egy másik gépbe adata sp600-on(sata ez is) Arch Luks-al, az még nem lassult be, pedig kb egy éve használom, lehet az a meghajtó jobban komálja a linux alatti folyamatos trim-et.
-
attilav2
őstag
Arch - Windows 11 dual bootot akarok, a 2 rendszer 2 külön lemezen van, mindegyiknek saját efi partíciója van a saját lemezén. A windows bitlockerrel titkosított. Lehet ez kavar be, ugyanis amikor a systemd-boot menüből elindítom az arch systemd-boot wiki alapján lérehozott Windows bejegyzést, szépen el is indítja, de a bitlocker jelszóbekérő képernyőjén a jelszómező csillagokkal végig kivan töltve, a billentyűzetre nem reagál, tehát törölni és a helyes jelszót beírni nem tudom. Itt elakadtam. A windows.nsh efi script a linux efi partíciójára került, oda ahol a bootx64.efi és a shellx64.efi is van, a windows.conf indítóbejegyzést megfelelően felparamétereztem az arch systemd-boot wiki alapján, ötletem nincs miért produkálja ezt a viselkedést. Ha a systemd-boot menüből nyitok egy efi shellt(direkt benne hagytam a menüben a lehetőséget, hogy tudjam indítani a windowst, linuxot, az f11 bootoláskori szorgos nyomogatása helyett), és beírom windows.nsh akkor jól működik a bitlocker jelszóbekérő, üres jelszómezővel indul, bill. működik, be tudom írni a jelszót a windows elindul.
Van valami ötletetek hogy rendesen működjön a windows indító bejegyzés ?
Az arch wiki mellett még ez a leírás volt segítségemre: Link
Most cseréltem gépet, ahogy az aláírásomban is látszik, eddig a dual(trial) bootot OpenCore-val oldottam meg mert macOS is ment a gépen. Haswell-re viszonylag könnyű volt felrakni, 12.gen -re állítólag nehezebb, egyelőre nem akarok nekiállni új OC EFI-t készíteni, így a dual boot-ot systemd-boot al akarom megoldani. -
Sonja
nagyúr
Pedig nem nehéz. Partícionálásnál használj cfdisk-et, azzal egyszerűbb lesz.
UEFI-t én is most telepítettem először tavaly, mikor az új gépet vettem. Azt hittem nehéz lesz, de a systemd-boot-tal pofon egyszerű volt, még nekem is. 
-
Shyciii
veterán
válasz
Archttila
#8089
üzenetére
Igen, kalapáltak rajta, mert az elején összeomlott párszor, de most kipróbálva jól működött. Simán felment.
Persze, hogy publikus. Semmi olyan nincsen benne, ami titkos lenne:
https://github.com/og900aero/archlinux
Arra figyelj a scriptekben (install.sh, install2.sh), hogy ez kifejezetten számomra van kialakítva. Eleve feltételezi ugyanazt a partíciós kiosztást, van benne a notebookhoz szükséges tapipad beállítás, hogy érzékelje a double tap-ot, saját programok, csak systemd-boot-al csinálja stb., szal mindenképp értően kell belenézni, hogy neked ebből mi használható. Igyekeztem commentezni a sorokat, hogy érhetőebb legyen. Ha van kérdésed, akkor nyugodtan tedd fel.
-
Frawly
veterán
Csinálj UEFI-t. Jobb, gyorsabb, egyszerűbb. Arch Wiki systemd-boot szócikkét nézd.
Az UEFI boothoz csak 1 extra partíció kell, de még ez se extra, mert egyben a /boot szerepét is betölti. Egy kb. 100 megás, vagy kicsivel nagyobb FAT32 partíció, mindenképp 1 giga alatt adj meg neki méretet, Archnak nem kell sok hely, ha lesz mellette más OS is, akkor viszont nem árthat 200 mega felett adni, akár 500-ig is. A típusa mindegy is, de „EFI System” típus szokott lenni, és FAT32-re kell formázni, és így kell telepítéskor felcsatolni /boot-ként. Annyi, hogy UEFI bootnál a partíciós tábla ne dos/MBR legyen hanem GPT.
Lényegében az egész systemd-boot telepítése csak egyetlen bootctl install parancs. Meg az EFI partíción két .conf fájl szerkesztése kézzel, amibe megadod neki a bootmenü opcióit, és a kernelparamétereket, initramfs nevét. De cserébe se GRUB, se semmilyen nyomorékság nem kell hozzá, később nem törnek el ilyen hülyeségek.
UEFI BIOS-ban sem kell általában állítani semmit, a legtöbb gépen a deafult az UEFI boot vagy UEFI + Legacy BIOS boot. Bár én azért meggyőződnék, hogy a bootopció UEFI only boot-on legyen, az a legtisztább, nehogy elkezdjen az Arch iso mégis Legacy BIOS módban bootolni.
Az UEFI boot egyébként sok mindenben megegyezik a Legacy BIOS boottal. Annyi a változás, hogy az OS-ek a bootkódjukat többé nem a lemez 0. szektorába, az MBR-be teszik bele, hanem a FAT32-es EFI partícióra teszik .EFI fájlok formájában. Így több OS megfér egymás mellett kulturáltan, és nem írják felül egymás bootszektorát, és emiatt többé az OS-ek telepítési sorrendje is mindegy lesz. Az UEFI BIOS meg tudja kezelni ezeket az .EFI fájlokat, indítani. Ennyi a lényege tömören.
De az UEFI bootnak van egy csomó előnye. GPT partíciós táblával megy, amiben csak sima (nem göcsörtös) partíciók vannak, nincs vergődés többé ilyen elsődleges, kiterjesztett, logikai partíciókkal, nem kell bootflagekkel szórakozni, nem kell külön bootmanagert telepíteni (hiszen az UEFI BIOS egyben már bootmanager is, és tudja menedzselni neked az általa detektált EFI partíciókon lévő .EFI fájlokat).
Plusz az UEFI bootnak előnye lehet, hogy a gép az OS betöltése előtti eszközinicializálási időt lerövidítheti. Nem minden gépen, de néhányon ez lehet a helyzet. Hiszen ha nem hagyományos BIOS módban bootol, akkor nem végez el egy csomó, visszafelé kompatibilitás miatt benne hagyott hagyományos BIOS POST eszköztesztet, és kihagyva ezeket a sallangokat gyorsabban eljuthat a gép az OS betöltőjéig.
Meg most már így 2021-ben nem célszerű MBR Legacy BIOS bootot erőltetni, hacsak nincs annyira szükség az adott gépen, hogy valami legacy OS-t futtass, DOS, Win9x, XP, vagy hasonló.
A másik előnye az UEFI bootnak, hogy pl. Archnál csak egyszer kell megcsinálni. Utána megmarad, esetleges újratelepítésnél már hozzá se kell nyúlni az EFI partícióhoz, simán bootol majd vele az új telepítésű rendszer is, főleg, ha PARTUUID-kel hivatkoztál a root partícióra és nem particináltál újra. Ez jelentős kényelem a hagyományos MBR-es boottal szemben. Illetve előny, hogy ha nem is bootolna a rendszer egyszer, akkor is könnyű megjavítani, mert a FAT32-es partíciót minden OS olvassa, írja és csak szöveges config fájlokat kell a sytemd-boothoz szerkesztened, emiatt nem kell speciális Live rendszert, meg GRUB javítókonzolt beizzítani, hanem bármivel megjavíthatod a dolgokat. Ez se elhanyagolható.
-
Frawly
veterán
válasz
Archttila
#8054
üzenetére
Nem kell figyelni semmilyen sorrendre. Ugyanazon EFI partíciót használják, sőt, az azon lévő .EFI fájlokat is tudják közösen használni, ha az adott disztrók mindegyike támogatja a systemd-bootot. Annyi, hogy a közösen használt /boot/loader/*/*.conf fájlokba hozzá kell adni a másik rendszer kernelbetöltő sorát, paraméterestől, root partícióstól, stb. és simán bootolnak.
Ez a jó az UEFI bootban, hogy azonos EFI partíciót használnak, legfeljebb különöbző .EFI fájlokat, amik megférnek egymás mellett. Mert MBR Legacy BIOS bootnál az volt, hogy átírogatták az OS-ek egymás alatt az MBR-t, így számított a sorrend.
-
Frawly
veterán
válasz
attilav2
#8028
üzenetére
Persze, hogy működik. Ez egy teljesen sztenderd telepítés, annyi benne a csavar, hogy cryptsetup-pal letitkosította a második partíciót, és arra telepítette a rendszert. Illetve a systemd-boot menüjében hozzáadott egy extra sort: options cryptdevice=PARTUUID=bla-bla... Illetve, ha tudod így telepíteni, akkor ennél kell maradni, és hagyni a GRUB-ot.
Amire még figyelj, hogy ha SATA SSD-ről van szó, akkor a TRIM átengedéséről a LUKS rétegén gondoskodni kell. NVMe SSD-nél (amilyen a leírásban is van), meg HDD-nél nem kell ilyen.
Vim az hasznos, de nem kötelező azt használni konzolban sem. Bármit felrakhatsz magadnak, leginkább a micro nevű text editort ajánlom, de van helyette egy csomó másik: ne, e3, ee, nano, tilde, mcedit, emacs, uemacs, vagy amit akarsz. Van egy rakat, közülük egy csomó „hagyományosabb” a vim-nél. Régen a base csomag része volt a vi, de már nem az. De szerintem a vim a legjobb az összes közül, főleg, ha tud valaki gépírni. Illetve az Emacs is nagyon jó, de azt sem sokkal könnyebb megtanulni, mint a vim-et.
-
-
attilav2
őstag
Találtam egy jó leírást, egyszerű LUKS telepítés, systemd-boot -al:
https://jherrlin.github.io/posts/arch-install/
VirtualBoxban kipróbáltam, nekem működött!
Itt meg egy magyarázó videó, szintén alap LUKS telepítés, Grub boot -al:
https://www.youtube.com/watch?v=XNJ4oKla8B0
Ezt is megcsináltam vboxban, ez is működött.
Vim vágólapkezelés:
https://vim.fandom.com/wiki/Copy,_cut_and_paste
konzolban hasznos -
Frawly
veterán
Gummiboot tudtommal már nincs. Az a systemd-boot régi neve volt. De nem tömi tele a partíciót. Ennek ellenére nem írtam, hogy nekem sem volt még gondom a GRUB-bal, mikor még használtam. Egyszer volt, hogy nem bootolt, de akkor balfék Win7 update-je írta felül, nem Linux oldalán volt a hiba. Én csak azért nem használom a GRUB-ot, mert 1) feleslegesen nagy, bloat valami, 2) nincs rá szükségem. De ahogy olvasom a fórumokat, nagyon sok embernek eltörik, és rendszeren jönnek kérdésekkel, hogy nem bootol. Systemd-bootnál ilyet még nem hallottam, az is igaz, hogy annál lehet azért nem, mert aki olyat használ, az ért hozzá, és jól rakja fel magának. Na, meg sokkal egyszerűbb is, csak egy szál .EFI fájl, meg két darab plain text .conf fájl, az egész egy pirinyó megoldás.
De elvileg az EFI stub boot még elegánsabb, ott semmilyen bootmanager nincs (az UEFI már önmagában is egy bootmanager), ott a kernel bootol közvetlenül EFI binárisként. Ennek viszont van 1-2 hátránya, néhány nem annyira szabványos alaplap UEFI-je nincs vele kibékülve, meg ha pl. hirtelen átszerkesztett paraméterekkel kell hívni a kernelt, akkor azt nem lehet egykönnyen kivitelezni.
GRUB csak akkor kell, ha valaki ZFS-ről, btrfs-ről, RAID-ről, egész lemezes szoftveres titkosításos megoldásról (esetleg LVM-ről), stb. akar bootolni. Akkor kell. De ezek nem az átlag felhasználói réteg, az simán titkosítatlan ext4 partíciókat használ, ahhoz nem kell. Még legacy BIOS bootnál sem, mert vannak nála soványabb, biztosabb megoldások, amik nem törnek el.
-
Frawly
veterán
válasz
attilav2
#8001
üzenetére
Az efistub nagy királyság, annak a lényege, hogy a kernel közvetlenül .EFI binárisként bootol, nincs semmilyen bootmaganer (az UEFI egymagában is egy bootmanager). De az efistub-ot nem támogatja sok nem szabványos gyártói UEFI, meg ha initramfs, titkosítás, stb. van, akkor vagy nehézkes lehet, vagy lehetetlen.
Én systemd nélküli disztrókon lehetőleg efistub bootot használok, systemd-s disztrókon systemd-bootot, mert az is még kellően egyszerű. GRUB-ot csak akkor tennék fel, ha valami RAID-ről, egzotikus partíciótípusról, spéci titkosítós mókáról kell bootolni, vagy MBR Legacy bootkor (bár akkor is hajlanék valami egyszerűbb bootmanager felé).
-
attilav2
őstag
válasz
Shyciii
#8000
üzenetére
Ebben a leírásban külön van az efi és a boot partíció, én jobban szeretem ha egybe van. A youtubeon vannak LUKS Arch telepítési videók, de többnyire Grub-osak, nem tudom miért ragaszkodnak annyira a Grub-hoz, mikor a systemd-boot sokkal egyszerűbb, mondjuk systemd mentes rendszeren érthető, de itt Arch LUKS telepítési videókról van szó, nem az Arch egy systemd mentes forkjáról ahol érthető ha Grub-ot használnak. Artixon én is Grub-ot használok, efistub meg hasonló csak uefi nvram-ba író megoldások jöhetnének még szóba Grub helyett, de ha átrakom a lemezt egy másik gépbe akkor már nem bootolna mert a másik gép uefi-jében értelemszerűen nincs ott a bejegyzés.
Egyelőre a jövő zenéje lesz a titkosított ökoszisztéma, mert csak akkor van értelme ha minden adatomat letitkosítom, a külső lemezeken levőket is, a külső lemezeket valószínűleg bitlockerrel oldom majd meg, hogy win alatt is használhatóak legyenek. Linux alá van bitlocker megnyitó tool, csak nem tudom mennyire stabil. -
Shyciii
veterán
válasz
attilav2
#7999
üzenetére
https://linuxhint.com/setup-luks-encryption-on-arch-linux/
Ahogy nézem semmi extra nincs a luksban. Lásd fenti link. Pár sorral több csak a telepítés. Nyilván systemd-boot esetén más a /boot. Mondjuk vmware alatt lehet hogy kell más is, de azt nem tudom. Én az összes próbálkozásomat a saját fizikai notimon csináltam, mert az ha működik, akkor nem kell még azt átirogatnom, hogy fizikai gépen is működjön. Nyilván ha ilyen volumenű dolgot csinálok, mert van időm, akkor előtti csinálok a rendszerről egy image-t. Mondjuk múltkor már arra sem volt szükség, mert a jelenlegi telepítőscriptem a beállítássaimat is visszatölti az adatokkal együtt :)
-
attilav2
őstag
válasz
Shyciii
#7998
üzenetére
Egy leírást te vagy Frawly vagy más hozzáértő csinálhatna a titkosított(LUKS) kézi telepítésről, mondjuk kezdetnek egy egyszerű 2 partíciós telepítéssel ( / /boot), swap nélkül
Csak a / lenne titkosítva, systemd-boot-al. Virtuális gépben meg lehet csinálni és akkor képekkel is tudjátok illusztrálni -
Frawly
veterán
válasz
anorche1
#7961
üzenetére
A --efi-directory nem jó, annak is a /mnt/efi-t adjad meg. Elvileg úgy jónak kéne lennie. A másik, ami előfordul, hogy egyes Acereknél az UEFI nem szabályos, csak Windows only bootra van fixen bedrótozva, hogy bootkor a Windows bootmgfw.efi fájlát akarja bebootlni név szerint. Ez kikerülhet az alábbi parancs kiadásával:
cp $MOUNTPOINT/EFI/grub/grubx64.efi $MOUNTPOINT/EFI/Microsoft/Boot/bootmgfw.efi$MOUNTPOINT helyett nyilván azt adod meg, ahová felcsatoltad. Bár az is furcsa, amit írsz, hogy /mnt-be csatolod, az EFI partíciót /boot-ként szokásos felcsatolni.
Másrészt, ha sima UEFI és ext4 partíciók, semmi titkosítás, RAID, LVM bonyolítás nincs, akkor systemd-bootot is használhatsz, az egyszerűbb, és nem kell hozzá GRUB sem.
-
jimmy399
senior tag
Végre át tudtam én is térni UEFI-s bootra, eddig pár dolog akadályozott, de egy teljes rendszerújratelepítés után gondoltam kipróbálom már.
Vanilla arch linux (xfce4 DE, 12 GB RAM AMD A8-5600K AMD HD7650D, Samsung 512 SSD, grub2 boot loader, tudom, lehetne systemd-boot-is de nem akartam a dualboot miatt a win8.1-el): a boot idő:Startup finished in 78us (firmware) + 17us (loader) + 1.204s (kernel) + 1.617s (initrd) + 809ms (userspace) = 3.631s
graphical.target reached after 786ms in userspaceViszont az EFI partíciót a windows hozta létre. 100MB. Nagyon lecsökkent a hely rajta, így kénytelen voltam kiszedni a fallback initrd generálást. Valami más ötlet van?
Relatíve új vagyok az UEFI boot-ban, virtuális gépben már sokat gyakroltam dualboot-ot, meg olvasgattam is a témába, azárt nagyjából megvan, hogyan is működik kb.
-
Frawly
veterán
válasz
szuszinho
#7281
üzenetére
Ez attól függ milyen szerver. A partíciók felcsatolása persze, hogy számít, mert először a root-ot kell felcsatolni, utána az annak a mappáiba csatolt egyéb partíciókat, és csak utána mehet a genfstab script futtatása, meg az arch-chroot.
Bootloader annak függvénye, hogy mit használsz. Szerintem a systemd-boot elég egyszerű, csak a UUID-kre kell figyelni. Az EFI stub boot még egyszerűbb, de az nem minden UEFI-vel megy. És itt végig UEFI-t emlegetek, mert már minden szerver tudja.
De hagyományos MBR + Legacy bootnál sem olyan nehéz GRUB2-őt telepíteni, lényegében:
pacman -S grub && grub-install --target=i386-pc /dev/sdX && grub-mkconfig -o /boot/grub/grub.cfgDe az a lényeg, hogy sikerült feltenned. Ez az Arch ilyen, először belerakod a munkát, de aztán kitapasztalod, hogy mit hogy kell, és többé nem leszel semmilyen más disztróra rászorulva, hogy menjenek a hardvereszközeid, menjen a bootolás, dualboot, multiboot, stb., nem leszel installer bugoknak kitéve, mert kézileg bármikor tudsz magadnak Archot telepíteni. Nem kell többé disztróhoppolni (hacsak nem akarsz még minimalistább disztrót, meg systemd-mentes megoldást), csak azért, mert az adott gépen egyik disztróval mennek a dolgok out of the box, máskor meg csak a másikkal.
Archot egyébként csak akkor nehezebb telepíteni, ha túl spéci beállítás kell, RAID, LLVM, LUKS, és hasonlókkal van bonyolítva, meg Secure Boot, és társai. Na, akkor tényleg nagyobb munka. De csak házi szerverre, meg hagyományos desktopra felhúzni titkosítatlan ext4 partíciókra nem valami nagy szám, elég könnyen meg lehet tanulni.
-
Frawly
veterán
válasz
#63718632
#6870
üzenetére
Ha a Secure Boot be van kapcsolva, akkor szopás az UEFI boot, olyan bootmanager kell akkor, ami kezeli a shim-et. Azt nem tudom, hogy a systemd-boot kezeli-e. Sose használtam Secure Bootot, az első, amit kikapcsolok, mert
1) mint védelem nem sokat ér ténylegesen
2) csak megkeseríti az ember életét OS-ek telepítésekor
3) akármilyen OS-en driverek telepítésekorAz ujjlenyomat-olvasónak nem kéne elvileg megkívánnia a Secure Bootot, de ki tudja, lehet azon a gépen fogja. Mondjuk ezekben én nem tudok neked segíteni, mert semmi ilyen flancos dolgot nem használok, se Secure Boot, se ujjlenyomat-olvasó, se Windows Live arcfelismerés, se VR-szemüveg, se multimonitor setup, se 100 gombos 3000000 DPI-s Gaming Pro RGB Ultra egér, se BT-os eszközök, se USB-s vibrátor, se semmi ilyen szarokat nem használok, nem kötözgetek a gépre. Így ilyen spéci dolgokról nem tudok nyilatkozni, hogy mi mit igényel, hogy menjen. Régi vágású vagyok, bekapcsolom a gépet, beépített eszközöket, beépített kijelzőjét használom, egy kijelző, 1 virtual desktop, tapipad, stb..
-
Frawly
veterán
válasz
#63718632
#6868
üzenetére
Tudtommal EFI partícióból nem lehet kettő azonos meghajtón. De pont az az EFI partíció lényege, hogy több OS-nek is elfér rajta az .EFI fájlja, nem írogatják át egymás dolgait, megférnek egymás mellett. A MBR bootnak pont ez a baja, hogy az egyes OS-ek kicserélgetik egymás alatt az MBR indítókódot. Ez UEFI bootnál nincs.
Simán telepítheted az Archot systemd-boottal a Win10 mellé, amennyiben nem használsz Secure Bootot. A Windowst nem a systemd-boot teszi bele a menübe, hanem a Windows alakítja ki hozzá a szükséges dolgokat az EFI partíción, amit az UEFI talál meg. Te csak a meglévő EFI partíción létrehozol 1 mappát meg 2 konfig fájlt, és a végén kiadsz egy bootctl --path=/boot install parancsot. Ez egy teljesen új systemd-bootx64.EFI fájlt fog létrehozni a /boot/EFI/systemd mappában. A Windowst indító /boot/EFI/BOOT/BOOTX64.EFI fájlhoz nem nyúl hozzá egyáltalán, a Windows nem is fog róla tudni, hogy rajta kívül új OS lett telepítve.
-
#63718632
törölt tag
Meg lévő Win10 telepítés mellé, dual bootban is lehet alkalmazni a systemd-bootot? Az asztali gép mellé érkezik majd egy kis Dell noti is.
[link]
Egy db. m2-es SSD van benne (256 GB), telepített Win10-el. Erre is Arch-ot szeretnék majd telepíteni.
El gondolkodtam azon, mint azt fentebb említették. Hogy a linuxnak is készítek saját kis efi partíciót, hogy ne közösködjön a Win10-ével, meg emez ne rondítson frissítéskor bele.
Mi a helyzet, ha az Arch-ot systemd-boottal telepítem? Fölveszi a Win10-et az indító menüjébe? -
ztsoft
őstag
Megint nem tudok belépni a BIOS-ba (át akartam rendezni a boot sorrendet).
De a Win vígan indul. Még sem jó ötlet ezen a gépen a Win UEFI partícióját használni. Át fogom gondolni, hogy annyira fontos-e a Win.Át fogom nézni a systemd-boot-ot, nem sokat vesztek vele, még ha újra is kell rakni az Arch-ot.
-
Frawly
veterán
Ha az Arch Wiki systemd-boot cikke alapján csinálod, akkor nem kell GRUB-ot sem telepíteni. Az UEFI/EFI bootnak pont az a lényege, hogy az UEFI már önmagában is egy bootmanager, nem igényli további bootmanager feltételét.
Az egyébként önmagában nem baj, ha 9,3 MiB maradt csak az EFI partíción. Ráfért, aminek rá kell. Úgyse történik rá sok írás, sok olvasás, mindegy mennyi szabad hely van rajta.
A HDD kivétele szerintem azt okozta, hogy 1-2 UEFI boot opció mögött a meghajtó elérhetetlenné vált, és ilyenkor sok UEFI BIOS automatikusan törli a bootbejegyzést az UEFI-ből.
-
Frawly
veterán
válasz
Archttila
#6803
üzenetére
A cfdisk után nem feltétlen kell a -z kapcsoló. Az csak arra való, hogy ha lenne már a meghajtón valamilyen partíciós tábla, akkor nem abba particionál, hanem teljesen új, üres partíciós táblát kezd, ír fel, olyat, amilyet kérsz, gpt vagy dos/mbr. Nyilván ha EFI boot van, akkor gpt kell.
Az SSD partícióeltolása miatt nem kell aggódni, a cfdisk modern tool, eleve 1024K-val tolja el a partíciókat, ami mindenfajta SSD-hez és modern HDD-hez megfelelő.
Hacsak nem akarsz hibernálni, 16 GB RAM mellett szerintem semmilyen swap nem kell, nem hogy swap partíció. Ha esetleg később mégis szükséges lenne swapra, azt lehet fájlként is létrehozni, pl. 8 gigás swap fájlt így tudsz akármikor, telepítés után is létrehozni:
dd if=/dev/zero of=/elérési/út/swapfile bs=1M count=8192
mkswap /elérési/út/swapfile
swapon /elérési/út/swapfile
Illetve be kell tenni a /etc/fstab-ba is ezt a sort:
/eléséri/út/swapfile none swap defaults 0 0Az Arch-nak nem kell nagy EFI partíció, jelenleg nekem 100 megás van, és abból is 51 MB szabad. Ha egyedüli rendszered az Arch azon a lemezen, akkor neked se kell nagyobb. Csak egyes disztróknál kell nagyobb, mint az Ubuntu, Debian alapúak, meg Void, amelyek otthagyják a régi kerneleket szaporodni. De adhatsz végül is 500 megát is neki, 400 mega ide vagy oda ma már nem tétel. De csak Archhoz overkill az 500 MB. Az EFI partíció típusának EFI system-et kell megadni, és az Arch Wiki alapján mkfs.vfat-tal FAT32-re kell formázni.
EFI bootoláshoz nem kell GRUB sem, az Arch Wiki systemd-boot cikke alapján csináld.
Root partíciónak annyit adj, amennyire szükséged szokott lenni, nálam 50 giga van, de az overkill, nagyját nem használom, 11 GB-ból megáll a teljesen belakott Arch telepítésem, de aki nagyon fullos, GUI-s, DE-s kiszerelésben használja, annál sem hinném, hogy 20-30 gigánál többre szükség lenne, én is csak biztos, ami biztos alapon szabtam ilyen nagyra. Persze ez mindenkinél felhasználásfüggő, mennyi programot, csomagot telepít, hol van a Steam mappája, stb..
A maradékot (~461 GB) meg adhatod /home-nak, ahol nem csak az user home mappája lehet, hanem használhatod általános adatpartíciónak is, bármilyen adat tárolósára, torrent, dokumentumok, portable programok, stb..
Partíciókat, ha csak speciális igény nincs, simán, ext4-re kell formázni.
-
Frawly
veterán
válasz
Shyciii
#6620
üzenetére
Esetleg még azt lehet csinálni, hogy teljesen megkerülöd a Debian GRUB-ját, és közvetlenül veszed fel a Debian kernelt és initramfs-t az Arch systemd-boot menüjébe, ahogy először próbáltad (GRUB-ból kimásolva a kernelparamétereket). De ezzel az a probléma, hogy ha Debian alatt frissül a kernel, akkor nem fogja megtalálni az új verziót. Mert a Debian beteszi ugyan az új kernelt a GRUB-jába is, de mivel ezt te megkerülöd, ezért nem fog látszani, és a régi kernellel indul a rendszer.
Az, hogy mi mennyit foglal, az attól függ, hogy mit mivel telepítesz. Egyforma csomagoknál azért nem kéne nagy különbségnek lennie.
A Termite nekem is érdekes, mert Archon kívül szinte semmilyen disztrónak nincs benne a tárolójában. Nem is értem az okát. Void meg Gentoo alatt is külön tárolóból kell forgatni. Mivel nem akartam én sem ezen tökölni, így most Voidon Alacritty-t használok, ez se rossz, csak speciális vim-módokat nem tud kijelölésnél és görgetésnél.
-
Frawly
veterán
válasz
Shyciii
#6618
üzenetére
Most én is ezzel küzdök, de Void alatt. Az GRUB-ot használ, és működik ugyan az UEFI boot, de csak akkor, ha F12-t nyomva a boot menüből kiválasztom a void_grub bejegyzést. Egyébként mindig az Arch akar indulni. Pedig az UEFI-ben be van állítva a bootsorrendnél, hogy a void_grub legyen az első.
Amit a entriesről írtam, azt visszavonom. Ez csak systemd-bootnál működik, ami közvetlen kernelt bootoltat initramfs-sel. Ha a Debian GRUB-os, akkor nem kellenek ezek a conf fájlok. Helyette Arch alatt efibootmgr-rel vedd fel a grubx64.efi-t indulásra. Még paraméterek sem kellenek neki, mert a GRUB ezt saját hatáskörben elintézi. A lényeg, hogy az UEFI BIOS találja meg a grubx64.efi fájlt:
sudo efibootmgr -c -L "Debian" -l '\EFI\Debian\grubx64.efi'Vigyázat, az UEFI-nek visszafelé perjel kell, mint Windowsnál. Ugyanis egy DOS-ból származtatott implementáció! Nem a normál linuxos-unixos perjel kell neki. A harmadik kapcsoló az efibootmgr-nél egy kis L, nem nagy i, csak rosszul látszik a Prohardver által használt talpatlan betűtípussal. Arch alól csináld természetesen, ne Debian alól.
-
Frawly
veterán
válasz
Shyciii
#6614
üzenetére
A leírásod alapján jól csinálod pedig. A /boot/loader/loader.conf hogy néz ki nálad? Tudni kéne ugyanis, hoyg indításnak mit adtál meg a debian.conf-ban. Ha GRUB jön a képbe, akkor a grubx64.efi fájllal kell indítani, de mivel nálad van shimx64.efi, ezért lehet mégis az kell helyette, a shim a Secure Bootot intézi, de ehhez a részéhez nem értek, mert én mindig letiltom a Secure Bootot.
A Debian, mint ahogy a legtöbb disztró, felteszi a GRUB-ot, ha kéred, ha nem. Nálam a Void is feltette sajnos, majd kigyomlálom belőle.
Bár annyi előnye lehet, hogy ha végképp sehogy nem boldogulsz, akkor nem a Debiant veszed fel a systemd-boot-os menübe, hanem fordítva, az Archot veszed fel a Debian GRUB-jába.
-
Shyciii
veterán
Frawly:
Szia. Egyszer régen úgy rémlik, hogy leírtad, hogy mi van akkor ha valaikinek UEFI-s systems boot-os Arch van, és mellé akar egy másik linux disztrót, akkor hogyan lehet ugyanúgy UEFI-s megoldással. Muszáj feltennem a jelenlegi Arch-om mellé egy Debian 10-est, és netinstall-al felraktam egy teljesen minimal rendszert egy külön 15GB-os szeletre. Eleve érdekes hogy felrakott Grub-ot úgy, hogy meg sem kérdezte, hogy akarom-e, de mindegy. A /boot/loader/entries alatt létrehoztam egy Debian.conf-ot is az Arch mintájára. Nyilván a PARTUUID-t átírtam az új értékre. De mivel ez a szerencsétlen Debian grubosként installálta magát automatice, így persze nem működik, hisz a /boot/EFI alá létrehozott egy debian mappát amiben most van BOOTX64.CSV, fbx64.efi, grub.cfg, grubx64.efi, mmx64.efi, shimx64.efi.
Szerinted hogy tudom kikerülni egyrészt a grubot (úgyse működik, mert debian nem bootolbe, csak az arch), és hogy tudom az arch uefi+systemd-bootos megoldást megcsinálni debian esetében is. Ha egyáltalán lehet... -
Frawly
veterán
Igen, ha nem tudod, mi kell neked, akkor jó eséllyel nem való az Arch. Persze gyűrődni akkor is lehet vele, tanulási célzattal. Pont ezért jó, tapasztalatszerzés miatt, hogy legalább tisztában leszel vele, hogy mi is kell neked. Meg ahogy egyre régebb óta linuxozol, úgy változni is fog, hogy épp milyen megoldásra esküszöl.
Az EFI-től nem kell félni, mert pont, hogy egyszerűbb. Nem kell ilyen os-probe-os, mountolós varázslás sem. Az EFI boot lényege, hogy van egy univerzális FAT32 bootpartíció. Egyetlen egy (elméletileg lehet több, de nem ajánlom), az összes azon a lemezen lévő OS-nek (de fel lehet venni közéjük más lemezen lévő OS-eket is). Mivel GPT UEFI boot esetén nincs MBR, ezért nem oda írja be az OS az indítókódját, hanem egy .EFI fájlba, az EFI partícióra. Így nem írogatják át az OS-ek egymás alatt az MBR-t, hanem mindegyik tud indulni a saját loaderjével.
Így ha már van fent a gépen egy UEFI-s OS, mindegy, hogy Linux vagy Windows vagy mi, akkor eleve el lesz készítve az EFI partíció, lesz loader.conf vagy valami hasonló megoldás. Akkor csak bootctl installal-lal beteszed a systemd-boot .EFI fájlját az EFI partícióra, meg a loader.conf-ban kitöltöd az EFI fájl indulási paramétereit. Vagy alternatív megoldásként nem foglalkozol loader.conf-fal és systemd-boottal, hanem mindjárt az EFI partíción lévő kernelt használod indításra EFI stub boottal, ezt efibootmgr -c paranccsal tudod hozzáadni az UEFI BIOS bootbejegyzései közé az NVRAM-ba.
Egyébként meg UEFI-s gépen lehet továbbra is hagyományos BIOS bootot használni MBR-rel. Egyedül 2020 után készült, vadi új Intel lapoknál lesz csak megvonva ez a lehetőség. A régebbi lapokon, meg az összes AMD-n támogatva van.
Egyébként az EFI egy nagyon érdekesre kitalált dolog. Lényegében egyfajta 64 bites DOS. Nem röhögni, tényleg ez az igazság. Ezért is van FAT32 kitalálva EFI partíciónak, és nem ext, nem NTFS, nem más. Hiszen az .EFI fájlok MZ-fejléces DOS .exe fájlok, .exe kiterjesztés nélkül (a kiterjesztés mindegy), de nem tartalmaznak DOS vagy BIOS hívásokat (mint a legtöbb DOS program), hanem bare metal binárisok, közvetlenül a „vason” futnak, OS közbeékelése nélkül. A neten vannak olyan pihent agyú kockák, akik ilyen ASM-ben írt DOS bare metal progikat bootolnak be UEFI-vel (primitív játékok, képernyővédők, grafikus demók), pontosabban EFI stub boottal
![;]](//cdn.rios.hu/dl/s/v1.gif)
A sors iróniája, hogy hagyományos MS/PC/stb. DOS nem bootolható be UEFI-vel, mivel még ugyan .EFI binárisként be lehetne bootolni elvileg, de az UEFI 64 (ritkán 32) bites védett módra lövi be a procit, a DOS meg nem kapcsolgat bootkor x86 proci módot, hanem csak 16 bites valós módból (x86 real mode) tud indulni. Bár elvileg a FreeDOS-t fel lehetne készíteni erre. -
Frawly
veterán
válasz
#63718632
#6319
üzenetére
Az mindegy, hogy systemd boot vagy nem. Az UEFI boot az UEFI boot. A lényege, hogy az OS indítókódja egy futtatható, .EFI kiterjesztésű fájlként az EFI partíción van. Csak annyi a különbség, hogy systemd bootnál egy systemd-bootx64.efi fájlt tölt be az UEFI BIOS, GRUB-nál meg egy grub.efi fájlt. Tehát a GRUB csak annyiban más a systemd boothoz képest, hogy be van toldva egy plusz felesleges láncszem. Hiszen az UEFI már önmagában is egy bootmanager, felesleges mögé még +1 bootmanagert beláncolni a bootolási folyamatba.
A Windowst mindez nem zavarja, mert az az EFI partícióról a saját bootx64.efi fájlját menedzseli. Az UEFI boot pont azért lett így kitalálva, hogy egymást ne bántsák a feltelepített OS-ek. UEFI bootnál az OS-ek telepítési sorrendje is mindegy, nincs az, mint Legacy BIOS bootnál, hogy a Windowst kell elsőnek telepíteni és csak utána a Linuxot.
-
attilav2
őstag
válasz
Siriusb
#6175
üzenetére
Én pl azért raktam Grub-ot systemd-boot helyett, mikor egy Kubuntus próbálkozás után újraraktam az Arch-ot, mert a Grub képes egy másik lemezen lévő OS-t(gyk Windows) is indítani. Míg a systemd-boot csak akkor képes erre ha a windows efi partíciójáról a microsoft könyvtárat átmásolom az Arch efi partíciójára. Nem túl elegáns megoldás de így érzékeli a systemd-boot a windowst és megjelenik a menüben és el is indítja a másik lemezről. Hátránya ennek a megoldásnak hogy a Bios(uefi) menüben így kétszer jelenik meg a windows boot manager bejegyzés, ezt el akartam kerülni, ezért raktam Grub-ot. A windowsos indítómenü hozzáadása a grub hoz úgy nézett ki hogy felcsatoltam a windowsos lemez efi partícióját a /mnt alá, futtattam az os-prober-t, kiírta hogy felismerte a windows efi betöltőjét, aztán a szokásos grub-mkconfig -o /boot/grub/grub.cfg ami szépen hozzáadta a windows indítómenüt. Nem olyan rossz a Grub, custom menük hozzáadására is van lehetőség, az Arch wiki grub pontja ír néhány példát, pl Efi(Bios) menübe lépés, én ezt hozzáadtam, és prímán működik, ha rányomok akkor az EFI-be dob a gép újraindulás után. Bár tény hogy a systemd-boot-ban alapból van efi-be lépés menü.
-
attilav2
őstag
Kipróbáltam a Kubuntut a hardveresen gyorsított chromium-beta chromium-dev miatt, de végülis nem tetszett a rendszer filozófiája, vissza tértem az Arch-ra, amit megint uefi telepítéssel raktam fel. Ezúttal viszont grub-ot raktam fel systemd-boot helyett és a másik lemezen levő szintén uefi módú windowst az os-prober segítségével adtam hozzá a grub menüjéhez ezen leírás szerint, működik. Nem kellett átmásolni a Microsoft mappát a windows efi partíciójáról /boot/EFI alá mint systemd-boot-nál, így nem jelenik meg kétszer a windows boot manager az alaplap menüjében. A grub és az os-prober ezt kultúráltabban megoldja.
Viszont egy negatív jelenséget felfedeztem ami sajnos érinti az Arch-ot és a (K)ubuntu-t is, hogy mikor átmásoltam a zenéimet (több tíz giga) az ntfs-es adattáróló lemezről a linuxos lemezre akkor közel 100% körül volt a prociterhelés(Pedig mindkét lemez ssd). Keresgéltem a google-ban de megoldást nem igazán találtam erre. -
Frawly
veterán
Egyébként nagy francok az archosok. Sokszor még hír sincs kint egy változásról. Pl. jó pár hónapja kikerült a linux-firmware csomagból az AMD procikhoz a microcode csomag, és most már külön csomagban van, amd-ucode néven. De erről se hír, se értesítés, gondolom mert úgy gondolták, hogy a rendszert nem töri el működésképtelenre, nincs szükség kézi beavatkozásra (de, szükség van rá). Én is csak azért vettem észre, mert múltkor itt egy kolléga felhozta UEFI systemd-boot kapcsán. Az Arch Wikiben már benne van, de aki nem tud a változásról, az nem fogja keresgetni benne.
Gondolom úgy voltak vele, hogy majd az emberek észreveszik frissítéskor, vagy egy olyan csomag telepítésekor, aminek opcionális függősége.
-
attilav2
őstag
válasz
wwenigma
#6004
üzenetére
Grubnál elég egyszerű hozzáadni az Lts kernelt, az lts kernel telepítése után:
grub-mkconfig -o /boot/grub/grub.cfg
Ezzel alapból az lts kernellel fog indulni azthiszem. De kiválasztható marad a sima kernel is ha jól emlékszem. Már systemd-boot-ot használok ott picit macerásabb hozzáadni új kernelt, de nem bonyolult az sem. -
attilav2
őstag
Na túlestem rajta megvolt a windows újratelepítése EFI módban (természetesen leválasztottam minden linuxos efi-s meghajtót a windows telepítése idejére, ahogy a fentebb linkelt leírás is említi:
"You can copy the "/EFI/Microsoft" folder from the EFI partition on the Windows drive into the EFI partition of your Arch drive. The systemd-boot loader will then automatically add an entry for Windows to its menu.
That new menu entry will start Microsoft's boot loader. Inside that "Microsoft" folder you copied, that loader will have all files it needs to be able to boot the Windows that's on the other drive.
This idea requires that you have two EFI partitions, one on each drive. To make this happen, you have to disconnect the Arch drive while you install Windows. The Windows installer will then create a new EFI partition on that drive."
Az UEFI módú windows telepítés létrehoz egy rakat partíciót, de linux alatt az fdisk -l megmondja melyik a windows efi partíció. Ennek felcsatolása és a /EFI/Microsoft könyvtár átmásolása az Arch-os lemezre a /boot/EFI/Microsoft helyre, egy újraindítás és már ott is van a systemd bootloader menüjében a windows, és szépen el is indítja a windowst a másik lemezről. Nem kell a windowsos lemezen a windowsos bootloaderrel szenvedni hogy az töltse be a linuxot, ez a megoldás sokkal elegánsabb.
Az windows driver aláírásellenőrzését is sikerült kikapcsolni a "bcdedit /set nointegritychecks on" paranccsal, így a tunerkártya drivere sem problémázik uefi módban, a leírást itt láttam:
Link
Persze linux alatt simán működik a tunerkártya uefi módban mindenféle driver aláírásellenőrzés nélkül, ez a linux egyik előnye. Csak minden kernelfrissítéskor újra kell forgatnom a driverét, ami elég sokáig tart, mert teljes v4l tree-t is forgat.(https://github.com/tbsdtv/linux_media/wiki) működő dkms megoldás még nincs a TBS6221-hez. a Tbs-ecp-dkms driver az aur-ból amit ajánlanak nem támogatja ezt a kártyát sajnos. -
attilav2
őstag
Összeszedtem minden angol tudásom és találtam egy reddit szálat ami már azt boncolgatja amit én akarok:
Dual-boot Arch and Windows on separate drives with systemd-boot?
Elovastam, amit itt írnak az tűnik működőképes megoldásnak. -
attilav2
őstag
Na találtam is valamit Windows systemd-boot ügyben.
Link
itt thomasamadeusking hozzászólását kell nézni.
Kreálni kell egy új entry fájlt a /boot/loader/entries alá, pl /boot/loader/entries/windows.conf
Ennek a tartalma meg:
title Windows
efi /EFI/Microsoft/Boot/bootmgfw.efiEhhez meg nyilván létre kell hozni a /EFI/Microsoft/Boot könyvtárakat a linuxos lemez efi partícióján, aztán a windowsos lemez efi partíciójáról be kell másolni a bootmgfw.efi-t a linuxos lemez efi partíciójának /EFI/Microsoft/Boot könyvtárába.
Elméletileg így már indítható is a windows a linuxos lemezről, de csak elméletileg. Mert ugyan biztos lefut a windows efi alkalmazás de mivel másik diszkről indul, nem fogja megtalálni a windows rendszerpartícióját. Persze aztán lehet hogy megtalálja és betölt a windows, de murphy törvénye alapján inkább nem
Update: Illetve nem is kell ennyi marcera, a bootmgfw.efi fájlt egyszerűen bele kell rakni egy tetszőleges könyvtárba a linuxos lemez efi partícióján és aztán meghivatkozni a (boot)/loader/entries/windows.conf fájlban.Arch systemd-boot wikiben is van utalás erre a megoldásra, még ha nem is szó szerint:
Még meg kell ezt gondolnom, mert már telepítettem efi módban a windows10-et, és a tunerkártya drivere nem szerette, aláíratlannak(érvénytelen aláírás) mutatta magát és letiltotta a windows, az aláírásellenőrzést ugyan macerásan de ki lehet kapcsolni(nekem nem sikerült állandóra csak egy egy alkalomra, ennek is utána kell nézni), de még kékhalálozott is asszem. Ugyanez a driver mbr módú windowson persze megy normálisan.
További probléma még ezzel a boot megoldással hogy a linuxos lemezen a bootmgfw.efi -t manuálisan kell frissítgetni, egy egy nagyobb windows frissítés után bizonyára nem árt megtenni. Kérdés ha nem frissítgetem akkor sok sok update múlva is indul e így a windows.
-
attilav2
őstag
Gondolkodom rajta hogy a windowst is újrarakjam e uefi módba, de csak akkor ha a systemd-boot -ba könnyen bekonfigurálható hogy elindítsa a windowst is, azaz legyen egy boot entry a windowsnak is. A nehézséget az jelenti hogy a windows másik lemezen van, de ha uefi-s lenne az a lemez is, akkor valahogy csak meg lehetne hivatkozni a systemd-boot konfigban. Csak kellene valami leírás.
-
attilav2
őstag
Na rászántam magam, újra raktam uefi/gpt módban az "éles" Arch telepítésemet a 480Gb-os ssd-men, systemd-boot -al. Kevesebb ideig tartott mint gondoltam. Sokat gyakoroltam virtuális gépben ezért mehetett gyorsabban. Eddig MBR-es volt, de szokni kell az UEFI-t mert ez a jövő
-
attilav2
őstag
válasz
vargalex
#5947
üzenetére
Írhatnál egy systemd-boot konfiguráló shell szkriptet Arch-hoz, ami bekéri a partíciót
és már nyomja is bele a konfigba az uuid-jét. Illetve telepíti a systemd boot-ot a megfelelő(bekért) paraméterekkel. Amit most írtál azt shell szkriptként elmentem, hogy ne kelljen beírni, mert úgyis elrontom -
vargalex
félisten
válasz
attilav2
#5945
üzenetére
EFI esetén valóban a legegyszerűbb a systemd-boot használata. Évek óta azt használom, nincs gondom vele.
Nem kell kézzel bepötyögni, berakhatod egyetlen paranccsal:echo "options root=PARTUUID=$(blkid | grep sda2 | sed 's/\(.*\)PARTUUID="\(.*\)"$/\2/') rw" >> /boot/loader/entries/arch.confTermészeteesen itt az sda2 a megfelelő partíció számával helyettesítendő. De magát a root partíciót megadhatod labellel, vagy akár device-val is.
-
attilav2
őstag
Uefi Systemd-boot beállítására van olyan megoldás ahol nem kell disk UUID-eket körmölgetni?
Most kísérletezgetek a uefi módú arch telepítéssel, a grub uefi módja egyelőre szimpatikus, különösen hogy nem kell lemezazonosítókat körmölgetni telepítés közben, amikor se egér se vágólap nincsen.
Ezt a leírást követtem: https://averagelinuxuser.com/a-step-by-step-arch-linux-installation-guide/# a startup.nsh készítés kivételével, mert az csak virtualboxhoz kell. Az itt leírt grub uefi telepítési paramétereket ha megtoldom még egy --removable kapcsolóval akkor bios reset vagy lemez eltávolítás visszadugás után is indítható az UEFI Grub-os Arch. Csak ha --removable kapcsolóval telepítem akkor nem veszi figyelembe a bootloader-id paraméterben megadott nevet, egyszerűen UEFI-OS néven jelenik meg az alaplap boot menüjében. -
csixy
addikt
-
Siriusb
veterán
Nem használok systemd-boot-ot, esetleg különböző elnevezéseket használva nem lehetne megoldani?
Pl. az egyik rendszerben megváltoztatni a generált fájlok neveit:
# cat /etc/mkinitcpio.d/linux.preset
# mkinitcpio preset file for the 'linux' package
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"
PRESETS=('default' 'fallback')
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux.img"
#default_options=""
#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-linux-fallback.img"
fallback_options="-S autodetect"És ez alapján módosítani a releváns boot bejegyzést (az csak a minta fájl):
# cat /usr/share/systemd/bootctl/arch.conf
## This is just an example config file.
## Please edit the paths and kernel parameters according to your system.
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=XXXX rootfstype=XXXX add_efi_memmap
Gondolom a /boot-on van még plusz 60-70 MB szabad hely. -
Sziasztok!
A systemd-boot automatikus frissiteset szeretnem beallitani, amit szerintem meg i stettem, de kernek egy megerositest, hogy jol csinaltam-e.
Az itt leirtak alapjan letrehoztam a megfelelo tartalmu file-t (nem az AUR csomagot telepitettem).
Ket dolog okoz bizonytalansagot:
- nem letezett a hooks mappa a /etc/pacman.d/ mappaman. -> Letrehoztam.
- a pacman hook-okrol szolo leiras azt irja, hogy a /usr/share/libalpm/hooks/ mappaban keresi a pacman a hook-okat, de meg lehet adni ujabbakat is, ami alapbol az /etc/pacman.d/ mappa, ami a pacman.conf file-ban van megadva. Viszont itt ez a sor ki volt kommentazve. -> Kivettem a #-t a sor elejerol.A kerdes, hogy ez igy fasza, vagy jelez az valamit, hogy nem letezett a mappa, es ki volt kommentezve a megfelelo sor? Jobb lett volna a /usr/share/libalpm/hooks/ mappaba tenni?
A masik kerdes, hogy minden boot utan le kell futtatni a dhcpcd parancsot, hogy legyen netem.
Ezt hogy lehet megoldani? Siman tegyem be az autostart-ba, vagy hianyzik meg valami beallites? A networkmanager csomag fent van.
-
Sziasztok!
Most etlepítem az Arch-ot a melós laptop-ra.
Grub2 helyett szeretnék systemd-boot-ot használni. Az Arch wikiben kezdek ez ügyben eltévedni.Szóval a kérdés, hogy miaf*sz?!
- EFISTUB - értem az angol szöveget, de mégsem értem, hogy mit akar jelenteni.
- "make sure the system has booted in UEFI mode and that UEFI variables are accessibel" - éppen arch-chroot-ban vagyok, így itt nem érhetőek el ezek a változók. Ezek szerint ezt nem lehet elsőre telepíteni?
- azfdisk -lazt mondja az EFI particiora, hogy "Linux filesystem", pedig fat-re formáztam:# mkfs.fat -F32 /dev/sdc1
- a "# bootctl --path=/boot install" parancs azt mondja, hogy: "File system "/boot" has wrong type for an EFI System Partition (ESP)"Mit hagyok ki?
-
Frawly
veterán
Ha már fent van a Windows, akkor még könnyebb is az UEFI boot, mivel a Windows telepítője már megcsinálta az EFI partíciót, meg létrehozta a /boot/loader/loader.conf-ot, így annyival is kevesebb munka van vele, neked a bootctl install után csak a kész loader.conf-ot kell szerkeszteni, meg egy arch.conf-ot a entries mappába és így csak bővíted a már meglévő UEFI bootos opciókat egy újabbal. Teljesen veszélytelen művelet, mivel a Windows bootolhatóságát nem érinti, még ha el is rontasz valamit, attól legfeljebb csak az Arch nem fog bootolni.
Van egy másik módszer az EFI systemd-booton kívül. Ez pedig a EFI stub boot, ezzel már egy másik Arch Wiki cikk foglalkozik. Itt nem az EFI partíción lévő .conf fájlokkal zsonglőrködünk, hanem efibootmgr futtatásával közvetlenül az UEFI-ben matatunk, adjuk hozzá kézzel a bootopciókat. Na, ez veszélyes, mert ha valamit rosszul viszünk fel, bootképtelenné vállhat a gép, és ha nincs defaultra állítás az UEFI-ben opcióként, akkor az egész UEFI-t haza lehet vele vágni. Ezt tényleg csak annak ajánlott, aki tudja mit csinál.
UEFI-t én is most telepítettem először tavaly, mikor az új gépet vettem. Azt hittem nehéz lesz, de a 
Csak a / lenne titkosítva, systemd-boot-al. Virtuális gépben meg lehet csinálni és akkor képekkel is tudjátok illusztrálni 
De a Win vígan indul. Még sem jó ötlet ezen a gépen a Win UEFI partícióját használni. Át fogom gondolni, hogy annyira fontos-e a Win.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
A sors iróniája, hogy hagyományos MS/PC/stb. DOS nem bootolható be UEFI-vel, mivel még ugyan .EFI binárisként be lehetne bootolni elvileg, de az UEFI 64 (ritkán 32) bites védett módra lövi be a procit, a DOS meg nem kapcsolgat bootkor x86 proci módot, hanem csak 16 bites valós módból (x86 real mode) tud indulni. Bár elvileg a FreeDOS-t fel lehetne készíteni erre.
Új hozzászólás Aktív témák
Hirdetés
- alza vélemények - tapasztalatok
- Miért vezet mindenki úgy, mint egy állat?
- Milyen légkondit a lakásba?
- iPad topik
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Gyúrósok ide!
- Milyen videókártyát?
- Apple asztali gépek
- Genshin Impact (PC, PS4, Android, iOS)
- Formula-1
- További aktív témák...
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Antivírus szoftverek, VPN
- ÁRGARANCIA!Épített KomPhone Ryzen 5 5600X 16/32/64GB RAM RTX 4060 8GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Asus TUF F15 FX506HM Gamer notebook - i5 11400H 16GB DDR4 RAM 512GB SSD RTX 3060 6GB W10
- DUPLA XEON GOLD 6134!!! HP Z8 G4 LEGNAGYOBB WORKSTATION 64GB 2x8 mag 2x16 szál gamer, szerver, munka
- iKing.Hu - Apple 16 Pro Max - Natural Titanium - Új, kipróbált
- Honor 90 Lite 256GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged