- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- bitblueduck: RTX 50-es széria PhysX támogatás nélkül. Tényleg akkora probléma?
- sellerbuyer: Milyen laptopot vegyek? Segítek: semmilyet!
- Magga: PLEX: multimédia az egész lakásban
- Argos: Az vagy, amit megeszel
- Real Racing 3 - Freemium csoda
- eBay-es kütyük kis pénzért
- MaxxDamage: Vizes Laptop Hűtés? Lehetséges? Igen!
-
LOGOUT
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
-
PROHARDVER!
(rögzített hozzászólás)
Legyetek szívesek az offtopik témákat ne ebben a topikban tárgyaljátok ki. A topikgazda is jelezte, most törölni kellett jópár hozzászólást, most már maradjatok a (szakmai) topik keretei között.
Új hozzászólás Aktív témák
-
Dißnäëß
nagyúr
válasz
Normi™ #106144 üzenetére
Szóval több dolog, eredeti kérdésedre válaszolva (kicsit vissza a gyökerekhez):
1. UEFI-ben jelszó az SSD-nek, a büdös életbe fel nem nyomják. Hegyekben állnak az elfelejtett jelszavas SSD-k a világ legkülönbözőbb elektronikaihulladék temetőiben és szervizeiben, mind kifogástalanul működik, csak elfelejtették a jelszavukat - kuka.
2. Laptopon (de akár desktopon is) egyébként SSD-n ha UEFI-ből aktiválod annak a saját titkosítását, az a legjobb, mert trim-el is kompatibilis marad minden műveleted, míg LUKS esetén a TRIM parancsok használata default off (biztonsági leak miatt), így kicsit jobban nyúzódik az SSD (a maiaknál már nem aggódnék emiatt sem amúgy), hisz a szabad helyed alatt is titkosított random adat van, amiről NEM TUDJA az SSD kontroller, hogy az szabad hely és játszhat vele, ergo olyan, mintha nem lenne szabad helyed egyáltalán, hogy wear leveling-ezhessen, míg ha luks titkosított diszket discard opcióval használunk, átengedi a fölötte lévő tényleges fájlrendszeren lévő üres helyeket (trim) az alatta lévő luks réteg a kontroller fele, hogy az tudja, az ott üres hely és használhatja wear leveling-re.
Ennek annyi biztonsági kockázata van, hogy az adataid továbbra sem látszanak, annak mintázata viszont igen, hogy mely helyeken van tényleges adat egy háttértáron és mely helyeken nincs. Ezzel az infóval önmagában sokra nem lehet menni, de van, aki erre is háklis (egyfajta metaadat) és inkább discard nélkül brutálba titkosítja a teljes SSD-t. Hát ez olyan, mintha teleírnád csurig, nulla provisioning, ergo LUKS esetén (discard nélkül) jó, ha az SSD 20%-át szabadon hagyod és csak mondjuk a 80%-át foglalod be partíciókkal és titkosítod azokat be, így a kontrollernek marad némi mozgástere TÉNYLEGES üres helyet érzékelni és arra át-mappelni blokkokat (titkosítástul mindenestül), ergo valamiféle belső wear-levelinget tud csinálni TRIM hiányában is, míg Te boldogan használod a luks réteg felett a helyet amire akarod és idegen gépbe betéve a megfelelő program/jelszó ismerete nélkül semmit nem fognak tudni felnyitni belőle földi halandók. (Ez nem olyan, mint a filmekben, hogy nekiesünk, miközben pisztoly a fejünknek nyomva és 40 mp alatt Tomkrúz feltörte).
3. A Mint default install-al ha a titkosítást pipálod, lesz kívülről látva egy EFI partíciód, egy /boot-nak használt ext4-ed (nyitva, olvashatóan) és egy hatalmas nagy titkosított partíciód, amiről látni fogja minden Linux, hogy LUKS titkosított, mert a fejléccel kezdődik. Ergo, bármilyen másik gépbe betéve duplakatt rá fájlkezelőben és felnyitja Neked a jelszó ismeretében. Mivel a teljes rendszered titkosítva ezáltal, mint partició, a /home-ot már felesleges még extrán is titkosítani, csak bonyolítod..
Szóval még mindig maradnék a jó öreg bevált uefi jelszónál, az bekapcsolja az SSD-d saját titkosítását (ami azelőtt is ment, csak jelszó nélkül átengedett Téged ezen a rétegen, mintha nem lenne titkosítva). Ugyanez SED típusú, jellemzően enterprise HDD-k esetén is amúgy.. már jó régóta a szerver világban. Trim használva lesz UEFI-s jelszó esetén és a wear leveling, minden egyéb gyönyörűen teszi a dolgát.
Ha öreg SSD, LUKS-oznék discard-al. Ha viszonylag újabb, azon erősebb algo lehet, simán UEFI módszer, kényelem, öröm, bódottág.
btrfs: én fázom tőle (és erről vitába se megyek senkivel, ez csak saját véleményem, de nem vagyok egyedül), engem a zfs elvitt. De az meg csak NAS-ra, úgyhogy desktop-on, laptopon ext4-eznék, atime=off paraméterrel, az picit könnyít a dolgokon.
Fun fact: akkor is érdemes titkosítani, főleg sokterás HDD-t, ha nincs kitől és mit féltened, vagy nincs annyira érzékeny adat rajta, mint mondjuk egy faukettes műszaki leírása. Ugyanis ha eladod a meghajtót, elég csak törölnöd a titkosítást róla, vagy beleformázni az elejébe pár száz megányit egy DD-vel és viszlát, lecsatolod, zacsi, mehet eladásra.
Nagyvállalatoknál is régen voltak ezek a merevlemez-sanitizer meg mindenféle progik a diszkek nullával teleírására, ma már úgy megy, hogy reset-eli a lemez tartalmát a kontroller vagy alaplapi UEFI-ben, a háttérben ez annyit csinál, hogy a meglévő titkosítási kulcsokat eldobja és újakat ad neki, ergo szűz lemez üresen láttatja magát innentől, nem férnek hozzá semmihez. Ennek ellenére is - egyesek - még ezen felül is luks-oznak.
-
cigam
titán
válasz
Normi™ #106100 üzenetére
Pl. Telepítéskor nem egy hanem két partíciót készítesz. Az egyik a / lesz amin a rendszer van, és készítesz egy /home-ot, amit meg kedved szerint titkosíthatsz. pl.
cryptsetup luksFormat /dev/sdX
cryptsetup open /dev/sdX titkos
mkfs.btrfs /dev/mapper/titkos mount /dev/mapper/titkos /home
Titkosíthatod az egész / partíciót, de ehhez kell egy külön /boot partíció, hogy betöltse a kernelt, és vele a LUKS titkosítás kezelőt.De készíthetsz LVM-et is ami eleve támogatja a titkosítást, és formázhatod Btrfs-re is.
Nem elég ha a BIOS-ban bekapcsolod a jelszavas védelmet?! Akár bekapcsoláskor, akár a háttértárhoz kapcsolva? Pl. Ha a háttértárnak adsz meg jelszót, minden bekapcsoláskor bekéri a jelszót, hogy elindíthassa a telepített op.rendszert. Mivel ez a jelszó közvetlenül az adattároló firmware-ébe kerül, nem az operációs rendszerbe, másik gépbe átrakva a háttértárat, ugyanúgy jelszót kér. Nem férsz hozzá az adatokhoz. Ez nagyon praktikus megoldás, mert OS független, és a titkosítás/dekódolás nem az CPU-t terheli.
Amúgy nem macera bekapcsoláskor 2 jelszót megadni? (Ha BIOS-ban is be van kapcsolva, akkor hármat, vagy négyet?!)
Mekkora az esélye, hogy a rablónak az adataid kellenek? Sanszons, hogy az első dolga, hogy leformázza a háttértárat, és pár ezer forintért eladja alkatrészenként/egybe. -
válasz
Normi™ #106085 üzenetére
A /home titkosításának amúgy mi a célja pontosan?
A BTRFS választását EXT4 helyett már nem is kérdezem, gondolom kíváncsiság lehet az oka. Amúgy jó elfoglaltság, de előtte/közben igen hasznos a BTRFS dokumentációkat átolvasni, aztán még 5x és közben értelmezni is, mi más az EXT4-hez képest. Ilyenkor egyébként jobb egy nem BTRFS alapú rendszerrel csinálni az ismerkedést. Normál használatra viszont tényleg nem a legtutibb ötlet Linux Mint-et erre építeni.
-
urandom0
senior tag
-
urandom0
senior tag
válasz
cigam #106094 üzenetére
Oké, szerintem nem fog működni.
Tudtommal a Mint a home mappa titkosítására ecryptfs-t használ, ami nem kompatibilis btrfs-sel (írta is a kolléga). A megoldás LVM+LUKS, de mivel ez csak teljes partíciót tud titkosítani, ezért vagy az egész lemezt kellene titkosítani, vagy külön partícióra tenni a home mappát, és azt a partíciót titkosítani.A másik megoldás, hogy nem a home mappát titkosítja, hanem létrehoz egy titkosított konténert, és abba rakja a privát fájlait. Ehhez jó a cryfs, de még jobb a Veracrypt (de szerintem ez nincs bent a repóban, külön kell letölteni).
-
urandom0
senior tag
Én továbbra is btrfs+snapper párti vagyok. Egyszer kell beállítani, onnantól fogva stabilan üzemel. A visszaállás egy korábbi állapotra kb. 2 perc. Ha a boot manager is be van állítva, akkor rögtön lehet korábbi snapshotról bootolni. Ennél egyszerűbb és gyorsabb megoldás erre a problémára nem is létezik.
-
Sup Raa
újonc
Vigyázat!
A Kubuntu szétcseszi a Suse alapértemezett btrfs fájlrendszerét(alapértelmezett telepítés gyanánt mindeképp shrinkelni akarja majd meg sem talalja) ,rádobva még egy Fedorát(ami alapértelmezettem lvm orientált ami +külön öröm lehet) a Kubi + Fedra páros működik a Suse szétcseszve(bár a Fedra látja nem mutatja,tovább nem mókoltam).Jótanács: válassz rendszert és no dual boot! Ha mégis akkor külön meghajtó!
Na pá!👋
-
bobalazs
nagyúr
válasz
urandom0 #105520 üzenetére
Egyik opcio sincs megadva.
Konsole: cat /etc/fstab
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 / btrfs defaults 0 0
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 /var btrfs subvol=/@/var 0 0
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 /usr/local btrfs subvol=/@/usr/local 0 0
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 /srv btrfs subvol=/@/srv 0 0
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 /root btrfs subvol=/@/root 0 0
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 /opt btrfs subvol=/@/opt 0 0
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 /home btrfs subvol=/@/home 0 0
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0
0
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=f40dfbc7-800d-497a-911f-e2df9b9c9733 swap swap defaults 0 0
UUID=317fd740-0bb9-466f-8260-ebb033d2d101 /.snapshots btrfs subvol=/@/.snapshots 0 0
UUID=1912-2D3E /boot/efi vfat utf8 0 2
UUID=f3b7e192-c2fd-48e4-be8a-6edc8faf3bed /mnt/steamdrive ext4 defaults, nofail 0 2
Konsole: -
válasz
tordaitibi #105517 üzenetére
Nem mindegyik sor az. Jelen esetben ez a harmadik sor a Btrfs fájlrenszer velejárója (itt nem kell a timeshift Tibi papó !)
Szerintem visszaállítható fájlrendszermentést lehet vele indítani.
Egyszer láttam ilyet a garudában . Egyből el is idegenedtem tőle.
Az első két sor a két különböző kernel. -
Sz_Imre
senior tag
válasz
IstvánLászló #105024 üzenetére
Amit én már korábban leírtam.
#105022 hcl: Miért kell lehúzni az ssd? Nem fogja szét barmolni, kivéve ha a felhasználó figyelmetlen.
Nekem jelenleg nvme ssd van a Win11 és egy sata ssd-n a EOS (teszt céljából) (de majd lehet lesz ez fordítva is)
Linux rendszer telepítéskor grub-ot ki kell választani, és amikor feltelepült, akkor újraindításkor válaszható lesz a rendszerek között. Mindkét rendszer tökéletesen indul.#105014 Edorn:
"BIOS-ban az M.2-t adom meg, hogy onnan induljon a rendszer, feljön GRUB, kiválasztom, hogy az M.2-n lévő linux induljon-e, vagy a sima SSD-n lévő windws..."
- Felesleges biosba menni, automatikusan a legutóbbi telepített rendszert fogja indítani a bios, ha telepítettél grub-ot, akkor az a menü fog megjelenni, hogy melyik rendszer induljon."Linuxot az M.2-n EXT4 fájlrendszerrel hozzam létre?"
- Igen azzal nem lehet mellényúlni, bár van aki a btrfs-re esküszik, kinek mi."ui.: Így ha nem jön be a Nobara, akkor gondolom így nagyon egyszerű újrapakolni valami mással és nem kockáztatom win-t."
- Persze, hogy egyszerű, ha másik linux rendszert telepítesz, akkor arra figyelj, hogy a linuxhoz tartozó particiót töröld és ne a Win-t. -
válasz
fekete.puma #104391 üzenetére
Szerintem manuális partcionálással érdemes csinálni, én is csak azzal tudom majd. Kijelölöd az EFI-t neki és csinálsz egy /-t Btrfs-re, videón is ezt csinálja az ember, mondjuk fura, mert nem a manual particionálást választotta előtte vagy csak nem vettem észre!
-
-
válasz
fekete.puma #104383 üzenetére
Bár úgy lenne..
Ha ez a Big Linux, akkor viszont rossz hírem van, BTRFS-t még nem kezdtem el megismerni, így ezek a subvol valamik is csak ismerősek, de manuálisan nem tudnék velük mit kezdeni! Nyilván elsők között a particionálást érdemes rutinná tenni. Szóval ebben nem tudok segíteni, sorry!!
-
mcwolf79
veterán
Sziasztok!
A következő a helyzet:
Van fent egy Win11 egy 2 TB-os SSD-n. Mellette van egy 1 TB -os SSD - N egy Nobara.
Jelenleg a 2 TB-osat a Win "uralja". Szeretném újra húzni a Windows -t, és abból az SSD-ből 1 TB-ot lecsípni a Linux-nak. Mi ennek a legegyszerűbb módja ? Az működik, hogy Linux alól ketté partìcionàlom ,egyik fele NTFS, másik fele btrfs formátumra, majd előbbire meg fel a Windows? Jó lenne ha menne a dualboot, nem tudom ez a módszer mennyire barmolja össze a dolgokat.
Köszi -
válasz
Krissz80 #103659 üzenetére
Akkor valamit sikerült kisillabizálnod a hsz-emből...elég reggel volt még és most visszanézve jó nagy katyvaz lett, néha belekavarodok én is, mint majom a házicérnába.
Érdekes párosítások lesznek nálad, főleg ha Debian+Arch lesz. Vagy ezt használják a userek vagy azt és a másikat inkább utálják, mivel az ős-stable meg az ős-rolling ritkán kedvelt egyszerre.
Én is fel akarom rakni újra a Debiant meg valami Archklónt, de meg kéne várnom, mire sikerül elcsípnem az egyetlen valamirevaló SSD-t az Aprón, mindig elviszik az orrom elől. Egy van fenn ugyan, de sajnos az eladó SK Hynix Platinum P41-nek írja, a képen meg SK Hynix PC801 van, utóbbi volt már egy nekem és ez az OEM verziója ugyan a Platinum P41-nek, de akkor se írja ki így!
Addig meg marad a Garuda Mokka ismerkedni a BTRFS-sel.
-
válasz
fekete.puma #103523 üzenetére
Nem csinálja minden disztró, az Ubuntu és a Linux Mint egy ideje alkalmazza, de úgy emlékszem a Debian nem rakott fel automatikusan. Amúgy ha nem lennél lusta, inkább zram-ot csinálnék helyette, már rég ki akarom próbálni a működését, de ahhoz fel kéne raknom valami RAMzabáló programot/játékot is. Egy időben foglalkoztatott nagyon a zram, látszik is a linkelt hsz-ek mennyiségéből. Fura egy madár a zram, mert anno a nagyon kevés RAM-ok miatt hozták létre, de azóta sok RAM mellé is érdemes felrakni. Például a Garuda alapból azt csinál a BTRFS mellé.
-
Sz_Imre
senior tag
Manjaro 25.0 kezdve, az ext4-ről - btrfs lesz az alapértelmezetten fájlrendszer.
(persze meglehet változtatni ext4, stb-re) -
urandom0
senior tag
válasz
Rowon #101203 üzenetére
Ilyen esetekre jó a Snapper, a btrfs-es snapshotokkal, mindennel együtt (meg a transactional-update, de az tudtommal nem érhető el Mintre). Amióta tudom, hogy létezik, azóta így használom az összes rendszerem, és erősen tudom javasolni mindenkinek, hogy btrfs+Snapper+minden frissítés előtt snaphot.
-
moleculez
veterán
Mit gondoltok amúgy a Fedoráról, mik a tapasztalatok vele? Mennyire másabb mint egy Debi alapú distro? A btrfs-nek bármi hátránya?
-
válasz
vadkörte #98682 üzenetére
& IstvánLászló
Örülök ha legalább régebbi bejegyzéseimnek hasznát látja valaki néha!
Ritkán jártok erre, így legalább pozitívan is meg
említ néha valaki!
Ha nem folyt volna ki a szemem a Garuda kipróbálásának idején 15 perc múltán, lehet fel is raknám, bár most az előbb a Win10-től 3 perc alatt kiugrott majdnem a szemgolyóm.
De megint kíváncsi lettem erre a Garudára, ahogy olvastam a régebbi bejegyzéseket, tényleg érdekes megoldásai vannak. Ha lesz félnapom valamikor, fel is telepítem. BTRFS-sel nyilván.
-
vadkörte
addikt
Üdv lakók!
Jó rég nem toltam el erre a képem, mivel nem futottam bele olyan problémába ami fórumozást igényelt volna. Viszont pár hónapja elkövettem azt a hibát, hogy a jól belakott, de már kellően teleszemetelt kissé megfáradt Plasma 5-ös Manjaro-m upgrade-eltem a fincsi új Plasma 6-orsa. (hiába no, az újdonság varázsának szirénjei nem hagytak békén, hogy rohadna meg az összes kornyikáló ri***nc...) Utólag úgy érzem, nem ez volt az év döntése...A vége egy (kettő) szűz install lett de valamiért még mindig nem kerek a karika. Az addig stabil, pörgős lapitopi meglustult, az OS valahogy instabilabb nyögvenyelősebb lett.
Az uborkafa nem tetszik, az Arch vonalat sem akarom elengedni, ezért tettem egy próbát a Plasma 6-os Garuda-val. A nagyon rövid próba (csak telepítés, minimális belakás) után a kontraszt... hmmm... erős. Leszámítva a csiricsáré, nekem "kissé" (nem, nem kissé!!!) bazári színvilágát, alapjában véve tetszik. Működik, stabil, pörgős.
Aki a Calamares-szel nem tudja telepíteni, az ne akarjon linux-ozni, bár az Oktopi egy kicsit tohonya, a Discover-rel nem lehet programokat telepíteni, de a Manjaro-nál megszokott Pamac telepítése kb. 4 kattintás, onnantól meg megy minden mint az ágybasza***ás. Kíváncsi leszek, ha sikerül normálisan belaknom mennyire leszünk barátok.
A végére egy kérdés. India színes csodája betegesen ragaszkodik a BTRFS-hez. Ez nekem mennyire baj, illetve a másodlagos SSD-m hagyhatom EXT4-en, vagy formázzam át BTRFS-re? -
válasz
#63718632 #98477 üzenetére
Oké, meg ne sértődj, hogy válaszoltam.
Én Ext4-gyel is telepítettem Fedorát, azzal is megy Debianszerűen partícionálva. Az alapértelmezettet érdemes elfogadni, amit az Anaconda kínál. BTRFS-en a subvolumeok is be vannak állítva, a home méretével sem kell szórakozni.
-
urandom0
senior tag
válasz
#63718632 #98467 üzenetére
A Fedora telepítőbe be van "drótozva", hogy kell egy /boot partíció 1GB méretben és ext4 fájlrendszerrel.
Nincs bedrótozva, csak alapértelmezett felállás az, hogy készít magának boot partíciót. Azért a Fedora telepítője nem akkora rakétatudomány, mint ahogy itt egyesek beállítják.
Haladó módban bárhogy lehet partícionálgatni. Az "über expert" mód a Blivet GUI, de átlagos otthoni felhasználásnál soha nincs rá szükség, én is csak egyetlen egyszer használtam, mert kíváncsi voltam rá.Fel kell rakni párhuzamosan egy "susét" és egy "fedórát" és megnézni a különbségeket. Vagy nagyon mélyen doksikat olvasni.
Itt egy Suse telepítés:
[root@Fujitsu-Suse /home/balazs]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 119,2G 0 disk
├─sda1 8:1 0 487M 0 part /boot/efi
├─sda2 8:2 0 114,9G 0 part /var
│ /usr/local
│ /tmp
│ /srv
│ /opt
│ /root
│ /boot/grub2/x86_64-efi
│ /home
│ /boot/grub2/i386-pc
│ /.snapshots
│ /
└─sda3 8:3 0 2G 0 part [SWAP]
sdb 8:16 0 931,5G 0 disk
└─sdb1 8:17 0 931,5G 0 part /mnt/sdb1
sr0 11:0 1 1024M 0 romVan még két másik Suse-s gépem, mindkettőnél van egy ~500 MB-os EFI boot partíció, ez nyilván az UEFI boot miatt kell.
---
Kicsit szerintem túl van lihegve ez a partícionálósdi. A disztrók által felkínált default partíciós sémák az otthoni felhasználók 99%-nak teljesen jók.
A BTRFS pedig teljesen jó, teljesen használható, kb. 5 éve csak azt használok, semmi gond nincs vele. -
#63718632
törölt tag
válasz
RaZroX #98463 üzenetére
Igen, ez jó meglátás. Nincs semmi gond a / btrfs-el. Ismerni kell egy kicsit. A Fedora fejlesztő Team ezt tette default sémának, nincs vele semmi gond. DE!!! A Fedora telepítőbe be van "drótozva", hogy kell egy /boot partíció 1GB méretben és ext4 fájlrendszerrel.
Meg kell nézni a forrást, utána kérdezni. vagy istetelen módon többször telepíteni, azttán rájössz, hogy ezt így valakik kitalálták.
Vagy über expert módon el kezdessz partícinálni.
Egyébként pont a btrfs miatt van a /boot külön szedve, más fáhjlrendszerre. A suse épp pont tud read only btrfs snaphot-ból bootolni is akár. De Ők ezt masáhogy oldották meg.
Fel kell rakni párhuzamosan egy "susét" és egy "fedórát" és megnézni a különbségeket. Vagy nagyon mélyen doksikat olvasni. -
cigam
titán
válasz
RaZroX #98463 üzenetére
Egy egyszerű kérdésnek tűnik, de előjönnek az egyéni preferenciák, ill. az elméleti tudás megléte/hiánya. Ha rákeresel, hogy ext4 vs btrfs, rengeteg találatot kapsz pro és kontra érvekkel.
Pl. a btrfs képes pillanatképet készíteni magáról a futó rendszerről, de az adatbiztonságot garantáló "copy on write" növel(het)i a nagy fájlokmentés idejét, mert előbb lemásolja (a módosításokat), és csak ezután írja felül az adatokat), stb...Ha nem használod ki az előnyeit, akkor simán maradhatsz az ex4-nél is, de ha már Fedora-t választottad, miért ne használnád az ő alapértelmezett választásukat?
peterattila
Fura függőségi hiba. A 0.188-2.1-hez ragaszkodik de egy nálánál frissebb 0.191-1 érhető csak el? Van beállítva plusz repo?
Mihez kellene a csomag? Nem lehet máshogy áthidalni a problémát? -
Csabu82
csendes tag
Nem írtam mert arra voltam kíváncsi mi van ha csak egy könyvtár alá felmountolom a HDD-ket, menyire járható? valaki játszót e már ezzel?
Egy sima EXT4-s meghajtót azért mégis csak könnyebb máshová felcsatolni ha gáz van.
meg hát LVM-t nem csináltam még Linux alatt, biztos megvannak a buktatói, de BTRFs is egy megoldás, bár kicsit ágyúval verébre, főleg hogy nem használom ki a funkcióit. arra gondoltam hátha van egy faék megoldás -
urandom0
senior tag
válasz
vizcsap #98250 üzenetére
Feltételezem ha belső meghajtóra telepíteném a rendszert, akkor nem lenne ilyen probléma
Igen. Valószínűleg a külső házad nem inicializálja a lemezt időben, ezért a rendszer nem találta meg magát. Külső házas történeteknél ilyenek előfordulnak.
@mindenkinek
A Fedora és a Fedora alapú rendszerek alapértelmezetten btrfs-t használnak. A /var, /var/home stb. mappákat külön subvolume-ok alá csatolják fel. A subvolume-ok olyanok, mint egy "fájlrendszer a fájlrendszeren belül", saját gyökérrel, saját inode táblázattal, stb.
Az a partíciófelosztás, a vizcsap ezen screenshotján van, teljesen normális, fizikailag egy partíción vannak azok a mappák, csak más subvolume alá vannak felcsatolva. -
cigam
titán
válasz
vizcsap #98248 üzenetére
Ez fura, mert egy partíciót több helyre felcsatolni nem tűnik jó ötletnek. De nem ismerem a btrfs(subvolume)-t, se a Silverblue-t.
Én nem szoktam játszani, nincs tapasztalatom, de szinte bármelyik rendszerre feltelepíthető a Steam és társai. Nem kell hozzá se btrfs se silverblue. Nagyon ragaszkodsz ehhez a distrho-hoz? Nem lenne jobb pl. egy Pop!_OS? -
vizcsap
tag
Nem én választottam a btrfs-t, alapból így települ.
Telepítésnél több opciót is felajánl a partíciók létrehozására: automatic, custom, advanced custom.
Azt hiszem a jelenlegi install-t custom opcióval csináltam, de mikor automatic-al telepítettem, akkor is ugyan ez volt a problémám, csak akkor még nem jöttem rá, hogy a meghajtó kihúzásával majd visszadugásával életre tudom kelteni a telepített rendszert. Ha gondolod újratelepítem automatic opcióval a rendszert és megnézhetjük ezekre a parancsokra úgy mi lesz a kimenet.lsblk -f:
-
Azert ezt vki magyarazza el nekem: annyira kezdo Linux user, hogy nem tudja kideriteni a hiba okat, de azert btrfs a filesystem...?
-
vizcsap
tag
Nem teljesen önsanyargatásból esett erre a distrora a választásom
Állítólag gamingre ez az egyik legjobb distro, minden elő van benne készítve a Windowsos játékok futtatásához. Ami úgy tűnik igaz is, random kipróbáltam párat játékot és hibátlan eddig.
A hibaüzenetben szereplő UUID (444afad4-262e-4144-8058-fe141aa5fc04) alapján azt látom, hogy azt a btrfs partíciót nem mindig találja, amin a root, home, var stb. dolgok vannak és ezeket nem tudja/akarja csatolni valamiért.
UUID=444afad4-262e-4144-8058-fe141aa5fc04 / btrfs subvol=root,noatime,lazytime,commit=120,discard=async,compress-force=zstd:1,space_cache=v2 0 0
UUID=d2ee26e6-b2b4-46de-b51b-d8d2d3076957 /boot ext4 defaults 1 2
UUID=3F6C-20DC /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=444afad4-262e-4144-8058-fe141aa5fc04 /home btrfs subvol=home,noatime,lazytime,commit=120,discard=async,compress-force=zstd:1,space_cache=v2 0 0
UUID=444afad4-262e-4144-8058-fe141aa5fc04 /var btrfs subvol=var,noatime,lazytime,commit=120,discard=async,compress-force=zstd:1,space_cache=v2 0 0
-
urandom0
senior tag
válasz
tordaitibi #96418 üzenetére
A /home csak egy elérési út, semmi más. Lehet az egy könyvtár egy, a rendszerrel azonos partíción. Lehet egy könyvtár egy másik partíción. Lehet egy logikai LVM kötet egy RAID tömb fölött. Lehet egy BTRFS kötet. Lehet egy távoli NFS/SFTP/SMB....
-
#02705152
törölt tag
válasz
tordaitibi #95926 üzenetére
Nem piszkálni akarlak, de ezt az "1 év míg belakom" dolgot értelmezni sem tudom...
A Devuan -> Fedora váltás kb. 40-50 perc volt. Már a kezdetekkor is volt egy átgondolt/átlátható partíciós sémám, most még átgondoltabb/átláthatóbb van (Btrfs, alkötetek; ezúton is pusszantom a fejlesztőket), az adatok külön meghajtókon (szal csak átírom az fstabot), a fontos konfig állományokról másolat, új telepítés után a helyükre másolás kb. 3 perc és ennyi a történet... -
cigam
titán
válasz
tordaitibi #95719 üzenetére
A Windows rendszer része az VSL, de amúgy nem csak ext4-re, hanem btrfs-re is van megoldás. Nem is értem hogy jön ez ide. Nem, nem azt mondtam, hogy azokat a fájlrendszereket is titkosítja a bitlocker, nem emiatt nem működik a dualboot. Plusz a közös "adat" partíció simán lehet exFAT, amit mindkét rendszer kedvel, kezel.
Ha a Linux hozzá sem szagol, akkor hogyan fér hozzá a C: partícióhoz, hogy zsugorítsd a partíciót?
Ok, tegyük fel hogy Windows alól zsugorítod a titkosított C: meghajtót, és van particionálatlan üres hely a lemezen.Elindítod a telepítőt, és ...
Én se néztem utánna, de a TPM-ben tárolt (bitlocker?)kulcsal, valahogy zárolja HDD és a gép közötti kommunikációt. Pl. az EFi hozzáférést. Ez magyarázat lehet, hogy arra, miért kezd minden dualboot leírás úgy, hogy kapcsold ki a bitlocker-t. pl. [link] A nagy kérdés, hogy, a 24H2 után, utólag kikapcsolható lesz-e. Plusz egy mezei user bele mer-e vágni egy ilyen túlbonyolított telepítési folyamatba. -
Nem.
A Bitlocker nem teszi lehetetlenné a dualbootot, mivel a Win ext vagy btrfs partíciókhoz hozzá se szagol, nem is mountolja, csak a lemezkezelőbe jelenik meg mint ismeretlen partíció. Mivel 1 bájtot nem képes róla olvasni, se ráírni, így érdekes lenne ha lecryptelné a Bitlocker.Akkor van gebasz ha valaki dualbootos és 1 darab közös NTFS adatpartíciót használ, úgy mint én mivel azt szó nélkül bitlockolja. A / meg a többi ext az menni fog de nem tudja majd Linux kartárs az NTFS adatpartíciót használni.
Nem néztem utána de fizikai képtelenség hogy az EFI partíciót is titkosítsa mivel akkor ő maga se tudna bootolni. Csak NTFS-t lockol le, amit használ.
Androidot példának hoztam fel hogy (talán, nem vennék rá mérget de valahol) 10 Android főverziónál lett visszavonhatatlanul kikerülhetetlenül letitkosítva a data partíció, user kérésére titkosítható a belső adat tárhely is. 13-tól asszem ez is alap. És ez ugye azzal jár ha el is lopják, elveszíted, feloldás nélkül semmilyen módon nem lehet adatot, banki jelszót, semmit levadászni a datáról.
Ezokból droid10 fölött nincs is megoldás zárképernyő, pin, feloldóminta, vagy biometrika, ujjlenyomat, arcfelismerés stb. nélkül feloldani a kijelzőt, mint az én 7-esemen ahol duplakoppra ébred és minden faxni nélkül a kezdőlapra dob.És ez a módszer Droidon dettó ugyanaz mint a Bitlocker, ha nincs meg a feloldó kód, jelszó bármi, akkor arról fehér ember 1 értelmes bitet nem olvas ki.
És most ugyanezt vezette be igaz suttyomban Redmond a W11-en. -
válasz
PCProfessor #95481 üzenetére
Utánajár és dönt, nincs rossz válasz.
Egy kezdő user? Aham, persze. Én egyébként alapból a kezdő userek halmazáról beszéltem, Te most jössz a 10 ismerősöddel, nehéz is megvitatni még egyszerű dolgokat is.
Komolyan mondod, hogy egy kezdő el tudja dönteni, melyik fájlrendszerrel telepítsen? Honnan fogja tudni, hogy nincs rossz választás?
Az XFS egy nagy teljesítményű naplózó fájlrendszer, amely különösen jó a párhuzamos I/O-ban.
Az Ext4 a széles körben használt Ext3 fájlrendszer továbbfejlesztése, és jobb teljesítményt, megbízhatóságot és funkciókat kínál.
A Btrfs egy modern copy-on-write fájlrendszer, amely fejlett funkciókkal rendelkezik, és a hibatűrésre és az egyszerű adminisztrációra helyezi a hangsúlyt.
Az F2FS egy NAND-alapú flashmemóriához tervezett fájlrendszer.
A ZFS a Sun Microsystems által létrehozott fejlett fájlrendszer, amely stabilitást, sebességet, biztonságot és jövőbiztosságot kínál.
Szerintem egy kezdőknek készült disztrónál nem szembesül a leendő felhasználó ezekkel a kérdésekkel.
Az tényleg totál indiferens most, hogy a körödben mindenki téged kérdez, sejthető egyébként, ha itt is PCProfesszor nicket választottál.
-
PCProfessor
aktív tag
válasz
ubyegon2 #95474 üzenetére
Jó, mert nem a mama kérte, hanem fiatalabb, általában középszintű angol tudással rendelkező ismerősnek az ismerőse is kért javaslatot linuxxal kapcsolatban, mert tudják, hogy a pingvines fazon én vagyok a társasági körben.
Btrfs a válasz, timeshift pedig a másik ha archról van szó. -
válasz
PCProfessor #95473 üzenetére
Alapból annyira jól van optimalizálva az os, hogy bárkinek megmutatom/felrakom nagyon meglepődnek és nekik is olyan kell.
Nem vonom kétségbe, de azt újra megemlítem, hogy nem való kezdőknek, kivéve ha megmutatod, felrakod nekik. Azért elég sokan maguknak telepítik a rendszerüket, utána néznek az ISO kiírásnak, választanak boot managert, DE-t is...no de előtte még jön egy kezdő számára kicsit nyűgös választás:
When you install CachyOS, you can choose from the following five filesystems: xfs, ext4, btrfs, f2fs, and zfs.
XFS is a high-performance journaling file system that is particularly good at parallel I/O.
Ext4 is the evolution of the widely used Ext3 file system and offers improved performance, reliability, and features.
Btrfs is a modern copy-on-write filesystem with advanced features and a focus on fault tolerance and easy administration.
F2FS is a file system designed for NAND-based flash memory.
ZFS is an advanced file system created by Sun Microsystems that offers stability, speed, security, and future-proofing.(eredeti nyelven másoltam be, mivel installnál nem lehet magyar nyelvet választani) [link]
A listában egy laikusnak jól fog kinézni a high-performance, improved performance, modern copy-on-write, future-proofing kifejezés, de melyiket válassza?
És még odáig csak most fog elérni a kezdő tudata, hogy neki SSD-je van, ahhoz meg megint egy másik filesystem választható... Mondjuk utánaolvas a F2FS-nek és látja, hogy a zstd az 6-os compression level szinten optimális és a lazytime mount opció is ajánlott, de a többi FS-ről is olvasgat sajátosságokat...
A kérdésem a következő: a kezdő melyik FS-t fogja választani, esetleg azt mondja, hogy jó köszi ez ennyi volt!
-
PCProfessor
aktív tag
válasz
ubyegon2 #95456 üzenetére
Bőven jó a mezei felhasználónak is(btrfs vagy ext4-el, igen), végre egy distro amiben minden is benne van/ad lehetőséget váltani és mindent a lehető legjobban teljesít.
Ha abból indulok ki, hogy legtöbb ember asztali felhasználásra tart pc-t akkor ott bore a nyerő. Lehet csak én vagyok ezzel, de nagyon észrevehető ha bore van valahol, annyira smooth és gyors midnen, hogy hihetetlen.
Alapból annyira jól van optimalizálva az os, hogy bárkinek megmutatom/felrakom nagyon meglepődnek és nekik is olyan kell. -
válasz
PCProfessor #95450 üzenetére
CachyOS nem kifejezetten home user célokra való, tekintve milyen célokra default benne az XFS, párhuzamosan a BORE scheduler alkalmazásával. XFS inkább bivalyerős CPU és sok RAM mellett nagy fájlokkal végrehajtott műveleteknél optimális, rengeteg kis fájllal való művelethez EXT4 a jó. Nyilván lehet váltani FS-t, de semmiképp nem javasolt kezdő home usereknek. szerintem
Egyébként megfelelő hardverkörnyezetben a BORE scheduler kifejezetten jó tud lenni, épp a github linkben lévő Demo is mutatja.
Garuda inkább alkalmas home usereknek, bár rettenet bloat így elsőre majdnem az összes felülettel, de legalább érdekes, itt is alapból BTRFS van zstd tömörítéssel az EXT4 helyett, Ennél is a jobb I/O kezelés a cél előbbiekkel, plus alkalmazzák default a ZRAM-ot, az nem rossz megoldás szerintem. De a Garuda azért is szimpi, mert van önkritikája, a Chaotic-AUR ezt jelzi.
Endeavour az jó választás natë fórumtársnak, mivel már használta.
-
válasz
Rimuru #94589 üzenetére
Nem. Azt nem értettem, hogy miért mondták azt, hogy a /boot/efi és a /boot mindkettő legyen külön-külön. Én csak az EFI-t raktam külön. Azzal érveltek, hogy, ha a "/" BTRFS-be van formázva, akkor a grub nem működik normálisan, így kell külön egy /boot, ami ext4.
De én nem használok BTRFS-t, csak ext4-et, szóval azért és kérdeztem, hogy kell-e az nekem? Vagy elég az EFI? De akk. feltételezem, hogy elég az EFI. -
Rimuru
veterán
Nem ez volt az eredeti kerdesed? Azt hittem azt akarod hogy az ESP es a /boot legyen egy particio (tehat itt van bootloader, initramfs, stb), de akkor te arra gondoltal hogy a /boot marad a /-on.
Utobbi esetben az a kerdes hogy egyebkent kepes vagy-e bootolni az adott fs-rol (pl bootloader tamogatja-e). Arch wiki pl azt mondja hogy a grub tamogatja de en nem hasznalok btrfs-t, igy a konkret kerdesben nem tudok segiteni. -
Mindenképpen muszáj a /boot-ot külön partícióra tennem, ha már van /boot/efi partícióm?Fedorás fórumon ezt javasolták, ha a / partíció BTRFS fájlrendszerű, de én ext4-re formáztam. Így feltételezem nincs sok jelentősége hétköznapi használatnál?
-
#63718632
törölt tag
Kell is. Amennyiben nem telepítő a particionál, hanem Te manuálisan.
A/boot/efi
az evidens, a szokásos módon 500MB és fat32.
Kell!/boot
partició is mindenképp, ami 1GB és ext4.
A gyökér lehet bármi. A/boot
azért kell így, mert default a gyökér btrfs szisztéma szerint települ és a telepítő keresni fogja a külön csatolású/boot
-ot. Ezt mindazért, mert ha megbomlik a btrfs és abban van a/boot
is. Nem fog tudni a kernel sem elindulni, még recovery módban sem. Ellenben az openSuse szisztémájával, ahol van előre beállított readonly btrfs snapshot. Ott benne van a /boot is a btrfs fában. Viszont így tud indulni recovery-ben, ahonnan rendbe lehet elvilrg rakni a btrfs-t. A Fedora-ban ez nem így van. -
#02705152
törölt tag
Jó kis flamewar lesz ebből!
A RH mindig egy fura szerzet volt, érdemeik elismerése mellett egy csomó f@szság nekik köszönhető, kezdve Mr. Pöcstering áldásos tevékenységével.
Hogy jobban jártak az IBM-mel mint a Microsofttal, ezen is vitatkoznék. Az MS-nél a nagy pénz nem a Winben van, hanem az Azurban, amihez kapcsolódóan a Linux laborjuk komoly munkát végez, és ebből szépen forgatnak vissza a közösbe, ahogy kell (a kernelhez 2009 óta küldenek kódokat). Meg aztán lóvéval is tömnek egy rakás ópenszósz projektet (pl. OpenSSH, OpenSSF). A legszebb meg amikor Linuxos sérülékenységeket ők fedeznek fel és javítanak (pl. Nimbuspwn, amit közösen javítottak a Claytonnal)...
Mondjuk az IBM-et sem akarom bántani, a JFS-sel nagy szolgálatot tettek nekem a Btrfs megjelenéséig...Amúgy nekem nincs bajom velük, a hőskorban szívesen használtam, jól összerakott cucc volt, aztán a 9 után jött a Fedora, ami már közelről sem azt képviselte, mint a klasszikus RH kiadások, szépen elfelejtettük egymást...
Az RH-ért sem kell fizetni elvileg (ugye forráskód szintjén elérhető, bár ugye itt kezdtek el trükközni), a támogatásért fizetsz...
-
válasz
#02705152 #94265 üzenetére
"Ezt a parancsot még sose használtam"
Közben leesett, hogy csak a -D kapcsolót nem használtam, az lsblk az régi jó parancs.
Csak már ha írsz valamit, mindig beugrik a BTRFS és összezavarodtam...
Én nem mentek semmit hardveresen, aminek nem kéne elvesznie, az felhőkben van és ugye megbízható SSD...
-
#02705152
törölt tag
válasz
ubyegon2 #94259 üzenetére
"Ezt a parancsot még sose használtam"
Azért szeretem, mert az összes eszközt látom egyszerre, és ugyi az asztaliban van 4db SSD..."A super Intenso meg bármikor lecsukhatja a szemét"
Én egyikben sem bízok, a házi mentés nálam úgy néz ki, hogy (1) Rockstor (Fujitsu szerver, 2db HDD Btrfs RAID1), (2) SATA dokkoló 2db HDD (Btrfs csíkozva), (3) USB külső HDD ("hordozható" exFAT), (4+5) a nagyon fontos dolgokat meg a Microsoft és a Koofr is őrzi, szal nincs a véletlenre bízva... -
#02705152
törölt tag
Én mindig előre particionálok, de egyébként mindegy (bár pont a Popról írták itt a kollégák, hogy mindenféle idióta partíciókat hoz létre magának, innentől jó kérdés, inkább mutasd meg a szabad helyet neki). Cache partíción gondolom a swap partíciót érted...
Manapság a swap fájl a divat, partíciót akkor csinálj, ha tudod miért csinálod (pl. Btrfsre nem szeretünk swap fájlt rakni).
-
#02705152
törölt tag
válasz
ubyegon2 #94017 üzenetére
De én home user vagyok, és mindig is más fs-t akartam, nem ext-et!!!
Na jó, benyelem, hogy én vagyok a kivétel, ami erősíti...Amúgy amikor a telepítő szkriptjeit, konfig fájljait kell telepítés előtt/közben turkálnod, hogy a szájízednek való végeredményt kapj, az azért ciki, és ha mondjuk az ext4-nek szeretnél vmi csatolási opciót megadni, akkor is ezt kéne csinálnod, a dolog független a Btrfstől ilyen szempontból...
Ja és nem volt Linuxos vagyok, most is mindnyájunk kedvencével szopatom magam (bár tény, mióta Devuan/dwm kombó van, azóta kevésbé).
És lezárásként talán pont veled beszélgettük, picike vidéki eü. intézményben terelgetem a biteket, teljesen Wines környezetben (szerver/kliens egyaránt), szal amikor éppen dicsérem, akkor nem csak úgy bebüfizem, hogy bosszantsalak benneteket...
-
válasz
#02705152 #94013 üzenetére
De nincs gond, már a hosszú évek alatt megszoktam, hogy a Linux evangelistáknál ez a vitakultúra...
Szerintem a thread-hez viszonyítva tök normális a vitakultúra.
hogy ha normálisan konfigurált Btrfst akarsz, akkor a kijelentés korlátozottan igaz
Ebben teljesen igazad van. Viszont senki nem akar semmilyen más FS-t, ha home userként felrak egy Linuxot, remélem ezt elfogadod. Home userek 99,9%-a úgy van ezzel a BTRFS/EXT4 dologgal, mint a sysvinit/systemd témával. De miért is lenne másként, amikor nem az érdekli, mi van a rendszerben, hanem az, hogy jól működjön minden. Egyszóval azt a könnyen telepíthetőség ellen felhozni, hogy neked nem ment könnyen a BTRFS konfigolása...azért érzed mennyire sánta ez így.
Különben meg ne érzékenykedj, volt Linuxosként dícsérgeted itt a Wint és csodálkozol, hogy a torkodnak ugrunk!?
Ja és kicsit dekoncemtrált voltam, mert RO-t írtam, pedig writeonly-t akartam. Belinkeltem csomó BTRFS leírást, man-t és akkor leírod, hogy miért nem olvasunk doksikat róla? Writeonly vagy...
-
#02705152
törölt tag
válasz
ubyegon2 #94012 üzenetére
Nekem sincs egyikkel sem, és ha nem RO lennél, akkor emlékeznél hogy a Linux gyorsan és könnyen telepíthetőségére jegyeztem meg szerintem kulturált hangon, hogy ha normálisan konfigurált Btrfst akarsz, akkor a kijelentés korlátozottan igaz, erre a torkomnak ugrottatok, hogy minek a Btrfs, miért nem jó a bolygó összes lakójának az ext4... De nincs gond, már a hosszú évek alatt megszoktam, hogy a Linux evangelistáknál ez a vitakultúra...
-
válasz
#02705152 #93999 üzenetére
Ha genyó lennék, mondanám, hogy olvassatok Btrfs doksit, és akkor rájöttök miért jó, de azért segítek: COW, pillanatkép, tömörítés, alkötetek, CRC32C, eszközök ki be pakolása a fájlrendszerbe szabadon.
Ha nem csak RO lennél, láttad volna az iménti hsz-emben a rengeteg BTRFS linket, ennél többet hová olvassak róla? De amúgy nekem semmi gondom nincs vele, viszont az EXT4-gyel sem.
-
#02705152
törölt tag
Látom nagyon rágyógyultatok a Btrfsre...
Ha genyó lennék, mondanám, hogy olvassatok Btrfs doksit, és akkor rájöttök miért jó, de azért segítek: COW, pillanatkép, tömörítés, alkötetek, CRC32C, eszközök ki be pakolása a fájlrendszerbe szabadon. Ezek amiért szeretem, és kutya közönséges felhasználó kutya közönséges asztali gépéről beszélünk.
A Garuda a parasztvakítás példája, mi szupcsik vagyunk Btrfssel jövünk, miközben pont nem tudod beállítani ahogy szeretnéd, ezzel a hozzáállással gyk. semmit nem tudsz kihasználni a képességeiből. Ezen az alapon az összes disztró jó, mert bármelyiket tudod Btrfsre telepíteni, úgy ahogy a kedves fejlesztők jónak látják, és nem úgy ahogy te jónak látod...
A két kivétel amit ismerek a openSUSE és a Mageia, ezek amiknél trükközgetés nélkül beállíthatod ahogy akarod. -
butterfs...
Nem teljesen értem minek kéne nekem a butterfs pl. egy Debianra vagy Mintre.
Ez a fs egy olyan madár, aminek igen egyszerű a szükségessége. Akinek kell ez, az tudja, hogy kell neki és tudja is konfigolni, akinél előbbiek nincsenek meg, annak nincs rá szüksége.
(kivétel itt is erősíti beruskomám képében a szabályt)
De most jövök rá, hogy ezt anno főleg flexmester komával nagyon kitárgyaltuk, szinte BTRFS szakértők lettünk páran, aztán mégse...
De legalább pár tényleg hasznos link el van mentve a hsz-ekben.
Anno a JFS-re volt olyan érzésem, hogy az qrvára kell nekem, ill az SSD-mnek, ki is próbáltam. No de egy idő múlva rájöttem, hogy fogalmam sincs, miért is jobb ez az SSD-nek, aztán a következő installnál vissza is tért a jó öreg EXT4.
Ja és aki nagyon BTRFS-t akar, annak ott a csodás Garuda Linux.
-
válasz
#02705152 #93970 üzenetére
- Könnyen és gyorsan telepíthető. > Ez csak néhány terjesztésre igaz (lásd Btrfs normális konfigurálása).
Btrfs normális konfigurálása...
Mesélsz erről, hogy mennyire tömegigény ez a homeusereknél, de akár mondhatnám a haladó usereket is!? Követhettük, amint neked voltak próbálkozásaid, de azért érvként ezt felhozni elég kemény, nem? De!
Kb annyira sz*r érv, mint Tibikománál az, hogy buta a Linux, mert nem tudja használni rajta a Win 3.1, XP, etc alatt megszokott szuper appjait!
-
#02705152
törölt tag
Tényleg nem akarok flamewart, de:
- Ingyenes. > Ez OK.
- Stabil és megbízható. > Ez csak néhány terjesztésre igaz.
- Biztonságos (ha tudod mit csinálsz). > Nem az.
- Könnyen és gyorsan telepíthető. > Ez csak néhány terjesztésre igaz (lásd Btrfs normális konfigurálása).
- Szoftverek frissítése/telepítése nagyon egyszerű. > Ez OK, de Winen is megoldott (Winget).
- Rendszer frissítése gyors és automatizálható. > Ez OK (és ebben messze jobb mint a Win).
- Ergonómikus, multifunkciós és változatos asztali környezetek, pl. Gnome és KDE. > Borzalmas bogárfarmok, felhasználók és a minimális szabványosítási törekvések lesajnálása (pl. GNOME+ Wayland), stb.
- Terminálban sok dolog gyorsabb, mint GUI-n keresztül. > Ez OK, és igaz a PowerShellre is.
- Közeljövőben valószínűleg még jobban fejlődni fog, nagy cégek pumpálják bele a pénzt. > De nem azért, hogy neked jobb asztali környezeted legyen.
- Általában nyílt forráskódú, ami lehet éppen előny is. > Ez OK.
- Magánszféra és adatvédelem jobb, mint Windowson. > A Win hírhedt telemetriája 30 másodperc alatt kikapcsolható (lásd Gemini oldalam). Onnantól hogy csatlakoztál a ziternyetre a magánszférát felejtsd el (a legcukibb amikor a Zinsta meg F@szbuk felhasználók aggódnak, hogy kémkedik utánuk a Win).
-
#02705152
törölt tag
válasz
tordaitibi #93952 üzenetére
Semmit nem vesztesz, ha leszállsz a Linux vonatról. A Linux sz@r és egyre sz@rabb lesz, ezt 20+ év tapasztalata mondatja velem...
Én is megszokásból használom, és nem azért mert észérvek szólnak mellette.
Na jó, két pozitívuma azért mégis akad, a Btrfs meg hogy ingyé van... -
#63718632
törölt tag
válasz
tordaitibi #93318 üzenetére
"Visszaálltam régebbi Timeshift mentésre, mikor kezdte, ugyanez, próbálom régebbi kernellel indítani ugyanez a hiba."
A Timeshift mentés hogyan van beállítva?
Mert ott két lehetőség van.
1: rsync
2: btrfs -
válasz
#79484416 #93319 üzenetére
Nem 100 hanem 1000% hogy egyik gépen sem volt az életbe btrfs, én még soha nem csináltam ezt fájlrendszert.
Growler, negatív:
tibi@TibiXubuntu:~$ sudo apt-get purge btrfs-progs
Csomaglisták olvasása... Kész
Függőségi fa építése
Állapotinformációk olvasása... Kész
A(z) „btrfs-progs” csomag nincs telepítve, így nem lett törölve
tibi@TibiXubuntu:~$ sudo apt-get purge btrfs-tools
Csomaglisták olvasása... Kész
Függőségi fa építése
Állapotinformációk olvasása... Kész
A(z) „btrfs-tools” csomag nincs telepítve, így nem lett törölve
Initramfs update, ennek is baja van de mi?
tibi@TibiXubuntu:~$ sudo update-initramfs -ukall
update-initramfs: Generating /boot/initrd.img-4.15.0-221-generic
cryptsetup: WARNING: found more than one resume device candidate:
30b00271-26f3-4b5d-a97b-9897ed48c5ca
98cb6841-4da3-4297-9c0f-9f065ab8683a
I: The initramfs will attempt to resume from /dev/sdb4
I: (UUID=98cb6841-4da3-4297-9c0f-9f065ab8683a)
I: Set the RESUME variable to override this.
-
growler
őstag
válasz
tordaitibi #93318 üzenetére
sudo apt-get purge btrfs-tools # (vagy:btrfs-progs)
sudo update-initramfs -ukall
sudo update-grub
?
[link] (A Googli a baratom!)
-
Hordozható ssd-s portable Ububtum pár hete elkezdte ezt a hibát.
Bootoláskor itt megáll és vagy 20-25 perc múlva továbblép és jól működik, vagy örök időre itt marad.
Scanning for btrfs filesystem, itt akad el, nincs is egyik lemezemen se ilyen.
Visszaálltam régebbi Timeshift mentésre, mikor kezdte, ugyanez, próbálom régebbi kernellel indítani ugyanez a hiba.
Mit csinál, mitől romlott el, lehet orvosolni? -
válasz
#02705152 #92840 üzenetére
Tudom hogy UFO vagyok a Btrfssel
Egy kicsit, ja!
De nem rossz ez a btrfs szerinten se, discard=async-ról se, igaz jó ideje nem olvasgatok ezekről. Szóval ez a discard nem is az a discard, ami at fstrim-et alkalmazza.
A teljesítményt nem befolyásolja, és elvileg a meghajtók is jobban szeretik.
Tényleg kipróbálom már ezt valamikor és én is megkérdem a PM883-tól, hogy jobban szereti-e!
Referenciának meg ott a Meta, ők így használják a meghajtóikat.
Hát ha a Fécbúk is ilyenen fut, akkor nincs mese, már rakom is fel!
-
#02705152
törölt tag
válasz
ubyegon2 #92838 üzenetére
Csak hogy teljes legyen a kép.
Tudom hogy UFO vagyok a Btrfssel, de a 6.2 kernel óta itt a discard=async default opció lett. Ha defaultsal csatolsz az fstabban akkor mindenképp, de elvileg enélkül is beállítja MINDEN támogatott meghajtóra, az NVMe cuccokra is (tehát nem a hagyományos SATA parancs hívása). Van egy kis vita, hogy jobb v. nem jobb minta az fstrim, de többségben vannak akik szerint jobb. Ez egy komolyan felokosított discard, blokk csoportokat hoz létre a memóriában, és méret v. idő limit elérésekor takarít (ezt most nagyon leegyszerűsítettem, de ez a lényeg). A teljesítményt nem befolyásolja, és elvileg a meghajtók is jobban szeretik.
Én eliminálom az fstrimet alapból, és a mellékelt ábra szerint az új discard mechanizmus takarít ahogy kell.Referenciának meg ott a Meta, ők így használják a meghajtóikat.
-
#63718632
törölt tag
válasz
tordaitibi #92456 üzenetére
A Fedora-nak kicsit eltérő partíció és könyvtár struktúrája van, mint a Debian és Ubuntu származékoknak. Mármint ami a grub és kernel helyét illeti. A Fedora elég régóta default LVM-re vagy mostanában már btrfs-re pakolja a / és /home könyvtárakat. Emiatt a /boot könyvtár egy külön partíció ext4-el. Ha szétbomlik az LVM vagy a btrfs struktúra, akkor is tudjon bebootolni legalább egy minimális rendszer. Aztán helyre lehet pakolni a dolgokat. Ellenben, ha a /boot könyvtár marad a /-en és a széthullás miatt még bebootolni sem tud a rendszer.
A videón a csávó az efi partíción matat, ahol a grub "dógai" vannak.
Szó nincs a /boot könyvtárról.
Én custom telepítést csináltam, a csávó meg az üres helyre nyomta be a telepítést. A kettő nem ugyan az. Arra kiváncsi lennék, hogy a default btrfs / és /home meg a külön /boot 1GB ext4 megmaradt-e?
Szerintem igen.
A saját custom telepítésem partíció méreteit a default telepítés sémája alapján méreteztem. -
#63718632
törölt tag
Ez meg custom telepítés, btrfs nélkül. Sima ext4-es gyökérrel. "Mordor" mellé dual-ban.
nobi2@nobara-pc:~$ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 04F7-F698 681,3M 2% /boot/efi
├─sda2 ext4 1.0 boot 85c221e7-d480-45c9-9068-9fd1515ae865 667,7M 25% /boot
├─sda3 swap 1 994a786a-bd69-4875-a6b4-485d376135cc [SWAP]
└─sda4 ext4 1.0 root 7e33edf8-1b26-4f7a-bb8d-4cd8f9b20a1b 36,7G 26% /
sr0
zram0 [SWAP]
nobi2@nobara-pc:~$ su
Jelszó:
root@nobara-pc:/home/nobi2# fdisk -l
Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9363D34C-1EBE-4E15-A3F7-0F54277B0498
Device Start End Sectors Size Type
/dev/sda1 4096 1437695 1433600 700M EFI System
/dev/sda2 1437696 3534847 2097152 1G Linux filesystem
/dev/sda3 3534848 11923455 8388608 4G Linux swap
/dev/sda4 11923456 125827071 113903616 54,3G Linux filesystem
Disk /dev/zram0: 3,79 GiB, 4071620608 bytes, 994048 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
root@nobara-pc:/home/nobi2#
-
#63718632
törölt tag
Ilyen a default telepítés, teljes lemez belakással.
nobi@nobara-pc:~$ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 4B5B-4F24 581,5M 3% /boot/efi
├─sda2 ext4 1.0 37633c74-ba6d-4872-925b-fb9f57f6b103 722,5M 19% /boot
├─sda3 btrfs 68fca3fa-abc4-4791-8fb0-59b86fec16ec 44,1G 14% /home
│ /
└─sda4 swap 1 swap 491337d9-523b-4bf3-8611-12a7b0f3de6f [SWAP]
sr0
zram0 [SWAP]
nobi@nobara-pc:~$ su
Jelszó:
root@nobara-pc:/home/nobi# fdisk -l
Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 8A3E0F44-1047-4AFC-A17A-EE6E0809509A
Device Start End Sectors Size Type
/dev/sda1 4096 1232895 1228800 600M EFI System
/dev/sda2 1232896 3330047 2097152 1G Linux filesystem
/dev/sda3 3330048 113362260 110032213 52,5G Linux filesystem
/dev/sda4 113362261 125821079 12458819 5,9G Linux swap
Disk /dev/zram0: 3,81 GiB, 4086300672 bytes, 997632 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
root@nobara-pc:/home/nobi#
-
válasz
#63718632 #92445 üzenetére
Én ext4-gyel telepítettem /boot nélkül , de akkor újra telepítem és 1GB ext4 /boot partíciót is csinálok neki. De a rettenet btrfs fájlsystémát mellőzöm, maradok az ext4 mellett. Valami bandzsalítás miatt láttam is, hogy (most kínjában) egy rejtett kernel hivatkozás, vagy fájl van az EFI partíción. .... KÖSZI!!! vajákos lehetsz az biztos! először a 600Mb-os EFI partíciót is megszívtam, mert szokás szerint csak egy 320MB-os EFI partíciót csináltam neki és azt telepítés közben leköpte.
-
#63718632
törölt tag
A Nobara-t pont azért is ajánlom, mert-
1: Van egy Nobara (edition) ISO, ami készre van moddolva az alap KDE-Plasma-hoz képest.
2: Fel lehet rakni ext4 fájlrendszerrel is. (Alapból btrfs-re teszi a / és /home partíciókat.
3: A Fedora miatt nagyon friss dolgok vannak benne + a Nobara csapat hozzá teszi a játékokhoz való friss dolgokat.
4: Nem kell külön tárolókat és szoftver forrásokat neked hozzá tákolni a rendszerhez. -
válasz
sh4d0w #91726 üzenetére
Ez nagyon jó...még a dallama is a fülembe ugrott egyből!
Ja, meg stabilitás és megbízhatóság fanoknak is...
Kb. ennyi idő szükséges, hogy egy terjesztés igazán kiforrja magát, müxik is minden ahogy kell!A Zorin....biztosan, bár lehet van ilyen szempontból stabilabb is.
Ja hogy BTRFS szempontjából...így már értelek. (mindegy, várunk akkor vagy két napot és meglátjuk melyik a következő stabil disztród)
(#91729) CPT.Pirk
Régi szép idők...még mindig hiányzik, az utolsó rc5 tökéletesen futott nálam...
-
#02705152
törölt tag
Xubuntu 23.10 Minimal, nincs bloat, van régi telepítő (lehet Btrfst szokott módon idomítani), és eddig stabil...
-
#02705152
törölt tag
Közben kiokoskodtam hogyan lehet Manjaro/Calamares esetén a telepítés során normálisan beállítani a Btrfs csatolási opciókat, akit érdekel a Gemini oldalamon találja a részleteket.
gemini://berus.flounder.online/
-
#02705152
törölt tag
válasz
ubyegon2 #91356 üzenetére
Másképp müxik a defrag és az autodefrag. Az előbbi (parancs) azt csinálja alapból ami a neve, az utóbbi (csatolási opció) meg az írásokat késlelteti, és a memóriában rendezgeti a blokkokat, és hajlamos túlgondolni a dolgot (mint te a Btrfst
), aztán egyszer csak elárasztja a lemez I/O-t, ami vicces, ill. nem túl vicces dolgokat tud művelni...
Mint írtam a noatime lényegesen csökkenti a metaadatok töredezését, ezért fontos Btrfsnél.
Kérdezhetném, ha kiszeded a COW-ot, akkor minek használsz Btrfst (persze vannak más okosságai is)...? -
#02705152
törölt tag
válasz
ubyegon2 #91350 üzenetére
Nem kell azért túlgondolni, főleg nem otthoni rendszeren.
A COW miatt a defragnak van értelme SSD-n is Btrfs mellet (meg van egy rakás egyéb funkciója is, lásd újra tömörítés az én esetemben), viszont az autodefrag csatolási opció tud furi dolgokat művelni, egyáltalán nem ajánlom a használatát.
A noatime amellett hogy hoz minimális gyorsulást, segít megakadályozni a metaadatok töredezését, szal erősen ajánlott.
Sok optimalizációt nem igényel, ami amúgy fontos az SSD-knél, hogy legyen elég szabad hely az Btrfsnél kiemelten fontos! Én következetesen 2GB hagyok a meghajtókon, a nálam okosabbak meg 5%-ot javasolnak, ha tuti a biztosra akarsz menni. -
válasz
growler #91351 üzenetére
A defrag opcióra rákérdeztem az angol Garuda fórumon - állitólag btrfs-en van
értelme SSD-n is - úgy-hogy az maradt.Érdekes, ugyan írta a discard=sync opciónál, hogy azért nem jó, mert töredezett fájlrészleteket hagyhat, de az eddigi ismeretek a TRIM műveletről ezt elég érthetetlenné teszik, de Te tudod, ha benne hagyod, benne hagyod, szerintem baromság ez így.
Mondjuk ha ugyanott olvastad, ahol az előző javaslatot, akkor azért elgondolkodnék a dolgon...szerinted van értelme két azonos funkciót ellátó ütemezett szolgáltatás lefutásának?
-
#02705152
törölt tag
válasz
growler #91349 üzenetére
Ha tisztán Btrfst használsz elég a btrfs-fstrim, de hagyhatod mindkettőt, mert ha normálisan van összerakva a rendszer, akkor úgyis Conflicts=fstrim.service paraméterrel van konfigurálva, elvileg a rendszer nem futtatja mindkettőt (SUSE-n így volt, Ubu meg csak fstrimet használ).
-
growler
őstag
válasz
ubyegon2 #91350 üzenetére
Az első Garuda telepítésem btrfs-re történt - de valamiért az első boot alkalmával
elakadt / nem töltődött be a rendszer. ... Lesikáltam.
Masodszorra, már Ext4-es fájlrendszerekre telepítettem (kézi mókolással mert a
telepítő csak a fat32-őt, btrfs-t és a cserehelyet ismeri.) Később valami probléma
miatt ez is ment.
Harmadszorra ismét btrfs-el ... amely sikeres lett, és kb. 1-1.5 éve megvan.
A defrag opcióra rákérdeztem az angol Garuda fórumon - állitólag btrfs-en van
értelme SSD-n is - úgy-hogy az maradt. -
válasz
growler #91349 üzenetére
Atyaég...belenéztem a btrfs mount opció doksijába, hát lehet tépném a hajam, ha nem EXT4-et használnék. Neked is javaslom, mert vannak saját mount opciói a btrfs-nek és vannak általános mount opciók is.
erre itt egy példa:
btrfs-trim.service
fstrim.timerTotál ugyanazt csinálja mindkettő, szóval mivel nem ismerem a fs-t, mégis azt mondom, csak az egyiket hagyd benn!
Alapból a discard egész korrekt lenne a async kapcsolóval, mert ha ba van kapcsolva a COW, ami szintén hasznos lehet, akkor azt üti a discard=sync.
Ami fontos lehet még, hogy sok mount opció működik default a 6.1 és néhány a 6.2 kernelek óta. Szóval hasznos doksi, amit linkeltem, nem 10 perc, míg értelmezed azt opciókat és egymásra hatásukat!
Ha most btrfs-t használnék, beraknám az fstab-ba discard=sync opciót és meghagynám a btrfs-trim.timer-t weekly időzítéssel.
Mi nekem értelmezhetetlen, az a defrag opció, mert SSD-nél ez kifejezetten haszontalan és ellenjavallt...nem is értem itt miért van...
Van ilyen mount opció is:
ssd, ssd_spread, nossd, nossd_spread
, ami azért érdekes, mert default SSD autodetected van bekapcsolva, de megmarad mégis a defrag is...Meg is állapítottam, hogy totál hülye vagyok ehhez a fs-hez, ha SSD-t kéne ezen optimalizálnom, égnek állna a hajam.
Persze ha NVMe SSD-ről van szó, jóval egyszerűbb lenne a helyzet, ott legalább a TRIM-meléssek kapcsolatos opciókat el lehetne felejteni.
Sok sikert a beállításhoz és úgy általában a btrfs használatához! Reméljük berus szaki majd jön és megvilágosítha homály elménket!
Szerintem tényleg modern(COW például), jó dolgok vannak benne, de kiforratlan ez a fs picit még, inkább annak javasolnám a napi használatát, aki valóban tisztába van a különböző és egymásnak időnként ellentmondó default beállításaival és képes optimalizálni.
Ja és mindenhová be van rakva a noatime opció, ami meg kifejezetten nem modern, a mai SSD-nél már totál értelmetlen opció!
Új hozzászólás Aktív témák
A 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!
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Antivírus szoftverek, VPN
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap
- BESZÁMÍTÁS! MSI B450 R7 5700X 32GB DDR4 512GB SSD RTX 3070 Ti 8GB Zalman Z1 Plus Corsair 750W
- GYÖNYÖRŰ iPhone SE 2020 128GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3279, 100% Akkumulátor
- iKing.Hu - Xiaomi 14 Ultra Ultra White Használt, karcmentes állapot, Kamerás csúcsmobil
- iKing.Hu - Apple iPhone 14 Stílusos megjelenés, megbízható teljesítmény
- Részletre elviheted akár 365 napra. Bankmentes.Gainward GeForce RTX 5070 Ti Phantom
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest