- SkyShowtime
- Musk átirányította a Teslának szánt AI-chipeket
- DIGI kábel TV
- Gyorsabban hozná el az önvezetést Kína
- Megpróbálják a spanyolok: megvédenék a gyerekeket a közösségi médiától
- Microsoft Excel topic
- Otthoni hálózat és internet megosztás
- Windows 10
- Facebook és Messenger
- Mesterséges intelligencia topik
-
IT café
Arch Linux topik
Új hozzászólás Aktív témák
-
A partclone tud fizikai lemezről fizikai lemezre partíciót másolni? Ha igen milyen paraméterek kellenek ehhez? Tudna valaki egy példa parancsot írni, ahol ext4 partíciót másol egyik lemezről a másikra partclone-val? Erről nem találtam leírást, csak arról hogy lehet vele partíciót image fájlba menteni. Gondoltam hogy a frissen belakott friss arch telepítésemet átmozgatnám az 500-as crucial-ról az 1tb-os 860QVO-ra. Ha sikerült átmozgatni a partíciót akkor milyen parancsokkal kell átméretezni a partíciót és az ext4 fájlrendszert ? Mert ugye a céllemez nagyobb mint a forrás.
[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
baloo79
tag
-
válasz
baloo79
#7952
üzenetére
A partclone-val valóban át tudom másolni a partíciókat, viszont utána átméretezni sehogy sem lehetett az így átmásolt partíciókat, és más gondok is voltak, pl újraindítás után elvesztek az átmásolt partícióra írt fájlok, stb, ez azért lehet mert a clonezilla a gpt-uefi vel hadilábon áll. Inkább megoldanám közvetlenül partclone-val ha lehetséges.
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
válasz
Shyciii
#7950
üzenetére
Szerintem ez nem kell, ha amúgy nincs problémád a bootolással és a GPU-t használó alkalmazásokkal, akkor nem szükséges belebarmolni az mkinitcpio.conf-ba. Ha viszont van, és Intel GPU-t használsz, akkor igen, az i915-öt a MODULES sorba bele lehet tenni, próbaképp. Azért írtam fentebb, hogy nálam ez amdgpu KMS driverrel működött, de akinek hasonló problémája van, hogy nem megy neki valami, vagy esetleg bootkor a kernel behányna ilyen zavaró hibasorokat, akkor ezzel a beállítással sanszos, hogy megszabadulhat ezektől. Rémlett, hogy egy oldallal ezelőtt egy másik kollégának két AMD-s gépen is volt ezzel gondja, egy dedikált és egy integrált AMD GPU-val is.
Ilyen intel_agp meg kötve hiszem, hogy manapság kell bárkinek is. Ez valami nagyon régről maradhatott benne a Wiki-ben.
-
Frawly
veterán
válasz
attilav2
#7953
üzenetére
Ha tényleg nagyobb a céllemez, mint a forrás, akkor nem kell semmilyen clone-szutyok. Először megparticionálod a céllemezt, akkora partíciókkal, amekkorákat akarsz rá. Aztán a sudo dd if=/dev/akármi[partíciószám] of=/dev/másikeszköz[partíciószám] bs=32M status=progress paranccsal átklónozod őket egyenként.
A végén még szükséges, hogy az átklónozott partíción a fájlrendszert a sudo resize2fs /dev/cél[partíciószám] segítségével, hogy ténylegesen is kitöltse a rendelkezésére álló nagyobb partíciót.
Ha bootmeghatjó, akkor még szükség lehet a bootloaderben a kernelparamétereknél a root partíció PARTUUID-jének átírására, illetve a /etc/fstab-ban is az UUID-ket átírni, mert azok ezzel a módszerrel változhatnak.
Egyébként szerinte a clonezillának sem lehet baja a GPT-UEFI-vel. Semmiben nem bonyolultabb, mint az MBR Legacy Boot. Annyi, hogy át kell klónozz egy FAT32 partíciót. Igazából az UEFI boot nem hogy bonyolultabb, de egyszerűbb, ha megérted hogyan működik.
Egyébként dd helyett működne a fájl szintű átmásolás is, rsync-kel vagy tar-ral, de az bonyásabb, bár annyi előnye lenne, hogy a nem használt szektorokat nem másolja át feleslegesen.
[ Szerkesztve ]
-
A dd ről azt mondják hogy egyszerű és jó eszköz, viszont az üres blokkokat is átmásolja ezért általában lassú.
Arch wikiben ajánlják az e2image-t ext fájlrendszerek másolására:
File system cloning
Using e2image
e2image is a tool included in e2fsprogs for debugging purposes. It can be used to copy ext2, ext3, and ext4 partitions efficiently by only copying the used blocks. Note that this only works for ext2, ext3, and ext4 filesystems, and the unused blocks are not copied so this may not be a useful tool if one is hoping to recover deleted files.
To clone a partition from physical disk/dev/sda, partition 1, to physical disk/dev/sdb, partition 1 with e2image, run
# e2image -ra -p /dev/sda1 /dev/sdb1Ez akkor most úgy működik hogy a céllemezen létrehozom az üres ext4 partíciót és a forráslemez ext4 partíciójáról átmásolom az adatokat e2image-vel a céllemez ext4 partíciójára(a wiki-ben megadott paraméterekkel)? Használtál már e2image-t klónozáshoz? Az e2image talán gyorsabb lenne mint a dd mert csak a használatban levő blokkokat másolja, az üreseket nem.
Szerintem a nem használt blokkok átmásolása egyébként sem tenne jót az ssd-nek, ezért ssd-hez ideálisabb olyan tool ami kihagyja az üres blokkokat.[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
válasz
attilav2
#7956
üzenetére
Igen, írtam, hogy a dd az üres blokkokat is átmásolja, de ez nem tragédia. Írtad, hogy SSD-ről van szó, azon eleve nem tart sokáig, másrészt szekvenciális művelet, ami egy HDD-n sem annyira rettenet lassú.
Ez az e2image is megfelelő lehet, bár nem ismerem, így ebben nem tudok segíteni, hogy hogyan használd. Max utána tudnék olvasni, de azt te is meg tudod tenni magadtól.
Amikor én csináltam ilyet, akkor tömörített tar-t használtam:
cd /
sudo tar -czfpv --one-file-system /cel/backup.tar.gzMajd ezt bontottam ki a céllemez előre létrehozott partíciójával
sudo tar -xzfpv backup.tar.gz /cél/felcsatolás
(ebből a -p nem is feltétlen kellett volna, a -v csak a fájllistázáshoz van, a z=gzip, de lehetett volna használni -j, -J, --zstd vagy egyéb kapcsolókat helyette)
De lehetett volna így is, pl. root partíciónál, az előre létrehozott, formázott, és felcsatolt célpartícióra:
sudo rsync -avHASX / /cél/csatolás/
Ez is kicsit overkill, mert szerintem elég lenne az rsync -a, a többi kapcsolónak nem lenen szerepe egy átlagos rendszeren.
Az rsync előnye, hogy előbb nem ment tömörítvénybe, hanem közvetlenül másol forrás és cél között. A tar viszont jobb, ha el is akarod tenni a mentést backupként.
[ Szerkesztve ]
-
Végül némi kínlódás után sikerült rsync-el átklónozni a fájlrendszert, nem az általad ajánlott kapcsolókat használtam, hanem az Arch rsync wiki File system copy pontjában ajánlott kapcsolókkal oldottam meg. Futó rendszerről a céllemezre nem tudtam átklónozni a rendszert mert a rsync hibára futott. Bebootoltam a MagyArch telepítővel(ami live rendszer is), majd terminálban sudo passwd root, majd su, felcsatoltam csak olvasható módban a forrásmeghajtót(ext4 root filerendszer) a home könyvtárban létrehozott MX500 mappába, a célmeghajtót partícionáltam formáztam, majd a root partíciót felcsatoltam az /mnt alá. Majd következett a fájlrendszer másolás:
rsync -qaHAXS --progress=2 MX500/ /mnt
Azt googlezás után megállapítottam hogy a forrás csatolási pont után / jel szükséges, különben a forrás csatolási pont tartalma nem a célmeghajtó gyökerébe hanem az MX500 könyvtárba kerül
A --progress=2 vel állítólag gyorsul a másolás, ami igaz lehet mert elég gyorsan végzett Ezután kijavítottam a uuid-ket az fstab-ban, majd csatoltam a boot partíciót
a /mnt/boot alá, utána arch-chroot /mnt, majd pacman -S linux amd-ucode, bootctl install, szerkesztettem amit kell, és máris bootolt az átklónozott rendszerMint az látható a MagyArch iso, de akár a CalamArch iso is(kipróbáltam), alkalmas az Arch hagyományos kézi telepítésére/klónozására, közben gui-s böngészőben -firefox- tudjuk nézni az Arch wiki-t, rágooglezni valamire. Mondjuk a CalamArch nál kicsit trükkös magyar kiosztást beállítani
[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
válasz
attilav2
#7959
üzenetére
Örülök, hogy sikerült. Ez a másik szépsége a Linuxnak a Windowszal szemben, hogy nem csak szektor alapon lehet klónozni, nincsnek rejtett szektoros trükkök. Simán fáljalapon másolható.
Az rync kapcsolói nem fontosak. A nagybetűs kapcsolók csak nagyon speciális esetben fontosak, a --progress 2 semmit nem gyorsít (azért volt gyors, mert SSD-ről volt szó, nem a kapcsoló miatt), igaz ezek a sebességen nem is rontanak. Ha az Arch Wiki így ajánlotta, akkor jónak kell lennie.
Természetesen bármi alól csinálható, még csak Arch alapúnak sem kell lennie, csak legyen rajta egy konzol, shellel meg rsync-kkel. Ez megint csak a CLI toolok szépsége, nem kell neki GUI, meg 1-2 gigás Live iso, és hasonló extrák.
Ez az rsync nem csak rendszerklónozáshoz jó, hanem backup készítéséhez, gépek közötti adatátvitelnél is jól hasznjálható, sokoldalú alapparancs, megéri ismerni a használatát. Szerintem a kapcsolói kicsit hülyék és komplikáltak, de simán megtanulható.
-
anorche1
őstag
Szeretnek uefi modban archot telepiteni egy acer aspire e5-532-p78v laptopra.
A sajat leirasomat kovettem, ami alapjan a dell e6440 -emre mar tobbszor sikerult feltelepitenem.Egyszeru tortenet, sda -n 2 particio, az elso 256MiB -os fat32 -re formazott, a masodik ext4 -re formazott. Sda1 /mnt/efi -re csatolva, az sda2 / -re.
Ezutan kovetem arch wikit.Grubot telepitesenel ezt csinalom:
grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB
pacman -S intel-ucode
grub-mkconfig -o /boot/grub/grub.cfgA laptopomon ez igy tokeletes, az aceren is lefut hiba nelkul, de restart utan no bootable device.
Probakent felraktam egy manjarot, azzal nem volt gond, az bootolt. De az rendszerbetoltesre mintha nem grub -ot hasznalna.
/boot/efi/EFI/Manjaro mappaban volt a grubx64.efi fajl
de volt egy /boot/efi/EFI/boot mappa, amiben ha jol emlekszem talan egy boot.efi fajl.
Ez utobbit kitorolve mar nem bootolt be tobbet, szoval ez lehet a kulcs.
Grub helyett probalkozzak meg systemd boottal? Vagy lehet csak annyi a gond, hogy en a grubot /efi -be telepitem, /boot/efi helyett?"It never gets easier, you just go faster." Greg LeMond
-
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.
-
anorche1
őstag
chroot utan telepitem a grubot, ugy a /efi a helyes.
De kozben rajottem, valoban az acer bios/uefi/firmware -je a ludas. Secure bootot vissza kellett kapcsolni, utana security fulon trusted efi file -nak kijelolni a grub efit, utana secure bootot ujra kikapcsolni, es mukodik.
Bár az is furcsa, amit írsz, hogy /mnt-be csatolod, az EFI partíciót /boot-ként szokásos felcsatolni.
Arch wiki install reszebol:
"mount /dev/root_partition /mnt
Create any remaining mount points (such as /mnt/efi) using mkdir(1) and mount their corresponding volumes. "root -nak /mnt -t ir, majd /mnt/efi -t emlit. De ha boot/efi -t szoktak, akkor legkozelebb oda teszem, nekem aztan mind1
[ Szerkesztve ]
"It never gets easier, you just go faster." Greg LeMond
-
Kíváncsiságból kipróbáltam a dhcpcd-t, előtte systemd-networkd és systemd-resolved volt(a régi telepítésemen pedig networkmanager, de bloatnak találtam így az újrahúzáskor már mellőztem), gondoltam kiváltom egy szolgáltatással, kikapcsoltam mindkét szolgáltatást(systemd-networkd systemd-resolved), rebootoltam majd systemctl enable dhcpcd@enp5s0 az már gyanús volt hogy az indulása eltartott kb 5mp-ig, de utána működött a net bármiféle külön resolver indítása nélkül, ez elsőre tetszett, de rebootkor jött a fekete leves a systemd rendszerindításkor vár a dhcpcd szolgáltatás elindítására kb 5-10mp-et
Próbáltam konfigurálni a systemd-t már amennyire értek hozzá, egyszerűbb beállításokat változtattam az /etc/systemd/system.conf-ban:
DefaultTimeoutStartSec=3 -al próbálkoztam, de így a dhcpcd nem tudott elindulni, felemeltem 5-re, úgy sem, majd 10-re és így már indul bootkor a dhcpcd. A systemd-networkd systemd-resolved párossal semmilyen problémám nem volt.
Lehet valahogy diagonosztizálni mi akasztja meg ennyi időre a dhcpcd indulását?
Vagy váltsak valami systemd mentes Arch klónra?Na az arch wikiben meglett a megoldás:
https://wiki.archlinux.org/index.php/Dhcpcd#dhcpcd@.service_causes_slow_startup
Működik, nem gondoltam volna hogy egy ilyen szögegyszerű szolgáltatással mint a dhcpcd gond lehet, egyszer kipróbálok egy systemd mentes arch klónt [ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
válasz
Shyciii
#7967
üzenetére
Akkor minimalista rendszert használsz. Nálam legalább 2-3 giga minimum, gondolom a KDE miatt. Szoktatom magam a Sway-hoz, de még ott is 1.5-2giga a foglalás egy idő után gondolom a sok háttérszolgáltatás amit a KDE felrakott. Szerencsére legalább 4 ssd-m van a gépbe így tudok különböző rendszerekkel kísérletezni, ki kell próbáljam a minimalista Arch telepítést, vagy egy systemd mentes Arch klónt, ez utóbbiból tudtok ajánlani párat?
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Shyciii
veterán
válasz
attilav2
#7968
üzenetére
Hát elég minimalista rendszert használok Bspwm-el. Helyenként túlzóan is. Pl az usb-s háttértárakat egy script oldja meg, de pl használok network managert hiába bloat, mert ez egy notebook, így kell kényelmes wifi választán, vagy openvpn-es csatlakozás.
Én nem ismerek teljes systemd mentes arch klón-t, csak az Artix Linux-ot, ami részben systemd mentes, de azért van benne egy-két ráutaló jel. Asszem tán az elogind pl., s-ig systemd-mentes. -
Frawly
veterán
válasz
Shyciii
#7967
üzenetére
Ez néha ugrál, majd mikor 178-at ír, akkor hagyjad futni a watch free -mw parancsot, és látni fogod, hogy egy idő után (10-20 mp.) visszaugrik ~140 MB környékére. Az teljesen jó. Le lehet menni egyébként ez alá is, de csak systemd-mentes disztrón, és annyira ultraminimalista megoldásokkal, hogy szerintem nem éri meg, mert használhatatlan lesz a gép, nem tudsz hatékony workflow-t kialakítani. Ez a ~140-170 MB ez teljesen jó, már kellően minimalista, hogy atomgyorsan, pattogósan fusson, de még kellően rugalmasak ezek a bspwm, Sway, stb. szintű dolgok, hogy bármilyen workflow-ra be tudod configolni őket.
#7968 attilav2: Nyilván úgy a Sway-nek meg a akármilyend-ket elhagyó minimalizmusnak nincs értelme, hogy a sok KDE által feltelepített szutyok továbbra is fut, meg mindenből olyan progikat használsz, amik betöltik a Qt-hegyeket. Minimalista rendszernél nem csak az OS meg az init service-ek minimalisták, hanem a progik is, többségében terminálos, CLI-TUI megoldások. Nyilván nem mindenben, mert pl. a grafikus bloat böngészőket nem lehet kiváltani, meg ha kell Wine, Steam, videóvágó progik, vagy hasonló, akkor annál sem lehet megúszni a bloatot. Ez nagyban attól is függ, hogy mire használod a gépet.
Egyébként a KDE-vel, Cinnamonnal, stb. sem lenne baj, csak bloat és nagyon windowsos szemléletű. Ennek ellenére kezdőknek kiváló, az első linuxos hónapjaikban, de ha már elértél egy szintet, akkor érdemes túllépni rajtuk.
Épp így, ahogy a kolléga is észrevette, hogy felesleges a GRUB, meg ahogy te is észrevetted, hogy felesleges a systemd-networkd, meg egyéb szutykok, úgy még elég sok ilyen sallangot lehet kilőni, ha ezeket nem tölti be a gép, máris sokat gyorsul a boot, betöltési idők, stb.. Csak azért, mert a gépnek nem kell betöltenie egymásra épülő sallangokat. Ezt nem érti ubyegon, hogy nem arról van szó, hogy ezek a sallangok ne férnének el 8-16 GB RAM-ba, hanem mikor ezeket kell a RAM-ba töltögetni, akkor az a procinak is munka, a felhasználnak plusz latency, és mindegyik csak egy apró, pár msec, de mikor sok ilyen egymásra épülő szutyok összejön, egyik 10, másik 50, harmadik 100 megákat töltöget be, akkor tudnak belassulni a dolgok.
systemd-mentes Archot viszont nem ajánlom. Még többet is foglalnak a memóriából, mert egyszer fut a saját initrendszerük, meg még rá a különböző systemd-pótló megoldások (elogind), és ezek együtt többet kitesznek, mint ha csak systemd-t használnál önmagában. Persze próbálkozhatsz vele, pl. Artix Linux, hátha bejön, de sok előrelépésre ne számítsál.
Főleg akkor nagyon kínszenvedés a systemd hiánya, ha ilyen KDE meg hasonló megoldásokat futtatsz, mert azok extrán igényelni szokták a sok szutykuk futtatásához. Gnome, Xfce is.
Igazából a Sway is támaszkodik a systemd-re, de csak a logind részére, de még ezt is át lehet hidalni elogind nélkül, a Gentoo Wiki-nek van erről valami cikke emlékeim szerint, hogy scripttel hogy lehet ezt kiváltani.
-
-
Artix-openrc, blackbox memóriafoglalás, friss virtualboxos telepítés:
~70mb
Első benyomások alapján komplikáltnak tűnik ez a systemd nélküli lét, a konfigfájlok több helyre vannak szétszórva a vanilla Arch-hoz képest. Szolgáltatások engedélyezése, letiltása is komplikáltabb. Office-olós/youtube-ozós átlag desktop usernek bőven jó a systemd, sőt neki az az optimális. Aki meg szereti a rendszerét állandóan faragni annak jó az initscriptes rendszer.
Ja és nem kapcsolja ki a gépet shutdownkor, legalábbis virtualboxban nem, szinte minden disztró amit eddig vboxban próbáltam ki tudta kapcsolni a virtuális gépet, ez megakad itt:
[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
válasz
attilav2
#7972
üzenetére
Ebből a memóriafoglalásból nem lehet kiindulni. Csalóka. Virtuális gépben futó rendszernél nem lesz GPU driver, nem lesz hardveres gyorsítás, nem fut mesa, nem fut kompozitor (jó ennek nem is kell más rendszeren sem), nem fut hangdriver, stb.. Úgy persze, hogy kevesebbet foglal. Igazi gépen nézd, ott bőven lehet kb. ugyanez a rendszer az általam írtakkal 200-250 MB is, ha valami komolyabb dedikált GPU-d van, vagy modern AMD APU. Intel IGP kicsit soványabb, de ott is meglesz vagy 150 MB körül.
A megakadás kikapcsoláskor is lehet ACPI driver meg nem felelősége, ez igazi gépen nem lesz problma. Initrendszer ízlés kérdése. Artixot mindjárt háromféle inittel is lehet telepíteni. Nekem egyébként a systemd-vel nem is a tulajdonságai, memóriafoglalása a bajom, hanem hogy minden dependel rá, és nem lehet elhagyni maradéktalanul. Itt a képeden is bizonyíték, hogy ott fut az elogind, ami systemd-logind részimplementációja, ergo nem kerülted ki teljesen.
A másik baja az alternatív initnek, hogy a bootidejük általában kicsit lassabb, és a disztrónak sok csomagot patchelnie kell, hogy menjen nem systemd-inittel, és emiatt kicsit lassabban érkeznek meg az újabb verziók bele. Szóval ez a systemd-nélküliség kétélű fegyver.
[ Szerkesztve ]
-
Sway ~150mb-ot eszik ezen a vboxos artixon, blackbox 75mb-ot eszik.
Mikor feltettem a firefoxot magával húzott vagy 600 megát, és ha elindítom akkor ~300 megára felugrik a memória foglaltság. Artix-on egy csomag több tárolóból is elérhető community, galaxy, stb ez újdonság az Arch-hoz képest.[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
válasz
attilav2
#7974
üzenetére
Nem blackbox hanem az Openbox eszik 75 megát, elírtam. Blackbox memória fogasztásáról már írtam.
Érdekes hogy ezek az Xorg-os wm-ek a Sway-nál jóval kevesebbet esznek.
[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
válasz
attilav2
#7975
üzenetére
Nekem fordított irányú a tapasztalatom, és nálam a Sway eszik kevesebbet, igaz két különböző gépen néztem, ahol az eltérő méretű driverek jelenthetnek különbséget, az egyik Intel IGP-s gép, a másik AMD APU-s. Az intelesen a Sway majdnem 100 megával kevesebbet eszik, mint az AMD-sen a sokkal minimalistább X.org + dwm.
Mint mondtam, virtuális gép alatt sose fogsz valós számokat, valós viselkedést látni, ahhoz fel kell tegyed fizikai vasra, rendesen. Nem csak a GPU miatt, hanem pl. hangdriver, Pulseaudio, egyéb szutyok is fut egy átlag desktop rendszeren, míg virtuális gépben, ha nincs hangeszköz, nincs hardveres GPU gyorsítás, akkor egy csomó driverrel, kernelmodullal kevesebb is fut. Egy zárt NV driveres rendszeren ez elvileg még rosszabb, főleg, ha a user még egy csomó más hardvert is hajt róla. Tehát az, hogy minek mekkora a fogyasztása, az elég gépfüggő is, meg attól is függ, hogy ki mire használja a gépet.
Amit ilyen virtuális gépekben, mindenféle extra hardveres körítés és virtuális extension nélkül látsz memóriafoglalási adatokat, azok csak elvi minimumok. Lehet ilyeneket a valóságban is elérni, pl. egy Gentoo + X.org + dwm trióval, ha nem fut GPU driver, nincs még hang, stb., akkor esetleg, pl. ilyen beágyazott rendszereken. De desktopnál, amin böngészel, meg használsz mindenféle programot, ott a 100 mega alatti foglalás irreális. Akármi az initrendszer.
-
Na betöltöttem az alsát és a pulse-t az artixon, youtube videót játszok le firefoxon Blackbox alatt, a memória fogyasztás közel 600mb!
[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
válasz
attilav2
#7977
üzenetére
Na, látod, erről beszéltem. Ha feltennéd a VBox Guest Additions-t is, azaz a hozzá való KMS modulokat az Artix tárolóiból, meg belövöd rajta a hardveres gyorsítást, meg még nyitsz pár böngészőfület, és máris még jön rá jó pár mega. Azért is mondtam, hogy van egy gyakorlati minimum, amit figyelembe kell venni, és nem szabad ilyen kérdésben sem sznobságból túlzott, értelmetlen minimalizmusra törekedni, mert azért a hardvereket meg kell hajtani, kellenek a különböző gyorsítások, ha az ember tartalmat fogyaszt, böngészik, esetleg játszik, stb..
Mint írtam, gépfüggő is, mert vannak emberek, akinek a nyomtató miatt CUPS, szkenner miatt Sane modulok, PPP csatlakozó egyes hálózati kapcsolatokhoz, webkamera, ujjlenyomatolvasó, stb. szutykok is igényelnek futó drivert, ez szépen mind jön rá.
De ez nem csak Linux alatt van így. Amlékszem anno XP is, mikor 140 MB-ot evett a rendszer boot utáni idle-ben, ahogy felment pl. egy bloatabb HP vagy Samsung, Cannon nyomtatódriver, máris megugrott közel 300-ra. Csak egy darab drivertől. Ha még jött rá ilyen Radeon Catalyst a .NET szutykaival, meg egyéb tálcaalkalmazások (pl. Intel RST, Creative Control Panel, stb..), máris hízott tovább.
-
-
Frawly
veterán
válasz
attilav2
#7979
üzenetére
VGA gyorsítást én ebben nem látok. A Firefoxot hagyd le, mert zavarja az adatok kiértékelését. Kicsivel több lett a fogyasztás, de nem annyival, mint vártam, talán mert nem fut 3D gyorsítás vagy nem tudom. Mondom, ez a mennyi az az annyi, azt akkor látod meg, ha fizikai gépre teszed fel, olyan rendszerre, amit tényleg használsz is napi szinten. Pl. egy 16 gigás pendrive-ra, vagy egy külső SSD-re vagy HDD-re.
Na meg ilyen virtuális gépen természetesen nem csak az Artix fogyaszt kevesebbet, de egy systemd-s Arch is. Ha már életszerűtlen környezetben hasonlítunk össze.
Egyébként Archon nálam még mindig fut két extra nyomorékság, amit sosincs időm kihekkelni, valami spi2 görcsség, meg polkit baromság, természetesen egyik se kéne, és sokat foglalnak. PulseAudio helyett lehetne apulse-t használni. picom kompozitort már régóta elhagytam, igaz így nincs árnyék meg átlátszóság, de nem sok különbség van szemre, vsync viszont épp így van. Háttérképnél is elértem, hogy a feh vagy xsetroot nem marad betötve, hanem kilép, miután lecserélte a hátteret. De még mindig érzem, hogy lehetne még mit minimalizálni a rendszeren, igaz már sokat nem nyerek vele, 1-2 folyamatot lehetne még megúszni, meg alig néhány MB memóriát lespórolni, de egy idő után az ember elég egy olyan minimalista korlátot, amit már nem lehet meghaladni, vagyis legalább úgy nem, hogy a rendszer általánosan használható desktop marad, ami mindenre használható.
Plusz nálam pl. olyanok is futnak, mint ntpd, amire nagy szükségem is van, mert ezen az új gépen hajlamos a gépóra sokat késni. A másik, régi laptopom meg asztali gépen ez nem jellemző, ott csak eseti jelleggel futtatnék NTP-t, de ezen a gépen hatványozottabban kell, meg ez a pontos idő nálam mánia is. Megint: hardverfüggő is.
Ez ilyen, ez egy folyamat, idő kell neki. A minimalizmus sose olyan, hogy meg lehet erőszakolni 5 perc alatt. Próbálkozni kell többször, új megoldásokat felfedezni, configokkal kísérletezni. Egy min. több éves utazás.
-
Most az i3-gaps WM -et raktam fel natív Arch-ra, ez X-es és legalább minden app fut, Sway -en sokminden nem indul el, ha bekapcsolom az xwaylandet és olyan appot indítok ami igényli akkor kidob koznolra a Sway, nincs kedvem debugolni, meg nem is értek ennyire mélyen a rendszerhez. Át chromecastoltam chrome-val tv-re az i3 képét, míg KDE-n ez a művelet 100%-on pörgette a procit, itt beérte a chrome 50%-al, és a chromecastolás befelyezése után a terhelés visszaesett a normál terhelésre 5-10%-ra, ez KDE esetén marad 100%-on és csak a restart segít. A tiling wm mintha tv képernyőre termett volna sokkal kezelhetőbbnek tűnik tv-s böngészésre, online webes videózásra. A memória foglaltság a chromecastolás alatt ~1gb körül volt, ez a KDE alatti chromecastoláshoz képest nagyon jó! Gondolkodok pl egy Rock Pi X x86-os sbc beszerzésén, ebben csak 4gb memória van, de pálcika wm-ek mellett ez bőven elég lenne, kifejezetten tv-s böngészéshez venném. Openbox-al is próbálkozni fogok(virtuális gépen nagyon jók a memória foglaltsági tapasztalataim), már fel is tettem a natív rendszerre, csak ezt bonyolultabb testre szabni mint a sway/i3-at, jól jönne ha megdobnál néhány példa konfiggal, leírással. Felfedeztem ha rendszerindítás után egyből KDE-t indítok és kilépek belőle konzolra akkor a szutykai a memóriában maradnak, sokszor igen magas proci terhelést okozva, amin csak a restart segít. Ha indítás után közvetlenül sway/i3-at indítok akkor sokkal pattógósabb a gép töredék a proci terhelés és a memória foglaltság, és még a chromecastolás is 50%-al kevesebb procit fogyaszt, még akkor is ha webes videót nézek közben, tehát a pálcika wm-ek használhatóvá tették a chromecastot de az 50%-terhelés még mindig sok, ezen lehetne még kicsit faragni ha linux szakértő lennék, de sokat faragni nem lehetne belőle valószínűleg, talán egy -10%-ot. Windows alatt a KDE-hez hasonlóan szintén közel 100% terhelés van chromecastolás közben.
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
válasz
attilav2
#7981
üzenetére
Sway konfigom feltölhetem neked a pastebin-re, de sokra nem mennél vele, mert egy majdnem teljesen stock Sway config, amit elérsz a /etc/sway/config vagy /usr/share/doc/sway/ alatt.
A konfig egy része amúgy is az én felhasználásomra van, keybind-ek, pl. meg billkiosztás, egyes hardverek pollrate-je, ID-je, ezzekkel semmire nem mennél. Ráadásul én a Sway-t és az i3-at is tabbed layoutban használom szinte kizárólag, nem tilingban, semmi extra layout, semmi gap, semmi cicomázás, nincs ablakkeret, nincs fejléc, nincs semmi, szerintem a falnak mennél tőle. Tehát a Sway konfigom egyik része neked teljesen irreleváns lenne, a másik része meg teljesen default, az i3-as konfig meg már meg sincs.
De igen, ezt nem hitted el, hogy a minimalizmus nem csak gyenge hardveren kamatozik. Az egész futási teljesítmény, lagok hiánya, prociterhelés, stb. is egész más, más használni a gépet. Ezek a KDE szintű monstrumok annak lettek kitalálva, aki modern, erős hardveres használja, windowsos desktop mentalitással, és nem akar azon a szinten túllépni, hogy egérrel kattintgat ikonkra. De hogy ilyen cast, szerver, meg hasonló spécibb dolgokra is van használva, ott már kijön a tiling meg a minimalizmus rugalmassága, aki ehhez hozzászokott, már nem fog visszatérni hagyományos DE-kre, mert túl korlátosnak, lassúnak, rugalmatlannak fogja érezni.
-
Nem i3/sway példa konfig kell, hanem Openbox, azt nehezebb élhetőre testreszabni, ha esetleg van Openbox konfigod megoszthatnád, meg leírhatnád azt is hogy milyen kiegészítő app-okat használtál openbox-hoz.
[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
válasz
attilav2
#7983
üzenetére
Itt el tudod érni a konfigom Openboxhoz. Egyben illesztettem be, az eleje a ~/.config/openbox/autostart script, a második bekezdéstől pedig a ~/.config/openbox/rc.xml.
Amiket használtam: picom kompozitor yshui forkja (ezt később dobtam), polybar panel, dmenu, xss-lock, synclient (Synaptic-kompatibilis touchpadhoz többujjas bindek), xbindkeys a multimédiagombokhoz, feh a háttérkép beállításához. Termite terminál, saját scriptek, képernyőkímélő asciiquarium teljes képernyős terminálban futtatva és transzparens i3lock-kal zárolva, képnézőnek imv, videók és audió lejátszsára mpv, pdf/ps/djvu nézésére Zathura, neovim szövegszerkesztésre, Vifm fájlkezelésre, csatolásra saját script, sok scriptem fzf-választót használ (az fzf ugyanolyan, mint a dmenu, de terminálban fut és rugalmasabban keres). De szinte minden megoldásom terminálos, pl. htop és hasonlók, majdnem mindent saját script végez, SSD infók kiírása, kézi fstrim, hangerő szabályozására pamixert használó script, vagy pulsemixer (amit látok te is használsz), torrentnek transmission-cli tremc terminálos klienssel vagy webes klienssel (böngésző), de mostanában btcli-vel kísérletezek helyette. Időjárás nézésére curl wttr.in. NTP-re ntpd, fényerőszabályozásra light, emellett redshift-script, screenshotozni scrot (Sway alatt grim), androidos teló csatolására jmtpfs script. Wi-Fi-hoz egyszerű wpa_supplicant + dhcpcd scripttel csatlakozok egy lépésben. Számológépnek calc (ez egy terminálos progi), illetve Python-értelmező. Login manager nincs, közvetlenül konzolban jelentkezek be, és bashrc-be az adott felhasználó/tty[szám] kombóhoz drótoztott WM indul el előre megadott xinit-scripttel.
A WM-ben a legtöbb progi Super+A-Za-z gombokra indul, speciális funkciók Super+1-9, Super+F1-F12, Alt-Tab, Alt F1-F12, PrnScr, stb. billentyűkre érek el funkciókat.
Egyébként most is ezeket használom kb., de dwm alatt, de a polybar helyett a dwm saját panelja megy egy dwmbar-script segítségével kiírva rá a doglokat, i3lock helyett alock, nem fut már kompozitor, médiagombokat is a dwm kezeli xbindkeys nélkül. Elkezdtem clipmenud-vel is kísérletezni, de ez nem jön be.
Mindenre próbálok vim-es kiosztást használni programon belül, minden mappára át tudod váltani közvetlenül fd + fzf kombót használó scripttel, minden doksim megnyitom fzf-es scripttel, 1-2 billetnyű lenyomása után ott van, akárhány almappa mélységben, az adott mappán, adott doksinál. Így 1-2 billentyű lenyomására gépírás módban ott van minden az ujjam alatt, az összes fontos program, mappa, doksi, azonnal nyílik, lag, betöltési idő nélkül, a billentyűt nincs időm felengedni, már a képernyőn van. Nincs grafikus tallózás, nincsenek ikonok, nincsen dokk, nincs tálcaapp, nincs egerezés, csak egész képernyős programok, gap, keret, fejléc, toolbar, menüsor, akármi nélkül. Tiling módba ritkán váltok, ha több mindent kell látni, vagy át kell tekinteni, hogy mi fut (a KDE érzékeny sarokmegoldása ihlette), ilyenkor az alap master-stack layoutot használom, ami default az összes tiling WM-ben. Nyilván ez Openboxnál nem játszik, de annak van saját taskváltó listája helyette.
Firefox a böngészőm, benne Tridactyl addon, ami vim-módban kezeli a böngészést, billentyűkkel, egeret így itt is alig használok (kivételesen igen, pl. a vim-es billentyűk miatt nem működne a YouTube-on a webes videólejátszó gyorsbillentyűi, így itt automatikusan kikapcsolódik a vim-mód, és egeret is használok, de nem is az egér a jó szó, hanem touchpad gesture-öket). Ténylegesen egeret csak akkor használok, ha FPS, TPS, szimulátor játékkal játszanék.
Kicsit külső szemmel figyelve olyasmi mikor a gépet használom, mintha MS-DOS-t használnék, billentyűzet, terminál, teljes képernyős szöveges progik, 0 betöltési idők. Alig-alig van grafikus progi, Firefox, Goldendict, 1-2 alkalmazás ritkán Wine-ban (pl. Scriptum GIB szótár), Steam, néhány játék (vegyesen natív linuxos, és windowsos Wine-ban).
De mégse DOS, mert nem legacy rendszer, hanem modern 64 bites, legújabb verziók, modern programok, ha valami régi is (pl. vim 90-ből, ami a 70-es évekbeli vi-ra megy vissza), annak is modern változatát használom (neovim), vagy kétpaneles fájlkezelő (ami a Norton Commanderre megy vissza, ehelyett Vifm, megint a vi/vim-mód miatt). Természetesen a minimalizmus miatt semmiről nem kell lemondanom, épp úgy fut minden GUI-s program, játék, médialejátszó, modern kódek, hardveres gyorsítás mindenféle kódekhez és grafikus API-hoz. Tehát nincs az, hogy hátrányt szenvednék akármiből. Nyilván, ha valami ritkább, GUI-s prorgamot indítok, az nincs az ujjam alatt, az dmenu-ből keresem ki, vagy fzf-script listázza (pl. játékok), de az is villámgyorsan nyitható, gyorsabban, mintha valaki ilyen hagyományos grafikus menüből tallózgatná ki egérrel.
De ahogy észrevettem, youtube-os linuxerek is hasonló rendszerrel dolgoznak, mind Arch vagy (ritkán) Gentoo alap, pálcika tiling WM, terminálos programok, neovim (vagy modern Emacs-disztró), fzf, dmenu, billentyűzet-only vezérlés. Nyilván azért nem ugyanaz a rendszer mindenkinél, mert más a WM (dwm, bspwm a legnépszerűbb, de előfordul minden más is), más a téma, más színek, betűtípus, más terminálemulátor (Alacritty és Termite a legnépszerűbb), más böngésző (most a linuxosok körében népszerűbb a Brave, mint a Firefox), más fájlkezelő (Vifm helyett vagy mellett lf, ranger, nnn, PCmanFM, Emacs dired), más screensaver (asciiquarium helyett pl. cmatrix vagy hasonló), stb., de a lényeg nem változik, hasonló rendszer, hasonló filozófiával. Nyilván két egyforma rendszer nincs, mert mindenkinek más szájíz diktálja a billentyűzetkombókat, amire drótoz, más progikat használ, más az ízlése, más a felbontása, monitormérete, billentyűzetkiosztása, hol laptop, hol asztali gép, hogy 1, hol 3 kijelző hol ergonomikus/osztott billentyűzet, hol másik kiosztás, stb.. Sok ötletet a youtube-osktól meg reddittről, unixpornról szedtem, sok megoldást ott láttam először, de nyilván ezeket már saját kútfőből is keresem, meg próbálom saját ötletekkel optimalizálni.
Egyébként nekem a Sway jött be eddig legjobban, de egyrészt mással is kísérletezni kell, nem ragadhatok le egy megoldásnál. Meg van 1-2 hiányossága is a Swaynak. Pl. teljes képernyős vagy floating módos programról nem tud átváltani a háttérben futó másikra, bár ez nem bug, hanem minden tiling WM-ben lévő feature, meg pl. nem mutat tasklistet, amikor alkalmazások között váltasz át, akár azonos monitor vagy workspace-re, akár nem, ez jó lenne bele, bár wrofi-val talán pótolható, de nem volt még türelmem megcsinálni. Vágólapkezelését is egységesíthetnék X-es és Waylandes alkalmazások között, ezt sati kolléga megoldotta clipman-nel.
A konfigom is mindig változik most fogok bspwm-re váltani, így megint lesz változás. Emiatt nem is szoktam a rendszerről mentést csinálni, csak az adatokról, adatfájlokról. Rendszermentés visszahúzásával nem is mennék semmire, ha egyszer a rendszer mindig változik.
[ Szerkesztve ]
-
Shyciii
veterán
válasz
attilav2
#7983
üzenetére
Én a Bspwm előtt Openboxot használtam. Tavaly nyáron még megvolt a config, de már töröltem, mert egyértelmű lett, hogy nem fogok visszamászni Openbox-ra. Amúgy az Openboxot szerintem könnyebb volt konfigurálni (általánosságban, mert pl a Bspwm szerintem könnyebb, de pl a qtile, xmonad nehezebb) ráadásul ott erre volt egy-két gui-s applikáció. Amúgy ahogy Frawly-nek, nekem sem az a tapasztalatom, hogy az Openbox kevesebbet fogyaszt, mint a TilingWM-ek. Itt egy régi kommentemből idézet:
"Hidegindításkori memóriafoglalások:
Openbox: 201MB
i3: 196MB
Bspwm: 185MB
Qtile: 227Mb"
Ezek mind fizikai gépen történtek, ugyanazon programokkal, ugyanazokat betöltve, ugyanolyan kinézettel. Itt látszik, hogy a Bspwm-el kaptam a legjobb eredményt. Az érdekesség még, hogy azóta a Bspwm nálam 141MB-ot foglal. Úgy látszik ennyit egyszerűsítettem a rendszeremen azóta -
jimmy399
senior tag
Sziasztok!
Van nekem egy dual gpu-s gépem. Egy AMD A8-5600k Radeon 7650D-vel (ez az elsődleges az UEFI-ben) és egy Ati Radeon HD5550-es kártyám.
UEFI boot, Arch Linux. Kettő darab 19"-os monitor ami VGA csatlakozós. Nem akartam kidobni egyiket sem, mert még működnek, de akadt egy kis gond vele. Mármint ami a HD5550-re kötött monitorra. Eddig vissza kellett tartani a kernel frissítést, mert azonnal csonttá fagyott a rendszer, ahogy engedélyeztem a 5550-esen a monitort. Ezt már javították, viszont előjött a fura képcsíkozódás probléma, ami a címben szerepel.
A legfrissebb radeon driver van fennt, amdgpu-val is próbálkoztam, de ezzel is ugyan ez a gond.
Van amikor elsőre jó a másodlagos kijelzőn a kép, de van amikor sok-sok próbálkozás kell hogy rendes kép legyen. Állítgatom a felbontást, a frekit (60 és 75 Hz), és egyszer jó lesz pár bróbálkozás után.
Megpróbáltam, hogy átdugom mások csatlakozóba, mert van rajta DVI-I, VGA, de ugyan ez a probléma.
Windows 8.1-10 alatt nincs ilyen gond.Csatolok képet, hogy hogyan néz ki a kijelző képe.
Valami tipp esetleg?
http://img4.imagetitan.com/img.php?image=23_20210329_163534_hdr1.jpg[ Szerkesztve ]
--- N/A ---
-
Frawly
veterán
válasz
jimmy399
#7986
üzenetére
Ezt szerintem X.org konfigban kéne beállítani, vagy valami xrandr-t használó sorral az xinitrc-be, hogy a default kártyát használja, amit te akarsz és kézilag egy általad megadott felbontás, frissítésre álljon be. A hibát valószínű az okozza, hogy a VGA csati analóg, nem jön át rajta a DDC jel a monitortól, hogy milyen felbontásokat támogat, így meg a X.org elkezd valamit defaultra állni, találgatás alapon és a monitor vagy kártya nem szereti, valami egzotikus frissítés miatt. Bár ezt a DVI-nak meg kéne oldania.
#7987 Shyciii: én sose hittem ezekben a spéci kernelekben. Lehet nyersz vele egy lényegtelen 1-2% futási többletteljesítményt, de egy csomó kompatibilititási szívás bugok árán. Egyszerűen az időt nem érik meg. Nem véletlen, hogy a hivatalos kernelben nincsenek benne ezek a csodapatchek, meg spéci ütemezők nem defaultok. Ha annyira jobb lenne, akkor Torvalds belereszelné ezeket defaultnak.
-
jimmy399
senior tag
A default kártya az UEFI-ben az integrált HD 7650D, 1 GB rammal. Amikor csak a HD 5550-est használtam legacy boot-al, akkor semmi gond nem volt az analóg csatis monitorokkal. Mióta átáltam így 2021-ben arra, hogy UEFI boot-al indítsam el a gépet, és a HD 5550-es csak másodlagos kártya lett (mivel nem képes UEFI GOP bootra), így kénytelen lettem az integráltat megtenni elsődleges kártyának, mert az 5550-es nem tud bootolni UEFI módban.
Az integrált 7650D VGA portájra rádugtam az egyik monitort, a másikat hagytam DVI-I porton, amin keresztül egy DVI-I - VGA átalakítóval használom a másik monitort.
Ha átdugom az 5550-es sima VGA csatlakozójára, akkor is hibát produkál, ergó nem a csatlakozókban van a hiba, hanem valahol a linux driverben.(5.11.11 kernel van most, korábban csak az 5.10.11-es kernel ment fagyás nélküll a gép fura csíkok nélkül) BÁR, már jobb a helyzet mert a korábbi kernelekkel csak szimplán rommá fagyott a gép ha engedélyeztem az 5550-esen a képernyőt, most már csak a korábban említett csíkozódás van meg, de ha sok paramétert (felbontás, frekvencia, oldalarány) állítom, egyszer csak lesz jó kép, de van amikor elsőre megy, random van hiba. dmesg, Xorg.log elemzés megvolt, semmi érdemleges nem derült ki a problémáról.Lehet későbbi kernel update-el kijavítják majd. Egyelőre ignorepkg listára tettem a rendszermagot. Kézzel telepítem, majd ha okés marad, ha nem akkor a cache-ból újratelepítem a korábbi kernelt.
[ Szerkesztve ]
--- N/A ---
-
Frawly
veterán
válasz
jimmy399
#7989
üzenetére
Továbbra is tartom, hogy ez valószínű nem kernelhiba, hanem az újabb kernelekhez kéne valami mágikus kernelparaméter. A HUP-on olvastam a bejegyzésed, hogy radeon driverrel hajtod mindkettőt és próbáltad amdgpu-val is, szóval mást nem nagyon lehet tenni. Azt már múltkor is beszéltük, hogy az xf86-video-ati és xf86-video-amdgpu drivereket is próbáltad X.org alatt. Mást nagyon nem lehet megpróbálni, csak a kernelparaméter marad, már ha tényleg nem kernel bug, ami azért meglehet, de nem találok semmit, ez jelentheti azt is, hogy más még nem jelezte.
Végső esetben egy CSM Legacy BIOS bootos telepítést is csinálhatsz, egy külső meghajtóra, hogy megnézd, hogy ha elsődleges kártyának használod az 5550-est, akkor a hibajelenség előfordul-e. Az ugyanis örökké nem maradhat, hogy emiatt sose frissítesz kernelt, mert előbb-utóbb nem úszod meg. Egy ideig lehet halogatni workaroundként, csak végleges megoldásnak nem jó. Azt is mondanám, hogy majd az 5.12-es kernel megoldja, de az véglegesként majd csak 3 hét múlva jön ki.
[ Szerkesztve ]
-
jimmy399
senior tag
Hm, persze, azért is állítottam be, hogy kernelt csak kézzel telepítek majd.
Legacy boot során is előfordult, hogy ugyan ez a csíkozodás hiba megjelent... Van ilyen kevert pendriveom, rufussal csinálva, és 3.12-es kernellel is megesett ,hogy ilyen lett a képernyő, csak ritkábban.--- N/A ---
-
Shyciii
veterán
Nem hiszem, hogy Torvalds belerakná. Ő egy eléggé "érdekes" gondolkodású ember. Minap olvastam, hogy most épp a Rust-ot isteníti, így ezt most linux felé is erősen ki fogja vetíteni. Inkább úgy mondanám, hogy az kerül előtérbe, amit ő jónak tart, és nem az ami ténylegesen fontos, és jó. Persze van mikor a kettő fedi egymást, de sokszor nem. Linux is nem véletlenül kezdett elterebélyesedni, mint a windows. Bár már egyszer-kétszer végre beismerte, hogy túl nagy és felesleges már a kód, csak éppen semmit nem csinál ez miatt.
-
Lehet hogy utoléri az Arch-ot is a bloatosodás?
Installer scriptet kapott a telepítő média: https://github.com/archlinux/archinstall-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Frawly
veterán
válasz
attilav2
#7993
üzenetére
Ez még nem bloatosodás, csak épp értelme nincs. Az Archnak szándékosan nincs telepítője, hogy ne találja ki a user helyett, hogy mi kell neki. Persze, eddig is voltak 3rd party telepítőscriptek, de azokkal az Arch értelme lett lehúzva a klotyón, meg sok láma összealkot vele ilyen gányolt telepítést, aztán jönnek az archos topikokba, mert nem érik hogy működik, mi van telepítve, mi mi miatt nem jó. Mert ha te telepíted kézzel a Wiki alapján, akkor a parancskimenetekből látod, ha valami nem jó. Ha egy installer csinálja helyetted, akkor nem látod.
Persze ettől még félpozitív hír is lehet, mert ha több user áll be az Arch mögé, akkor több csomag lesz rá, több tároló, jobban fejlődik. Inkább egy független Arch mögé álljanak be a userek, mint ilyen corporate bullshit Coninical, Red Hat, Süsü baromságok mögé. Szóval engem nem annyira zavar.
Annyiból viszont félnegatív hír, hogy ha sok windowsos meg ubuntus láma beáll mögé, akkor viszont az megindíthat nagyobb bloatosodást, csak azért, hogy őket kiszolgálják. Az meg nem lenne jó.
Egyébként én ha kezdőbbeknek kell Arch, Arco Linuxot szoktam ajánlani. Viszonylag egy normális belga faszi csinálja (Erik Dubois, még YouTube-csatornáján is közzétesz segítő videókat), vanilla Archot kap a user, ha feltelepíti (szemben a Manjaro-val, ami módosított tárolókat használ, meg le van maradva verziókkal), és általában még nem túl bloatak a lemezképek, default Archhoz elég közel vannak, nem kell túl sok sallangot elviselni a rendszeren. Az Arco Linux meg rendes telepítővel jön, azt hiszem Calamares. Így egy kezdőbb user is belekóstolhat a rollingba, meg a frissességbe. Vannak nagy DE-s és kisebb WM-es lemezképek is belőle.
-
Frawly
veterán
válasz
attilav2
#7993
üzenetére
Kiegészítés: egyébként nem haszontalan, mert ha legközelebb egy gépre valami gyors disztrót akarok feltenni, az már lehet nem Mint vagy Xubuntu vagy hasonló lesz, hanem ilyen archinstall scriptes vanilla Arch. Tehát ez haladóknak is jó lehet, ha gyorsítani akarnak a telepítésen. Mert sokszor telepít az ember egy 1-2× használatos, eldobható rendszert, ami gyorsan kell valami alapon kerül fel, arra az esetre kiváló. Tehát mint írtam, nem vagyok ellene. És ahogy a Phoronixon olvasom, ez ne is automatizálva lesz az Arch telepítőn, hanem egy parancs formájában kell behívni, ergo aki akarja, használja, aki nem akarja, annak továbbra is lehet hagyományos kézi módszerrel Archot telepíteni. Így tőlem elfér.
Meg azoknak is emberkéknek is jó lehet, akik már majdnem ott vannak azon a szinten, hogy Archot használjanak, de eddig valami nem ment a kézi wiki-s telepítésnél, és állandóan feladták, de már kevés hiányzik nekik, őket átsegítheti ezen a ponton egy extra lökést adva. Így már nem lesz visszatartó erő, hogy jajj, nincs installer, meg nem kell gyanús, gányolós, 3rd party installer scriptek beszerzésével és működésképtelenségével vergődni.
-
Vboxban próbálgatom ezt a hivatalos installert, háát, azt kell mondjam nem örülök neki túlzottan, alapból titkosított partíciót csinál, de hogy milyen megoldással azt nem választhatom meg.... Az Arch filozófiájával, egyáltalán a KISS-el ellentétes bármilyen installer szerintem... Aki nem érti hogy működik a titkosítás az szívhat vele, én sem értettem még meg hogyan kell titkosított (pl LUKS) telepítést csinálni, és amíg nem értem a folyamatot, de egy installer megcsinálja és valami gond lesz a későbbiekben akkor szívhatok vele mert nem fogom tudni megoldani, pláne hogy nem is tudom az installer milyen megoldással csinálta.
Időt viszont spórolt az installer rengeteget, töredék idő alatt megvolt a telepítés, viszont nem tudom milyen boot megoldást használ a rendszer, hogy lett megvalósítva a LUKS titkosítás, stb.[ Szerkesztve ]
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
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 -||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
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 :)
![[kép]](https://clonezilla.org/clonezilla-live/doc/03_Disk_to_disk_clone/images/ocs-08-3-command-to-run.png "[kép]")
Próbáltam konfigurálni a systemd-t már amennyire értek hozzá, egyszerűbb beállításokat változtattam az /etc/systemd/system.conf-ban:
Új hozzászólás Aktív témák
BoB
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs