- Milyen okostelefont vegyek?
- Xiaomi 14T Pro - teljes a család?
- VoLTE/VoWiFi
- Honor Magic6 Pro - kör közepén számok
- Android alkalmazások - szoftver kibeszélő topik
- Huawei Mate X6 - keleti oldal, nyugati oldal
- Honor 400 Pro - gép a képben
- Samsung Galaxy S24 FE - később
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Sony Xperia 1 V - kizárólag igényeseknek
-
Mobilarena
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
HW-es megoldás is lehetséges, pl. Yubico. Igaz Windows-ra létezik az USB raptor, ami egy mezei pendrive-ból készít "kulcsot", de tuti van linux-os megfelelője is. Vagy a proximity. Igaz egy ideje nem fejlesztik, de képes rá hogy ha az adott bluetooth eszköz a közelben van, végrehajtson bizonyos parancsokat, ill., ha eltűnik futtasson mást. Ezzel megoldható a titkosítás automatikus feloldása, ha a telefonod a közelben van.
-
Frawly
veterán
Megadhatod ugyanazt a karaktersorozatot mindkét jelszónak, de akkor sem fognak megegyezni, mert máshoz való jelszavak lesznek.
SpongyaGyurmaBoB-nak persze igaza van, lehet olyat, hogy user accounttal titkosítasz mappát, de ott tényleg szopó lehet egyrészt, hogy ha az user jelszót meg kell változtatni vagy újra kell telepíteni a rendszert, meg kevésbé is biztonságos. A LUKS viszont a saját jelszavával mindig felnyitható marad, tekintet nélkül újratelepítésre, gépre, platformra (Windows, BSD alatt is feloldható).
-
BoB
veterán
"azt hittem, hogy megoldhato az, hogy a titkositott HDD jelszava megegyezik a user jelszoval, es valahogy megoldhato, hogy eleg legyen egyszer megadni a bejelentkezeskor"
Jól hitted, lehet ilyet. Titkosított mappával meg lehet csinálni és ahogy olvastam ez pont az amire neked szükséged van, teljesen felesleges a teljes lemezzel megcsinálni.
Erre GNOME-on (ha jól emlékszem azt használsz) ott van az encfs + GNOME-keyring (opcionálisan + Gnome Encfs Manager ami GUIs).
Lásd továbbá: [link]
-
Frawly
veterán
Még egy gondolat. Kelleni nem kell semmit. Nem kell SSD-t titkosítani. HDD-t sem. Nem tart senki pisztolyt a bordáid közé. Te tudod, hogy neked milyen szintű biztonság kell, mire van szükséged, annak megfelelően döntsd el, hogy milyen részek legyenek titkosítva, és milyen titkosítási módszerrel (hardveres jelszó, szoftveres LUKS, stb.).
A titkosítás ilyen, kényelmetlenséggel jár. Persze feláldozhatod a kényelmet a biztonság oltárán, akkor a biztonságossági faktor csökken. Mindenkinek máshol van a két szélsőség között az arany középút.
Én régen minden HDD-men LVM-over-LUKS-ot használtam a rendszerlemezen, és LUKS partíciót az adatlemezeken. Aztán a rendszerlemezeim SSD-k lettek, azokon hardveres titkosítást használok (SATA SSD-ken ATA jelszót). Viszont 1-2 külső HDD-n természetesen megmaradt a LUKS. Teljesen megszoktam. Bootkor 1-2 mp. begépelni a jelszót. Plusz ha külső HDD-t csatlakoztatok nagy ritkán, akkor be kell írni még egyet. Nem halok bele. Már vagy 4 éve minden meghajtóm titkosítom. Kivételek ugyan vannak most, OS installálós, pendrive-nak használt SSD-ken nincs jelszó, de azokon érdemi adat sincs, meg egy mSATA SSD-n, amin csak Windows meg némi játék van, azon sincs titkosítás. Ennek az az oka, hogy ezek az SSD-k nem támogatják a hardveres titkosítást, a szoftvereset meg nem erőltetem rájuk, főleg, hogy nincs rajtuk semmilyen olyan egyéni adat, amit védeni kéne.
Plusz az SSD-k nem szeretik a szoftveres titkosítást. Ennek az az oka, hogy szoftveres titkosításkor az egész meghajtó telinek látszik, tele van pszeudórandom adattal. Persze a fájlrendszeren lehet szabad hely, de alacsony szinten az SSD vezérlője úgy látja, hogy tele van a meghajtó, és ezért nem tudja rajta az adatokat a cellák egyenletes fárasztása miatt pakolgatni. Vagyis van rá lehetőség, ha átengeded a titkosítási rétegen a TRIM-et, NVMe-nél még elvileg ez sem kell, mert ott a trimezést egy kombinált írási-törlési utasítás végzi. De az SSD-k akkor sem nagy barátai a szoftveres titkosításnak, sok azért is van felszerelve a hardveres titkosítási lehetőséggel, igaz ahhoz az alaplapnak is kell támogatnia, már pedig asztali lapok nem nagyon szokták, inkább laptopok, azok közül is inkább csak az üzleti kategória. Az SSD-k mindenképp más műfaj titkosításügyileg, mindenképp van velük szopófaktor valahol. HDD-t viszont mindenképp megéri titkosítani.
-
Frawly
veterán
Nem egészen értem mit akarsz, mintha kevernéd a dolgokat. A felhasználó jelszava nem egyenlő a titkosított partíció jelszavával. Mind a kettőt be kell írnod egy ponton (már ha nem csinálsz automatikus bejelentkezést, de az megint nem biztonságos). Kétszer viszont nem kell egyiket sem. HDD-nél választhatsz, hogy automatikusan csatolódjon bootkor, ilyenkor a bootkor kell beírnod a HDD jelszavát, vagy utólag csatolod fel filemanagerből vagy gvfs-ből, akkor bejelentkezés után kell beírni.
Esetleg lehet úgy, hogy jelszóbeírás helyett valami pendrive-ról kulcsfájlt használni, de az kevésbé biztonságos, mert ha valaki megszerzi a drive-ot, akkor hozzáfér az adatokhoz. A jelszó csak a fejedben van meg (ideális esetben), így azt senki nem tudja megkaparintani. Viszont kényelmetlen, hogy mindig be kell gépelni, de a kényelem és a biztonság mindig is ellentétes fogalmak.
De mondom, ha olyan az SSD, tudhat hardveres titkosítást is, azt BIOS-ban kell beállítani (vagy lehet linuxos hdparm-mal is, de nem ajánlom neked, ha nem vagy tisztában dolgokkal, mert hdparm-mal haza lehet vágni az SSD-t, meg ki lehet zárni magad belőle végleg). A hardveres SSD titkosításnak ez az egyik hátránya, ha elfelejted a jelszót, reszeltek az egész SSD-nek, többet nem tudod használni, nem csak az adatokat bukod. Szoftveres titkosításnál ha el is felejted a jelszót, akkor csak az adatokat bukod, magát a meghajtót bármikor újra tudod particionálni, a partíciókat újra titkosítani, stb..
-
Frawly
veterán
Igen, hozzáférsz a titkosított kötetekhez, akkor is, ha a felhasználói, rendszergazdai jelszót megváltoztatod, ergo nem úszod meg az SSD titkosítását, ha az azon való adatokat hozzáférhetetlenné akarod tenni.
Az érdekes, amit írsz, hogy PCIe SSD-n a nagyobb sebesség miatt a procinak jobban kell nyomni a hash sebességet, és emiatt jobban leszívja az erőforrásokat. Ez igaz is lehet. Én csak SATA meghajtókon használtam eddig, ott lassulást, gyorsabb merülést nem lehetett mérni.
Esetleg ha céges üzleti noti, akkor az SSD oldalán lehet bekapcsolni a hardveres titkosítást, annak semmi köze a szoftveres szinthez, OS, proci felé transzparens. Viszont NVMe SSD-knél nem tudom mennyire lehetséges, melyik támogatja, mert amúgy ATA-jelszóval kell bekapcsolni, de az NVMe-nek semmi köze az ATA/SATA protokollhoz.
Ha mindenképp szoftveres titkosítást szeretnél, az rendszerköteten bonyolultabb, mivel gondoskodni kell a bootolhatóságról, és SSD-n még az is bonyolító tényező, hogy ha ATA/SATA SSD-ről van szó, akkor a TRIM parancsot is át kell engedni a szoftveres rétegen, NVMe-nél elvileg nem.
Amit írtam, példát paranccsokkal, azt csak nem rendszerlemezek titkosításához írtam, tipikusan HDD-hez.
-
Nagy vonalakban: be lehet bootolni közvetlenül a shellbe root jogokkal a grub szerkesztésével indításkor.
Másik módszer, ha bootolod a gépet livecd-ről.
Azt érdemes tudni, hogy a lemeztitkosítás is csak akkor védi az adatokat, ha a kulcs nincs a memóriában. Tehát pl csinálsz egz veracryptes titkosított konténert és csak addig csatolod fel, amíg onnan olvasol, vagy oda írsz, aztán unmount.
-
Frawly
veterán
A dm-crypt csak a csomag neve. Valami köztes konténerréteg mindenképp kell, LUKS, VeraCrypt vagy hasonló konténerformátum, amibe titkosít. Ebből a LUKS a legajánlottabb.
Fogod a HDD-t, létrehozol rajta egyetlen darab partíciót, ami lefedi az egész HDD-t.
Majd rendszergazdai jogokkal terminált nyitsz (pl. su):
cryptsetup -v luksFormat --type luks2 /dev/sdakrámicsoda1
Ez titkosítja az egész partíciót, default paraméterekkel, ami AES256-XTS SHA256-hash, legalábbis Archon.cryptsetup open /dev/sdakármicsoda1 titkositott
mkfs.ext4 /dev/mapper/titkosítottEnnyi a titkosítás. Ha kézileg akarod felcsatolni, akkor így lehet:
cryptsetup open /dev/sdakármicsoda1 titkositott
mount /dev/mapper/titkositott /kivant/csatolasi/pont/mappajaHa már nem kell az eszköz, akkor:
umount /kivant/csatolasi/pont/mappaja
cryptsetup close titkositottNem muszáj kézileg csatolni, sok fájlkezelő és commander típusú progi meg tudja nyitni az így elállított titkosított partíciókat, bekérik hozzá a jelszót, te csak kattintasz a meghajtóra, kapsz egy ablakot, beírod a jelszót, minden más automatikusan megy, felcsatolódik a partíció, már ha jó jelszót adtál meg. Rossz jelszó esetén vagy újra jelszókérő ablak jelenik meg, vagy hibaüzenet.
Lehet automatizálni is, bootkor. A /etc/crypttab fájlba ez menjen:
titkositott /dev/sdakármicsoda1
(vagy)
titkositott UUID=partíció-uuid-je none luksA jelszó elég erős legyen, min. 20 karakter, minél változatosabb, lehetőleg kisbetű, nagybetű, egyéb írásjel, meg lehet fűszerezni ékezetes betűkkel is. Ezt garantáltan nem töri fel senki, még akkor sem, ha esetleg mégis csatlakoznál a CIA-hez. Se FBI, se NSA, se senki nem tud vele mit kezdeni, nem tudják feltörni. Egyedül a titkosszolgálatok lehetnek kivételek, de azok sem technikailag törik meg, azok téged törnek meg, ütnek addig cipóvá, amíg el nem árulod a jelszót.
Javasolni szokták még a legelső parancs elé, hogy futtass végig az egész HDD-n:
dd if=/dev/urandom of=/dev/akarmicsoda bs=20M
Ez csak azt a célt szolgálná, hogy a HDD-n előzőleg titkosítatlan tartalom lepucolódjon, és így nem látszik a különbség a titkosított és titkosítatlan részek között. Ez ellen van egy gyorsabb módszerem. Létrehozod és titkosítod a partíciót, úgy, ahogy írtam. Mikor kész van, telemásolod mindenféle adattal, amid csak van, felmásolsz rá, hogy elfogyjon a szabad hely rajta. Utána törölhetsz belőle, ami nem kell. Azért szoktam így, mert ez gyorsabb, a /dev/random és /dev/urandom végig dd-zése elcseszettül lassú, főleg ha valami nagyobb HDD-ről van szó, egyszerűen kín kivárni, mire végigszüttyögi, akár még 24 óránál is több lehet. -
Dave™
nagyúr
A pontos sorrendre már nem emlékszem, de a lényeg, hogy rendszerbetoltes előtt megadsz egy plusz paramétert, újra bootolsz, akkor megint elkapkod betöltés előtt, ekkor már root vagy jelszó nélkül, felcsatolod a fájl rendszert, listázod a felhasználókat és átírod a jelszavát. Ha jól rémlik valahogy így volt kb.
Nem kell hozza semmi, ez a legdurvább.
-
Dave™
nagyúr
Nem tudtam semmit a témáról, de múltkor be kellett jutnom egy régi debianos gépbe. 10 perc alatt megvolt, utána olvasással együtt. Mindegy milyen erős a jelszó mert átírtam rootkent. Szóval titkosítás nélkül kb. csak dísznek van az OS jelszó, a takarító ellen azért megvéd.
-
-
Tim82
félisten
Itt inkább a transzport a bosszantó, mert látja a Linux, szerinte küld is rá hangot (pl. Pavucontrol alatt rendszerhangnál mutatja), csak épp mégse. Az Oehlbach DAC esetén a gyártó nem ír Linux-kompatibilitást (OS X-et igen), de amúgy USB Class Audio kompatibilis lenne ez is. És működik is - ha előbb kihúzom az USB kábelt, bekapcsolom a DAC-ot, majd visszadugom a kábelt....
-
Tim82
félisten
Köszönöm. Ezek a tippeket sajnos ki kell lőnöm, mert mindkét gép notebook, mindegyik régebbi (Thinkpad R61 - 16.04, Thinkpad X220 - 18.04), egyiken sincs natív USB 3.0 port. (ExpressCard-bővítőkártyával van, de hangeszköznek csak USB 2.0 portot használok.) Az X220-nál lehetne UEFI, de Legacy módban használom, az R61 idejében még nem volt UEFI (2007-es Core 2 Duo noti). Egyik notinak sincsen XHCI mode nevű beállítás a BIOS-ában.
Az X220-szal - amíg rá nem untam a Win 10-re és át nem tértem rajta Ubuntura - egyébként ugyanezekkel a BIOS beállításokkal működött a CM6631A transzport. Az Oehlbach DAC viszonylag új vétel (kb. egy hónapja van meg, csak most volt időm a problémájával elkezdeni érdemben foglalkozni), azt más Win 10-es géppel, illetve Androidos tablettel próbáltam, ott nem volt vele gond.
Ugyanezen két géppel amúgy más USB-s hangkütyük (Creative SoundBlaster E5, Steinberg UR12, AudioGD NFB-11.32, illetve egy kínai Leaf Audio CMD-19 USB/BT képes DAC/AMP), illetve az R61-gyel, amelynek van PCMCIA foglalata, az ebbe illő Creative Audigy 2ZS Notebook gond nélkül működnek.
-
Frawly
veterán
A mesa csomag nem minden disztrón van fent alapból, bár a kulturáltabb, elterjedtebb desktop distrókon fent szokott azért lenni default. Az az OpenGL-hez kell. Vulkanhoz a vulkan-intel csomagot kell feltenni.
Shyciii: valóban, a hardveres videódekódoláshoz a libva-intel-driver csomagot kell feltenni, ha ez utóbbi nem menne, akkor újabb Intel GPU-kon meg lehet próbálni helyette felrakni az intel-media-driver nevű csomagot. Ezek archos csomagnevek, lehet Ubuntun, Minten kicsit máshogy hívják őket.
-
Shyciii
veterán
Azt tudom, mert eddig sosem volt gondom a driver felrakása után, csak gondoltam, ha van más driver, ami esetleg az újabbakat jobban kezeli, akkor használnám azt. Csak sikerült megint félreértenem
A vaapihoz kell. Pl intel-media-driver, vagy libva-intel-driver. Ezt is ki akarom majd próbálni, mert elvben ha ezek közül egyiket felrakom, akkor pl a vlc képes használni a hardveres gyorsítást.
-
lev258
veterán
Az a SiS eszköz már a maga idejében sem volt egy bajnok, Windows-on se. Egyáltalán nem vagyok biztos benne, hogy elbírna egy mai videóformátummal erejének teljében. A Google Maps meg tudtommal az OpenGL igényeit is növelte, tehát amiatt szerintem már alapból kiesik.
Az ilyen gépeket Lubuntuval még egy darabig használni lehet netezésre, szövegszerkesztésre, Minitube-bal talán még a Youtube sem lehetetlen. De nem alkalmas mindenes gépnek, erősen korlátozott. -
Pano
addikt
Ez volt nekem is az első gondolatom, de nem találtam olyan beállítást, ami erre utalna.
Engem a linux valamiért nem igen szeret. Akárhányszor újra visszatérek, mindig csak jönnek a problémák és jönnek, jönnek
Úgy érzem magam mint a régi Windowsos időkben, amikor mindig kellett valamit elhárítani (ezért a kijelentésért/hasonlatért most biztos kapok a fejemre![;]](//cdn.rios.hu/dl/s/v1.gif)
) -
Frawly
veterán
Nyugodtan titkosíts gyenge gépen is. Ryzenben meg modern procikban van AES utasításkészlet, ott eleve nem is okoz lassulást. Amelyik prociban meg nincs ilyen, ott sem okoz nagy lassulást. Én használtam tartósan AES256-os LUKS-ot egy marha gyenge T1400 CPU-s laptopon, és alig van mérhető lassulás (ilyen 1-3% közötti), kisebb az overheadje egy AES256 XTS LUKS-nak ext4-gyel, mint egy titkosítatlan NTFS-3G-vel hajtott NTFS kötetnek. Nem kell tőle tartani, ha az adataid fontosak, titkosítani érdemes.
SSD-ken is csak arra kell figyelni, hogy a TRIM-et engedd ki a LUKS-on, ehhez van leírás az Arch, Gentoo Wikijeiben.
(#62619) malnabokor: elvileg a Bodhi is jó lehet rá, a másikat nem ismerem, amit írtál. Én Sparky Linuxot tennék rá IceWM-mel, esetleg szintén IceWM-mel AntiX-ot vagy MX-Linuxot. A Vistához képest mindenképp hasítania kell. Főleg, ha vesztek bele egy olcsó 120 gigás SSD-t 6-8 ezer környékén, amit később újabb gépbe is át lehet tenni.
Az ilyen korú gépeken nem is a proci a szűk keresztmetszet, hanem az 1 giga RAM, az tud túl gyorsan fogyni böngészéskor.
-
MurdR
veterán
Bocsánat, elfelejtettem említeni: csak ne Ubuntu legyen...
Azt viszont tudnod kell, hogy az MS Office tamogatottsag linuxon nem teljeskoru.
Ha sokat kell speci formazott ms-office doksikat szerkeszteni, akkor lehetnek kompatibilitasi gondok.
Igen, sajnos már találkoztam ezzel a problémával én is, de útközben csak kisebb excel táblázatokat kell szerkesztgetnem, meg esetleg egy-két alap word documentumot.Ha pedig valami nagyon speckó kell, akkor marad az online szerkesztés böngészőből.
Ha már itt tartunk, ezekre milyen megoldást ajánlanátok:
-Felhőben lévő mappa, és annak fájljainak szerkesztése
-Teamviever, vagy távoli elérés -
CPT.Pirk
Jómunkásember
Itt van a probléma!
A grub install-t is a chrooton belül kell megcsinálni, hogy a chroot-olt rendszer grubja kerüljön az a bootsectorba, ne a live rendszeré.
*frissítenem is kell az összefoglalót ebben a témában, mert most pont nincs benne.
colomb2: úgy értettem nem tudom, hogy elcsesz-e valamit.
-
CPT.Pirk
Jómunkásember
Egy ilyet találtam a kiírt hibára amit chroot alatt lehetne kiadni:
mknod /dev/null c 1 3
de nem tudom, hogy mit csinál. Lehet, hogy csak ront a helyzeten szóval csak saját felelősségre. Innen van:
https://raspberrypi.stackexchange.com/questions/31898/dev-null-folder-doesnt-exist-should-i-create-itA grub install /dev/sda... parancs az még hiba nélkül lefut chroot alatt és csak az update-grub szál el hibával?
-
CPT.Pirk
Jómunkásember
-
Na, végül sikerült feltennem a grub-ot, de még mindig bénázom.
Most grub prompt-ig jut el a gép bootkor, pedig nyomtam update-grub-ot.
Valami olyan sejtésem van, hogy nem jó grub verzióval próbálkozom, de lehet, hogy tévedek.
Sima grub csomagot tettem fel.
A prompt 2.02-t mond.MBR/bios módban van a rendszer, van mellette egy win 8.1, és a windows reinstall elött működött.
Még annyi, hogy a korábbi w8.1 install után a Boot Repair Disk tette vissza a grub-ot. Most is ezzel kezdtem, de most nem járt sikerrel a dolog.
Ezután kezdtem a chroot-os megoldást. -
CPT.Pirk
Jómunkásember
Remélem ebben is benne van a szivárványt "ásító" unikornisos grub menü, mint a tavalyi kiadásában. EPIC
Amúgy meglepően gyors és összerakott volt.
Telepítés után kézzel kellett magyar nyelvet felrakni rá (ami nem volt túl bonyolult), de csak ennyi negatívumot tudok mondani róla. -
CPT.Pirk
Jómunkásember
Mint XFCE, nálunk a cégnél elfogadhatóan működik egy Intel Atomos vackon, amin több mint 2 percig bootol az XP... És akkor van friss kerneled, meg minden ami kell.
A frissítésnél ugyan kér jelszót, de ennyit talán meg tud tenni a csaj is, igazán nem nagy dolog megjegyeznie pár betűt. De ha ez probléma, akkor meg lehet csinálni az auto frissítés telepítést is, az egyik az unattanted megoldás amit Debian alatt is csináltál, a másik meg a Mintupgrade-es megoldás. [link]
A távoli supportra meg ott van a Teamviewer.
-
Ez a non-free elmászás nekem nem tiszta, de a helyedben felraknék egy ugyanilyen működőképes Debiant rá és ezzel oldanám meg a frissítéseket, viszont csak a maximum a security repot hagynám aktívan, a többit kikommentelném.
például
http://security.debian.org/debian-security buster/updates main contrib non-freeA többi desktop disztrónál, ami futna azon a gépen, még ennyi garancia sincs, hogy nem fog kampeca lenni bármikor.
Egy teamviewer-t is felraknék, hogy minimális hibákat tudjak orvosolni. (ez elég korlátozott, például ha nem indul el az X, akkor bakfitty)
**********************************
- Radeon gpu gyorsítás (3D + video) csak plusz non-free firmware install után megy.Valóban, ezt el is felejtettem, amíg nem raktam fel a fw-t, nekem is csak szoftveres leképezés módban indult a Cinnamon.
-
Frawly
veterán
Lánynak, ilyen gyenge gépre ne nyújts egyáltalán supportot. Főleg nem Linuxot. Mindegy mit teszel fel neki, frissítéskor bármi eltörhet más disztrókon is (Windowson is, de ahhoz vidéken könnyebben talál segítséget). Ha fent van a Debian, azon oldd meg, hogy jelszó nélkül frissüljön, ezt passzolom, attól is függ, hogy milyen grafikus felületet tettél fel. Meg engedélyezd a non free tárolókat.
-
#62234
herdsman12
őstag
Bici
#62221
herdsman12
őstag
Szintén MBR és Legacy BIOS, Win 10.
Linux Mint 19 kiterjesztett partíción, grub a Mint saját partícióján, Win-re telepített EasyBCD kezeli az oprendszer választást. Ezt némelyik Win frissítés miatt muszáj újra szerkeszteni.
Úgy még elindul a Win, ha csak a "Rendszer számára fenntartott" első (sda1) partíció rejtett, de, ha a Win 10 (sda2) is rejtett, akkor már nem. Most így van beállítva, de arról fogalmam sincs, hogy ez okozhat-e problémát később?
Az fstab nem tartalmazza ezt a két partíciót. Nem bánnám, ha volna megoldás az sda1 és sda2 eltüntetésére a filekezelőből, hogy még véletlenül se piszkálja senki azokat, persze induljon a Win, ha kell. -
-
CPT.Pirk
Jómunkásember
Ha egész partíciót vagy lemezt szeretnél alkalmi jelleggel eltenni egy tömörített fájlba, akkor a clonezilla mini disztró mindent tud és fut egy pendriveról. Azt nem tudom, hogy tud-e jelszavazni, de eleve csak a clonezilla tudja olvasni az elkészült állományt.
Ha csak egy-két mappát, akkor arra két mód van így gyorsban:
-csinálsz saját tar.gz állományt készítő szkriptet bash-ben, azt lehet crontabbal időzíteni, relatíve egyszerű, biztosan lehet jelszavazni
-csinálsz rsync-es automata mentést ami nagyon pöpec biztonsági mentések készítésére, de nem tömöríti a mentett állományokat és szerintem nem is jelszavaz. De adhatsz neki olyan cél mappát, ahová csak x felhasználónak van írási vagy olvasási joga. -
-
Ez tuti nem kezdő téma. Nem hallottam ilyenről(ami nem jelenet semmit), de van egy kis bibi:
Mi garantálja, hogy az A gépen betárolt és éppen szerkesztés alatt álló fájlt nem nyithatja meg valaki más a NAS-ról, vagy a B gép helyi gyorsítótárából? Pillanatok alatt inkonzisztens lesz, és ki/mi fogja eldönteni, hogy melyik példány módosításai maradjanak meg?- A gépekbe 2db Gigabites port összefűzése.(Sose csináltam, csak itt-ott fél mondatokat olvastam róla, de olyan eszközök kellenek hozzá a mik támogatják)
- Magába a NAS-ba kellene egy(két) SSD, ill. olyan NAS ami tudja gyorsítótárnak használni. -
Frawly
veterán
Igaz, én olvastam félre, abban a hsz-ben írtad, hogy chroot nélkül próbálva, majd próbáltad utána chroot-tal is. GRUB-ot MINDIG chroot után kell telepíteni!!! Időpocsékolás előtte próbálni.
A chroot utáni lépéseket viszont elvileg jól csinálod, i386 platform, /boot/grub mappába konfigurálva, a GRUB futtatható betöltőkódja meg az eszközre (első partcíció és partíciós tábla ELÉ) telepítve.
Esetleg az még lehetséges, hogy a grub-install előtti grub-configot hagytad ki. Ugyanis a grub telepítése előtt annak a konfigját le kell külön generálni. Bár mióta az Arch bevált, elég rég Uborkáztam, Mentáztam, és akkor is legutóbb automata partíciónál default telepítést nyomtam nekik, nem variáltam saját beállításokkal.
De ezért mondom, hogy büdös lófütyköst az Ubuntuba meg a Mentába, hogy GRUB, meg f@xtudja milyen config. Ha jól olvastam, már tudsz Archot telepíteni, felrakod azt UEFI-vel, systemd boottal, GRUB nélkül, Arch Wiki systemd boot cikke alapján. Egyszerű bootctl-es parancs, meg egy szöveges fájl szerkesztése az /boot/EFI/loader.conf-ként, elvileg ezt egyszer sikerrel abszolváltad nemrég. Nem is értem, hogy ha egy disztró beválik, meg megtanultad hibamentesen telepíteni, akkor minek ugrálni a disztrók között, meg kalandorkodni.
-
Tényleg, arról nem is esett szó, milyen alapú disztró, viszont az egyetlen UEFI-s próbálkozásomkor nálam is GPT sémán maradt az SSD és nem volt semmi gond a Mint-telepítéssel...... (a Mint-et már annyira szidják, hogy már csak szégyenében is feltelepül simán bárhová)
Az FSTAB-ba mindenképpen UUID-dal rakd be a meghajtót, ill. ha úgy volt, akkor az újat, ha MBR-be átparticionálod.
-
Nagyon régen raktam fel GRUB-ot, mobilról nem tudok linkelni meg keresni, de az Összefoglalóban a changeroot szó utáni rész részletezi mit kell csinálnod.
Az fdisk - l igen fontos az elején, ahogy látom, milyen fura a particiód számozása.
GRUB-ot normál esetben meghajtóra telepítünk.
/sda
és nem /sda1 -
Frawly
veterán
-
-
Másik pendrive-ról installálva pedig ezt a jelenséget tapasztalom:
Természetesen, bármire kattintok, hatástalan, nem történik semmi.
- az install elején az SSD mindig teljesen üres, csak a GPT partíciós tábla van rajta
- a BIOS UEFI-only módban van, de nincsenek elmentve korábbi UEFI-s installok
- nincs más média a gépben, csak egy optikai meghajtó lemez nélkül
- erre a gépre eddig már sok más linux disztrót raktam fel hiba nélkülMi lehet a gond?
-
#61331
King Unique
titán
Bici
#61327
King Unique
titán
Az előző válaszban már le volt írva, hogy ilyenkor hardvertől függően célszerű lehet kikapcsolni, mivel a rendszerindításnál előfordulhat, hogy egyből a W10 fog indulni és nem lehet kiválasztani a Linuxot. De volt akinél pl. az Ultra Fast opciónál pendrive-ról sem lehetett bootolni, avagy nem lehetett belépni a BIOS-ba. Viszont az mondjuk a fast startup esetében alapból megvan, mert ha így van leállítva a Windows, akkor egy hidegindításnál egyből az indul és nem lehet belépni a BIOS-ba stb. Max. csak úgy, ha nem leállítás, hanem újraindítás történik, illetve a rendszer alól a speciális rendszerindítással.
(#61330) Frawly :
Pedig de, van olyan, amikor célszerű azt is kikapcsolni... -
#61324
King Unique
titán
Bici
#61317
King Unique
titán
Ott van kapásból a Secure Boot, amit célszerű kikapcsolni az Arch miatt, mivel az rendszerint nem támogatott ilyen téren. Ugyan a linkelt leírásban van valami tákolásos módszer is, de talán egyszerűbb inkább kikapcsolni. A Windows 10-nél egyébként OK, illetve az pl. az Ubuntu, Linux Mint, Fedora Linuxoknál is, azok általában bekapcsolt Secure Boot mellett is használhatók. Bár az utóbbiaknál ez akár hardvertől függő is lehet. Aztán a Windows 10-nél a fast startup, illetve az UEFI BIOS-ban a Fast Boot funkciót célszerű még ilyenkor kikapcsolni. Ami nemcsak az NTFS partíció félhibernálásos állapota miatti esetleges problémás felcsatolás, hanem a rendszerindítás miatt is lényeges, mivel bekapcsolt állapotban egyből a 10-es fog indulni.
-
Frawly
veterán
Ha úgy csinálod, ahogy múltkor írtam, systemd boottal, akkor nem kell GRUB és jól megfér a Win10 és az Arch Linux, nagy Win10 Tükömtudjamilyenévszakos Négyszámjegyes Anniversary Update-ek után sem lesz baj a dual bootal, vagy ahogy a britek mondják: jewel boottal
Ehhez először a Win10-et kell telepíteni, az létrehozza az EFI partíciót, utána csak telepíteni kell a Wiki alapján az Archot (nem könnyített installos scripttel felbaromlni), bootctl-lel felpakolni rá az *.EFI fájlokat, majd menübejegyzést hozzáadni a loader.conf-ban és simán fog menni a dual boot. Lehet fordítva is simán fog menni, azzal nincs tapasztalatom, de valószínűnek tartom, maximum a loader.conf-ot kell még egyszer szerkeszteni, ha a Win10 belebarmol.
Win10-nél még arra figyelj, hogy ezek a nagy évszakos update-ek visszakapcsolják a fast bootot, ez a dual bootot nem bántja, de az NTFS partíciók felcsatolását Linux alatt zavarja, így ilyen frissítések után a Windows Gépházban ki kell mindig kapcsolni a Gyors bootot, ha valamelyik gerinctelen update kérdés nélkül visszakapcsolná. Nem kell parázni, 1 perc alatt kikapcsolható, nem kell hozzá sokat mókolni.
-
-
-Ben-
veterán
Az a probléma, hogy már nem tudom, mit próbáljak még ki. Ki lett próbálva nyílt driverrel, feltettem az ajánlott zárt drivert, de ubuntu 16.04 alatt is rossz, 18.04 alatt viszont még rosszabb. Live alól kipróbáltam a Mintet KDE -vel és Cinnamonnal, a Solust Gnome 3-mal, a Kubuntut és a Chakra -t KDE-vel. Ezek közül elmondható, hogy a KDE verziók egészen jól hasítottak, különösen a Chakrával és a Minttel, de gépeléskor - főleg chromiummal - azok se voltak tökéletesek. Ugyanakkor a régi kártyával se jó (nVidia 9400 GT), sőt, azon túl, hogy ugyanolyan lassú (vagy még lassabb) volt, mint a GT 710 -zel, még a gépnek is szabályosan pokolgép szerű hangja lett - pedig passzív hűtésű a kártya. Valami nem kerek ....
-
Frawly
veterán
Azért nem láttál még olyat, mert nem létezik. Nálad, ha frissítette az nV drivert, akkor fent volt. Lehet te nem kérted, hanem az alaprendszer része, vagy telepítéskor bepipáltad a 3rd party szoftverek telepítését, így automatikusan leszedte neked a drivert. Vagy valami progi húzta be függőségnek.
Ezért mondtam, hogy Arch. Az nem telepítget semmit helyetted, nem önállósítja magát a telepítő, mivel nincs olyanja. Zárt NV driverre meg semmi nem dependel benne.
(#60813) Bici: mikrobinak ez a virtualizációs terve működőképesnek tűnik. Viszont előtte bootkor a kernelparaméterekkel be kell állítani, hogy a host ne használja a dvga-t, különben ha használatba veszi, akkor VT-d-vel már nem tudod a virtuális gépnek átadni. Ennek ellenére én inkább dualboottal oldanám megy, ha más nem egy külön SSD-re tennék Windowst, és azon játszanék. Én is így teszek, pont most vettem ilyen célra olcsón egy Adata SU650-et 240 gigás méretben, külső meghajtónak használom. Úgyis ritkán játszok. Eddig egy 64 gigás Samsung PM800-at használtam ilyen célra, az is megfelelt, de azt egyrészt kinőttem, inkább használom arra, amire eredetileg vettem, pendrive-nak, meg OS telepítésekhez.
-
Ja hogy AMD...
Azért az fura hogy lemossák magukról a fejlesztők
2014-ben bejelentik, majd tippelgetnek, hogy a következő (kernel)kiadásban is nézzék meg, hogy még benne van-e a hiba.
2017-ben pedig azzal zárják, hogy lejárt a Fedora 25 támogatása ciklussa, már nem kap sem biztonsági, sem más hibajavítást.Ez is olyan tipikus, mint az én i945-ös chipsetem video=svideo-1:d kernel paraméteres "hibajavítása".
A cpufreq-et nézd meg. Alatta kell lenni egy boost kapcsolónak:
/sys/devices/system/cpu/cpufreq/boost
controls the boost setting for the whole system. You can read and write
that file with either "0" (boosting disabled) or "1" (boosting allowed).
Reading or writing 1 does not mean that the system is boosting at this
very moment, but only that the CPU _may_ raise the frequency at it's
discretion.gre3nwar
Tuti? Az oldalán pedig ott van a támogatottak listájában, alulról a 3. XFS, SGI's Journaled File System. Persze ez lehet csak a partíciók helyreállítására vonatkozik. -
lev258
veterán
Akkor most hagyjuk a Fedora-t. Nézd meg Live Ubuntuval, ezzel a kernelparaméterrel. Változtat-e bármin. Ubuntun a quiet és splash szavak után kell beírni a Grub menüben.
Ha nincs hatása, akkor értelmetlen kínlódnod vele a Fedora-n. Egyébként nekem gyanús, hogy nem csak a grub.cfg-t kell újragenerálni. -
lev258
veterán
Én mindig sudo update-grub-ot futtatok, nem tudom, miket generál le.
Egyébként az ilyeneket én sosem véglegesre csinálom, hanem hozzáadom induláskor, egyszeri alkalommal. Tudod, Grub menü, e betű, beír, Ctrl+X (ha jól rémlik). Még Live alatt is ennyire egyszerű.
És akkor próbáld meg mindkét módon (ponttal és alulvonással is).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
)
Új hozzászólás Aktív témák
Hirdetés
CPT.PirkA topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- Milyen okostelefont vegyek?
- EA Sports WRC '23
- Star Trek
- Xiaomi 14T Pro - teljes a család?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD GPU-k jövője - amit tudni vélünk
- Bittorrent topik
- Tudományos Pandémia Klub
- Eléggé lekorlátozza az NVLink Fusiont az NVIDIA
- Óra topik
- További aktív témák...
- Xbox Game Pass Ultimate kedvező áron, egyenesen a Microsoft-tól! - AUTOMATA BOLT
- Intel Core i7-8700, i7-9700 CPU, processzor - Számla, garancia
- Apple iPhone 16 Pro Max - Desert Titanium - 256GB 1 ciklus 100% akku! 1 év garancia! Új készülék!
- BESZÁMÍTÁS! ASUS Z390 i5 9500 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA Thermaltake 500W
- Apple Watch SE 2 44mm, Újszerű, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest