-
Fototrend
Arch Linux topik
Új hozzászólás Aktív témák
-
b3Ro
senior tag
Par napja jott frissites Solus-ra, es jott vele a 4.16.7-es kernel. Aznap este felraktam, de masnap reggel mar jott is egy masik frissites, ami kernelt cserelt, a 4.15.18-67.current x86_64-ra. Lehet, h erdemes lenne megprobalnod, neked is vissza menni. Talan valami nem stimmel meg a 16-os vonalal
-
Frawly
veterán
Kösz a válaszokat. Jó tudni, hogy nem csak én szívok ilyennel akkor. Pedig tényleg teljesen támogatott Intel Wi-Fi kártyával tolom, ami megint csak a Linux kernel által teljesen támogatott üzleti szubnoteszben működik.
Korábbi kernelre nem váltok vissza, mert amúgy más baj nincs vele, és ezzel a netctl-es trükkel használható a rendszer, de kezd már frusztrálni, hogy az utóbbi időben túl sok baj van ezzel, ha így megy tovább, akkor át kell állnom Gentoora.
Egyébként ezt sem értem, mert ha a kernel lenne hibás, vagy a csomagkarbantartó hibázna, akkor nem lenne az, hogy a 4.16.x-es kernelek közül egyikkel jó lenne, a másikkal nem, hanem akkor mindig konzisztensen rossznak kéne lennie egy bizonyos verziószám fölött. De nincs így, egyszer megjavult, jó egy ideig, aztán megint előjön. Nagyon komolytalan ez így, mint egy hullámvasút.
-
Slownz
senior tag
Megpróbálom itt is: katt
-
b3Ro
senior tag
Baratnomnek a laptopjan Ubuntu Mate figyel. Ukku-val szoktam frissitgetni neki a kernelt, es 4.16.3 megy neki tokeletesen, de a 4-5-6-7 mind hibat jelez bootkor, es itt meg is all. Szoval 3-as verzio szam folott azon a laposon azzal a rendszerrel nem megy. Ha ez jelentene valamit....
-
vargalex
félisten
Sziasztok!
Cégnél kaptam egy 500 GB-os SSD-t, így arra fogok a notebookon átköltözni. Kérdésem, hogy ki milyen filerendszert javasol? Nálam az XFS, illetve EXT4 merült fel. Persze más is lehetséges. Az szinte biztos, hogy LVM-en lesz.
Sajnos az SSD az egy Samsun 850 EVO, így a queued trim nem fog menni. Jobban járok a discard mount opció helyett az fstrim.service futtatásával?[ Szerkesztve ]
Alex
-
Frawly
veterán
válasz vargalex #5208 üzenetére
De, 8xx-es Samsungon is megy a queued TRIM, de teljesítményvesztés léphet fel, ezért nem érdemes használni. Ez csak azzal jár, hogy a mount opciók között nem szerepelteted a discard-ot.
A hiánya egyáltalán nem fájó. Bőven elég, ha az fstrim-et használod helyette, vagy fstrim systemd service engedélyezésével, vagy néha napján kézzel lefuttatva a sudo fstrim -a -v parancsot. Ezek a megoldások is rendesen TRIM-elik a meghajtót, semmi hátrány nem ér.
Fájlrendszernek XFS semmiképp. Vagy ext4, vagy f2fs. Mindkettővel van tapasztalatom. Mindkettő egyformán gyors. Az ext4 szerintem jobb, mivel az f2fs bootkor néha lassan ellenőrzi a fájlrendszert (fsck), az ext4-nél ez is villámgyors.
-
vargalex
félisten
Szia!
A queued trim <> continuous trim. Előbbi akár ütemezett, akár folyamatos trim esetén működik, ha tudja a drive és nincs blacklist-en. Sajnos a 850 esetében blacklist-en van, azaz a hagyományos blokkoló trim működik. Ekkor is használható mindkét módszer (continuous trim - discard, illetve periodic trim - fstrim.service, vagy kézi futtatás), csak a blokkolás miatt talán a periodic kevésbé zavaró.
Alex
-
BoB
Topikgazda
Nem megy a queued trim mert a kernelben le van tiltva, ahogy a legutóbbi hosszabb írásomban írtam, de látom hasztalan volt
Mégegyszer: a discard nem a queued trim-et állítja be, hanem alapvetően a trim-et, ha a meghajtó tudja azt akkor azt. Ugyanaz mint az fstrim csak folyamatosan megy.
Szerk. Vargalex éppen megelőzött
[ Szerkesztve ]
You may corrupt the souls of men, but I am steel. I am doom.
-
Frawly
veterán
Ilyen értelemben nem ugyanaz. Igazából ugyanazt mondjuk, csak a kifejezéseket használtam pontatlanul.
Ha nagyon a mélyére nézünk, TRIM-ből csak egy van. Ezt lehet kétféleképpen is kettébontani, attól függően, hogy milyen időbeli beosztásban van végrehajtva.
Az egyik a folyamatos TRIM (discard) a másik az időszakos (fstrim). Ez a felbontás Windows alatt is él, a Windows kernel (Win7 és attól felfelé) folyamatos TRIM-et alkalmaz (menet közben TRIM-el, mikor valami törlésre kerül, azzal együtt a TRIM parancsot is kiküldi), míg egy-két SSD-gyártónak és defrag progit fejlesztő szoftvercégnek van időszakos TRIM-es megoldása (ami viszont megy XP-n, Vistán is, ha a meghajtó és a driver tudja a TRIM-et).
Egy másik bontásban meg van a queued TRIM (a kiküldött TRIM parancsok későbbre ütemezve, kötegelve futnak) és a sima TRIM, aminek egyrészt ilyen terminológia miatt a felülete nem göcsörtös, és a TRIM parancsok valós időben hajtódnak végre, nem ütemeződnek kötegelt végrehajtásra.
Ezeket párokat keresztben is lehet párosítani, négyféle kombinációban. Kivéve, ha nem megy a queued TRIM, mert a kernelben tiltva van. Igazából még mindig áll, amit mondtam. A discard TRIM-et nem tanácsos használni feketelistás meghajtókon, mert nem kötegelve futnak, hanem azonnal hajtódnak végre valós időben egyenként, és ettől belassulhat a meghajtó. fstrim-nél ez mindegy, ahogy írtátok, „kevésbé zavaró”.
Egyébként meg azt a mai napig nem sikerült megfejtenem, hogy az fstrim első futtatásra miért végez sokára, akkor is, ha trimmelt meghajtón fut. A 2-3., stb. futásnál már 0 mp. alatt végez. Majd egy reboot, és újra az első futtatásra mintha újra végigtrimmelné az SSD üres szektoraihoz tartozó cellákat.
Pont a queued TRIM miatt vettem anno Crucial MX300-at. Két fontos szempont volt, tudjon ATA-jelszavazható hardveres AES öntitkosítást a meghajtó, és ne legyen feketelistán a meghajtó queued TRIM ügyében. A Samsung 840, 850 emiatt esett ki, öntitkosítást tud, de a queued TRIM tiltva van. Kiderült, hogy felesleges volt aggódni, mert csak fstrim-et használva is normálisan trimelődik a meghajtó, és nem baj, ha nem használjuk a discard paramétert.
Igazából pedig a feketelistás meghajtók is tudnák, de firmwarehiba miatt okozna a használata anomáliát, ezért van a kernelben szoftveres úton letiltva. Ami duplán meglepő, hogy az illető SSD-k gyártói nem akarják ez ellen a firmware-t patchelni. Tudom, a Linux marginális platform, 0%-os részesedés, a kutya nem használja, mert csak a Windows a tuti. Az néha kísérletezik vele, akinek nincs pénze Mac-re vagy Windows licencre, de előbb-utóbb ők is letörlik, és ChromeOS-t vagy Androidot tesznek fel.
A másik, amit nem értek, hogy az fstrim miért nem támogat minden fájlrendszert. Olyan egyszerűt pl. mint a különböző altípusú FAT fájlrendszerek. A discard támogatja, az fstrim nem. Így ha valaki ilyen fájlrendszert akar trimmelni, feketelistás meghajtón is használni kell a discard TRIM-et.
[ Szerkesztve ]
-
ubyegon2
nagyúr
Te amúgy érzel kényszert SSD-n FAT akármiről futtatni a rendszert?
Egyébként meg azt a mai napig nem sikerült megfejtenem, hogy az fstrim első futtatásra miért végez sokára
Ezt pedig jó lenne, ha megfejtenéd! Amennyit lebzselsz az SSD topikban, simán kideríthetnéd. Nagyon anno olvastam erről a témáról, de már nem emlékszem, mi volt a lényeg.
[ Szerkesztve ]
-
Frawly
veterán
Pedig ugyanazt mondjuk, azért nem volt vita. Azt is elismertem, hogy pontatlanul használtam a fogalmakat, ebben sem volt vita. A lényeg lényegén meg amúgy sem változtat, Samu 850-en nem jó ötlet a discard TRIM-et erőltetni, és az is tény, hogy nem veszteni semmit a hiányával, de ha ez utóbbiakkal nem értesz egyet, cáfolhatsz nyugodtan. Érdemi cáfolatra gondoltam, nem elnevezéseken lovaglásra, azon túlvagyunk.
De ha már Gyurmafigura paprikás kedvében van, akkor mégis húznám még azzal az idegeit, hogy a security erase is trimmelés lényegében, és annak is van kétféle változata, egy rövidebb, és a meghajtó teljes felületén végrehajtott. A rövidebb azoknál a meghajtóknál lehetséges, amelyek támogatnak öntitkosítást. De a security erase-t nem a kernel intézi, hanem az SSD vezérlője, ha erre kap parancsot.
Júbájgön: az EFI partíció FAT32-es, bár az elméletileg nem igényel trimmelést, mert egyszer ráírod, ami rákerül, utána nem nagyon történik róla törlés, csak néha felülírás kernelfrissítéskor (initramfs, fallback). Egyébként másra nem használnék FAT-ot, NTFS partícióm sincs (jó, vagy egy nyomorult darab egy külső meghajtón). Viszont nem kerülne semmibe lefejleszteni, hogy az fstrim vigye a FAT-ot is, soha nem tudni mikor jön jól, elfér, ha tudja. Nem lenne bonyolult implementálni, lényegében a FAT a legegyszerűbb létező fájlrendszer a swap után, már ha utóbbit lehet fájlrendszernek tekinteni.
Az fstrim-nél meg nem értem, hogy miért lenne nekem kötelességem rájönni a futási sebesség rejtélyeire. Tippem persze van. Első futáskor végignézi a fájlrendszer foglalási tábláit, megnézi, hogy mely szektorokhoz nem tartozik fájl, és ezekre mindegyikre kiküldi a TRIM parancsot, akkor is, ha ezek közül van olyan, ami már TRIM-elve van (tehát az adott partíció egész üres területét trimmeli). Második futásnál viszont a fájlfoglalási táblában az újonnan kiürült szektorokat keresi meg, és csak azokat trimmeli. Pedig még a forráskódjából is puskázhatnék, ha nem lennék lusta.
SSD topikot meg jó nyomon követni, melyik szériával mik a tapasztalatok, hogy alakulnak az árak. Egyszerűen tanulságos, még akkor is, ha nem akarsz SSD-t venni. Már pedig akarok (mSATA-s menne bele a fő gépembe 2. SSD-ként, már csak annak van hely), de nem találtam még jó áron. Nagyon fent vannak az árak, de nézelődök.
Persze emlékszem a fénykorodra, mikor te is aktívan részt vettél SSD-s flame-ekben, hogy pl. kell-e kímélni, le kell-e tiltani az atime-ot. Akkor azzal csesztettelek, hogy ki kell venni az SSD-t a gépből, betenni üvegvitrinbe, akkor nem kap sok írást. Csak ezzel azóta nem poénkodok, hogy pár helyről kiderült, hogy üvegvitrinben is bedöglenek ezek, épp úgy a vezérlő adja be a kulcsot.
-
ubyegon2
nagyúr
Nincs nekem ezzel gondom, inkább örülök, ha valaki képben van az SSD dolgaival kapcsolatban, mert bár már nem annyira féltjük, mert tudjuk, hogy mindent kibír, a vezérlő adja meg magát úgyis. Ettől még jó, ha tudja a felhasználó, mi micsoda. Hányan tudják szerinted, mi a különbség a 120 és 128 gigás meghajtók között? Mi az overprovisioning?
Te és sokan tudjátok ezeket, de legtöbben nem. Ez viszont helytelen, de legalábbis értelmetlen felhasználói szokásokat alakíthat ki! Feleslegesen hagynak particionálatlan területeket például előbbiek, de akár a trim miatt is.
Szóval csak legyél képben! Én már nagyon nem vagyok, nem mint ha.....(szerintem, mivel én sem értek hozzá)
[ Szerkesztve ]
-
Frawly
veterán
válasz ubyegon2 #5219 üzenetére
Na, látod, azt nem tudtam, hogy a tartalék területet overprovisioningnek hívják. Az viszont vitatott, hogy egy 120 gigás meghajtónál 8 giga elég-e. Valamennyit biztosan segít, de hogy milyen mértékben, az vitatható.
Azt én sem szoktam javasolni, hogy particionálatlan helyet hagyjunk. Csak abban a speciális esetben jó, ha nagyon laikus felhasználóhoz kerül az SSD, akinek nem lesz adattárolási fegyelme, és állandóan csurig pakolva használja az SSD-t. Aki viszont nem ilyen, ne hagyjon particionálatlan helyet az SSD-n, csak arra figyeljen, hogy ne legyen állandóan csurig, legyen rajta tartósan legalább kb. 10% hely (néha be lehet menni ezalá, de ne legyen tartós állapot). Jobb, ha ez a szabad terület a partíción van meg, mintha partíción kívül. A hatása a wear levelingre mindkettő megoldásnak azonos.
Már a HDD-k sem örültek, ha csurig voltak töltve. Pedig azoknál nincs se TRIM, se wear leveling. Még a 4K alignálás sem csak a SSD-k specialitása. Igazából az SSD úgy kell használni, mintha HDD lenne. Egy plusz dologra kell figyelni, a TRIM menjen, meg pár havonta ránézni a SMART adatokra, nehogy valami bugos program írási kergekórt kapva szétírja. Meg ugye defragolni nem kell, de ez sem gond, mert Win7 és attól felfelé már alapból nem defragolja, Linuxon meg sose volt erőltetve a felhasználó tudtán kívül a defrag, ott neked kell futtatni, nincs az, hogy véletlenül lefutott, mert nem akadályoztad meg, elfelejtetted letiltani.
Így ha lehet is az SSD-vel bonyodalom, az csak a TRIM körül lehet, esetleg az ATA jelszavas titkosítás terén (de az meg megint lehet HDD-nél is).
-
ubyegon2
nagyúr
OP-re 8-27 százalékot célszerű tartalékolni, de ez bőven megvan a gyári lefoglalással is, mert nem valószínű, hogy 100 százalékig teletömöd a többi részt a meghajtón. De ha mégis, a 120GB-os még így is jól lesz.
Sokan totál értelmetlenül hagynak még pluszban ki helyet, mert nem tudják, hogy az ő SSD-jük is 128-as a valóságban.HDD-ből az AF-es a jó, az már 4k-s, WD1003FZEX például.
Ha valaki akkora idióta, hogy csurig pakolja a meghajtóját, akár HDD-n is.......
Amúgy msata-s SSD-t tárolásra akarsz venni a laptopodba? (az árát említetted, ezért gondoltam)
ATA jelszavas titkosítás ez jó móka, ha elfelejted a jelszót.
[ Szerkesztve ]
-
Frawly
veterán
válasz ubyegon2 #5221 üzenetére
Valóban, Linuxon pl. a fájlrendszer is eleve tartalékol, az ext4-nél valami 5% ez, ami ha rájön az overprovisioningre, akkor az már magában elegendő lehet. Ezt a szabad hely hagyása igazából windowsos usereknél fontos.
Második OS futtatására venném, jelenleg egy külső SSD-t használok erre, de az kicsi (64 GB), és idegesít, hogy lóg ki a gépből USB-SATA átalakítós kanócon. A ThinkPad X220-amba már benne van egy SATA SSD, így már csak mSATA-nak marad hely. Viszont ez egy elavult, kifutott csatolófelület, egyre inkább nem kapni, ami van, az is drága.
A 3D TLC-s SSD-k még a 4K AF-es HDD-knél is jobbak, mert 16K-s alignálást igényelnek. A több pedig jobb Persze nem kell aggódni, mert a modern particionálóprogramok, OS telepítők 1024K-n alignálnak (2048-cal osztható szektoron kezdődnek a partíciók, azaz egész MB-os határon), ami megfelel az 1K, 2K, 4K, 8K, 16K, 32K, 64K, 128K, 256K, 512K, 1024K-s alignálásnak is, mivel ezekkel is osztható maradék nélkül.
[ Szerkesztve ]
-
ubyegon2
nagyúr
Az msata SSD tényleg drágább, 15 alatt nem is nagyon van jó minőségű 12GB-os. Amúgy jelennek meg még újak ezzel a csatolóval is, van még időd válogatni.
Valóban, Linuxon pl. a fájlrendszer is eleve tartalékol, az ext4-nél valami 5% ez
Ez ki is ment a fejemből, ebből is látszik, milyen elavult a Win fájlrendszere......
3D TLC-s SSD-kről épp nemrég olvastam, nem olcsók, átlagfelhasználó elvan egy mezei SSD-vel is, én az elsőt pont akkor vettem, mikor kifutó lett az Intel 520 10GB, a laptopba meg vettem egy használt Fury 120-ast. Ezek elketyegnek még jó darabig. 16K-s meg a többi align-ról még nem is hallottam, ezért jó, hogy legalább valaki követi az SSD totyikot!
-
Frawly
veterán
válasz ubyegon2 #5223 üzenetére
Jó neked, hogy ilyen 10-12 gigás SSD-kkel beéred, én 480-525 gigás kategóriában nézelődök Tudom, hogy elgépelted, gondolom a 12-es az 120 gigás akart lenni, az Intelnél meg a 10 az lehet 120 vagy 180 giga?
Abban igazad van, hogy átlag felhasználó, amilyen én is vagyok, elvan planár TLC-vel is, mivel nem ír annyit rá, hogy számítson a TLC, 3D TLC, MLC írásterhelhetőségi különbsége. Amúgy is a vezérlő fárad el, nem a cellák. Szóval nyugodtan meg lehet venni ilyen kifutó SSD-ket olcsón, nem baj az se, ha planár TLC, csak sokat nem szabad érte adni.
A 16K-s align onnan jön, hogy 3D TLC-nél 16K-s lapokba vannak a cellák szervezve, nem 4K-ba. Ez az átlag usert nem érinti, mivel a modern particionálóprogik és telepítők továbbra is úgy alignálnak, hogy mindenfajta eszköznek megfeleljen tekintet nélkül a fizikai szektorméretre, az OS felé meg tudják a 0,5K-s módot emulálni (egy szektor 512 bájt sémát). A lényeg, hogy ilyen DOS-os meg meg Win9x-es progikkal nem szabad particionálni, meg XP és annál régebbi Windows telepítőjével sem, azok a partíciókat 63-mal osztható szektoron kezdik, mivel a HDD-ken egy sávban 63 szektor volt. Ez az SSD-nek nem jó, jelentősen belassul tőle.
-
ubyegon2
nagyúr
A manóba, tényleg kevesebb nullát írtam, szokni kell még ezt a 14" -os ketyerét vagy túl gyorsan írtam.
Szóval nyugodtan meg lehet venni ilyen kifutó SSD-ket olcsón
Az Intel 520 esetén ez különösen jó üzlet volt, mert pár évvel ezelőtt magasan a legjobb consumer SSD volt megbízhatóság terén és gyakorlatilag feleződött az új eszköz ára az új modell miatt. A Furyra meg használtan elég nehéz volt lecsapni, nagyon ajánlott még a legtöbb új modellel szemben is, a milyen SSD-t....topikból infóztam vétel előtt.
Annyira jók ezek az SSD-k, hogy ha nem Arch-ot rakok rá, akkor is repül a rendszerem!
-
Frawly
veterán
válasz ubyegon2 #5225 üzenetére
Óó, ne aggódj, ha Archot teszel rá, azt azért SSD-n is érezni. Ha minimalista WM-mel használod, akkor a bootidő leszorítható 4 mp. környékére egy sima SATA3 SSD-vel. Ez Minten elérhetetlen.
Ennek az SSD-korszaknak már nagyon ideje volt, a HDD-k nagyon visszafogták már a mai gépeket. Főleg a Win10-nél fontos az SSD, mert mocskosul tekeri a lemezt, részben az NTFS fossága miatt, másrészt a registry írása, olvasása is elég lassú. Linux fronton el lehet lenni HDD-vel, de az SSD ott is sokat gyorsít. Ma már nem éri meg spórolni rajta, ha más nem egy olcsó 120 gigás Kingston A400-at be kell szerezni, vannak boltok, ahol 10 ezer alatt megkapod, alig drágább, mint egy nagyobb pendrive. Lesz ez még olcsóbb, ha lemennek reálisabb szintre az memória/SSD árak.
-
ubyegon2
nagyúr
Ha minimalista WM-mel használod, akkor a bootidő leszorítható 4 mp. környékére egy sima SATA3 SSD-vel. Ez Minten elérhetetlen.
Szép is lenne, ha WM-et kéne használni, hogy megfelelő bootidő legyen. Amúgy igazad van, Mint Cinnamonnal 5 sec alá nem ment a bootidő, Debian Cinnamonnal viszon 3 sec volt, pár éve kipróbáltam Antergossal, az 2,7 sec bootidőt hozott. Mindenütt a leglomhább DE volt fenn, szóval nem kell ide WM.
Jó dolog az SSD, én is sokáig küzdöttem ellene, mert minek az, ha WD Black-et használok rendszer alatt, de szerencsére már megvannak, így viszont a leggyorsabb, legstabilabb HDD-t tárolásra használom, ha ezt előbb tudom, dupla tárhelyet vehettem volna az áráért.
Desktopnál lehet a legjobban megoldani, mert ott valóban elég egy 10 rugós 12GB-os SSD és xTB HDD tárolásra. Laptopnál kicsit nehezebb ezt megoldani, ha csak ki nem dobod a DVD írót.
[ Szerkesztve ]
-
Frawly
veterán
válasz ubyegon2 #5227 üzenetére
Márpedig szerencsénk van, mert a DVD meghajtót a laptopból úgy kivágjuk, hogy csak nyekken. Konkrétan a bal vállunk felett hajítjuk hátrafelé. Persze nem mindenhol opció, mert az X220-ban mivel szubnotesz, eleve nincs ODD, így nincs az, hogy a HDD-t átrakod a helyére. Meg a 2. SSD sem azért kéne nekem, mert annyira szűkében vagyok a tárhelynek, csak inkább szeretném külön lemezen tudni a két OS-t.
Az 2,7 másodperces antergosos Cinnamon-boot az nagyon szép. Lehet ahhoz jobb gép kéne. NVMe-vel is max csak ilyen 0,1-0,5 mp-eket lehet lefaragni, inkább a procin, buszsebességen múlik, nem az SSD-n. Esetleg ha a kernelben a hardverdetektálást fel lehetne gyorsítani nem használt komponensek detektálásának a letiltásával.
-
ubyegon2
nagyúr
Hasznosak ezek az optibay-ek valóban. Mint Cinnamon amúgy most sem túl gyors bootban:
ubyegon@HP-EliteBook-8470p ~ $ systemd-analyze
Startup finished in 5.315s (kernel) + 1.534s (userspace) = 6.849sKipróbálom valamelyik Arch klónnal, de nem pure Arch lesz, mert már megszoktam, hogy 5-10 perc egy full install.
A GPT-re átállás nem sikerült, pedig live alól inicializáltam, el is tűnt minden, de egyrészt a HP biosában nem lehetett választani, majd körül kell benne néznem, másrészt MBR maradt. Lehet, hogy bios is régi ebben a Elitbookban.
Most jött ki friss Antergos, érdemes bepróbálkozni vele? Anno elég gyatra volt a Inchi nevű telepítősegéd benne.
Meglepő, de Mint Cinnamonnal 500 mega alatt maradt a memória (boot után 423MB), FF 3 lapjával lépte át az 1gigát. Meglátjuk, mit ad ehhez az Arch alap.
A Cin 3.8 a Mint 19 alatt simán kiröhögi a KDE-t, ha most ennyit zabál csak.
[ Szerkesztve ]
-
Frawly
veterán
válasz ubyegon2 #5229 üzenetére
A systemd-analyze outputját felejtsd el, bullshiteket írogat. Stopperral mérd. A bootmenüben ahogy indítod a rendszerd, onnan indítsd a mérést, és ott állítsd le, ahogy minden ikon az asztalon, tálcán, stb. megjelent.
Az a HP Elitebook, ami neked van, elviekben UEFI-s és támogatja a GPT-t. Az UEFI-ben állítsd át a Boot type-ot vagy Legacy + EUFI-re, vagy UEFI-re. Tessék csak szépen próbálkozni vele.
A telepített rendszer csak akkor fog az UEFI-ben látszódni, ha az OS megtette a szükséges bejegyzést magában az UEFI-ben. Valószínű jó az a GPT-s átállás, csak az OS telepítésekor az UEFI boot részletei nem megfelelően lettek beállítva, ezért nem bootol.
-
ubyegon2
nagyúr
Jó az, minek stoppereljem, érezhetően kb annyi az így is.
Nincs GPT, mint említettem, felment a teszt Mint C és első dolgom volt gpartedben csinálni 4 elsődleges partíciót próbaképpen. A negyediknél jött az ismerős ablak, hogy csak 4 elsődleges ......
Szóval bootol ez rendesen, csak nincs választási lehetőség, mert desktopon van, amikor pendrive-ról bootolok.
Annyira látszik, hogy semmi nem akarja ezt az UEFI-t! Mondhatnám azt is, hogy fák jú GPT/UEFI ![ Szerkesztve ]
-
májkimiki
őstag
Sziasztok!
A következő csomagfrissítési hibába futottam, a js52 csomag frissítésekor.
js52 (JavaScript interpreter and libraries-Version 52)ütköző fájlok:
js52 /usr/lib/libmozjs-52.so.0 már létezik a fájlrendszerbenAz 52.7.3-1 csomag frissűlne 52.7.3-2 verzióra.
Firefoxot használok, annak szükséges. Előjött már másnál is ez a hiba? -
Siriusb
veterán
válasz májkimiki #5232 üzenetére
https://www.archlinux.org/news/js52-5273-2-upgrade-requires-intervention/
Célszerű ilyenkor a híreket vagy a hivatalos fórumot megnézni. Ha van valami hiba, valószínűleg mások már megoldást is találtak a problémádra.
-
BoB
Topikgazda
Bekerült a core tárolóba a pacman 5.1-es verziója.
A felhasználókat érintő legfontosabb változás, hogy megszűntetésre került a
--force
kapcsoló, helyette--overwrite
van.További változások listája itt található: [link]
You may corrupt the souls of men, but I am steel. I am doom.
-
Frawly
veterán
válasz májkimiki #5234 üzenetére
Nem baj, hogy kérdeztél, megvan legalább itt is. Én is belefutottam, de magamtól rájöttem, ha ez a fájl létezik, akkor szimplán csak törölni kell rm paranccsal. Utána szépen megy a frissítés. Majdnem beírtam én is ide figyelemfelhívásnak, de aztán megjelent az Arch oldalán is a hírekben, aztán úgy voltam vele, hogy az elég figyelmeztetés mindenkinek.
Egyébként nem értem, hogy a csomagkészítő milyen nem vettem fel scriptbe, ha létezik a fájl, akkor telepítés során automatikusan törlődjön.
-
májkimiki
őstag
Lehet, hogy lényegtelen dolog. De lehet fontos is. Leírom.
Szóval többször neki kezdtem a pamac-el feltenni ezt a js52 csomagot. Aztán az itt kapott link segítségével feltudtam frissíteni.
Viszont én root mc-vel kerestem a fájlt és töröltem is. Volt még egy ugyanilyen nevű fájl is csak az @ karakterrel kezdődött és a szine is eltért mc szerint az előtte lévőtől. Töröltem azt is. Majd sudo pacman -Syu paranccsal frissítettem a rendszert.
Szóval ez a @ elejű fájl nem olyankor keletkezik, ha szöveges fájlt kezdünk módosítani? Lehet törölni akarta a szkript, de nem ment végbe. Vagy a szkriptben felülírás van, nem törlés?[ Szerkesztve ]
-
őstag
Ilyet még nem tapasztaltam!
Arch alatt Firefox és a Chromium egy üres fehér képernyőt jelenít meg a youtube helyett, csak a fejléc látszik az oldalból, a midori simán behozza a youtube-ot. Windows alatt is megy a youtube firefox és chrome alatt. Ilyet még nem pipáltam! Milyen hiba ez?
Képernyőkép:
[link]-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
-
őstag
Ha kikapcsolom a hardveres gyorsítást a chromiumban akkor sem jelenik meg a youtube.
Opera alatt is fehérséget ad a youtube-ra, sőt a falkon browser is ugyanezt a tünetet produkálja.
Tehát a firefox chromium opera falkon browserek alatt csak a yt fejléce jelenik meg egy üres fehér oldallal. Csak a midori hozza be a yt-ot.
dailymotion rendesen megy firefox és chrome alatt, sőt a vimeo is.
Inxi kimenete:[xfce@attilav aur]$ inxi -Fxxx
System:
Host: attilav Kernel: 4.14.48-1-lts x86_64 bits: 64 compiler: gcc v: 8.1.1
Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 info: xfce4-panel dm: startx
Distro: Arch Linux
Machine:
Type: Desktop Mobo: ASUSTeK model: A88X-PLUS v: Rev X.0x
serial: <root required> UEFI [Legacy]: American Megatrends v: 3003
date: 03/10/2016
CPU:
Topology: Quad Core model: AMD Athlon X4 860K bits: 64 type: MCP
arch: Steamroller rev: 1 L2 cache: 2048 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
bogomips: 29525
Speed: 1695 MHz min/max: 1700/3700 MHz Core speeds (MHz): 1: 1695 2: 1690
3: 1695 4: 1694
Graphics:
Card-1: AMD Turks XT [Radeon HD 6670/7670] driver: radeon v: kernel
bus ID: 01:00.0 chip ID: 1002:6758
Display: server: X.Org 1.20.0 driver: radeon resolution: 1920x1080~60Hz
OpenGL: renderer: AMD TURKS (DRM 2.50.0 / 4.14.48-1-lts LLVM 6.0.0)
v: 3.3 Mesa 18.1.1 compat-v: 3.1 direct render: Yes
Audio:
Card-1: AMD FCH Azalia driver: snd_hda_intel v: kernel bus ID: 00:14.2
chip ID: 1022:780d
Card-2: AMD Turks HDMI Audio [Radeon HD 6500/6600 / 6700M Series]
driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 1002:aa90
Sound Server: ALSA v: k4.14.48-1-lts
Network:
Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
driver: r8169 v: 2.3LK-NAPI port: d000 bus ID: 05:00.0 chip ID: 10ec:8168
IF: enp5s0 state: up speed: 100 Mbps duplex: full mac: f0:79:59:6c:c6:58
Drives:
HDD Total Size: 618.55 GiB used: 10.32 GiB (1.7%)
ID-1: /dev/sda vendor: Samsung model: SSD 840 Series size: 111.79 GiB
speed: 6.0 Gb/s serial: S19HNEBD353510Y rev: AB0Q scheme: MBR
ID-2: /dev/sdb vendor: AMD Radeon model: R3SL480G size: 447.13 GiB
speed: 6.0 Gb/s serial: E201607070040523 rev: 2C scheme: GPT
ID-3: /dev/sdc vendor: A-Data model: SP600 size: 59.63 GiB speed: 6.0 Gb/s
serial: 2E4620012337 rev: 5.2 scheme: MBR
Partition:
ID-1: / size: 58.44 GiB used: 10.32 GiB (17.7%) fs: ext4 dev: /dev/sdc1
Sensors:
System Temperatures: cpu: 14.5 C mobo: N/A gpu: radeon temp: 48 C
Fan Speeds (RPM): cpu: 0
Info:
Processes: 147 Uptime: 4h 04m Memory: 7.74 GiB used: 1.67 GiB (21.6%)
Init: systemd v: 238 Compilers: gcc: 8.1.1 Shell: bash v: 4.4.23
running in: xfce4-terminal inxi: 3.0.10-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
eddie1978
aktív tag
Xfce-Dusk témát használok. Az utóbbi időben ahogyan jönnek a frissítések, egyre több helyen nem használja a beállított témát. Ez mivel van összefüggésben? GTK? Most átraktam Adwaita-dark témára, ezzel most jó. Annyi a különbség, hogy ez nem fekete hanem szürke. Picit zavar. Van valami jó fekete téma ami használható?
-
eddie1978
aktív tag
Szerintem igazad van mert ezt olvastam is valahol. Ezzel akkor nincs teendő ha jól sejtem. Marad az Adwaita-dark.
Van GTK3-as is. Majd kipróbálom. pl Xfce-dusk-gtk3 Minőségét nem tudom milyen.
[ Szerkesztve ]
-
Frawly
veterán
válasz attilav2 #5244 üzenetére
Az inxi kimenetéből az látszik, hogy rendben van a videódriver, van hardveres gyorsítás. Ha kikapcsoltad és úgy sem megy, akkor azt jelenti, hogy FF-ban szintén be volt kapcsolva. Az is biztos, hogy nem a böngésző beállítása, addonja, mert több böngészővel sem megy. A Chrome, Opera azonos böngészőmotort használ (Blink), de nem is lehet az, mert mind a FF, mind a Falkon más motorral fut.
Próbából az Xfce-ben kapcsold ki a kompozitort. Tényleg csak tesztképpen, kicsi az esélye, hogy segít. Ha az lenne a baj, akkor más oldalak sem jelennének meg.
[ Szerkesztve ]
-
Silεncε
őstag
Sziasztok! Szeretnék kicsit ismerkedni az Arch-al, sok jót hallottam már róla. Jelenleg a laptopomra szeretném telepíteni (ThinkPad X230), most van rajta dualbootban egy Windows10 és egy Ubi 18.04. Viszont a partícionálással totál elakadtam. Szeretném róla az uborkát letakarítani és a helyére rakni az Archot, viszont fogalmam sincs, hogy kéne. UEFI-t használok a laptopon, a Windows már megcsinálta az EFI partíciót, innen viszont nem tudom merre tovább. A wikin valószínűleg a bénaságom miatt nem tudok eligazodni, tudna valaki segíteni, pontosan merre induljak el?
Előre is köszi!
-
Frawly
veterán
válasz Silεncε #5249 üzenetére
Az Arch Wikinek ezt a cikkét nézd.
A lényeg, hogy fel kell lennie csatolva a EFI partíciónak, tipikusan /boot-ként. Ekkor arch-chrootban kiadod a bootctl --path=/boot install parancsot, és felteszi az EFI partícióra az Arch indítófájlait. Ezzel nincs vége, mert szerkeszteni kell egy konfigfájlt is, a /boot/loader/loader.conf néven, sőt, kell egy conf fájl a /boot/loader/entries/-be is, ennek a neve szabadon választott, de össze kell egyeztetni a loader.conf-ban írtakkal. Én is így csináltam meg az Arch EFI bootját, csak X220-on. Működik. Úgy is, hogy ha Win10 van mellette.
Ha elakadnál, akkor nyugodtan kérdezz még, lehetőleg a hibaüzenettel együtt, amit kiírt.
Új hozzászólás Aktív témák
- Nők, nőügyek (18+)
- Autós topik
- Ukrajnai háború
- Helldivers 2 (PC, PS5)
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- HiFi műszaki szemmel - sztereó hangrendszerek
- Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
- Gitáros topic
- Azonnali VGA-s kérdések órája
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest