- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Apple notebookok
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Videós, mozgóképes topik
- CPU léghűtés kibeszélő
- Melyik tápegységet vegyem?
- Vezetékes FEJhallgatók
- Kormányok / autós szimulátorok topikja
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
-
PROHARDVER!
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
-
válasz
growler
#28853
üzenetére
Ez nem elég tiszta dolog, úgy látom, bár ezer éve foglalkoztam a témával. Az általad linkelt írásban is az a konklúzió, hogy fene tudja, no de mindegy. Garbage collection akkor is jól működik, mivel azt saját vezérlője intézi az SSD-nek, modernebb vezérlők meg simán megoldanak mindent TRIM nélkül is. Szóval tényleg nem működik ATA parancsként a discard, ha manuálisan kiadom, ezt dobja a terminal
ubyegon@LM191Cin-8570p:~$ sudo fstrim /media/ubyegon/a3758240-3c59-40fb-af9f-042681c26dc4
fstrim: /media/ubyegon/a3758240-3c59-40fb-af9f-042681c26dc4: the discard operation is not supportedDe fentiek miatt nem is lényeges például 860 EVO-nál. Egyébként érdekes, hogy a
sudo fstrim --allparancs meg nem dobott hibakódot! Igaz nullát se.The command fstrim --all returns 0 (all succeeded), 32 (all failed)
or 64 (some failed, some succeeded).(#28852) samujózsi
Most már ezt a külső házas dolgot jobb ha nem feszegetjük, mert ha nem működne a dolog, akkor rosszul jársz!
[ Szerkesztve ]
mennyé' be az ólajtón és ne gyere ki
-
válasz
Jester01
#28844
üzenetére
Szerintem nem halado tema, de en is hasonlo helyzetben vagyok, csak desktop kornyezetben es a celrendszer nem ugyanaz, mint amin most vagyok.
A jelenlegi Mint 18.3 Xfce mar csak nyomokban tartalmaz Xfce-t es jo ideje i3-mal hasznalom, tobbek kozt ezert valtanek Manjaro i3-ra.
A /home nem hidden resze es a relevans dot fajlok (i3 config, .zshrc, .vimrc, rofi config, etc.) mennenek az uj rendszerre.
Az a terv, hogy a Manjaro install utan kezzel atmasolgatom, ami kell.
A regi SSD-rol mar nem akarok bootolni, de lehet, hogy marad a gepben.
A telepito ilyenkor leszedi a GRUB-ot a regi rendszer mellol es nem fog osszekavarodni a ketto? Mire kell figyelnem? -
válasz
0xmilan
#28855
üzenetére
Mire kell figyelnem?
Arra, hogy Manjaro mellett ne tarts Ubuntu alapú disztrókat, mert ha annak frissól a kernele, akkor az kinyírja a Manjaro init-jét, persze vissza lehet állítani manuálisan. [link]
Legacy esetén az utolsó GRUB mindent visz, nem érdekli a többi (kivéve ha Manjaro is van), nem értek hozzá, csak tapasztalatból mondom. Sokáig volt SSD mellett HDD-n is disztróm és ha BIOS-ban arról bootoltam, annak a GRUB-jával indult a kiválasztott rendszer.
[ Szerkesztve ]
mennyé' be az ólajtón és ne gyere ki
-
-
válasz
0xmilan
#28859
üzenetére
Manjaro mellett ne tarts Ubuntu alapú disztrókat, mert ha annak frissül a kernele, akkor az kinyírja a Manjaro init-jét
3 hsz-szal ezelőttről.......(ha nem olvastad, akkor bocsi)
Mint kernel upgrade után a Manjaro boot ilyen képet mutatott. Ez akkor is tény ha nem akarjátok érteni.
De ne foglalkozz ezzel, csináld amit gondolsz és majd meglátod mi történik. Vedd úgy, mint ha nem szóltam volna.
[ Szerkesztve ]
mennyé' be az ólajtón és ne gyere ki
-
válasz
ubyegon2
#28860
üzenetére
Elolvastam nyilvan, meg ertem is, csak azt nem hogy miert.
Valami olyat sejtek, hogy a manjaros GRUB nem tudja lekezelni, hogy a masik rendszer alatt valtozott a bootolando kernel, mert az csak a sajatjat frissitette.
De koszi az infot. Erre nem gondoltam volna, mint potencialis issue.
Mint irtam, nem tervezek a regi Mint-be bootolni, igy ez a veszely nem fenyeget.csináld amit gondolsz és majd meglátod mi történik
Ja, vsz tulbonyolitom
[ Szerkesztve ]
-
válasz
0xmilan
#28861
üzenetére
Senki nem érti miért, mint ahogyan azt sem, miért nem javítják Manjaro-nál ezt a bugot évek óta. Más Archklónnál ez nem jelentkezett. Gondolhatod mennyire megdöbbentem, mikor először ugrott arcomba a kernel panic képe!
Ahogy írták, ne legyen Manjaro mellett Debian/Ubuntu alapú disztró, mert az sem megoldás, hogy utoljára rakják fel a Manjaro-t, épp a kernel frissítés miatt.....
Ja, vsz tulbonyolitom
Nem bonyolítod túl, a helyzet bonyolult addig, míg nem csinálod 20x egymás után, a végén már fejből a Manjaro init javítását.
(lehet, hogy tényleg nem haladó téma, mivel én is belevauzok itt a nagyok topikjába)
[ Szerkesztve ]
mennyé' be az ólajtón és ne gyere ki
-
samujózsi
senior tag
Visszatérve az SSD-re...
Ez a tavaly januári állapot:
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 2298177 Wear_Leveling_Count 0x0013 098 098 000 Pre-fail Always - 49Ez a mai
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 3593177 Wear_Leveling_Count 0x0013 097 097 000 Pre-fail Always - 791300 óra, az kb. 150 napnyi használat. Az SSD ezt megelőzően kb. négy éven át egy Windows 7-es laptopban volt, úgy jutott el 30-35-ös Wear Leveling Count-ig.
Két éve linuxra váltottam, nincs HPA, nincs üresen hagyott terület, de nincs swap sem rajta, a fájlrendszer rendszeresen trimmelve van és közel 100GB szabad a fájlrendszeren. Így jutott el két év alatt 79-ig, holott jóval kevesebbet használtam, mint Windows alatt.
Ezt a linux okozza? Vagy ez a wear level nem lineárisan növekszik?Azért is furcsa, mert a szerverként használt gépemben is SSD van, de az Kingston, 7x24-ben megy, 28600 órán át volt bekapcsolva, mégis csak 4%-nyit csökkent a várható élettartama (SSD_Life_Left értéke 100-ról 96-ra csökkent, a threshold érték 11)
Viszont ezen be van kapcsolva a HPA, igaz, kevesebb van fenntartva, mint az ajánlott 10%.Lehet, hogy kár volt elhinnem amit talán az askubuntu-n olvastam arról, hogy felesleges az over provisioning?
Itt azt írják, hogy a raw value-val nem kell törődni.
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
válasz
samujózsi
#28864
üzenetére
Jó SSD az, ha növekszik a Wear Leveling Count értéke, mert amúgy 100-ról csökken alapból az elhasználódás alapján.
Lehet, hogy kár volt elhinnem amit talán az askubuntu-n olvastam arról, hogy felesleges az over provisioning?
Neked felesleges vele külön foglalkoznod az esetek nagy részében, egyrészt gyárilag is el van különítve erre hely sok tipusnál, például nekem van egy 120GB-os Intel 520, az is 128GB-os, mivel a NAND-ok mérete adott, csak gyárilag le van foglalva 8GB. Az EXT4 is tartalékol helyet, amihez alapból nem férsz hozzá és gyakorlatilag minden szabad hely rendelkezésére áll a vezérlőnek az overprovisioninghoz. Particionált vagy particionálatlan terület, az mindegy a vezérlőnek.
Egyébként Linuxos programok nem valami megbízhatóan olvassák a smart értékeket, én a helyedben összehasonlítanám ezeket a HDS eredményeivel(igaz a Linuxos verzió nem sok adatot dob). Ha meg a 840-es SSD-d hoz hülye értékeket, azon nem érdemes csodálkozni, ritka bughalmaz széria volt.
Linux jóval kevésbé nyírja amúgy az SSD-t, mint a Windows, múlt évben néztem az akkor kb 5 éves Intel 520-ast és 7TB írás volt rajta. Éjjel nappal futott valami desktop disztró rajta.
A 860 EV 250GB-ot kb január óta használom:
HDD Device 0: /dev/sda
HDD Model ID : Samsung SSD 860 EVO 250GB
HDD Serial No: S3YJNX0K609165E
HDD Revision : RVT01B6Q
HDD Size : 238475 MBx
Interface : S-ATA Gen3, 6 Gbps
Temperature : 34 °C
Highest Temp.: 49 °C
Health : 100 %
Performance : 100 %
Power on time: 117 days, 12 hours
Est. lifetime: more than 1000 days
Total written: 1.49 TB
The status of the solid state disk is PERFECT. Problematic or weak sectors were not found.
No actions needed.Itt azt írják, hogy a raw value-val nem kell törődni.
A sudo smartctl -a /dev/sdx raw értékei pedig jók, az az egyetlen oszlop, amit érdemes nézni.
Ezt a részt berakhatnád
Programkód-dal, valaki biztosan ért az SSD-khez és megnézi.SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0032 100 100 000 Old_age Always - 0
9 Power_On_Hours_and_Msec 0x0032 000 000 000 Old_age Always - 921173h+19m+01.520s
12 Power_Cycle_Count 0x0032 098 098 000 Old_age Always - 2420
170 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always - 0
171 Program_Fail_Count 0x0032 100 100 000 Old_age Always - 0
172 Erase_Fail_Count 0x0032 100 100 000 Old_age Always - 0
174 Unexpect_Power_Loss_Ct 0x0032 100 100 000 Old_age Always - 2418
184 End-to-End_Error 0x0033 100 100 090 Pre-fail Always - 0
187 Uncorrectable_Error_Cnt 0x000f 120 120 050 Pre-fail Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 2418
225 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 297166
226 Workld_Media_Wear_Indic 0x0032 100 100 000 Old_age Always - 65535
227 Workld_Host_Reads_Perc 0x0032 100 100 000 Old_age Always - 35
228 Workload_Minutes 0x0032 100 100 000 Old_age Always - 65535
232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always - 0
233 Media_Wearout_Indicator 0x0032 100 100 000 Old_age Always - 0
241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 297166
242 Host_Reads_32MiB 0x0032 100 100 000 Old_age Always - 163505
249 NAND_Writes_1GiB 0x0013 100 100 000 Pre-fail Always - 11084Ez a sor nálam nulla, lehet, hogy Intelnél ez felel meg a 100%-nak? (múlt évben néztem SSDOK-kal, akkor ott 100% volt)
233 Media_Wearout_Indicator 0x0032 100 100 000 Old_age Always - 0[ Szerkesztve ]
mennyé' be az ólajtón és ne gyere ki
-
válasz
growler
#28867
üzenetére
Tegnap megnéztem a
sudo hdparm -I /dev/sdb | grep TRIMkimenetet, support volt, de akkor az tényleg magának az SSD-nek a képességeire utal. Tényleg kezdenem kéne valamit már az SSD-s blogommal, egyre több részlet gázos benne ezek szerint.mennyé' be az ólajtón és ne gyere ki
-
samujózsi
senior tag
válasz
growler
#28867
üzenetére
Friss az élmény?
(úgy értem, újra tudod próbálni?)Van a smartctl-nek egy -d kapcsolója, amivel néhány doboznál egész jó eredmények érhetőek el. Igaz, é a -A mellé használtam, mikor nem adott semmi infót a benne lévő diszkről.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
-
válasz
growler
#28873
üzenetére
Én egy 860 EVO-t tarogatok a Mint 20 Cinnamonra.
A telepített Linuxok nekem is 860 EVO-n pörögnek, a 850 EVO az a pendrive!
Axagon házak jók és nem is drágák valóban! Multkor akartam is venni, mikor King kolléga valahol linkelte, de aztán a NAS projekt elvitte a dolgot másfelé.....mondjuk ez is megfeneklett kicsit.Nem egyezett saját elképzelésemmel, amit olvastam és inkább jegelem a projektet, hogy szegény NAS egyben maradjon.mennyé' be az ólajtón és ne gyere ki
-
samujózsi
senior tag
Hogy lehet megnézni egy docker image adatait anélkül, hogy letölteném?
Például:docker search ubuntu
Ez kidob rengeteg találatot. Mondjuk kíváncsi vagyok, hogy a legelső, az official milyen verziót tartalmaz? (vagy a méretére vagy a ... szóval bármi, ami egyébként elérhető infó)
Hogy tudom lekérdezni?Valamiért úgy érzem, ez nem egy triviális dolog.
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
válasz
samujózsi
#28875
üzenetére
Alapvetően egy Docker container image -ről nem fogod tudni eldönteni, hogy mi van benne, erre nincs API érhető okokból. Tehát csak a készítő specifikációjában bízhatsz. DockerHub, stb.. Ha mélyebben érdekel a téma, van egy aprócsak Docker topikunk, de hátha ott több ötletet kapsz
-
samujózsi
senior tag
válasz
haddent
#28877
üzenetére
Félreértesz, azt hiszem. Nem a konkrét tartalmára vagyok kíváncsi, hanem fogalmazzunk úgy, a metaadatokra. Az image konkrét méretére, a hozzá tartozó teljes leírásra, aminek egy része a search kimenetében megjelenik. Satöbbi.
Tegnap próbálkoztam közös felebarátunknál, a google-nél, és arra jutottam, hogy erre nincs parancs, valami webes API segítségével lehetne lekérni, ha jól értem. Ha... kérdés, hogy jól értem-e?[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
-
Vladi
nagyúr
válasz
samujózsi
#28882
üzenetére
Ha látok 21 új hozzászólást amiből kb 15 offba van téve akkor mi legyen? Fél délelőtt mérlegeljem, hogy offe?
On ami linux és nem kezdő. Tehát telepítés, program felrakás, vagy hogy írjak be egy parancsot kapcsolóval a terminálba. MInden ami e fölött van. Amibe beletörne a bicska a kezdőbe.
il sole non sorge più ad Est!
-
samujózsi
senior tag
Nem erre gondoltam.De mégis, csak az első mondatra válaszoltam kapásból. Általában "remegő kézzel" bökök a Küldés gombra, hogy vajon jó helyen van-e itt amit kérdezek vagy inkább menjek a kezdőbe vele.
Ahogy elnézem a kezdő topic-ot, ott sokkal több olyan kérdés van, amit néha nem is értek, nemhogy esetleg válaszoljak rá, itt meg legalább ami felmerül, azt úgy-ahogy értem.
Más kérdés, hogy általában előtte próbálom a google-t vallatni, csak az meg... hát olyan, amilyen.
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
senior tag
A tudomány mai állása szerint milyen módon illik belakni egy vadiúj SSD-t?
Régen erősen javasolt volt hdparm segítségével lefoglalni az ú.n. over provisioning területet (HPA a kulcsszó ha igaz)
Később azt olvastam, hogy ez felesleges, bőven elég, ha partícionálatlanul hagyok 5-10%-ot.
Még később olvastam olyat is, hogy valójában ez is felesleges.
Mindez több mint három éves infó, azóta változott-e valami, amiről nem tudok?Aztán emlékszem még az fstab discard opciójára, ami egyes SSD-k esetében gondot okozhatott, ezért került be egy naponta vagy hetente futó fstrim -v. Samsung 860Pro esetében mi a helyzet? Tudja valaki?
Van valami egyéb ami fontos lehet egy notebookba rakott SSD használatakor?
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
senior tag
válasz
sh4d0w
#28888
üzenetére
Köszi mindkettőtöknek, csak ettől kezdve nem értem, hogy mi ette meg a mostani SSD-t.
Annak utánanéztem, hogy a LUKS nem jelent számottevő írástöbbletet, fstrim viszonylag rendszeresen futott, ext4 fs-t használok, swap ugyan van rajta, de nincs használatban és kb 50% szabad a 256GB-ból.
Mégis két év nem túl intenzív használat után nagyobb elhasználódást produkált, mint előtte négy év intenzív win7 használattal.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Jester01
veterán
válasz
samujózsi
#28890
üzenetére
Az a wear levelling count 1-et csökkent összesen,
098-ról097-re. Nem tudom ebből hogy számította ki az utolsó oszlopot de én nem aggódnék.Egész véletlen nekem is 97, de a raw value az 157. Biztos más skálázás, de nem tudni ez felfelé hová megy. A 97 viszont garantáltan lefelé 0-ra szóval én azt nézném.
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 090 090 000 Old_age Always - 48313
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 194
177 Wear_Leveling_Count 0x0013 097 097 000 Pre-fail Always - 157[ Szerkesztve ]
Jester
-
Frawly
veterán
válasz
ubyegon2
#28850
üzenetére
A hardveres titkosítást használó SSD-k mindig titkosítanak, így a 860 EVO is. Ezt le sem lehet tiltani rajtuk. Viszont alapesetben a titkosításhoz használt random generált kulcs az SSD-n el van tárolva (ez nincs külön titkosítva alapesetben), amivel automatikusan feloldja, ezért neked úgy tűnik, hogy nincs letitkosítva.
Viszont ha olyan géped van, aminek a BIOS-a támogatja, vagy hdparm-mal megcsinálod, akkor be tudod rajta kapcsolni az ATA jelszót, ez azt csinálja, hogy újragenerálja a hardveres titkosításhoz használt random kulcsot (ezzel az összes fent lévő adatnak is azonnal bukó lesz, abban a pillanatban), majd ezt a kulcsot is letitkosítja azzal az ATA jelszóval, amit megadsz neki. Így viszont már csak akkor férsz hozzá az SSD-hez, ha ATA jelszóval oldod fel.
A titkosítás nem a géphez, hanem az SSD-hez kötődik, ha be van kapcsolva a jelszó, akkor más gépeken is csak úgy lehet hozzáférni, ha tudod a jelszót.
Ez a felcsatolt fájlrendszered ez egyébként micsoda, amire az fstrim ezt a discard operation is not supported hibaüzit írja? NTFS, FAT32, vagy micsoda? Milyen meghajtón van ez pontosan, milyen SSD, min keresztül kapcsolódik a gépre? SATA, USB?
[ Szerkesztve ]
-
Frawly
veterán
válasz
samujózsi
#28849
üzenetére
A LUKS, VeraCrypt, BitLocker és társai gyorsabban amortizálják az SSD-t. Illetve a szoftveres titkosításoknak van egy hátránya SSD-n. Át kell engedni rajtuk a TRIM-et, viszont ez meg könnyebben törhetővé teszi a titkosítást, mintázati támadással. Ha viszont nem engeded át rajta a TRIM-et, akkor meg az SSD-nek rosszabb, nem tud működni a garbage collection sem, mivel az SSD vezérlője úgy érzi, hogy tele van az SSD adattal, és nem pakolgathat rajta semmit. Szoftveres titkosításnál ugyanis az egész meghajtó tele van írva random titkosított adattal, azok a részek is, amiken valójában nem tárolsz adatot.
A hardveres titkosítás ennyiből biztonságosabb. Viszont hardveresen titkosított SSD-ről akkor tudsz csak bootolni, ha a gép BIOS-a támogatja az ATA jelszót. Már pedig csak üzleti laptopok, céges kliensgépek, workstationök, serverek szoktak ilyet tudni, konzumer laptopok, asztali alaplapok nem! Egyébként BIOS-támogatás hiányában csak adattárolónak használhatod, és (Linuxon) hdparm-mel tudod feloldani használat előtt, meg először ATA jelszavazni is ezzel tudod.
Viszont a hardveres titkosítás veszélyesebb is. Ha véletlenül rosszul jelszavazod le, vagy elfelejted a jelszót, kizárod magad az SSD-ből örökre, nem lesz róla leoldható a titkosítás, dobhatod ki a kukába. Gariban sem cserélik, és a gyártó sem tudja róla a tiktosítást feloldani. Tehát a hardveres titkosításnál nagyon kell tudni, hogy mit csinálsz. Az ATA jelszó ugyanis nem csak az adataidat védi, hanem az SSD-t is a lopástól. Pont arra az esetre csinálták, ha valaki ellopja a gépet, az ATA jelszavazott meghajtót dobhatja ki, nem lehet újrahasznosítani. Nincs rá semmi átforrasztós, elemkivevős, firmware-frissítős, meg orosz crackes trükk, hogy leoldd róla a titkosítást.
Ha a LUKS jelszót felejted el, az nem baj, le lehet törölni a meghajtót, és csak az adatokat bukod, nem az egész SSD-t.
-
samujózsi
senior tag
válasz
Frawly
#28894
üzenetére
Köszi. A hardveres titkosítás veszélyére nem gondoltam.
Úgy emlékeztem, hogy azt is lehet resetelni adatvesztés árán.
Így azt hiszem, jobb ha azt hanyagolom.Hardveres titkosításnál nem is lehet módosítani a jelszót adatvesztés nélkül?
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Frawly
veterán
válasz
samujózsi
#28896
üzenetére
Nem, nem lehet módosítani a jelszót adatvesztés nélkül. Sem a hardveres titkosításnál, sem a szoftveresnél. Így a jelszót jól meg kell választani, hogy biztos hosszú, bonyolult legyen, de számodra könnyen megjegyezhető. Az ilyen 12345, password, meg egyéb amatőr húzásokat el kell rajta felejteni. Min. 8 karakter, számok, kisbetű, nagybetű, egyéb karakterek (írásjelek és/vagy ékezet). Bár egyes BIOS-ok az ATA jelszónak határt szabnak, pl. az én ThinkPad X220-amon úgy van megoldva, hogy a BIOS nem tesz különbséges kis-nagybetű között (nagybetűsként tárolja a jelszót, mindegy hogyan viszed be), és egy csomó speciális karaktert sem enged.
Persze a jelszómegváltoztatás (ami lényegében mindig újratitkosítás) nem valódi adatvesztés. Másolatnak minden fontos adatról kell lennie, meg ilyen jelszómódosítás előtt át tudod menteni az adatokat másik (szintén előre titkosított) drive-ra. Ez egyszerű szervezési kérdés, kényelmi szempont.
-
samujózsi
senior tag
válasz
Frawly
#28897
üzenetére
Szoftveres alatt mit értesz? Ha például a LUKS is ide tartozik, akkor ott lehet jelszót módosítani. Sőt... ott több eltérő jelszóval is lehet dolgozni egyszerre.
Ui: ékezetes karakter bármilyen jelszóban nagy hiba. Szerintem. Főleg, ha a BIOS bootoláskor nem ad megfelelő billentyűzet kiosztást.
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
senior tag
Két újabb kérdés:
1. Tudja valaki, a google chrome (tehát nem a chromium), hol tárolja a cookie-kat, illetve ha nem mondom neki, hogy törölje azokat, akkor miért törlődnek időnként mégis?Átköltöztem 16.04-ről 18.04-re, áthoztam a ~/.mozilla könyvtár és a ~/.config/google-chrome teljes tartalmát a régi rendszerről.
A Firefox úgy-ahogy rendben van, csak a cache tűnik hiányosnak, a chrome alól viszont eltűnt az összes cookie, viszont az egyéb history adatok megmaradtak.2. Van egy "apró" rsync logom. A végén ott van, hogy voltak hibák másolás közben, de hogy konkrétan hol, az nem derült ki. Hogy tudnám a kb. kettőszázezer sorból kiszűrni a "zajt" és megtalálni benne az érdemi hibaüzeneteket? Van erre valakinek ötlete?
ui: bevallom, most kihagytam a google-t, egyből ide jöttem.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
(úgy értem, újra tudod próbálni?)
Új hozzászólás Aktív témák
Hirdetés
- Game Pass Ultimate előfizetések 1 - 19 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN! AKCIÓ!
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Játékkulcsok a legjobb áron: Steam
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, kedvező ár!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest