Ha LTS kernelre váltasz az nem segít? linux-lts és linux-lts-headers csomagok, telepítés után be kell állítani a bootloaderben, utána reboot. Hátha ezzel lefordul.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Nem kell átállítani semmit a bootloaderben. Ahogy telepíti a linux-lts és linux-let-headers csomagokat, a pacman automatikusan legyártja az initramfs-t, a bootloader pedig azt indítja. Semmi extra teendő nincs, csak telepíteni ezt a két csomagot.

Pedig módosítani kell, hiszen az újonnan legyártott initramfs/vmlinuz nevében benne lesz az lts, amihez nincs bootloader bejegyzés...

[ Szerkesztve ]

Alex

Megnézem, remélem be is bootol utána még

Steam: http://bit.ly/1rRuf8p , Origin: wwenigma -- | -- Jiayu F1 / G3C / OT995 cuccok: http://bit.ly/1w44CI2 -- | -- ZTE V5 Red Bull -> http://bit.ly/1mgtfrd -- | -- Xiaomi RN3SE -> http://bit.ly/2r8DlV7 -- | -- Live Stream: twitch.tv/wwenigma

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.

[ Szerkesztve ]

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Jó tudni. LTS kernelt nem használtam még Archon, csak tárolósat meg git-eset. Azt hittem, hogy ahogy azoknál, átnevezi a meglévő kernelt, és nem lesz benne a nevében az lts.

Mondjuk nem is fogok egyhamar LTS kernelt használni Archon, az Arch lényege a frissesség. Ha LTS-re van igény, akkor másik disztró után néznék inkább. Persze teszt erejéig oké, nem is biztos, hogy megoldja a szóban forgó fordítási problémát.

`base` group replaced by mandatory `base` package - manual intervention required

[link]

You may corrupt the souls of men, but I am steel. I am doom.

Ez sajnos nem tűnik igaznak. Mármint nem téged kritizállak, hanem a hír valódiságát. Most próbáltam ki egy pacman -S base parancsot, a core tárolókban még a régi metacsomagot jelenti, aminek 53 csomag a tagja. Az testing tárolókban is még mindig egy metacsomag, de már csak 3 tényleges csomagot foglal magában: gcc-libs, glibc, linux. Tehát nem igaz, hogy kernelt nem tartalmaz.

Az meg egy kritikus döntés, hogy e2fsprogs-ot sem fog, mert az nagyon szükséges lenne, meg ha a kernelt is kiszedik belőle, függőségnek be kéne húzza mindkettőt. Ez a túlzott karcsúsítás csak arra jó, hogy egy csomó kezdőbb user kifelejtsen valamit, aztán menjen a vergődés, hogy se formázni, se ellenőrizni nem tudja a fájlrendszereit.

Az viszont nem baj, ha a text editort kihagyják belőle. Eddig vi volt a default, de azt sokan nem tudják használni, aki meg guru, úgyis gvim-et tesz fel (akkor is, ha terminálban használja, mert a gvim csomagban lévő vim-ben normálisan működik a vágólap a grafikus felület felé). Aki meg nem ismeri a vi/vim-et, az meg eddig is nano-t használt, vagy mceditet, vagy hasonlót, most csak annyi a különbség, ha nano-nál marad, akkor fel kell tennie.

Jó lett volna, ha frissíted a repo-t a pacman -S előtt. Így nyilván nálad még a cache-elt verziót jelentette. A linkelt hírben egyébként metapackage-t írnak, nem package-t és ez az infó jött RSS feed-ből is.
Ahogy a hír is mondja, eddg a base egy group volt, most viszont metapackage lett.

Alex

Igen, valóban igazad van. Lefuttattam most egy pacman -Syy parancsot és ezután már a pacman -S base nem is metapackage-t, hanem egy szál csomagot akar tényleg telepíteni.

Viszont írja, hogy opcionális függőségnek fent van a linux: bare metal support. Ez mi a tök? Esetleg ez csak simán a kernelt jelenti?

Az sem értem, hogy akkor mi a különbség a metacsomag és a csoport között.

Igen, megváltozott kicsit a telepítési eljárás 'pacstrap' pontja:

Nem tudom mi értelme ennek a karcsúsításnak, a kezdők simán, de még én is belefuthatok így szívásba telepítésnél ha nem figyelek.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Le is zavartam gyorsan egy Arch telepítést virtuális gépben hogy kipróbáljam működik e a megváltozott feltételekkel az install. Működik.
A base rendszer felrakása pacstrap '/mnt base' helyett így néz ki: 'pacstrap /mnt base linux'
a nano szövegszerkesztő már nem része a telepítőnek, az alaprendszer felrakása és chroot olás után lehet felrakni. Az mkinitcpio parancs paraméterezése is kicsit változott: 'mkinitcpio -p linux' (asszem ez volt régen) helyett csak simán 'mkinitcpio -P'

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Azért jó, mert így aki nem a default kernelt akarja használni, nem fog felmenni feleslegesen. Ahogy pl. nekem sincs szükségem a nano-ra.

Alex

Egy hátránya mindenképp van hogy kihagyták a telepítőből a nano-t, a base felrakása előtt nem tudod normális editorral szerkeszteni a mirror listát, sokaknak bonyolult a vi.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Nekem éppen a vi a normális editor.

Alex

Jó, de a vi sem lesz fent. Egyébként meg aki a vi-t tudja használni (mint te és én is), az meg nem vi-t fog feltenni, hanem mindjárt vim-et. Vagyis még inkább gvim-et, mert abban is van sima vim és az úgy van lefordítva, hogy működik a vágólapja a grafikus felület felé. A sima vim csomagban lévő vim-nél ez nem működik, fordítás közben lett kihagyva ez a feature. De gvim helyett lehet neovim-et is használni.

Egyébként a legkorrektebb lenne a szövegszerkesztőkre egy metacsomagot csinálnia az Archnak, editor néven. Így csak install közben annyit kellene tenni, hogy a pacstrap-nak vagy pacmannak a base linux csomagok mellé felsorolni az editor metacsomagot, és telepítéskor számozva rákérdezne, hogy melyik text editort telepítse, onnan meg mindenki kiválaszthatná magának, ami neki kell. Ez főleg kezdőknek lenne hasznos, akik nem tudják előre mit is akarnak, mi a választék.

Aki rutinos róka, az azonnal nyomatja a base linux gvim vagy base linux nano csomagokat, nem akasztja meg ez a változás.

gvim az a gui-s frontendje a vim-nek. Ezert mukodik a clipboard. Neovim-nek csak third-party feluletei vannak, amik leginkabb Electronos, vagy Golangos frontendek.
Lenyegeben amit mondasz az egy Arch derivatives-nel pl Archlabs megvan.

Nem. A gvim csomag Arch alatt két vim-et is tartalmaz. Egy grafikus Gtk-s GVim-et (ez az, amiről te beszélsz), és egy terminálos „sima” (karakteres felületű) vim-et is (de ennek is van clipboard támogatása), ez utóbbit használom én.

Ha a sima vim csomagot teszed fel, akkor az csak egyfajta vim-et tesz fel, de az sem terminálra, hanem konzolra van tervezve.

Persze ez Arch alatt van. Más disztrókon annak a kérdése, hogy a disztró készítői a vim-et milyen csomagba milyen compiler flag-ekkel fordították. Az archerek úgy döntöttek, hogy a sima vim csomagban lévő vim-nél kihagyják a clipboard funkciót a fordítás során, míg a gvim csomagba lévő vim-ben meghagyták. Lehet vitatkozni azon, hogy ez mennyire jó ötlet, de önkényesen így döntöttek.

Mivel te Gentoo-t használsz, nálad ez nem probléma, szépen a vim fordításakor bekapcsolod azt az opciót, hogy clipboard támogatás is legyen, már nem is tudom minek hívják ezt a flaget. Ez a vim vs. gvim csomag felrakása csak az Archnál kérdéses, de ez itt pont releváns, mert az Arch topikban vagyunk, nem a Gentoo-sban. De sokan már Archon is egy huszárvágással véget vetettek ennek a kérdésnek, és vim/gvim helyett neovim-et tesznek fel, amiben szintén van clipboard támogatás tudtommal.

van ha aktiv az xsel, vagy xclip.. egyebkent meg nincs.. [link] meg ugyszint akkor tudod hasznalni ha a terminal emulatorban van clipboard tamogatas. egybkent guirol terminalba siman ment eddig is, vica versa voltak gondok. A gvim meg egy gui-s frontend extrakkal. Nem is kerdes, hogy ezert mukodnek benne az altalad emlitett dolgok. Nalam ez valtozo mi van fent, legendas Distro hopper vagyok.

[ Szerkesztve ]

Nem. A gvim csomagban lévő „sima” terminálos vim nem GUI-s frontend. Épp olyan karakteres üzemmódú alkalmazás, mint a vim csomagban lévő vim vagy az mc, ranger, stb.. Fut grafikus felület nélkül is konzolban.

Amiről te beszélsz az a gvim csomagban lévő gvim bináris, ami valóban egy grafikus alkalmazás (grafikus felületen GVim-nek látszódik), aminek kell grafikus felület, X.org vagy XWayland, hogy futni tudjon, különben el sem indul, kiírja, hogy nem talált megfelel display-t.

Amiről én beszélek, az a gvim csomagban lévő „sima” vim bináris. Ez Archon +clipboard és +xterm-clipboard compiler flagekkel lett eleve lefordítva. Emiatt ahogy írod is, működik a vim-ből szöveg kihelyezése vágólapra, amit lát egy grafikus X.org-os progi is, pl. egy Gtk-s Firefox. Akkor is látják, ha nincs xsel, vagy stb.. Ennek viszont feltétele, hogy a vim vágólaptámogatással legyen fordítva. Persze az is kell, amit írsz, hogy a terminál tudjon grafikus vágólapot kezelni, de nem tudom kit hülyítünk, minden közismert terminálemulátor tudja ezt, aki meg valami olyan spéci őskövületet használ, ami ezt nem tudja, az magára vessen.

Archban a gvim és a vim csomag egymást kizárja. Ha fent van a vim, akkor a gvim csomag telepítésénél kérdez, hogy lecserélheti-e a vim csomagot, ha nem engeded meg neki a cserét, akkor a gvim nem települ. Persze nem csak a GVim-et telepíti a gvim keretében, hanem a sima vim-et is, pont ezért van ütközés a két csomag között, mert mindegyik ugyanazt a vim binárist is feltenné.

De ez így van Ubuntu- és Debian-származékokon is, azoknál a vim-gtk vagy vim-gnome csomagban lévő vim (és nem gvim) binárisnak van vágólaptámogatása. A különbség annyi, hogy vágólaptámogatással nem rendelkező vim nincs is ezeken a disztrókon, vagyis van, de azt már vim-tiny-nak hívják.

Engem soha nem zavart a clipboard támogatás hiánya. Kijelölök egy szöveget és középső gombbal (vagy touchpad esetén a 2 gomb egyidejű nyomásával) beillesztem. Nem akarom én nézegetni a vágólapot, nem kell többszörös tartalom, stb.. Mindig az utoljára kijelöltet akarom beilleszteni és ez megy oda-vissza a sima alap vim-el is.

Alex

Igen, ha a terminál emulátorral vágod ki egérrel, akkor nem gond, mert akkor nem a vim küldi vágólapra, hanem a terminálemulátor. De! A vim-nek pont az az értelme, hogy gépírástartásban kapcsolgass a módok között. Ahogy kinyúlsz egérért kijelölgetni, értelmét veszti a vim, annyi erővel használhatnál gedit-et, vagy Kate-et, vagy Geany-t.

A vim-nek pont az lenne a lényege, hogy y-nal (yank) jelölj ki normal vagy visual módban. Így kijelölve viszont a garfikus felület felé nem regisztrálódik, ha nincs a vim vágólaptámogatással lefordítva. Tudom, mert szívtam miatta, meg az Arch fórum tanulsága szerint mások is szoptak miatta.

A sima vim csomag annak van, aki konzolból használja csak a gépet (nem grafikus felület + terminál kombóval), és nem akar GVim-et is feltenni, hanem a legminimalistább akar maradni.

[ Szerkesztve ]

pl nekem arra van, hogy konfigot szerkesszek vele meg esetleg doto-ra vagy notetakingre.

Nekem mindenre van, a vim a fő szövegszerkesztőm, és file viewerem, grafikus felületen is (terminálban), nem csak konzolos felületen. Nem csak erre-arra használom. Vifm-ben még a csoportos átnevezés is vim-ben történik, meg sed/awk helyett is ezt használom, amikor csak lehet. Bashban is vi-módot használok. Meg Bashban is van egy olyan funkció, hogy meg tudom nyitni az utolsó parancsot átszerkesztésre vim-ben, fc paranccsal, vagy Esc + v egymásutánjával is ugyanezt a hatást érem el, ez utóbbi a Bash-féle vim-módban visual módba lép be.

Sőt, a WM-et és a böngészőket is vim-es módban meg vim-addonokkal használom, meg sok más programban is vim-billentyűket (Vifm, zathura, less, neomutt, Termite, stb.). Tehát nálam a vim egy életforma, mivel több mint egy text editor, egyenesen egy interakciós módszer, egyfajta működési filozófia az összes proginak. Kár, hogy nem mindegyikben lehet bekapcsolni, vagy konfigurálni vi/vim-módot.

Sziasztok!

Natív telepíteném az Arch -ot efi módban, /dual boot nincs / de a telepítés felénél a gép újraindításánál a következő hibaüzenetet kapom:

Minimal BASH like line editing is supported. For the first word, TAB lists possible command completions. anywhere else TAB lists possible device or file completions

Mit rontok el, hogy nem jó a grub?

Így telepítettem a grub -ot:

pacman -S grub efibootmgr

grub-install --target=x86_64-efi --efi-directory=/boot

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

Eddig mindent jól csináltál. Futtasd még le pluszban ezt a parancsot:
mkinitcpio -p linux

Gondolom nincs ott a kernel initramfs image a boot partíción, azért nem indul, a GRUB az működik, de nem tud mit elindítani.

Beírtam, de azt mondja, hogy: bash: mkinitcpio not found

Ahhoz lehet köze, hogy az mkinitcpio.conf tök üres. Ez hogy lehet?

Az Arch telepítőmédiáról bootolva futtatod? A partíciók fel vannak csatolva, chroot környezetbe beléptél? Mindezek után kell kiadni. Akkor lehetetlen, hogy ne találja.

Mind igen. Telepítettem az mkinitcpio -t most már van mkinitcpio.conf, de semmi nem változott, most sem jó.

Szerintem kernelt elfelejtettél telepíteni.

[ Szerkesztve ]

You may corrupt the souls of men, but I am steel. I am doom.

Az alap ment fel első körben, annak elégnek kellene lennie, nem?

pacstrap /mnt base base-devel

Nem, mert ezzel, akkor kernelt nem tettél (már). A #6007-es hozzászólásban (és utána) erről van szó.

[ Szerkesztve ]

Ha csalódni akarsz, bízz az emberekben!

Akkor meg is van a gond. Nemrég a base csomagot átrendezték, nem jó a régi telepítési módszer. A base már nem tartalmaz egy csomó mindent, így pl. kernelt és mkinitcpio-t sem. Pár napja variálták át. bob linkelt róla ennek a topikoldalnak a tetején, a #6007-es hozzászólásban, de itt a hír még egyszer.

Szóval pacstappal (vagy chroot környezetben pacmannal) nyomathatod is fel a linux linux-firmware mkinitcpio nano csomagokat is, mint a huzat.

Pont egy olyan szerencsétlen átmeneti időszakot fogtál ki, amikor már átvariálták, meg hír is van róla, de a Wiki-ben a telepítési útmutatóban még nem írták át. Annyira tudtuk előre, hogy ezt jó páran meg fogják szívni

Szerk.: de, át van írva már a telepítési útmutatóban. Ezért kell mindig a legfrisebb Arch Wiki alapján telepíteni, és nem ilyen más weboldalakon közzétett régi ismertetők alapján.

[ Szerkesztve ]

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.

