- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Milyen TV-t vegyek?
- TCL LCD és LED TV-k
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Gaming notebook topik
- Újabb "merénylő" érkezett a Thermalright megbízásából
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Amazon Kindle
- Milyen házat vegyek?
- Autós kamerák
Hirdetés
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Készülőben az Apple TV alkalmazás Androidra
ma Android rendszerű táblagépeken és telefonokon is elérhető lesz hamarosan az Apple saját streaming szolgáltatása.
-
Szilárdtest-akkumulátorokat fejleszt Kína, jöhet az áttörés?
it 830 millió dollárnak megfelelő összeget költ a szilárdtest-akkumulátorok fejlesztésére Kína a jelentések alapján.
-
PROHARDVER!
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
csixy
addikt
válasz Frawly #67050 üzenetére
Már megint az antergos mániám mondatja, hogy az se rossz és telepítéskor tolható vele a friss kernel alá párhuzamosan egy LTS kernel is és utána azt is csereberélgeti és ha bekcrahol a friss kernel, akkor be lehet bootolni az LTS kernellel.
Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.
-
ubyegon2
nagyúr
válasz Frawly #67049 üzenetére
Ja, tudom én, de így együtt az
együgyű
meg aszellemileg gyenge
jelző kicsit erős a nem Arch vonalat használók minősítésére, főleg ha új érdeklődők olvassák! Még szerencse, hogy többnyire én vagyok ledorongolva Tg által, hogy finomabban fogalmazzak az érzékenyebb lelkületűek miatt.
Mostantól viszont minimum hasonló jelzők használatára vagyok feljogosulva a nagyarchúak irányába. Ha nektek belefér, akkor hajrá!(#67050) Frawly
Mikor változott meg az archklónokról a véleményed? Eddig nagyon nem dicsérted ezeket.
[ Szerkesztve ]
-
Slownz
senior tag
Sziasztok!
Újabban (néhány napja) azt csinálja a Firefox, hogy, amikor kattintással akarok új ablakot megnyitni (jobb klikk, new window), akkor nem ugrik fel egyből az oldal, hanem jön egy notification, hogy "Firefox is ready", miután arra rákattintok, csak akkor dobja be. Érdekes, hogyha gyorsbillentyűvel csinálom (CTRL + N), akkor nem produkálja ezt. Hogyan tudnám beállítani, hogy alapból megnyissa? Idegesítő
Más programmal nem észleltem hasonlót.
Manjaro
DE: GnomeKöszi!
-
#68216320
törölt tag
Segítséget szeretnék kérni.
Ubuntu 18.04 esetében hogyan lehetne kideríteni, hogy mi okozza azt az esetek ~70%-ban, hogy amikor leállítanám a gépet ~30-40mp ideig semmi nem történik és csak azután indul el a leállítás?
Iszonyat bosszantó egy 6600K@4500MHz/16GB@3000MHz/SSD512GB/GTX1050TI társaságában a dolog. -
ubyegon2
nagyúr
válasz #68216320 #67054 üzenetére
journalctl -b -1 | curl -F 'f:1=<-' ix.io
Ez csinál egy linket a terminalba, a végén látod a leállítást, ha minden OK.
(#67053) Slownz
Az valami spéci FF nálad, vagy egérbeállítás, mert a sima jobbgombos menüben nincs is ilyen opció. Több disztróban megnéztem.
[ Szerkesztve ]
-
ubyegon2
nagyúr
válasz Slownz #67057 üzenetére
Ja így érted! Sajna Gnome-om nincs jó ideje, Cinnamonon hasonló a Panel indítók Applet, de itt működik az új lap jobb gombra, érdekes, ha nálad nem akar megnyitni új Firefoxot, mert már van nyitva egy. Gondolom frissült a Gnome mostanában, így abban bízhatsz, hogy javítják az applet bugot.
Én üres lapokat nem nyitok, csak középső gombbal linkre kattal nyitok új lapot, de ez nem üres. -
Frawly
veterán
válasz Slownz #67053 üzenetére
Ez nekem Firefox bugnak tűnik, ilyet akkor szokott csinálni, ha már össze van kuszálódva FF alatt a profil. Próbáld meg a Firefoxot Safe Mode-ban újraindani (Súgó menü, Firefox indítása addonok nélkül menüpont). Ha úgy jó, akkor hozz létre új Firefox profilt, firefox -P kapcsolóval indítod, ekkor előjön a profilmenedzser, ebben csinálsz új profilt, amit firefox -p profilnév formában írsz meg, ezt átállítod a parancsikonoknál, hogy ez induljon el. De úgy is lehet, hogy a régi profilt törlöd (könyvjelzők, jelszavak, beállítások elvesznek), akkor automatikusan az új profilt fogja betölteni.
-
ubyegon2
nagyúr
válasz IO.sys #67063 üzenetére
Ha félévente akarsz frissíteni egy disztrót, akkor tényleg rolling kell neked?
Fél év utáni frissítésnél már azért előfordulhat összeomlás, nekem sem omlott össze hetek utáni frissítés után sem, de olvastam már ilyet is.A rolling előnye a folyamatos frissülő csomagokban lenne, csak megemlítem. Csak a hype miatt is rakhatsz fel nem LTS-t persze.
(csak belevauztam)
[ Szerkesztve ]
-
IO.sys
őstag
válasz ubyegon2 #67065 üzenetére
Jó, én még abban a világban nevelkedtem, amikor a linux egyet jelentett a stabilitással. A frissítés utáni rendszerösszeomlás windows szint. Erre magától nem számít az ember. Azért akarom kipróbálni, hogy lássak ilyet is. A backup szerver megfelelő erre. Van olyan, hogy hónapokig nem jut eszembe ránézni. Ha összerogyik, meglesz a kellő tapasztalat.
凸_(ツ)_/¯ // -Valamit kiírt a gép!... -Az a dolga!...
-
ubyegon2
nagyúr
Rollingnál eldöntheted, hogy akarsz-e frissíteni a legújabbra vagy nem.
Most megfogtál ezzel, mert kb százezerszer írták le Archosok, hogy rollingnál nincsenek kiadások....vagy most mire gondolsz? A csomagokra? Szerintem LTS-nél ugyanúgy a felhasználó dönti el, hogy frissít-e vagy nem.
Azt nem véleményezem, hogy valaki azért rak fel rollingot, hogy soha ne frissítse.
(#67066) IO.sys
Nincs már ilyen, DE, WM, millió megjelenítéshez szükséges ez+az, xorg/wayland, sysvinit/systemd..... főleg amikor keverednek! (ja meg persze rolling, hogy azonnal kapjam a frissítéseket, mert belepusztulok, ha féléves csomaggal kell égetnem magam....)
Ezek nélküli alap még azért lehet stabil.[ Szerkesztve ]
-
CPT.Pirk
Jómunkásember
válasz ubyegon2 #67068 üzenetére
Szójáték, mindig a stabil tárolóban lévő aktuális verziót érti(k) alatta. Nyilván célszerű viszonylag sűrűn frissíteni, de nekem is van egy olyan laptopom, amit kb. évente 1x frissítek mert akkor jutok oda, de ettől még elvan rajta a Chakra, maximum ha történt valami kézi beavatkozást igénylő művelet az eltelt időben, akkor azt is meg kell csinálni.
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
kovaax
őstag
válasz ubyegon2 #67065 üzenetére
Legalább 2 percet gondolkodtam ezen, és két frissítési forma lehet így hirtelen:
1. A tárolóban ott van minden verziója a csomagnak:
csomag-v1
csomag-v2
csomag-v3
csomag-v4
Ebben az esetben a frissítés mindig történhet így: csomag-v1 -> csomag-v2 -> csomag-v3 -> csomag-v4
Így akármennyi időt is hagyunk ki, mindig jónak kéne lennie a frissítésnek.2. A tárolóban csak az utolsó verzió van ott (feltételezve, hogy a gépen a csomag-v1 van fent):
csomag-v4
Ebben az esetben már nem biztos, hogy menni fog a csomag-v1 -> csomag-v4 frissítés.De lehet a kettő mixelve: a tárolóban a legfrisebb csomag van csak, de a csomagban benne van a legfrissebb binárisokon kívül az összes tennivaló valami őseredeti verzióhoz képest, és mindig onnan kezdi végrehajtani őket, amelyik verzió fent van a gépen (értelem szerűen). Ennek is működnie kéne, ha jól van megcsinálva.
Szerk.: Mindamellett, hogy sosem upgradelek, hanem újrahúzom az egész rendszert. Még pontosabban, felhúzom előbb tesztnek, ott végigszüttyögöm az összes változást, hogy mi az ami engem érint, és hogy tegyem rajta túl magam, és ezt addig tolom, míg készen nincs a Végleges Install Dokumentáció, és az alapján rakom fel a friss verziót élesbe.
Szerk.: Nagy verzión belül persze megy az update.[ Szerkesztve ]
-=- There's no place like /home -=-
-
Rimuru
veterán
válasz kovaax #67070 üzenetére
Ugyanúgy eltörhet a v1->v2 mint a v1->v4, változtatásoktól függ.
Másik eset amikor a csomagoló változtat valamit verzió függetlenül.Lehet sokáig hallgatni a frissítést, csak el kell olvasni mik változtak, milyen manual changek kellenek és ezek szerint haladni.
Vigyázat, csalok!
-
Frawly
veterán
válasz IO.sys #67063 üzenetére
Össze bármikor bármi összerogyhat. Bármilyen gépen, bármilyen disztró, az LTS-ek is. Garancia nincs semmire. Akkor sem, ha milliókért vesznek a szerverre Windows Server + kliensekhez licencet, az MS sem garantál semmit, nem vállal felelősséget semmiért, persze a zsozsót szívesen felmarkolja, de utána mossák kezeiket.
Nem kötelező frissíteni, de ha nagyon sokáig nem frissítesz:
1) megnő a frissítésből származó hiba lehetősége, mivel több frissítési fázis marad ki, amik hatással lehettek volna egymásra, hiszen a frissítéseket alapvetően úgy tesztelik, hogy az előző csomagverzióra telepítik rá, de ha neked még 3-7-tel azelőtti verzióra települ, előjöhetnek gubancok. Nem azt mondom, hogy gondok fognak jelentkezni, de az esélyét megnöveled így.
2) elveszti az értelmét, hogy rolling disztrót használsz.Emiatt azt javaslom, hogy azért próbálj belőni egy értelmes időt, kb. 2 hónap, esetleg kicsit hosszabb, talán 6 hónapból sem lesz baj. Egzakt válasz nem is létezik rá, hogy milyen hosszú az az idő, ami után már gáz frissíteni. Függ attól is, hogy hány csomag van telepítve, mik azok a csomagok, mennyire gyakran adnak ki hozzájuk frissítést, mi fut a szerveren, mennyi időnként lehet leállítani, mikor megengedett a kiesés. De pl. évente frissíteni rollingnál már neccesnek hangzik, nem azt mondom, hogy baj lenne belőle, de annál én mindenképp gyakrabban frissítenék.
Nem szabad félni a frissítéstől, konzolon egy parancs, gyorsan lemegy. A rollingnak pont az a lényege, hogy egyszerre mindig csak kevés csomag frissül (minél rendszeresebben frissítesz, annál kevesebb csomag egyszerre), szinte észrevétlenül, apránként cserélődnek ki a rendszerkomponensek, nem egy nagy disztrófrissítés van, amikor az összes csomag frissül, és a teljes káosz lehet belőle. Pont ezért, ha rollingon el is törik valami, fogod látni milyen frissítések voltak az utolsóak, és csak 1-2 érintett csomagot kell helyretenni, és nem az egész rendszer áll be, mint a szög, hogy csak nézel, hogy még bootolni sem bootol a kóceráj vagy semmi sem működik. Tekintsd úgy a rollingot, hogy óvatosan, csomagonként tudsz frissíteni, mindig csak 1 lábujjat betenni a hideg vízbe.
Úgy sose szabad semmihez hozzáállni, hogy jajj, el fog törni, nem merek frissíteni, mert azzal teszed összességében a legrosszabbat, hosszú távon annál károsabb nincs, bizonyítja is az eseted, amiből kiindultunk, hogy a túl régi rendszert már nem tudtad rendesen frissíteni. Annál tényleg rosszabb nem létezik, mint hogy bebetonozod magad valami teljesen elavult verzióba, végtelenségig halogatod a frissítést, így a rendszer még ha fut is, egy ponttól csak a szívás lesz vele vagy időzített bomba lesz.
Azok a régi mantrák, amik szerint „Ami nem működik, azt nem kell megjavítani” vagy „az 1000 éves uptime mindenható” már rég nem tarthatók. 10 éve még lehet igaz volt, mikor még az volt egy gyakorlat, hogy 10 évig is ki lehetett húzni egy OS-sel, és a frissítések is kisebb számúak voltak. Ma már viszont annyira jönnek mennek hardveres/szoftveres sérülékenységek, foltok, frissítések, hogy nem lehet addig futni hagyni valamit egy verzión, amíg a vas ki nem rohad alóla, vagyis lehetséges, de elég nagy felelőtlenség.
-
Frawly
veterán
válasz Rimuru #67071 üzenetére
Abban igazad van, hogy a v1-v2 és a v1-v4 váltás is eltörhet, de abban nem értek egyet, hogy a kettőnek az esélye pontosan megegyezik.
Pl. a v4 csomag feltételez egy olyan beállítást, konfigfájlt, libet, fájlnevet, amit a v3-as verzió hozott be. De te meg v1-v2-re nyomatod fel, aminél még semmi nyoma nem volt. Pont ez a poén, hogy a csomagfenntartó teszteli a csomagot, de csak úgy, hogy v3-ra telepíti, így nála ez a hiba nem jön ki. Lehet, hogy előrelátó a csomagoló, és teszteli v1-re telepítve is, vagy körültekintőbben csomagolja a fájlokat, kalibrálja a post install scripteket, nem feltételez túl sokat, de ebben sose lehet biztosra menni.
Vagy pl. mikor v1-v2 csomagnak még A-nak hívják a függőségét csomagnév szerint, de aztán ezt átnevezik B-re, amire a v3-as csomag fel is lesz készítve erre. De mikor a v4-eset akarnád telepíteni, az meg csak nézni fog, hogy a B függőség nincs fent, az A-ról meg még hírből sem hallott.
Persze a másik véglet is problémás lehet, mikor valaki 5 percenként frissít. Ilyenkor meg bele lehet futni valami elrontott csomagba, amit amúgy 1-2 nap alatt javítanának, de hamarabb frissítettük. Bár a két véglet között inkább a túl gyakori frissítés a jobbik, mint a túl ritka.
Elvileg erre ki lehetne találni, hogy a csomagkezelő kezelje ezt, és az érintett csomagokat kis lépésekben, inkrementálisan frissítse, azaz az v1-et előbb v3-ra (mert a v2 kihagyható a példánknál), majd a v3-at v4-re, és nem mindjárt a v1-et v4-re. De ez eléggé megbonyolítaná a frissítést, Arch-vonalon nincs is ilyen.
[ Szerkesztve ]
-
CPT.Pirk
Jómunkásember
Linus Tech Tips - [Microsoft Should be VERY Afraid - Noob's Guide to Linux Gaming]
Jó kis videó a Steam, Steamplay - proton és a Lutris használatáról, Manjaro-n és Pop! on bemutatva, szóban érintve az Ubuntut.
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
IO.sys
őstag
válasz Frawly #67072 üzenetére
Köszönöm! Nemtom nekem ha nagy disztróm lenne, az lenne a belépő, hogy frissítésbiztos kell legyen. Az én idealizált világomban akkor van kész egy csomagkezelő, ha kezeli a verzióösszeférhetetlenségeket. Addig csak félkész, alfa verzió. Felteszem az Archot (ha sikerül), de be van izzítva a Debian is vész esetére.
Igazából egyedül Sambát kell tudnia, más nincs. A foltozások miatt fogott meg ez a rolling buli, eddig is frissítettem a szervereket emiatt.凸_(ツ)_/¯ // -Valamit kiírt a gép!... -Az a dolga!...
-
Frawly
veterán
válasz IO.sys #67079 üzenetére
A csomagkezelő kezeli a verziófüggőségeket. Amit írtam, az bizonyos verziófüggőség átugrása a frissítési folyamatban, ez szoros értelemben véve nem is klasszikus verziófüggőség. Ezt, amit példának hoztam, egyik csomagkezelő sem kezeli tudtommal, Debianon az apt sem. Egyedül kiadás alapú disztrókon van egy olyan védelem, hogy frissíteni disztrót csak kiadások között tudsz, inkrementálisan, azaz pl. Debian 7-et nem frissíthetsz azonnal 9-re vagy 10-re, így nincs az, hogy verziót ugranál át. De ez nem a debianosok előrelátása, hanem a kiadás alapú disztrók filozófiájából ered. Rollingon ilyen nincs, eleve mindig is esélyes volt, hogy köztes verziókat ugrálsz át.
Azt meg már írtam, hogy frissítésbiztos OS, vagy úgy általában szoftver NEM létezik. Egyik platformon sem. Mindegy, hogy ingyenes, fizetős, mennyire használ új verziókat, támogatott vagy nem, rolling vagy kiadás alapú, mekkora cég adja ki, mennyire alapos tesztelés után. Mindenben előfordulhatnak frissítési bugok, de még ezeket is jobb bevállalni, mint egy rendszert teljesen elhanyagolni, és nem frissíteni egyáltalán. Hiába a régi, bevált verziók használata, meg az alapos tesztelés, soha semmi nem lehet 100%-ban bugmentes, a frissítés sem.
De ha annyira paranoid van, létezik megoldás. A szerverről csinálsz működő mentést, ennek úgyis kell lennie. Ezt beröffented egy másik vason vagy virtuális gépen, és először frissíted ezt a tesztrendszert. Lehet cifrázni ezt a technikát, hogy tárolóból is sajátot klónozol, amiben csak azok a csomagok lesznek benne, amiket ki is teszteltél előtte a hivatalos tárolókból, majd a szervert már csak erről a saját tárolóból engeded frissíteni. Körülményes, de sok cég csinálja, még Windowson is. Sőt, már az XP-s időkben is láttam ilyen céget, amelyik így csinálta, hogy a rendszerüzemeltetők előbb tesztelték a frissítéseket (pedig akkoriban az XP-s frissítések jóval bugmentesek voltak mint a mostani, hulladék Win10-esek), nem csak azt, hogy rendszerkomponenssel nem akad, de azt is tesztelték, hogy a cégnél használt meg házon belül fejlesztett programoknál nem tör-e el valamit. Majd a tesztelt frissítéseket belső WU szerverre tolták ki, és az egész céges infrastruktúra csak innen frissített. Melós, de biztosra lehet vele menni.
A biztonsági foltokat nem csak a rolling disztrók kapják meg. A kiadás alapúak is elég gyorsan kitolják, ha más nem, régi csomagba visszaportolva.
[ Szerkesztve ]
-
Frawly
veterán
válasz IO.sys #67081 üzenetére
Akkor mégse azt csinálod, ami le van írva, az Arrch Wiki-hez képest kihagytál pár lépést.
Az első, ahogy ott is írják, meggyőződsz, hogy egyáltalán látja-e az lspci -v az adott kártyát. Ha látja, akkor az lsmod vagy dmesg segítségével megnézed, hogy van-e hozzá betöltve driver. Ezen a ponton kiderülhet, hogy nincs, mert nincs hozzá driver, vagy a kártyához olyan spéci firmware van, amit nem tartalmaz az Archon egyébként a base részeként automatikusan felkerülő linux-fimware csomag. Nem nagyon fordul ilyen elő, de elméletileg megeshet. Ehhez tudni kéne a kártya pontos típusát.
Ha van hozzá driver is betöltve (Debian Wiki szokta írni, hogy az adott hálókártyához milyen driver való, milyen kernelmodulnak és firmware-nek kéne lennie hozzá betöltve), akkor mész tovább a következő lépésre, „ip a” parancs, megnézed látszik-e az interface, mi a pontos neve. Lehet látszik az, csak nem eth0, ahogy Debianon.
Aztán az is lehet, hogy az interface is jó, csak hálózatkezelő szolgáltatás nem fut, ami DHCP-t hívna. DHCP nem csak ahhoz kell hogy dinamikus címet kapjon, hanem a statikus címhez is be kell konfigurálni.
Szerverre lehet felesleges is a Network Manager, bár azzal a legkönnyebb bekonfigolni mindent (nmtui), és sudo systemctl enable NetworkManager && sudo systemctl start NetworkManager kiadásával indulhat a móka. A netctl kevésbé bloatabb, de azt hegeszteni kell, nyomatod be neki sorban:
sudo nano /etc/netctl/interface-névA fájl tartalma, az IP-ket aktualizáld:
Description='A basic static ethernet connection'
Interface=interface-név
Connection=ethernet
IP=static
Address=('192.168.1.102/24')
Gateway=('192.168.1.1')
DNS=('8.8.8.8' '8.8.4.4')Majd:
sudo netctl enable interface-név
sudo netctl start interface-névAz még egyszerűbb megoldás, ha a statikus IP a router DHCP beállításai között fixálod le az adott MAC cím felé. Így hiába a DHCP-vel lekért cím, a DHCP mindig ugyanazt a címet fogja neki osztani. A dhcpcd-t is kell konfigurálni, ha nincs se Network Manger, se netctl, ilyenkor:
sudo nano /etc/dhcpcd.conf# define static profile
profile static_eth
static ip_address=192.168.1.23/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1# fallback to static profile on interface-név
interface interface-név
fallback static_ethEgy újraindítás, és a dhcpcd automatikusan indul a systemd-vel, be fogja tölteni az /etc/-ből a konfigot, lefut, beállít, lekér IP-t.
Ez a szép az Archban, sokféle megoldás játszik, egyre minimalistábbak is, egyikhez sem vagy kötve gyárilag (egyedül a systemd-hez). De ha még nagyon új vagy a témában, és máshogy nem sikerül, látszik az interface, jó a driver/firmware, akkor a NetworkManagerrel tutira lehet menni.
-
-
#89874944
törölt tag
Sziasztok!
Egy Lenovo ideapad 330 15-ARR laptopra szeretnék a Linux Mint 19.1-hez wifi drivert felrakni. A gyártó oldalán csak win10 driver van
A win10-re ezt adják. Lehet ilyet szerezni Mint-re is?
RTL8821CE_2024.0.2.101&NFA435A_12.0.0.725
-
CPT.Pirk
Jómunkásember
válasz #89874944 #67086 üzenetére
Most egyáltalán nincs működő wifid? Mostani Ubuntu és Mint verziókkal nem találtam wifi problémát a googleben.
Mit mond az lspci kimenete, milyen wifi van a gépben? A Mint volt frissítve?
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
#89874944
törölt tag
válasz CPT.Pirk #67087 üzenetére
A hálózati beállítások csak vezetékest lát. Semmi wifit.
Elvileg RTL8821CE van a gépben.
lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15d0
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 15d1
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge
00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 15d3
00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 15d3
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 15db
00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 15dc
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15e8
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15e9
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ea
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15eb
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ec
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ed
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ee
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ef
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega [Radeon Vega 8 Mobile] (rev c5)
03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 15de
03:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 15df
03:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15e0
03:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15e1
03:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Device 15e3
04:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 61)[ Szerkesztve ]
-
#89874944
törölt tag
válasz Rimuru #67091 üzenetére
unblocked.
Találtam egy fórumot, már másnak is volt ezzel a géppel és a linux minttel baja: [link]
~$ rfkill
ID TYPE DEVICE SOFT HARD
0 wlan ideapad_wlan unblocked unblocked
1 bluetooth ideapad_bluetooth unblocked unblocked
2 bluetooth hci0 unblocked unblocked[ Szerkesztve ]
-
CPT.Pirk
Jómunkásember
válasz #89874944 #67092 üzenetére
Ha az a dmesg üzenet van nálad is mint a srácnál, akkor a biosban a secure boot kikapcsolása lesz a megoldás. A jelek szerint az a modul nincs vagy nem jól van digitálisan aláírva.
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
jackal79
aktív tag
Sziasztok!
Nem biztos, hogy jó topic-ba írok, de már régóta foglalkoztat a kérdés. Ha dual boot-ra van telepítve egy rendszer, akkor rendszer futtatáskor nem fog a teljes memória rendelkezésre állni? Gondolom, hogy a másik rendszer foglal le belőle, vagy rosszul gondolom?
Köszi a választ! -
CPT.Pirk
Jómunkásember
válasz jackal79 #67096 üzenetére
A ram az felejtő memória.
Újraindításkor, áramszünetkor szépen törlődik minden benne egy pillanat alatt, de ha nem így lenne se történne semmi, mert az elinduló oprendszer minden esetben üres tárhelynek kezeli és elkezdi feltölteni adatokkal a boot során. Valamint szerencsétlen oprendszernek csak arról van fogalma, hogy ő mit hova tett a memóriában. Ha lenne is benne valami maradék, nem lenne mi szerint értelmezni az ott lévő dolgokat, csak egy halom értelmetlen bit lenne.A Windows hybrid sleep hülyesége kivétel ez alól egyedül, de azt meg úgy is ki kell kapcsolni dualboot rendszernél mert különben csak szívni fogsz, ezzel most nem érdemes foglalkozni.
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
Frawly
veterán
válasz #89874944 #67088 üzenetére
Persze, hogy nem látja. A RTL8821-eshez nincs driver a kernelben. A linux header csomagot kell feltenni, le kell tölteni az rtlwifi kódját, és saját kernelmodult kell hozzá forgatni, majd azt használni. Elég szopós móka. Ha érdekel, leírom Mintre lépésenként. Esetleg ha találni hozzá valami külső PPA tárolót, amin már úgy van fent kernelmodulként, hogy le van fordítva. De még ilyenkor is szopás lehet használni, mert ha pl. frissül a kernel, akkor a kernelmodul nem biztos, hogy működni fog tovább.
Ú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!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen