Kösz az ötletet, ezt én is olvastam valahol hogy altatással kiváltható a tápreset. Tehát ezzel laptopoknál is lehet használni..

Azért egy egyszerű képernyő felbontás problémától amire a segítséget kértem eljutottunk a lopásra felbujtásig..

Sajnos a 'blkdiscard' csak file/szektor szintű művelete(ke)t végez, míg a Secure Erase egy ATA szintű művelet, ezért ugyan hasonlót csinál, de nem ugyanazt. Ezért találtad meg utána azt amit nem kellett volna megtalálnod.

Láton kénytelen leszek kézikönyvet nyomtatni a 'hdparm' hoz, vagy tudás nélkül kisérletezni a PM képernyőfelbontás kézi megadásával a cfg fileokban..

18.10 Mate totál friss belakatlan kimenet.

(#63802) Doky586

kisérletezni a PM képernyőfelbontás kézi megadásával a cfg fileokban.

És ha rájössz a megoldásra egyébként? Mit érsz vele...ill. perzisztens módban telepített PM a pendrive-on....ha csak úgy nem! Ha nem perzisztens, akkor bakfitty. Meg persze amúgy is, lásd a Kapitány által leírtakat.

hdparm man-ját rárakod mobilra, de 10 alkalom után már fejből is tudni fogod a parancsot, ami kell

[ Szerkesztve ]

Négyen válaszoltak a kérdésedre, gondoltam átmegy......katonai hierarhiában - nem annyira katonai ez a kapitány kifejezés, nálunk például nincs is kifejezetten ilyen.

Perzisztens alatt azt értem, hogy ha egy telepítő pendrive-on eszközölt változások elmentésre kerülnek, más esetben nem változik a telepítő/live oprendszer tartalmilag. példa

(#63806) Cifu

Kösz, hogy közben kisegítetted a kollégát.

[ Szerkesztve ]

A hdparm-mal ne játssz, ha nem tudod mit csinálsz. Elgépelsz egy parancsot, és hazavághatja javíthatatlanul az egész meghajtót. SSD-nél és HDD-nél is. Csak akkor javallott a használata, ha tényleg ismered a kapcsolókat és pontosan tudod mit kell csinálni.

Egyébként security erase helyett lehet futtatni ezt is terminálban:
lsblk
sudo blkdiscard /dev/sdakármi (a /dev/azonosítót a fenti parancs jelzi ki)

Ez a megoldás is végigtrimezi az SSD-t, mint a security erase, és csak pár másodperccel tart hosszabb ideig.

Szerk: á, látom megelőztek. Ugyanazt csinálja mindkettő, csak a security erase-t a firmware hajtja végre, és két fajta security erase is van, az egyik csak a titkosítási kulcsot trimezi felül, a másik a teljes meghajtót. A blkdiscard a teljes meghajtót. Ugyanaz az eredménye, épp olyan biztonsággal törli végig a meghajtót mindkét módszer. Még -s kapcsoló nélkül is. Egy végigtrimezett meghajtóról minden adat törlődik, semmit nem tudnak visszaállítani róla.

Esetleg ez a security erase NVMe meghajtóknál lehet fontosabb, mert azokon alapból nincs TRIM külön (az SATA/AHCI feature), a törlési paranccsal van összekötve.

[ Szerkesztve ]

De, igazad van, vannak ilyen SSD-k. De nem mindegyik. Nem mindegyik támogatja a titkosítva tárolást, ATA jelszavazást, és a security erase-t.

Nemrég találtam ezt az ajánlást SSD biztonságos törlésére: [link]
Egyszer más alkalmaztam is, egy 30 GB-os SSD törlésére.
A rajta lévő rendszert lesöpörte, és az egész lemezen formázatlan területet hozott létre.
Úgy nézem, ezt régebbi SSD-khez ajánlják, de gondolom a moderneknél is alkalmazható.

Igen, ez használható módszer. Bár nem minden alaplap támogatja, hogy csak úgy lehúzogatod a SATA kábelt, van, amelyiknél ezt a trükköt nem tudod eljátszani, mert a BIOS-t felkészítették erre a trükkre.

Szóval nem az SSD régiségétől, hanem az alaplap/BIOS korától függ. De ha nincs lejelszavazva az SSD, és támogatja a security erase feature-t, akkor a hdparm minden esetben tud security erase-t végrehajtani. Ez a security state frozen, non frozen akkor számít csak, ha az SSD le van jelszavazva.

Hát szívesen....

Egyszerűen úgy csináltam, hogy indítottam egy live rendszert.
Betöltődése után, rádugtam az SSD.re a SATA tápcsatlakozót. (Az AHCI lemezkezelés
támogatja a hot-plugot.) És az SD-t nem csatoltam.
A kiadott "sudo hdparm -I /dev/sdx" parancs azt dobta ki, hogy not frozen.
Tehát, mehetett a "sudo hdparm --security-erase NULL /dev/sdx" parancs.

A gép, valamivel több mint 8 éves PC - BIOS-os.

[ Szerkesztve ]

Két malomban örlünk. Amikor elindul a gép, egy indító menü jön fel, és ott kiválasztani a failsafe menüt:
boot menu

De lehet hogy az extra-ban van, nem néztem meg. Itt szokott lenni egy 800x600-as, vagy VESA kompatibilis móddal indító üzemmód ami pont az ilyen VGA hibákat küszöböli ki.

[ Szerkesztve ]

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

Köszönöm szépen ez bejött !
Ugyan azon menupont alattiakkal sem működött, de akkor már kipróbáltam a többit is, és az alternatív grafika 32 -vel működésre lehetett bírni. Igaz kicsit furán: kb 800x600 felbontásnak néz ki nagy ikonokkal, a monitoron ellenőrizve az valójában 1920x1080@60 NN felbontású és a gépem is 64 bites (ezért eddig csak a 64-es dolgokat próbáltam)

Ha elolvastad, amit irtam, orultem, hogy talaltam olyat, ami telepult, es valahogy mukodott.
Majd, ha az illeto akarja, frissiti egy frissebbre - de ha az megint lassu lesz, majd visszajon es megint engem fog boldogitani.

A masik mondatodat nem ertem, ketfele dolgot irtam.
Megirnad, hogy melyikre vagy kivancsi reszletesebben es mit nem ertettel abbol, amit leirtam?

tippem szerint ezek lehettek a kérdés tárgyai:

""
Telepites nem lehetseges, mert olyan syslinux-ot hasznal, ami bug-os egy eve, igy hivatalosan nem adtak ki:
fedora xfce live 20181029
MX-17.1
Lubuntu 18.04
""

Többek szerint mégis kiadásra került. (milyen forrásokból merítetted az infóidat?)

""
nincs egy normalis hibakezeles, minden disztribucio ugyan azt a semmitmondo sablonszoveget hasznalja:
xubuntu 14.04
xubuntu 18.04
Lubuntu 16.04
Linux mint xfce 17
""

Gondolom az azonos csomagkezelő miatt a ráépülő GUI-s rendszerek hibaüzenetei értelemszerűen ugyanazok. (igaz nem említed, hogy hol olvasgattad ezeket a hibaüzeneteket, de gyanítom nem terminalban, pedig rendkívül szakavatottnak tűnsz a megállapításaid alapján)

Mi lenne ha inkább nézegetnéd a hibaüzeneteket? Azért semmitmondóak, mert nem érted őket, az nem lehetséges?

How To Use Journalctl to View and Manipulate Systemd Logs

[ Szerkesztve ]

A forras egyreszt a rufus indoklasa github-on, ami szerint ez a hivatalos oldal es itt 6.03 az utolso, mert a 6.04 meg mindig "bug"-os,
https://mirrors.edge.kernel.org/pub/linux/utils/boot/syslinux/

es tegnap rakeresve be is jott az az oldal, ami szinten azt irta, hogy bar egy eve bejelentettek a 6.04-et, meg mindig csak "pre" allapotban van, es az oldalon szurke szinu volt az egesz hir jelezve, hogy csak tajekoztatas.

Ami a hibauzenetet illeti egy tobb soros angol nyelvu marhasag, miszerint a merevlemezre masolas nem sikerult, vagy a merevlemez, vagy a cd/dvd lejatszo hibas, vagy valami mas - emlekeim szerint ugyan ez a sablonos marhasag volt mar tizen-huszon evvel korabban a suse valamelyik verziojaban, amig vegre kiderult, hogy valamelyik linuxos hoborgott, hogy tulmelegedett a gepe, es attol kezdve suse nem telepult olyan geppre, ahol nem tudta kozvetlenul olvasni a cpu homersekletet, de persze a hibauzenetet azota se modositottak.

Arra jo, hog szegeny gyanutlan, linuxot eloszor telepito valaki szivrohamot kapjon, hogy a linux szerint hamarosan megdoglik a merevlemeze, es erdekes, hogy ennek a linox telepitosok orulnek, de hat ez van.

Amugy kozben rajottem, hogy a MX-et cigam ajanlotta itt, a forumon, ezert probaltam ki.

Ui:
Valaki szolhatna mar a "zilletekes elvtars"-nak, hogy vegyek le rolam a korlatozast, idegesito, hogy nem irhatok. Igerem, amint befejezem a temat, leiratkzom errol a forumrol, csak addig hadd kerdezzek, mert van mit.

Ezt nehéz értelmezni, mivel írsz.

Igen, mert valaszoltal.
Egyetlen kerdest tehetek fel, meg kell varnom, hogy valaki valaszoljon, es akkor irhatok ujabbat.
Mondhatni nagyorom, foleg, hogy este van, ilyenkor gyer a forgalom errefele.

Amig korlatozva voltam, megtalaltam a rufusos irast:
https://github.com/pbatard/rufus/issues/1045

Alul van az indoklasa, ide masolom, ne kelljen kattintani, angolul tudok elonyben:

"First of all, as per the log, Rufus does embed TWO versions of Syslinux: 4.07 AND 6.03, 6.03 being the very latest OFFICIAL RELEASE of Syslinux (again 6.04 has NOT been officially released, and therefore it is not something that can be included in Rufus).

Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06

Second, if you actually bothered to test, you would have found that Syslinux 6.04-pre is already supported by Rufus anyway.

Now, if you are unhappy about the fact that Syslinux 6.04 has not yet been released in an official manner, and therefore is not included in Rufus, you can try to see with the Syslinux project when they plan to release 6.04."

[ Szerkesztve ]

Igen, mert valaszoltal.
Egyetlen kerdest tehetek fel, meg kell varnom, hogy valaki valaszoljon, es akkor irhatok ujabbat.

Ja, hogy már ilyen szabály is van!? Akkor nem kell aggódnod, ezt automatikusan leveszik rólad x idő vagy hsz után.

(#63826) Victor Súgó

Elég kényelmetlen lehet ez a szabály, de gondolom okkal vezették be.....persze ez a normális fórumozók agyára megy ettől még.

[ Szerkesztve ]

Mire megtalaltam a syslinux forrast, letelt a szerkesztesi ido, tessek:

https://www.syslinux.org/wiki/index.php?title=Syslinux_6_Changelog

Ezt sosem értettem, hogy mi az a DD képfájl mód.
Ugye általában iso-t írunk ki (mivel anno eredetileg cd-n volt minden), ezért ezt kell általában választani, de már én is futottam bele abba, hogy DD Image mód kell, hogy tudjak bootolni róla.

A rosszban mindig van valami megtévesztően jó, különben nem választanánk a rosszat

Szóval linuxot mindig DD módban kell kiírni.

"ugyanúgy írja ki az ISO-t, mint Linuxon terminálban a dd"
Ez az amit nem értek, hogy ott mi más (a mechanizmus részeltei nem érdekelnek (ahhoz sajnos kevés vagyok), hanem csak így címszavakban, hogy mit csinál másképp dd módban).
Kicsit ezt most úgy tudom értelmezni, hogy dd-ben linux módon/módszerrel írja ki.

Eddig csak párszor csináltam bootolható pendrive-ot linuxon, de az ilyen next-next-finish volt, nem nagyon volt opció és magyarázás.

[ Szerkesztve ]

A rosszban mindig van valami megtévesztően jó, különben nem választanánk a rosszat

dd-vel egy az egyben kiírod az ISO tartalmát.
Egyéb esetben általában varázsolni szoktak, pl felrak egy grub-ot mellé rakja az ISO-t és ezt tölti be vele (ilyen módszerrel lehet multi boot pen-t csinálni). Utóbbival az lehet a gond hogy kicsit is másképp kell paraméterezni akkor lehet hogy nem működik out of the box (jellemzően Arch alapúak nem mennek/mentek(?))

Vigyázat, csalok!

Egy kis tapasztalati hsz. csak.

A cél: feltelepíteni egy, a netről letöltött betűtípust (.ttf). A windowson nevelkedett embereknek ez csuklóból megy (jobb gomb, betűtípus telepítése), de Linuxnál persze nem így működik. A baj az, hogy fogalmam se volt, hogyan. Google skill elő, ám a találatok "meglepő" módon szinte kizárólag konzolparancsokban gondolkodnak. Én a Linuxnál eredetileg szerettem volna pusztán GUI-ra támaszkodni, persze nem tudok, úgy tűnik, hogy aki Linuxot akar használni, annak kell a konzolparancsokkal foglalkozni, vagy a folyamatos falbaütközések miatt hamar kiábrándul az OS-ből.

A probléma ugyebár az, hogy az \usr\local\share\fonts könyvtárba kellene csak kitömöríteni, és kész. Csakhogy az a könyvtár egyorrú felhasználóknak nem írható.
Itt jön az általános javaslat, hogy jah, sudo parancs konzolban, oszt az segít. Köszi...

Miközben kerestem egy számomra is elegánsnak tűnő megoldást, hirtelen belefutottam a font-manager nevű alkalmazásba. Pont azt csinálja, amire szükségem lenne. Discover beizzít, megkeres (jé, benne van! ), telepít. Működik. Csak a pluszra kattintok, és utána telepítem a könyvtárból a .ttf-et. WoW. Van remény.

[ Szerkesztve ]

Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

A kerdes az hogy kell-e minden usernek?
Ha nem akkor root jog nelkul eleg lett volna a ~/.local/share/fonts -ot hasznalni. (persze egy kezdo nem tudja hogy letezik es mire valo a ~/.local )

Vigyázat, csalok!

Hoppá, úgy tűnik akkor én vagyok megint a helikopter. Nézem Double Commanderben a Home könyvtáramat, és rohadtul nincs benne ~\.local\, sőt, semmilyen hasonló. Megnyitom a Nautilust, és erre voilá, ott van. Upsz...

Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

Ponttal kezdődő mappák rejtettek, ctrl+h kombóval tudod láthatóvá tenni a fájlkezelőben.
Terminált meg csapassad csak, egyáltalán nem olyan veszélyes, mint amilyennek látszik, ellenben elég gyors a használata, plusz baromi jó epénisz és felsőbbrendűségiérzés növelő a használata Valljuk be azért ez a linuxos szcéna egyik fontos eleme. Meg a windows szidás

A mai nap ismételten azzal indult, hogy beborult az egész rendszer (ubuntu 16.04). Frissítés közben megfagyott, újraindítás után kizárt a rendszer. Valamit sikerült úgy elbarmolnia a frissítésnek, hogy még a ctrl+alt+f1 is cifrán nézett ki....
Nekem ebből elegem van. 2016 -ig elégedett voltam, nem voltak különösebb gondjaim, de ami az elmúlt 1-2 évben történik az számomra több a soknál. Használni szeretném, nem érek rá állandóan újratelepíteni, hegesztgetni és őszintén szólva egyáltalán nincs is ehhez kedvem. Hab a tortán, hogy egy alapvetően erős hardver akadozik, szaggat, lefagy... Elkeserítő. Szerencsére 1,5 órányi vacakolás után annyit sikerült elérnem, hogy valahogy bejussak és lementsem a fontos dokumentumokat, képeket.....

Teszek egy próbát a Debiannal, hátha az nem dől szét egy kis frissítéstől és nem fagy le random minden héten legalább egyszer..... Beállítani biztos, hogy nem lesz egyszerű, lesznek is kérdéseim, de talán egy próbát megér.

Először is: ha innen letöltök egy 180 MB-os kis CD-t, az elég nekem?

[ Szerkesztve ]

Sajnos nem néztem meg. Grub biztos, hogy nem, inkább valami lib.....

Nem biztos... Van másik gép a családban és azzal nem szívtam ennyit. Valamiért erre a PC -re mintha nem frissítenének normálisan... Pedig „csak” 8 éves hardver, nem kellene ennyire köhögnie.

A konkrét hardver ismerete nélkül nehéz bármit mondani. Másrészt, ha már egy ideje hibákat tapasztalsz, korábban kellett volna írnod róla. Jó, én nem Ubuntut használok, de meg vagyok győződve róla, hogy nem általánosak a problémáid.

Ubuntu MATE 20.04, hobbi cayenne termesztő