[ Szerkesztve ]

Basszus! Tényleg, még olvastam is Köszi mindenkinek, így már felment.

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.

[ Szerkesztve ]

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

[link]

Egy LTS kerneles Arco linuxot telepítettem és így sajnos az lts kernel indul automatikusan. Hogy lehet megcserélni, hogy a fresh kernel induljon egyből és csak tartaléknak maradjon az lts kernel? ... Grubos bootja van egyébként.

[ Szerkesztve ]

Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.

Az ntfs-3g valóban terheli a procit, de azért 100%-ra nem kéne pörgetnie. Már a második user a héten, aki erre panaszkodik, ráadásul nem csak Arch alatt, szerintem ez egy bug lesz a legfrissebb verzióban. Lehet kipróbálom most már én is, és jelentek nálam hány %-ot eszik az ntfs-3g.

[ Szerkesztve ]

Ugyan nem írta a kolléga, hogy milyen CPU-ról van szó, de nyilván 1 mag futott 100%-on, kérdés az milyen sebességre képes.
Mégpedig valószínűleg pont azért, mert SSD-ről meglehetősen gyorsan lehet olvasni, így valóban az ntfs-3g terhelte. Persze az elért olvasási sebessegről sem tudunk semmit...

Alex

Igazad van, marhaságot írtam, az SSD teszi éppen bottleneck-ké a CPU-t! Egyszóval a lassú HDD esetén nem lenne akkora a terhelés.

(#6041) Frawly

Ne röhögtess így kora reggel! Csak nem fog egyszerre ugyanazon bug egy nyamvadt elavult LTS-en meg a super ropogós rollingon is jelentkezni!
És ahogy a mester is említette, nem volt arról szó, hogy az ntfs-3g terhelné a CPU-t, csak annyi, hogy közel 100-on pörgött, de másolás közben az emberek leállítanak közben minden egyéb folyamatot? Lószart.

Egyszóval amit a kolléga tapasztalt, az maga a normál működés abban a helyzetben. Ki kell lőni a -csába a Wines fs-et és minden OK lesz.

Egyébként meg meg kéne nézni a futó processzeket cli-ben és látható lenne minden, nem kéne itt a Látóasszony topik munkáját átvenni. (gondolom, ha én 1bites Ubuntu származék használóként használom a cli-s rendszer monitorozást, akkor Archereknek ez főleg menni fog)

[ Szerkesztve ]

Én torrentről letöltött filmeket linuxos ssd-ről usb3-as NTFS-es winyóra másolom (TV ezt ismeri fel), de most újra kipróbálva átlag 32%-al pörgeti a sima i3-as intel procimat a másolás (Arch+Openbox), úgyhogy biztos nem normális, hogy 100%-on pörgeti.

Vagy a grub.cfg-t szerkeszted közvetlenül (set default), vagy az /etc/default/grub-ot és legenerálod újra, a sor amin változtatnod kell: GRUB_DEFAULT=0. 0 helyett annak a menuentry-nek a számát, ami a kívánt kernelt tartalmazza.

Én ilyenre inkább exFAT-re formázott USB-s külső HDD-t használok. Hamarosan véglegesen bekerül a kernelbe a Microsoft-os exFAT implementáció, így natív lesz a sebessége. Eddig minden cucc (régi 2012-es TV, Dune HD médialejátszó, stb.) szépen kezeli, probléma nélkül. Szvsz érdemesebb átváltanod rá.

Ha csalódni akarsz, bízz az emberekben!

Most látom, hogy már az elnevezéssel is lehet hivatkozni rá: https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Changing_the_default_menu_entry

Szerintem megadtad a választ is: HDD-re másolod... Ott nyilván az írási sebesség lesz a szűk keresztmetszet.

Alex

Az emlékezetemben nekem már úgy élt, hogy az AMD procikhoz külön csomag van. Most jutott eszembe ez a hozzászólásod, így megnéztem gyorsan a microcode wiki history-t. Jól emlékeztem, az a jó pár hónapja egészen pontosan 2018 augusztus 26-án volt.
Nyilván azóta ránéztem már az oldalra, ezért emlékeztem...

Alex