Érdekesen működik mostanság a Fedora, nvidia driver, stb... inkább csak azt szeretném tudni, hogy ezek általánosak, vagy itt van valami nagyon elrontva.
Fedora 41 alatt, az aktuális nvidia driverrel kifagyogatott a suspend, nem sikerült deep sleep-be mennie a gépnek, vagy nem tért vissza belőle. - Korábban mint ha nem lett volna ilyen probléma.
Rájöttem, hogy friss boot után, ha waylanddal lépek be, akkor működik tökéletesen a deep sleep-be lépés is, és a visszatérés is onnan. Ha használok pár programot (pl brave), és utána próbálom meg a suspend-et, akkor deep sleep-be téréskor elmegy a kép, majd felzúgnak a ventillátorok, és 20-40 másodperc után lesz valami timeout a journalctl-ben. (bluetoothd-vel kapcsolatban is, és az nvidia driverrel kapcsolatban is).
Ha átmegyek X11-re, akkor minden működik, működik a suspend: a deep sleep, és a felébredés is. Kivéve, hogy itt elkezdődött az az idegesítő dolog, hogy a monitor kb 10 másodperc után lekapcsol, néha elmegy a kép, majd visszajön. Eddig ilyen probléma nem volt X11 alatt.
Az alaplap: Gigabyte B650, a videókártya: nvidia rtx 4060
Tapasztalt valaki esetleg hasonlót? Köszi szépen.
- 580 megtekintés
Hozzászólások
Saját történet, nem kifejezetten erre vonatkozik.
4-5 évente veszek új gépet, a mardék a házon, tápon kívül megy tovább a családban.
Régi gép: B450-3800X-32GB-NVME+SATAIII-NVidia1060
Új: B650-9900X-64GB-NVME-AMD7600
Átlag felhasználás mellett bőven elég volt a régi is, DE az nvme max sebesség miatt jóval gyorsabb minden az új gépen. 4-5GB-os thunderbird fiókon a részletes keresés a ~25sec helyett ~5sec lett.
Ezekből arra következtetek, hogy a háttértár még mindig a legnagyobb hátráltató tényező általános felhasználás mellett.
Az nvidia-amd GPU váltás elvitt a Kánaánba. Minden megy rögtön és gyorsan AMD vonalon. Eddig nVidia felhasználó voltam tudatosan, már sosem leszek az (legalábbis linux alatt).
- A hozzászóláshoz be kell jelentkezni
Igen, ez már eszembe jutott, hogy nekem nem biztos, hogy nvidia lesz legközelebb. :)
Az X képernyő lekapcsolásra úgy tűnik, hogy ez lesz a megoldás:
https://wiki.archlinux.org/title/Display_Power_Management_Signaling
xset -dpms
xset s offMajd vissza:
xset s 180
xset +dpms
xset dpms 300 360 420Én úgy vettem észre, hogy 180 másodperc után nem történt semmi, a képernyő ugyanúgy bekapcsolva maradt. 5 perc után lekapcsolt a monitor. 15 perc után jött a gép suspend, amit beállítottam. <- ez most így működik.
A beállításokat le lehet kérdezni, de itt valamit nagyon nem értek:
Miután visszajött a gép, szerintem lekérdeztem a beállításokat (ezt a terminálból copy paste-ezem):
xset q
...
DPMS (Display Power Management Signaling):
Standby: 300 Suspend: 360 Off: 420
DPMS is Enabled
Monitor is On
Majd hirtelen elment megint a monitor képe, és utána:
...
DPMS (Display Power Management Signaling):
Standby: 0 Suspend: 0 Off: 0
DPMS is Enabled
Monitor is On---
Wayland alatt minden oké ezzel. Ott a deep sleep nem működik. :D
Közben megtaláltam, nekem már volt egyszer a deep sleep-pel egyszer problémám: https://hup.hu/comment/3045712#comment-3045712 csak az sajnos más volt. Akkor működött minden, miután rájöttem, hogy mi van.
- A hozzászóláshoz be kell jelentkezni
Wayland alatt ez kerül bele a logba, mint probléma: (journalctl)
febr 19 18:49:55 fedora kernel: Freezing user space processes
febr 19 18:49:55 fedora kernel: Freezing user space processes failed after 20.002 seconds (1 tasks refusing to freeze, wq_busy=0):
febr 19 18:49:55 fedora kernel: task:gnome-shell state:R running task stack:0 pid:3177 tgid:3177 ppid:2840 flags:0x0000400e
febr 19 18:49:55 fedora kernel: Call Trace:
febr 19 18:49:55 fedora kernel: <TASK>
febr 19 18:49:55 fedora kernel: ? _nv027805rm+0x70/0x70 [nvidia]
febr 19 18:49:55 fedora kernel: ? os_get_current_tick+0x3b/0xa0 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv028580rm+0x7a/0x130 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv045009rm+0xd/0x20 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv011444rm+0x119/0x280 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv054282rm+0xee/0x170 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv036925rm+0x6b/0xd0 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv037124rm+0x107/0x360 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv031519rm+0xed/0x1f0 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv031519rm+0xbd/0x1f0 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv031487rm+0x6ed/0x1240 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv024076rm+0x139d/0x1e70 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv012989rm+0x161/0x290 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv035915rm+0x1f5/0x450 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv035915rm+0x19f/0x450 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv039493rm+0xb64/0xf00 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv051341rm+0x28a/0x3a0 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv049422rm+0xfd/0x160 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv049420rm+0x5c/0x90 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv049420rm+0x32/0x90 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv013245rm+0x64/0xa0 [nvidia]
febr 19 18:49:55 fedora kernel: ? _nv013245rm+0x28/0xa0 [nvidia]
febr 19 18:49:55 fedora kernel: ? rm_kernel_rmapi_op+0x92/0x273 [nvidia]
febr 19 18:49:55 fedora kernel: ? nvkms_call_rm+0x4a/0x80 [nvidia_modeset]
febr 19 18:49:55 fedora kernel: ? _nv002866kms+0x4c/0x60 [nvidia_modeset]
febr 19 18:49:55 fedora kernel: ? _nv000543kms+0xb4/0x110 [nvidia_modeset]
febr 19 18:49:55 fedora kernel: ? _nv000543kms+0x8e/0x110 [nvidia_modeset]
febr 19 18:49:55 fedora kernel: ? __nv_drm_gem_nvkms_map+0x63/0xd0 [nvidia_drm]
febr 19 18:49:55 fedora kernel: ? __nv_drm_gem_nvkms_mmap+0x16/0x40 [nvidia_drm]
febr 19 18:49:55 fedora kernel: ? nv_drm_mmap+0xda/0x160 [nvidia_drm]
febr 19 18:49:55 fedora kernel: ? __mmap_region+0x745/0xb10
febr 19 18:49:55 fedora kernel: ? mmap_region+0x78/0xa0
febr 19 18:49:55 fedora kernel: ? do_mmap+0x499/0x690
febr 19 18:49:55 fedora kernel: ? vm_mmap_pgoff+0xec/0x1c0
febr 19 18:49:55 fedora kernel: ? ksys_mmap_pgoff+0x14b/0x220
febr 19 18:49:55 fedora kernel: ? __pfx_nv_drm_gem_map_offset_ioctl+0x10/0x10 [nvidia_drm]
febr 19 18:49:55 fedora kernel: ? do_syscall_64+0x82/0x160
febr 19 18:49:55 fedora kernel: ? syscall_exit_to_user_mode+0x10/0x210
febr 19 18:49:55 fedora kernel: ? do_syscall_64+0x8e/0x160
febr 19 18:49:55 fedora kernel: ? avc_has_extended_perms+0x251/0x540
febr 19 18:49:55 fedora kernel: ? drm_dev_enter+0x1d/0x60
febr 19 18:49:55 fedora kernel: ? drm_ioctl_kernel+0xad/0x100
febr 19 18:49:55 fedora kernel: ? __check_object_size+0x58/0x230
febr 19 18:49:55 fedora kernel: ? drm_ioctl+0x2b7/0x540
febr 19 18:49:55 fedora kernel: ? __pfx_nv_drm_get_drm_file_unique_id_ioctl+0x10/0x10 [nvidia_drm]
febr 19 18:49:55 fedora kernel: ? syscall_exit_to_user_mode+0x10/0x210
febr 19 18:49:55 fedora kernel: ? do_syscall_64+0x8e/0x160
febr 19 18:49:55 fedora kernel: ? do_syscall_64+0x8e/0x160
febr 19 18:49:55 fedora kernel: ? do_syscall_64+0x8e/0x160
febr 19 18:49:55 fedora kernel: ? do_syscall_64+0x8e/0x160
febr 19 18:49:55 fedora kernel: ? do_syscall_64+0x8e/0x160
febr 19 18:49:55 fedora kernel: ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
febr 19 18:49:55 fedora kernel: </TASK>Újratelepítettem az nvidia drivert is, nem segített.
Van a naplóban még egy ilyen is:
febr 19 18:49:35 fedora systemd-sleep[4206]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
febr 19 18:49:35 fedora systemd-sleep[4206]: This is not recommended, and might result in unexpected behavior, particularly
febr 19 18:49:35 fedora systemd-sleep[4206]: in suspend-then-hibernate operations or setups with encrypted home directories.
febr 19 18:49:35 fedora systemd-sleep[4206]: Performing sleep operation 'suspend'...de ennek az átállítása sem segít. Mármint ezt sikeresen true-ra állítottam: SYSTEMD_SLEEP_FREEZE_USER_SESSIONS, de nem oldotta meg a kérdést.
Ezt a driver beállítást találtam még meg: NVreg_PreserveVideoMemoryAllocations=1 - de ez nem segít.
És úgy tűnik, hogy ez többeknek is problémája: https://discussion.fedoraproject.org/t/fedora-41-kde-nvidia-not-working… és ha jól értem AMD alatt is jelentkezik...
És furcsa, hogy Wayland alatt csak az esetek 70%-ban nem működik a suspend, a maradék 30%-ban igen.
X11 alatt működik minden, csak a resume egy kicsit lassabb: megjelenik egy egér kurzor (szinte azonnal), és onnantól kb 10 másodpercet kell várni, hogy történjen valami. Wayland alatt ha működik éppen, akkor ott nincs várakozás.
- A hozzászóláshoz be kell jelentkezni
Zseniális, X11 alatt pedig valami elállítja a timeout-okat, de csak egy idő után:
xset q
...
DPMS (Display Power Management Signaling):
Standby: 0 Suspend: 0 Off: 0
DPMS is Enabled
Monitor is On
xset dpms 300 360 420
xset q
...
DPMS (Display Power Management Signaling):
Standby: 300 Suspend: 360 Off: 420
DPMS is Enabled
Monitor is On
hiába vettem fel a /etc/X11/xorg.conf.d/ alá is
- A hozzászóláshoz be kell jelentkezni
Fedora 41 alatt, az aktuális nvidia driverrel kifagyogatott a suspend, nem sikerült deep sleep-be mennie a gépnek, vagy nem tért vissza belőle. - Korábban mint ha nem lett volna ilyen probléma.
Ez az, ami miatt nem használok Fedora-t: a folyamatos regressziók (általában véve is, de az ACPI S3 a leglátványosabb képviselője ennek a problémának, ugyanis ahhoz tökéletesen együtt kell működnie mindennek a rendszerben).
Fedora-val először 2010 vége felé hozott össze a sors, akkor munkahelyi gépre Fedora 13-at telepítettem. Néhány upgrade után (amelyek ismételten regressziókat hoztak be) feladtam, és áttértem RHEL6-ra; azóta RHEL7, RHEL8, RHEL9 futott nálam (most éppen RHEL9). Időközben rendszeresen olvastam a Fedora-t érintő ACPI S3 regressziókról. Érdekes látni, hogy a Fedora még most is esik-kel.
https://docs.fedoraproject.org/en-US/project/#_first
At any point in time, the latest Fedora platform shows the future direction of the operating system [...] We recognize that there is also a place for long-term stability in the Linux ecosystem [...] However [...] pursue a strategy that preserves the forward momentum [...] Fedora always aims to provide the future, first.
Ezért törik el mindig az ACPI S3, és ezért nem jön nálam szóba a Fedora.
- A hozzászóláshoz be kell jelentkezni
Nem volt még lelkierőm, de gondolkodom rajta, hogy kipróbálom egy Debiannal, vagy Arch linuxxal. A deep sleep-et szeretném ha rendesen működne a gépemen. De pont a deep sleep arch linuxos fórumok alapján ott sem tökéletes (vagy nem volt az korábban).
A helyzet lehet összetett is, nem tudom, hogy mit gondoljak a Fedora-ról, mert az ilyen jellegű problémáknál szokott az lenni, hogy a probléma nem teljesen a Fedora-ban van, hanem félig valaki más cuccában, jelen esetben pl az nvidia driverben. Vagy akár a Wayland-ben. Ilyenkor persze senki nem érzi, hogy neki kellene javítania. Itt pont találkoznak a problémás területek: ACPI S3, Wayland, Nvidia driver. :)
Most szerintem ezt konfig fájlokkal, beállításokkal nem tudom megoldani, valószínűleg ez egy javítandó bug. És az is lehet, hogy csak az én alaplapommal jön elő, ezért már a biosban is megpróbáltam állítgatni.
Külön jó a Fedora-ban, hogy az Nvidia driver telepítés akmods-szal már nincs úgy kitesztelve, hogy mi van, ha titkosítottad a partíciót. Bootoláskor pár másodperc után feljön egy képernyő, hogy írd be a jelszavad, és ha nincs az initramfs-be bemásolva a driver, akkor szétfagy minden. Driver, vagy kernel frissítés után kézzel szoktam dracut-ot indítani, mert szerintem lefut egy initramfs generálás automatikusan is, de még azelőtt, mielőtt a driver lefordulna. Ez a fordítás is a háttérben történik, a futó processeket kell nézni, hogy mikor ért véget. :) (a secure boot is bekapcsolva van). - Na egy ilyen eset már nem működik alapból, hanem kézzel kell belepiszkálni. - Lehet, hogy ez más linux distróval is így van.
Erre a problémára: Megpróbáltam az open source drivert is, úgy sem működött. Visszatérhetek a nouveau-ra, de szerintem nem ez a megoldás. A videókártyát nem játékra, és csak képmegjelenítésre szeretném használni, hanem programozáshoz is. Szerintem ez a nouveau-val nem fog menni, inkább csak a zárt driverrel.
- A hozzászóláshoz be kell jelentkezni
a probléma nem teljesen a Fedora-ban van, hanem félig valaki más cuccában, jelen esetben pl az nvidia driverben. Vagy akár a Wayland-ben
A technikai hiba szinte biztosan nem a Fedora-ban van. A Fedora-val sokkal inkább az a baj, hogy ha Fedora N-ben működik az ACPI S3 (esetleg miután napok alatt összereszeltél mindent), akkor majd a Fedora (N+1)-ben jól elrontják, azzal a felkiáltással, hogy "haladás" (és kezdheted előről összereszelni). Ha pedig nem akarsz frissíteni N+1-re, a regresszióktól tartva, akkor hamarosan nem fogsz bugfixeket / security fixeket sem kapni.
Stabil disztróban ez úgy néz ki, hogy a suspend vagy nem megy, vagy megy, de ha megy, akkor szinte biztos, hogy nem fogják évekig elrontani, miközben bugfixeket és security fixeket rendszeresen kapsz.
A Fedora-val nyilván nem specifikus probléma van. Ha tudnánk úgy feature-öket fejleszteni, hogy nem csinálunk bugokat, az lenne a Szent Grál. Ilyen persze nincs. Tehát a kérdés az, hogy folyamatosan az új feature-öket választjuk-e (amelyekkel megállás nélkül jönnek a bug-ok is), vagy azt, hogy a major release után lényegében csak bugfix-eket fogadunk be. Én az élet minden területén az utóbbi táborban vagyok (szinte sosem érdekelnek újdonságok; csak annyi kell, hogy amitől már függök, az ne romoljon el); a Fedora ennek a szöges ellenkezője. Ha valaki tudatosan vállaja a hullámvasutat, az rendben van persze.
- A hozzászóláshoz be kell jelentkezni
Megkérdezhetem, hogy melyik disztribúciót használod? A debian talán ilyen (stabilabb) lehet, amit írtál. Én azt régebben használtam, és szerettem is. Először szerveren, de desktopon is keveset.
- A hozzászóláshoz be kell jelentkezni
Ahogy fentebb írtam, most RHEL9-et (az asztali gépemen, amit csak magáncélra használok).
- A hozzászóláshoz be kell jelentkezni
Igen, bocsi. :) félreértettem. Pont az RHEL-re is gondoltam, hogy egy próbát megérne, otthoni felhasználásra ha ingyen lehet használni, ha jól tudom, csak regisztrálni kell.
Szerintem a hétvégén ki is próbálom.
- A hozzászóláshoz be kell jelentkezni
Ha nem akarsz licenckérdésekkel foglalkozni, akkor RHEL->Alma, és jónapot :)
- A hozzászóláshoz be kell jelentkezni
Köszi. Tegnap addig jutottam az RHEL-lel, hogy regisztráltam, letöltöttem, és nincs benne BTRFS (a telepítő nem ajánlja fel). (Eddig azt használtam, de mondjuk lehet, hogy nem is kell nekem BTRFS).
Ekkor gondoltam, hogy teszek egy próbát az Arch linuxxal, hogy az működik-e. Kétféle módon tettem fel, esőre telepítő nélkül: Na ez fájdalmas volt. Ugye úgy könnyebb, hogy egy másik gépről, ahol van Internet, és tudod nézni az egyes lépéseket, onnan lépsz be SSH-val, és úgy teszed fel. De nekem ez a másik gép egy Mac-book volt, aminek hülyét kapok a billentyűzetétől, nem áll kézre.
Majd miután az első install-t szétcsesztem (secure boot beállítással, és hogy a Luks titkosításhoz a kulcsót TPM2-ből szedje) már a telepítővel (archinstall) húztam újra. Ez már simán olyan egyszerű, mint más disztribúció telepítője.
Végül arch alatt a secure boot bekapcsolása nagyon könnyű, az sbctl-t érdemes használni. Az nvidia driver is működik pöccre, és a deep sleep is. Csak itt meg úgy látom, hogy jobban járok a systemd-bootloaderrel, mint a grubbal, ez meg új nekem még.
Ha az Arch linux nem válik be valamiért (használat közben derül majd ki), akkor kipróbálgatok még párat, ahogy majd az időm engedi, a Debiant is megnézem majd, és az Alma linux is eszembe jutott már. (Alma linux helyett még Centos-t használtam korábban).
- A hozzászóláshoz be kell jelentkezni
nincs benne BTRFS
Nálam ez feature, nem bug :)
https://access.redhat.com/solutions/197643
Én desktop gépen még az xfs-t sem használom, maradok az ext4-nél. Az utóbbi időben nem ellenőriztem, hogy az xfs képességei változtak-e, de azok az extrák, amit nyújt, számomra nem szükségesek, viszont az ext4-nek azon tulajdonságai, hogy egyrészt a mérete csökkenthető is, másrészt online is át lehet méretezni, fontosak nekem.
Arch
Nem próbáltam még, de ehhez már öregnek érzem magam. Anno sokat használtam az LFS-t (Linux from Scratch), most inkább valami jobban összerakottat szeretnék. Az tagadhatatlan, hogy az Arch wiki-je páratlan.
jobban járok a systemd-bootloaderrel, mint a grubbal
Egyetértek!
Alma linux helyett még Centos-t használtam korábban
Céges környezetben a támogatott disztró(ka)t használom, de ha nincs megkötés, akkor valószínűleg én is Alma-t vagy Rocky-t választanék.
- A hozzászóláshoz be kell jelentkezni
Az Arch-ot szerintem még 60 éves koromban is fogom tudni használni. Attól eltekintve, hogy nincsenek grafikus csillvilli felületkék a csomagkezelésre, felrakod -> működik, kész.
Amit nyersz az Arch-csal, az az, hogy pl tudsz AUR-ból viszonylag könnyen pl régebbi nVidia drivert felrakni, és az egyetlen dolog, ami ilyenkor eltörik az a Steam csomag, mert valahogy direktben függ az nvidia drivertől (még nem jutottam el oda, hogy ráncba szedjem), amúgy megy minden.
Én egy viszonylag régi GTX 1660 Ti-jal használom, és annál bonyolultabbat sosem kellett csinálnom, mint adott csomagok felrakása/leszedése, hogy ezt a régi kártyát életrekeltsem.
Ráadásul az LTS kernel megadja a mindennapi stabilitást is, nincsenek meglepetések induláskor.
- A hozzászóláshoz be kell jelentkezni
Az arch linux most elég jónak tűnik nekem. Nem volt nehéz az indulás (korábban egy keveset már használtam is), az nvidia drivert egy mozdulat volt feltenni (pacman -S linux-headers, nvidia-dkms nvidia-utils). És a secure boot-tal sem volt probléma, így hogy a leírásban megnéztem azt a pár parancsot, amit használni kellett. (őszíntén, lehet, hogy egyszerűbb volt, mint Fedora alatt, ott szórakoztam egy csomót az nvidia driverrel)
Az lts kernelre azt olvastam, hogy ott inkább azt vállalják, hogy a security patch-eket tovább adják hozzá, de ugyanúgy eltörhet bármi telepítéskor. Így én a sima kernelt választottam. Unified kernelt tettem fel egyébként, nem tudom, hogy ennek lesz-e valami értelme.
Most úgy látom, hogy fogok tanulni az arch linux használatából. (pl systemd-boot-tal semmi tapasztalatom, meglátjuk, hogy kezelem a hibaszituációkat, stb...) De arra számítok, hogy lesz egy bejáratott munkamenet, és szépen elhasználgatom. Sőt, szívesen megismerkedek egyéb ablakkezelőkkel is, pl a hyprland, vagy qtiles (ha kézre áll már, akkor biztos, hogy hatékonyan tudom majd használni, és jobban fogom szeretni, mint a szokásos ablakkezelőket, amiket már elég sokat néztem. És így megvan a hobbizás élménye is, ha a gép elé ülök itthon. :)) )
Ha valami bosszantó, megkerülhetetlen dolog jön, vagy havonta eltörik valami telepítés után, akkor szerintem megyek tovább.
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy én is áttérek az ext4-re, a btrfs-t a snapshot-ok miatt tettem fel és a Fedora miatt, és megmaradt, mint szokás. De a desktop gépemen nem sok alkalommal csináltam snapshot-ot, és timeshift-et, vagy hasonló toolt sem használok.
ehhez már öregnek érzem magam.
Ha nem kell folyton időt tölteni vele, hanem lenne egy bejáratott mód, ahogy telepítem, használom, akkor én meg tudok barátkozni vele. Persze ebbe a random problémák egyre kevésbé férnek már bele, ahhoz én is öregnek érzem magam. :)
- A hozzászóláshoz be kell jelentkezni
Online átméretezni az XFS-t is lehet, de természetesen csak növelni.
- A hozzászóláshoz be kell jelentkezni
Hm, bocsánat, akkor ez az XFS-ben azóta jelenhetett meg, hogy legutóbb próbáltam. Illetve valamiért (tévesen) azt gondoltam, hogy az ext4 támogatja a zsugorítást felcsatolva is.
Ami még eszembe jutott: az XFS-ről régebben azt írták, hogy rosszabbul tűri a lecsatolás nélküli leállást (pl. áramszünet, kernel crash), mint az ext4. Lehet, hogy ma már ez sem igaz?
- A hozzászóláshoz be kell jelentkezni