- Samsung Galaxy Watch6 Classic - tekerd!
- Milyen okostelefont vegyek?
- Honor 200 Pro - mobilportré
- iPhone topik
- Megérkezett a Google Pixel 7 és 7 Pro
- Samsung Galaxy Watch7 - kötelező kör
- Mobil flották
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Google Pixel 9 Pro XL - hét szűk esztendő
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
-
-
wwenigma
Jómunkásember
válasz
wwenigma
#5997
üzenetére
Itt van egy friss log, elnezest de keptelen vagyok az uj szerkesztovel normalisan beilleszteni.
[pkgbuilder@HomeServer iwlwifi]$ makepkg clean
==> Making package: iwlwifi 2018.03.19.r0.g9f4ef1d70-1 (Thu 03 Oct 2019 02:30:42 PM CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
==> Extracting sources...
==> Starting prepare()...
Cloning into 'iwlwifi-fixes'...
remote: Counting objects: 66901, done
remote: Finding sources: 100% (66901/66901)
remote: Total 66901 (delta 5128), reused 23513 (delta 5128)
Receiving objects: 100% (66901/66901), 177.97 MiB | 3.62 MiB/s, done.
Resolving deltas: 100% (5128/5128), done.
Note: switching to '9f4ef1d70f05ebb7f0755545c05ea383be0eeb0f'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
Updating files: 100% (62911/62911), done.
HEAD is now at 9f4ef1d70 iwlwifi: mvm: Move unused phy's to a default channel
==> Starting pkgver()...
==> Starting build()...
make: Entering directory '/usr/lib/modules/5.3.1-arch1-1-ARCH/build'
CC [M] /home/pkgbuilder/iwlwifi/src/iwlwifi-fixes/drivers/net/wireless/intel/iwlwifi/dvm/main.o
CC [M] /home/pkgbuilder/iwlwifi/src/iwlwifi-fixes/drivers/net/wireless/intel/iwlwifi/dvm/rs.o
/home/pkgbuilder/iwlwifi/src/iwlwifi-fixes/drivers/net/wireless/intel/iwlwifi/dvm/rs.c: In function ‘rs_get_rate’:
/home/pkgbuilder/iwlwifi/src/iwlwifi-fixes/drivers/net/wireless/intel/iwlwifi/dvm/rs.c:2739:6: error: implicit declaration of function ‘rate_control_send_low’; did you mean ‘rate_control_set_rates’? [-Werror=implicit-function-declaration]
2739 | if (rate_control_send_low(sta, priv_sta, txrc))
| ^~~~~~~~~~~~~~~~~~~~~
| rate_control_set_rates
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:281: /home/pkgbuilder/iwlwifi/src/iwlwifi-fixes/drivers/net/wireless/intel/iwlwifi/dvm/rs.o] Error 1
make[1]: *** [scripts/Makefile.build:497: /home/pkgbuilder/iwlwifi/src/iwlwifi-fixes/drivers/net/wireless/intel/iwlwifi/dvm] Error 2
make: *** [Makefile:1624: _module_/home/pkgbuilder/iwlwifi/src/iwlwifi-fixes/drivers/net/wireless/intel/iwlwifi] Error 2
make: Leaving directory '/usr/lib/modules/5.3.1-arch1-1-ARCH/build'
==> ERROR: A failure occurred in build().
Aborting...
[pkgbuilder@HomeServer iwlwifi]$ -
-
_NCT
addikt
válasz
vargalex
#5993
üzenetére
Ezt próbáltam, sajnos nem oldotta meg. Egy egyszerű scripttel kiolvastam pacman.log fájlból hogy milyen verzióról mire történt a frissítés, és a -U kapcsoló használatával a cache-ből visszaraktam a régi csomagokat, de halott volt a dolog (segfault ugyanúgy).
Mondjuk tegnap Manjaro-val is szívtam, USB-s TPLINK adaptert használok, amely mindenféle USB descriptoros hibákat dobott. Aztán átdugtam egy másik USB portba és tökéletesen működött a rendszer. Egy USB hardverhiba okozhat ekkora galibát? Konkrétan nem működött az egerem, billentyűzetem sem...
-
_NCT
addikt
Köszi szépen a választ! Tegnap felcsesztem magam és váltottam Manjaro-ra, mert szeretnék Arch vonalon maradni, de annyira nem fontos, hogy mindig megkapjam a legújabb frissítéseket. A stabilitás fontosabb, kernelből is lts kell vmware miatt. Mondjuk az az én balf@szságom hogy nem vollt beütemezve backup legalább a root-ról.
-
Frawly
veterán
Ne aggódj, szerintem nálad is a most kijött Mesa 19.2.0 okozza a hibát. Nem az Arch hibája, a Mesa devek írták a szoftvert ilyen instabilra. Tudnak a hibákról, javítás alatt van, nemsokára várható a 19.2.1.
Nálam egyébként csak a Chromiummal van baj. A többi program teljesen jól megy, Firefox, mpv, játékok.
(#5990) eddie1978: Annál szerintem el fogod tudni kerülni ezt a hibát, mert hátrébb jár a verziókkal, így a Mesa csomag is régebbi benne. Mire meg elérnek az újabb verzióig, az már a javított 19.2.1 lesz. Egyébként jövő héten én is kipróbálom a CL-t, nagyon kíváncsi vagyok rá. Nem a stabilitására, hanem a sebességére.
-
_NCT
addikt
válasz
attilav2
#5988
üzenetére
Én kb 3 éve használom nagy megelégedéssel. Eddig nekem sem volt gond, de ez most nagyon ráállított a szopórollerre. Eddig wiki meg gugli segített, de ez a hiba rejtély. Megnyugodtam hogy nem csak nálam van ilyen probléma. A lényeg: nem KDE a probléma, lxde és xfce4 alatt is ugyanez van. Ahogyan a kolléga is pl XFCE-t használ.
-
_NCT
addikt
válasz
eddie1978
#5938
üzenetére
Szia! Nekem ugyanez van KDE alatt, frissítés után meghalt a grafikus felület, segfault és társai. Néztem journalctl segítségével, de nem jutottam előbbre, valami ksmserver dobott egy stack trace-t. Újrahúztam Arch-ot, frissítettem és egy idő után szintén ez volt ( nem tudom hogy vmware workstation-nek lehet-e köze hozzá, de azelőtt működött. Ryzen cpu-m van rx580 radeonnal. nem tudom hogy ezek okozhatják-e a problémát. LTS kernelt használok.
-
Shyciii
veterán
válasz
attilav2
#5984
üzenetére
Tényleg. De ez a fura, hogy anno mikor vaapis verziót raktam fel, illetőleg azt a vaapi-sat amit mindig valaki előre lefordított a hardveres gyorsítás miatt (1 verzióval szinte mindig el volt maradva), azzal nekem működött, mert olyan 17%-ot mutatott a CPU. Mostani tényleg ergya. 79% környékén megy full screen esetén. Szerencsére én notin nem videózom. Arra ott a tv + winyó
-
attilav2
őstag
Itt van egy kép a felgányolt ubuntus dev-chromiumról, így néz ki ha elérhető a hardveres video gyorsítás chromium alatt:
"Hardware-accelerated video decode" beállítás elérhető és be van kapcsolva.A sima chromium és a chromium-vaapi-bin csomagoknál a "Hardware-accelerated video decode" beállítás a chrome://flags fülön az unavailable részen tanyázik és be sem lehet kapcsolni
-
attilav2
őstag
válasz
Shyciii
#5979
üzenetére
_Nem működik_ sima chromium alatt a hardveres videógyorsítás, akármit is írjon a chrome://gpu alatt. A chrome://flags alatt az unavailable résznél van a hardware video decode, be se lehet kapcsolni. 1080P 60fps youtube videó 30-50% proci terhelés, szóval sima chromium alatt semmilyen videógyorsítás nincs. A chromium-vaapi-bin aur-os chromiumnál sincs vga gyorsítás. Aki gyorsítást akar az felgányolja az ubuntus dev-chromiumot ahogy fentebb írtam. Vagy lefordítja az aur-os chromium-dev csomagot csak győzze kivárni.
-
attilav2
őstag
Most húztam fel magam a Mate-n, totál bugos
Ezt Link a videót követve próbáltam a mate-t testreszabni, az aur-os mate-menu-t(Advanced mate menu) hozzá sem adta a tálcához hiába nyomkodtam a hozzáadást, sebaj felraktam a brisk menu-t is, hozzáadtam azt, de egy ki és bejelentkezés után totál üres tálca fogadott. Le is dúrtam a mate-t. Kde-vel komolyabb gondom még nem volt, marad az. -
Frawly
veterán
válasz
wwenigma
#5980
üzenetére
Ha az AUR-os nem megy fel, akkor esetleg valami debianos vagy ubuntus csomagból. Amúgy milyen hibát dob? Mert el lehet hárítani a fordítási hibákat is.
Egyébként az iwlwifi firmware-nek alapból benne kell lennie a linux-firmware csomagban, ami a base install része. Az AUR-os iwlwifi csak abban különbözik ettől, hogy gyakrabban frissül és hamarabb kerül bele az új verziós firmware.
-
wwenigma
Jómunkásember
Arch Linux alá az IWLWIFI csomagot hogy lehet megoldani hogy felmenjen? AUR-ból amit letöltök nem tudom leforditani mert hibaval kiesik, egy ideig tudom a fileokat mozgatni hogy meglegyen minden de utana mar szintaxishiba jön amivel nem tudok mit kezdeni....
Intel 9260NGW van átalakítóval berakva alaplapba, BT részét latja de WLAN részét egyáltalán nem. -
Shyciii
veterán
válasz
attilav2
#5978
üzenetére
Csak olyat találtam a flags alatt, hogy:
Override software rendering list - Enabled -en van (még anno én tettem át)
Accelerated 2D canvas - Enabled -en van. Ezt is én tettem anno.Nekem a gépben van egy integrált Intel HD Graphics 620 (ez van a hetedik generációs i3-akban), és van egy dedikált vga is: Nvidia Geforce MX130-as. De ez szinte biztos, hogy nem működik, mert a BumbleBee-t nem konfigoltam fel. Ha csak nem tudja már alapból a Linux, hogy maga kapcsolgassa az integrált és dedikált vga között, de kizártnak tartom, hogy ez a Linuxnak menne csípőből.
-
attilav2
őstag
válasz
Shyciii
#5977
üzenetére
Pontosan milyen vga-d van?
Ez lényeges, mertlinkeltem egy hivatalos Arch fórumos threadet valamelyik fentebbi hsz-ban ahol panaszkodnak hogy nem megy náluk a hw video gyorsítás sima chromiummal egyes intel, nvidia és amd vga-kkal. Ha megnézed a chrome://flags -ot akkor a hw accelerated video decode vagy vmi ilyesmi, enabled -en van? -
Shyciii
veterán
válasz
attilav2
#5970
üzenetére
Nekem simán az extra tárolóból felrakma a Chropmium-ot (most 77-esnél tart) szinte ugyanazt a beállításokat mutatja mint neked, csak a Rasterization software only. Minden más hardware. És nem csináltam semmit. Anno én is a vaapi-t használtam, de úgy rémlik, hogy azért szűnt meg, mert mintha írták volna, hogy belekerült a rendes változatba is, amit ő csinált. Azóta a sima alap verziót használom.
-
attilav2
őstag
Néztem htop-al a különbséget, firefoxnál ahol nincs hw videó gyorsítás 40-50% között terhelődtek a processzor magok youtube 1080P 60FPS videó lejátszásakor, chromium-dev -nél ugyanez a videó 15% prociterheléssel ment. Nálam fenn van mind firefoxban mind chromiumban a h264ify plugin, ez kényszeríti a youtubeot hogy h264-ben renderelje a videókat vp9 helyett. A vga-m csak h264 dekódolást támogat, de szoftveres dekódolásnál is jól jön a h264 ify, mert a legtöbb procinak jobban fekszik a h264 mint a vp9. Szerintem te is rakd fel a h264ify-t ha még nincs fenn.
-
Frawly
veterán
A kalandok folytatódnak. Most frissült a SwayWM, ugyanaz a verzió (1.2), de újabb build (-2 helyett már -3). Erre most már el sem indul a chromium bináris, azt mondja terminálban:
[863:863:0930/042000.321493:FATAL:memory_linux.cc(42)] Out of memory.
Trace/breakpoint trap (core dumped)Természetesen van elég memória, 14,5 GB szabad a 16 gigából, egy keveset eszik az IGP, meg 600 megát az egész Linux, kernel, systemd, SwayWM, Firefox több füllel. Szerintem még az IGP 1 gigás memóriájából is szabad vagy 900 mega.
Szerk.: az Arch bugtrackere is hozza már, más is jelentette 23 órája. Állítólag a Mesa 19.2 okozza, ahogy már sejtettem, de szerintem nem csak az, mert azzal nekem legalább elindult, ha tearingelt is. A Sway frissítése tett be neki végleg.
-
Frawly
veterán
válasz
attilav2
#5973
üzenetére
Az a proci kihajtja szoftverrenderben is az 1080p-t, de talán még a 4K-t is. De mindenképp megéri hardveres dekódolást használni, mert nem melegszik feleslegesen a proci, nem zúgatja a ventiket, kevésbé eszi az akkut.
Archon az AUR lenne arra való, hogy forduljon a dev verzió, csak nem build szerveren fordul, hanem a saját gépeden. Az a gáz, hogy nincs belőle nem patchelt verzió.
-
attilav2
őstag
Igazából a kíváncsiság vezérelt hogyha felrakom az ubuntu alá forgatott chromium-dev verziót akkor működni fog e a hardveres videó gyorsítás, mert kubuntun a chromium-dev -el simán megy, és ahogy sejtettem arch-on is simán megy a videógyorsítás chromium-dev verzióval. Nomeg az ubuntus chromium-dev felrakásával fordítási időt is akartam spórolni, mert van ugyan az aur-ban chromium-dev de csak forrásból lehet feltenni, chromium fordításra meg horror időket írnak a neten ilyen alap procikkal ami egy átlagembernek van.
Egyébként meg az X4 860K, de gondolom a legtöbb mai alap proci is csak kihajtja rendesen vga nélkül is az 1080P-t, a 860K kihajtja, szóval nekem felesleges lett volna dev-chromium felrakásával bíbelődnöm de hajtott a kíváncsiság. A linuxos firefoxban sincs hw videó gyorsítás, elvileg mostanában rakják majd bele. Ha neked is elmegy az 1080p youtube cpu-ból akkor felesleges dev chromiummal bíbelődnöd szerintem. De ha kíváncsi vagy hogy nálad is működik e a hw videó gyorsítás akkor hajrá!
Arch-on ezzel a patchelt aur-os chromium-vaapi-bin -el van a gond, hogy a patchet nem megfelelően alkalmazzák nem aktualizálják az aktuális mesa-nak megfelelően, és az arch fórum topikban amit linkeltem ezt szóvá is tették. Az kellene itt is mint ubuntun, kellene egy build szerver amin mindig lefordulnak a legújabb chromium-dev buildek, ezt az arch közösség szerintem meg tudná finanszírozni.
-
Frawly
veterán
válasz
attilav2
#5970
üzenetére
Egyáltalán nem gányolás, szépen megoldottad újraforgatás nélkül. Gondolkodok rajta, hogy én is felteszem. Csak nincs kedvem szórakozni vele. Várok még pár napot, hátha egy frissítés helyreteszi a Chromiumot, ha nem, akkor törlöm a gépről, és helyette befogok egy másodlagos Firefox profilt inkább.
Nálam azért van 2 böngésző is fent, mert tematikusan használom. A Firefox a fő böngésző, a Chromium a másodlagos, amit csak szórakozásra, videózásra, stb. használok, hogy ne egy böngészőben legyen 500 fül megnyitva, hanem témák szerint szétszedem két böngészőre, így legalább több böngészővel is lesz tapasztalatom. De ha a Chromium ilyen bugos marad, akkor dobni fogom szemrebbenés nélkül. Egyébként sem a kedvencem, fájni nem fog érte a szívem.
Ugyebár a bug, ami nálam van, az abszolút a Chromium hibája. Még azzal sem jöhetnek, hogy túl új a Mesa, mert a 19.2-es ágat már hónapok óta tesztelték egy csomóan bétaként, majd RC-kként, sőt, jó ideje végleges kiadásban is, az csak az archosok lustasága, hogy Archra még csak most ért el. A Wayland és Sway WM sem lehet oka, mert az meg rég nem frissült, meg a többi alkamazással jó. Ez megint tipikus Google fejlesztési minőség. Utálom ezeket a multikat, csak bullshitelni tudnak, meg divattrendkedni és bloatosítani, de mikor normális dolgot kéne letenni az asztalra, akkor az már nem megy, helyette van a fetrengés, meg lázas bugfoltozás.
-
attilav2
őstag
Ezt a két csomagot
chromium-browser_78.0.3902.4-0ubuntu1~ppa3~19.10.1_amd64.deb
chromium-codecs-ffmpeg-extra_78.0.3902.4-0ubuntu1~ppa3~19.10.1_amd64.deb
kell letölteni innen: https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-dev/+packagesAmikor megnyitjuk a deb csomagokat az Ark-al akkor fogunk találni bennük egy data.tar.xz -t, ha megnyitjuk akkor akkor egy etc és egy usr mappát találunk benne, csomagoljuk ki az etc tartalmát az /etc -be az usr tartalmát az /usr -be
A dev chromium máris indítható a chromium-browser paranccsal. De érdmes paraméterekkel indítani különben youtube-on nézhetetlen lesz a kép hardveres gyorsítással(ez alapból be van kapcsolva ebben a buildben).
Így indítsuk: allow_rgb10_configs=false chromium-browser --enable-gpu-rasterization --ignore-gpu-blacklist --disable-gpu-driver-workaroundsAz allow_rgb_10_configs=false változó nagyon fontos mert enélkül szar lesz a kép youtube-on.
-
attilav2
őstag
Talán chromium-dev csomaggal megoldódna a videó és egyéb gyorsítás, viszont ott meg nem működik a google fiókkal szinkronizálás, de ez legyen a legkisebb gond.
Csak kellene csinálni egy bináris csomagot valakinek rendszeresen, kellene egy build szerver amin automatikusan fordulnak a chromium-dev csomagok arch-ra. -
Frawly
veterán
válasz
attilav2
#5966
üzenetére
Az hagyján, hogy az nem működik, de Archon a Chromium legújabb frissítése eltörte a hardveresen gyorsított kirajzolást, tearingel videók alatt.
Hiába lövöm be a szükséges dolgokat chrome://flags és chrome://gpu oldalon, hogy használjon GL renderinget, hiába kényszerítem a Chromiumra az --ignore-gpu-blacklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers --enable-zero-copy flageket az Arch Wiki alapján, akkor sem jó, a chrome://gpu oldalon azt írja, hogy:
Problems Detected
GPU process was unable to boot: GPU access is disabled due to frequent crashes.
Disabled Features: allEsetleg a Waylanddel vagy a Sway WM-mel nem fér össze. mpv és Firefox alatt jó a lejátszás, van gyorsítás, nem tearingelnek a videók.
Esetleg még a Mesa csomagra gyanakszok, pár napja frissült 19.1.x-ről 19.2-re. Lehet ez is az oka, de eléggé idegesít, hogy nem működik. Nálam Intel HD3000 GPU van, amit az i915 kernel driver hajtana.
-
attilav2
őstag
Nem működik nálam a hardveres gyorsítás a chromium-vaapi-bin aur csomagos chromiummal, Radeon 6670-nel. Valami gond van a csomaggal mert az Arch fórumban vitatkoznak róla:
Link
Régen még működött a hardveres videógyorsítás nálam ezzel a csomaggal, mostmár nem Akármit csinálok.
Vaapi működik rendesen:
[attilav@Attilav-PC ~]$ vainfo
vainfo: VA-API version: 1.5 (libva 2.5.0)
vainfo: Driver version: Mesa Gallium driver 19.1.7 for AMD TURKS (DRM 2.50.0 / 5.3.1-arch1-1-ARCH, LLVM 8.0.1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264High : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProcAmit az Arch fórumban írnak aszerint a gallium platformot is érinti a probléma. Szomorú vagyok
Kubuntu alatt bezzeg működik a vga gyorsítás, ha felrakom a chromium dev branch ppa-ról a dev chromiumot. Kicsit csalódtam az Arch-ban. Az arch fórumos threadben liewkj javasolt egy patchet amivel a hiba javítható lenne, de vagy nem akarja alkalmazni a fejlesztő vagy nem reagál.Próbáltam aur-ból chromium-dev verziót forgatni, abban a reményben ha Kubuntu alatt megy vele a gyorsítás akkor Arch-on is működni fog, el is kezdtem, de a rákerestem a google-ba a fordítási időre és ilyen 7-13 órákat írnak, úgyhogy meg is szakítottam a fordítást. Kubuntu-ra van bináris chromium-dev csomag, Arch-ra nincs
Nincs valami izmos procim ilyen nagy fordításhoz, csak egy X4 860k-m -
attilav2
őstag
Na túlestem rajta megvolt a windows újratelepítése EFI módban (természetesen leválasztottam minden linuxos efi-s meghajtót a windows telepítése idejére, ahogy a fentebb linkelt leírás is említi:
"You can copy the "/EFI/Microsoft" folder from the EFI partition on the Windows drive into the EFI partition of your Arch drive. The systemd-boot loader will then automatically add an entry for Windows to its menu.
That new menu entry will start Microsoft's boot loader. Inside that "Microsoft" folder you copied, that loader will have all files it needs to be able to boot the Windows that's on the other drive.
This idea requires that you have two EFI partitions, one on each drive. To make this happen, you have to disconnect the Arch drive while you install Windows. The Windows installer will then create a new EFI partition on that drive."
Az UEFI módú windows telepítés létrehoz egy rakat partíciót, de linux alatt az fdisk -l megmondja melyik a windows efi partíció. Ennek felcsatolása és a /EFI/Microsoft könyvtár átmásolása az Arch-os lemezre a /boot/EFI/Microsoft helyre, egy újraindítás és már ott is van a systemd bootloader menüjében a windows, és szépen el is indítja a windowst a másik lemezről. Nem kell a windowsos lemezen a windowsos bootloaderrel szenvedni hogy az töltse be a linuxot, ez a megoldás sokkal elegánsabb.
Az windows driver aláírásellenőrzését is sikerült kikapcsolni a "bcdedit /set nointegritychecks on" paranccsal, így a tunerkártya drivere sem problémázik uefi módban, a leírást itt láttam:
Link
Persze linux alatt simán működik a tunerkártya uefi módban mindenféle driver aláírásellenőrzés nélkül, ez a linux egyik előnye. Csak minden kernelfrissítéskor újra kell forgatnom a driverét, ami elég sokáig tart, mert teljes v4l tree-t is forgat.(https://github.com/tbsdtv/linux_media/wiki) működő dkms megoldás még nincs a TBS6221-hez. a Tbs-ecp-dkms driver az aur-ból amit ajánlanak nem támogatja ezt a kártyát sajnos. -
Frawly
veterán
válasz
attilav2
#5963
üzenetére
A Windows nem tud systemd boottal indulni, mivel nem tartalmaz systemd-t. De egy épp olyan .EFI fájllal indul, mint amilyen a systemd bootnak is van, tehát megférnek egymás mellett, két külön EFI fájl, két külön bootloader, az UEFI BIOS bootkor mindkettőt megtalálja. Még a loader.conf-ba is be tudja magát írni a Windows (ilyenkor az Arch boot menüjében is látszik, anélkül hogy belemennél az UEFI BIOS bootmenüjébe), de ez továbbra sem jelenti azt, hogy systemd boottal indulna.
-
attilav2
őstag
Összeszedtem minden angol tudásom és találtam egy reddit szálat ami már azt boncolgatja amit én akarok:
Dual-boot Arch and Windows on separate drives with systemd-boot?
Elovastam, amit itt írnak az tűnik működőképes megoldásnak. -
Frawly
veterán
válasz
attilav2
#5960
üzenetére
Ezt elég könnyű. Windows az nem systemd boottal indul, hanem a saját .EFI fájlait teszi be az EFI partícióra, de ez a systemd bootot nem zavarja. Pont ez az UEFI boot lényege, hogy sok OS .EFI loadere elfér ugyanazon az EFI partíción, és nem írogatják egymást felül, mint Legacy BIOS bootnál az MBR-ben. Szóval nyugodtan telepítsd újra a Windowst, az Arch systemd bootot nem fogja bántani.
Sőt, Windows UEFI bootos telepítésekor van több opciód is. Az egyik, hogy a linuxos meghajtó EFI partíciójára teszi az indítófájlait. A másik, hogy annak a meghajtónak az EFI partíciójára, amelyiken a Windows lesz. Mindkettő simán kell hogy működjön.
-
attilav2
őstag
Na találtam is valamit Windows systemd-boot ügyben.
Link
itt thomasamadeusking hozzászólását kell nézni.
Kreálni kell egy új entry fájlt a /boot/loader/entries alá, pl /boot/loader/entries/windows.conf
Ennek a tartalma meg:
title Windows
efi /EFI/Microsoft/Boot/bootmgfw.efiEhhez meg nyilván létre kell hozni a /EFI/Microsoft/Boot könyvtárakat a linuxos lemez efi partícióján, aztán a windowsos lemez efi partíciójáról be kell másolni a bootmgfw.efi-t a linuxos lemez efi partíciójának /EFI/Microsoft/Boot könyvtárába.
Elméletileg így már indítható is a windows a linuxos lemezről, de csak elméletileg. Mert ugyan biztos lefut a windows efi alkalmazás de mivel másik diszkről indul, nem fogja megtalálni a windows rendszerpartícióját. Persze aztán lehet hogy megtalálja és betölt a windows, de murphy törvénye alapján inkább nem
Update: Illetve nem is kell ennyi marcera, a bootmgfw.efi fájlt egyszerűen bele kell rakni egy tetszőleges könyvtárba a linuxos lemez efi partícióján és aztán meghivatkozni a (boot)/loader/entries/windows.conf fájlban.Arch systemd-boot wikiben is van utalás erre a megoldásra, még ha nem is szó szerint:
Még meg kell ezt gondolnom, mert már telepítettem efi módban a windows10-et, és a tunerkártya drivere nem szerette, aláíratlannak(érvénytelen aláírás) mutatta magát és letiltotta a windows, az aláírásellenőrzést ugyan macerásan de ki lehet kapcsolni(nekem nem sikerült állandóra csak egy egy alkalomra, ennek is utána kell nézni), de még kékhalálozott is asszem. Ugyanez a driver mbr módú windowson persze megy normálisan.
További probléma még ezzel a boot megoldással hogy a linuxos lemezen a bootmgfw.efi -t manuálisan kell frissítgetni, egy egy nagyobb windows frissítés után bizonyára nem árt megtenni. Kérdés ha nem frissítgetem akkor sok sok update múlva is indul e így a windows.
-
attilav2
őstag
Gondolkodom rajta hogy a windowst is újrarakjam e uefi módba, de csak akkor ha a systemd-boot -ba könnyen bekonfigurálható hogy elindítsa a windowst is, azaz legyen egy boot entry a windowsnak is. A nehézséget az jelenti hogy a windows másik lemezen van, de ha uefi-s lenne az a lemez is, akkor valahogy csak meg lehetne hivatkozni a systemd-boot konfigban. Csak kellene valami leírás.
-
Frawly
veterán
válasz
attilav2
#5957
üzenetére
Megoldódott vele a konzol háttérszíne? El lehet lenni azért Legacy boottal is, de érdemesebb az UEFI bootra rámenni. Egyes gépeken meggyorsíthatja a booteszközök megtalálását, meg kényelmesebb több OS-nél.
Engem meg legutóbb az Arch a light nevű csomaggal ×0patott meg. Már van fél éve használom, de egy hónapja kitalálta, hogy nem ment a fényerőállítás. Utánaolvasva meg is találtam a megoldást, hogy a jogosultságprobléma, nincs jogom a /sys/class/backlight/intel_backlight/brightness írására, és nem elég átállítani chmod-dal, mivel bootkor nullázza magát, hanem udev szabályt kell rá csinálni. Meg is tettem, wheel csoport tulajdonába tette az udev szabály, meg adott neki a csoportra nézve írási jogot. Reboot, nem jó, nincs jogom írni. Anyád. Utánaolvasva találtam egy másik udev példaszabályt, ami a video csoportot használja, megpróbáltam ezt is, mert a felhasználóm tagja ennek a csoportnak. Így sem ment. Terminálban udev szabály nélkül kiadtam megint a chown-t a wheel csoportnak, majd chmod g+w, majd az udev szabályban is visszaírtam a wheel csoportra (csak a video stringet kellett megint átírni wheel-re). Reboot után jó lett. De amit nem értek, hogy mindjárt először is így próbáltam, akkor miért nem működött? Elég X-Akta.
-
attilav2
őstag
Na rászántam magam, újra raktam uefi/gpt módban az "éles" Arch telepítésemet a 480Gb-os ssd-men, systemd-boot -al. Kevesebb ideig tartott mint gondoltam. Sokat gyakoroltam virtuális gépben ezért mehetett gyorsabban. Eddig MBR-es volt, de szokni kell az UEFI-t mert ez a jövő
-
attilav2
őstag
Igen, sajnos a radeon 6670-el nem fér össze valamiért az arch konzol, google kidobott pár arch-os találatot erre de megoldás nincs
Sajnos a mikrokód betöltése sem szünteti meg a hibát, néhány alkalommal fekete ahogy kell a konzol, de kikapcs és másnapi bekapcs után szürke konzollal indít megint. Különösen telepítéskor kellemetlen, nem jó a szemnek Feltelepített rendszeren nem annyira zavaró már. Ez a hiba azthiszem a display managerre is hat, ha feltelepítek valamilyet, sddm-et próbáltam régebben, mert kde hez ezt ajánlják, akkor elég sűrűn elhasalt a DM, le kellett szedjem mert nem tudtam vele bejelentkezni, el sem indult vagy összeomlott. De ugyanaz a DM kubuntunál rendesen működik ezen a vason.... -
attilav2
őstag
Találkoztatok már olyannal hogy amikor bebootoljátok az Arch telepítőt akkor a konzol háttere szürke színű? Ez a telepített rendszernél is így van, szürke hátterű konzollal tölt be az esetek 99%-ában. A grafikus felület rendben indul startx-re (Display managert nem használok). Miután kilépek az X-ből akkor normális fekete hátterű konzolt kapok. Most feltettem és betöltöttem az amd-ucode -ot, ez úgytűnik megoldani látszik a hibát(de nem akarom elkiabálni), legalábbis egyelőre, de csak a telepített rendszernél. Azt hogy tudom elérni hogy a telepítő _ne_szürke_ konzollal bootoljon? Vga és a proci is amd, ott van az aláírásomban.
-
Dévacsen
senior tag
válasz
eddie1978
#5938
üzenetére
Nálam is volt valami hasonló,igaz manjaro mate alatt,pár napja volt egy frissítés 600 mb körüli csomag,utána hasonló jelenségek játszódtak le a gépen,firefox keresősávban magától mozgó folyamatos szaggatott vonal rajzolódott ki,ez megjelent a programok közt is a keresőben folyamatosan futott..meg egyéb anomáliák,nem tudtam megállapítani mi okozhatta frissítettem újabb és régebbi kernelre is,átvizsgáltattam egy kaspersky rescue disk el,nem talált semmit.egyelőre leszedtem most olvasgatok hogy másnál is volt e valami..
-
Frawly
veterán
válasz
attilav2
#5951
üzenetére
Már el is küldtem privátban, ott válaszoltam. De valahová leírtam ezt ebbe a topikba is, mikor csixy csinálgatta magának a multibootos lemezeit. Neki sikerült a leírás alapján, sőt, annyira belejött ebbe a GRUB nélküli UEFI systemd bootba, hogy a végén vagy 9-10 disztró is bootolt neki ugyanezzel a módszerrel, az Arch systemd EFI loadere töltögette be mindet .conf fájl alapján. Szóval nem nehéz ez, csak rá kell jönni hogyan működik.
A legtöbb leírás feleslegesen ragaszkodik a GRUB-hoz, ez még Legacy BIOS MBR-es beidegződés, reflex.
-
attilav2
őstag
válasz
vargalex
#5947
üzenetére
Írhatnál egy systemd-boot konfiguráló shell szkriptet Arch-hoz, ami bekéri a partíciót
és már nyomja is bele a konfigba az uuid-jét. Illetve telepíti a systemd boot-ot a megfelelő(bekért) paraméterekkel. Amit most írtál azt shell szkriptként elmentem, hogy ne kelljen beírni, mert úgyis elrontom
-
vargalex
félisten
válasz
attilav2
#5945
üzenetére
EFI esetén valóban a legegyszerűbb a systemd-boot használata. Évek óta azt használom, nincs gondom vele.
Nem kell kézzel bepötyögni, berakhatod egyetlen paranccsal:echo "options root=PARTUUID=$(blkid | grep sda2 | sed 's/\(.*\)PARTUUID="\(.*\)"$/\2/') rw" >> /boot/loader/entries/arch.confTermészeteesen itt az sda2 a megfelelő partíció számával helyettesítendő. De magát a root partíciót megadhatod labellel, vagy akár device-val is.
-
attilav2
őstag
Uefi Systemd-boot beállítására van olyan megoldás ahol nem kell disk UUID-eket körmölgetni?
Most kísérletezgetek a uefi módú arch telepítéssel, a grub uefi módja egyelőre szimpatikus, különösen hogy nem kell lemezazonosítókat körmölgetni telepítés közben, amikor se egér se vágólap nincsen.
Ezt a leírást követtem: https://averagelinuxuser.com/a-step-by-step-arch-linux-installation-guide/# a startup.nsh készítés kivételével, mert az csak virtualboxhoz kell. Az itt leírt grub uefi telepítési paramétereket ha megtoldom még egy --removable kapcsolóval akkor bios reset vagy lemez eltávolítás visszadugás után is indítható az UEFI Grub-os Arch. Csak ha --removable kapcsolóval telepítem akkor nem veszi figyelembe a bootloader-id paraméterben megadott nevet, egyszerűen UEFI-OS néven jelenik meg az alaplap boot menüjében. -
válasz
vargalex
#5936
üzenetére
Köszi!
Akkor rosszul tudtam.
Teljesen gyári kernelem van.
Próbáltam a wiki szerint csinálni, de nálam nincs olyan sor, hogy "works!", amikor futtatom a turn_off_gpu.sh-t. Ez a gond.vinibali: Nálam Gigabyte lapon csak az van, hogy "Init display first"; IGP, PCI-E, vagy auto.
Eredetileg PCI-E-n volt, de a másik kettőt is kipróbáltam, semmi változás nem történt. -
eddie1978
senior tag
Xfce
Valami miatt pár napja egy idő után szétesik a grafikus felület. Eltűnik a tálca. Bekapcsoló gomb megnyomására nem kikapcsol a gép, beállítás szerint azt kellene csinálnia, hanem feldobja az ablakot, ahol lehet választani a kikapcsolást. Viszont csak négyzetek vannak a karakterek helyén. Ugyanez van Chrome-ban is. Illetve itt még tapasztaltam olyat is, hogy címsorba elkezdek gépelni és nem a webcímet dobja fel, hanem egy karakterhalmazt. US locale-t hagytam a telepítéskor és később az Xfce-ben állítottam be a UK és HU beállítást. Lövésem sincsen mi lehet ez. Ilyenkor teljesen szétesik a grafikus felület. -
vinibali
őstag
a laptopok esetén azért teljesen más a felállás, mert van egy muxed/muxless switch.
én egy ideje már - nagy szerencsémre - Asus lapokat használok, és idáig (FM1->FM2->FM2+->AM4) mindegyiken volt egy IGFX Multi-monitor support opció a BIOS-ban. talán azzal lenne még érdemes játszani, mindamellett ez teljesen másképpen műküdik végeredményben Linux és Windows alatt.
viszont az igényed nagyon egyedi, talán az AMDGPU display core-ral lenne érdemes valamit nézelődni. -
Frawly
veterán
BIOS-t próbálj meg frissíteni, lehet úgy az új BIOS ténylegesen is le tudja kapcsolni a kívánt GPU-t. Nagyon más ötletem már nincs.
Az acpi-call-dkms-nél konkrétan arra gondoltam, hogy a hozzá való kernelmodullal együtt. Arch alapú disztrókon elvileg AUR-ban van, és kernelmodullal együtt települ.
-
Frawly
veterán
Hú, ez tényleg húzósabb, mint gondoltam. Minden oldal ezt az acpi-call-t írja, amit az Arch Wiki is. Esetleg acpi call dkms?
Akkor könnyebb lenne, ha két különböző gyártójú GPU lenne. De így, hogy mindkettő AMD és mindkettőt az amdgpu kerneldriver hajtja, így kiesik a kernelparaméteres letiltogatás, hiszen ha letiltod, akkor egyikkel sem lesz kép.
-
Frawly
veterán
Ezt kernelparaméterrel lehet elérni, a bootloaderben megadod a kernel mögött a vonatkozó paramétert, hogy az IGP-t használja. De ehhez tudni kéne, hogy pontosan milyen IGP-ről van szó.
Szintén kernelparamétereknél le lehet tiltani a dGPU-t is. Ehhez megint tudni kéne, hogy pontosan milyen GPU-ról van szó.
-
Sziasztok!
Van az asztali gépemben IGP és dGPU is.
Két problémám van ezzel:
1.) Jelenleg a dGPU az elsődleges kimenet a login folyamat végéig, vagyis vakon kell begépelnem a jelszót, és még azt sem látom, hogy mikor jelent meg a login képernyő. Monitort nem akarok rá kötni, lényegtelen okokból.
A BIOS-ban már átállítottam az "init display first" opciót IGP-re, de semmi hatás.2.) Az IGP-n nincs 3D gyorsítás, vagy ha van is, az olyan lassú, hogy a böngésző is néha több percre beragad. Gyanítom, hogy a Mesa a CPU-ra tol minden grafikai feladatot. Ha áthúzom az ablakot a másik képernyőre és épp van rajta monitor, akkor ott minden jó.
Két dolgot szeretnék megcsinálni:
a.) Az IGP legyen az elsődleges legkésőbb a login képernyő betöltődésekor.
b.) Szintén a login képernyő elött a dVGA-t valahogy teljesen ki kellene kapcsolnom (teljes poweroff), de az Arch wikiben leírt módszer nem megy. Nem talál sehol kompatibilis eszközt a shell script, pedig mindent úgy csináltam, ahol le van írva (100%). Nincs "worked" sor. (szerintem ez a script csak laptop-okra van tervezve)Ha a fenti kettő egyszerre nem megy, akkor mindkét grafikus eszközön legyen működő 3D gyorsítás, és benyelem a dVGA készenléti fogyasztását.
Valamelyikre van ötletetek?
Előre köszi!
-
attilav2
őstag
válasz
attilav2
#5927
üzenetére
Keresgéltem a "Kde stuck on splash screen"-re és egy találat azt javasolta hogy a kompozitor beállítások körül nézzek szét. Kikapcsoltam a kompozitort, és újraindítottam a kde-t, megszűnt a probléma, majd visszakapcsoltam a kompozitort és próbáltam indítani így is, ekkor is késlekedés nélkül betöltött. X akta
-
attilav2
őstag
Beleütköztem egy Kde plasma indítási problémába.
Szokatlanul hosszan kinn marad a Kde splash screen, utána betölt megjelenik az asztal, de a tálca csak később jelenik meg.
Mit tudok tenni hogy tudom ezt debugolni? Teljes újratelepítés a megoldás? Nem szivesen raknám újra mert ez egy belakott jól bekonfigurált rendszer. -
Frawly
veterán
Mielőtt valaki jönne, hogy rövid időn belül már a második frissítés problémás Archon, annak azért elmondanék előre pár dolgot:
1) Ez a két érintett csomag elég ritkán használt. A tensorflow egy gépi tanuláshoz való valami (nem sokan foglalkoznak vele), az astyle forráskód formázáshoz (amit azért nem használnak sokan, mert azt a fejlesztői IDE-k is automatice megcsinálják). Tehát egyszeri Gipsz Jakab átlagfelhasználó általában ezeknél nem is érintett egyáltalán. Általában azért is szoktak ezek ritkán használt csomagnál előfordulni, mert azok ritkábban frissülnek és ilyenkor nagyobb közöttük a verzióbeli ugrál általában.
2) Az ilyen figyelmeztetéseket legtöbbször már maga a pacman is kiírja, elismételve a hírt, arra az esetre, ha valaki nem követi az Arch oldalát.
3) Általában ezek könnyen megoldhatók. Ha a hírre nem is figyelmeztet a pacman (de szokott), hanem csak pl. azt írja ki, hogy blabla already exists, akkor azt a bizonyos fájlt, symlinket csak el kell távolítani sudo rm-mel vagy pacman --overwrite-tal felülírni. Ha azt írja, hogy package conflict, akkor a vonatkozó csomagot el kell távolítani sudo pacman -R kapcsolóval, az új megfelelő csomag meg be lesz húzva függőségként Szóval a megoldás általában valami pofon egyszerű valami, nem kell hozzá feltétlenül az archlinux.org hírszekcióját követni árgus szemekkel.
4) Évente jó ha 1-2 ilyen van. Általában az is valami apróbb-cseprőbb csomag. Jelentősebb szopó frissítésnél Archon akkor volt, mikor systemd-re álltak át, de az minden disztrónál szopó volt. Azóta csak ilyen apró, könnyen megoldható manual intervention-ök vannak nagy ritkán már évek óta.
-
BoB
Topikgazda
-
Frawly
veterán
Ezt egy kicsit bővebben kifejtem, mert nem érthető.
Tehát az SSD-ket ún. lapméret alapján szokták alignálni. Az SSD-n a NAND cellák NAND lapokba vannak rendeződve. De egy darab cellát nem lehet írni/olvasni (az SSD vezérlője nem képes rá), hanem csak egy egész NAND lapot (akkor is, ha csak 1 cellát érint majd a módosítás, olvasás). Ez a lapméret jellemzően 4KB volt a régi SLC-MLC-s SSD-ket, egy ideig még a TLC-seken is, de a modern 3D NAND-on már általában 16 KB vagy még több.
Emiatt a legtöbb particionálóprogi 1024K eltolással particionál, mert az maradék nélkül osztható 4K-s, 8K-s, 16K-s, 32K-s, ..., 512K-s, 1024K-s lapmérettel is, megfelelve a jövőbeni SSD-k igényének is.
Na most itt ebben a topikban valaki német fórumok javaslata alapján felvetette, hogy egy még nagyobb egység, a blokkméret alapján kéne alingálni. Ugyanis a NAND lapok egy még nagyobb egységbe, ún. blokkban is kezelhetők, ennek törléskor, trimeléskor van előnye. A blokkméret általában elég nagy, ilyen több MB-os, SSD-nként eltérő, modern 3D NAND-okon magasabb, mint korábbi 2D-seken, ilyen 6-30 MB nagyjából. Tehát egy blokkban ~1000-es nagyságrendű lap van.
De itt jön a logikai bukfenc. A fájlrendszerek által kezelt logikai szektorok 0,5-4K-sak jellemzően, ez meg is felel, maradék nélkül osztható a 4-16K-s lapmérettel, és az 1024K alignálással, mert így a lemezműveletek nem lógnak át laphatárokon. De tegyük fel, hogy nem blokkméret alapján vannak alignálva a partíciók. Ekkor a partíciók első és utolsó pár szoktora, fizikai lapja átlóghat blokkhatárokon, de ez csak ezt a pár szektort, lapot érinti. De a közöttük lévő szektorokat nem, mert azoknak a lapmérete/szektormérete maradék nélkül osztható a blokkmérettel, így nem lesz olyan köztes lap/szektor, ami blokkhatárokon nyúlna át.
Vegyük például az én átlagos felhasználásomat. Egy régi 3D TLC-s SSD-m van, 16 KB-os lapmérettel, 24 MB-os blokkmérettel (1 blokkban 1536 NAND lap van), és 4KB clusterméretes ext4 partíciókat használok rajta, 512 bájtos logikai szektormérettel. A partíciók 1024K-n vannak alignálva. Ez azt jelenti, hogy a partícióim első 23 megabájtja (1472 lapja vagy 5888 logikai klusztere vagy 47104 logikai szektora) átlóg blokkhatárokon. Az ezek után lévő többi szektor, lap nem lóghat át blokkhatáron, ami a tárterület 99,99%-át jelenti.
A gyakorlatban tehát ezzel annyit bukok, hogy ezeknek a szektoroknak a törlése lassabb egy nagyon minimálisan, talán már ez sem mérhető. De mi annak az esélye, hogy pont az ezekre eső blokkot érinti a törlés? Nagyon minimális. Szóval a gyakorlatban nincs semmi értelme blokkméret alapján alignálni, felesleges önszopatás. Nem nagy áldozat, mert maximum 23 MB veszteséggel járna az első partíció előtt a kihasználatlan terület, de nekem pl. nem tetszene, hogy emiatt nem feltétlenül lennének egész GB-tal osztható partícióméreteim. Ez utóbbi akkor jön jól, ha szétcsesződne a partíciós tábla (bár GPT-n ilyenkor van belőle több másolat), könnyű rekonstruálni a partíciós táblát.
Persze továbbra sem lehetetlen, mert csinálhatnám úgy, hogy partícióméretek ne csak 1 GB-tal, hanem 24 GB-tal legyenek oszthatóak (pl. az első partíció 48 gigás, a második 240, a harmadik 480, stb.), de ez felesleges matek, meg helypocsékolás az első partíció előtt. Ez ilyen tipikus német precízkedés, hogy 0,00000001% előnyért szopjuk, hogy elméletileg is maximálizáljuk a lehetőségeket. Nehogy egy krumlihéjnyi valami is pocséka menjen.
Arról nem is szólva, hogy az adott SSD blokkmérete elég nehezen deríthető ki adott esetben. Az SSD gyártók fel sem tüntetik, hanem be kell azonosítani a NAND típusát (ha ezt sem találni meg online, akkor szét kell szedni az SSD-t, vagy leszedni róla az M.2 matricát, ami azonnali garivesztés, és megnézni milyen NAND van rajta), majd a NAND gyártójának valami részletes technikai spec sheetjéből nyomozható ki. Tényleg nem éri meg vele szívni.
-
-
Frawly
veterán
válasz
Siriusb
#5921
üzenetére
SSD-s körökben szokták használni, nem a térdemből szoptam. Ahogy a particionálást sem fordítják le, sokan az alignálást sem magyarítják le még jobban partícióeltolásnak. Ja, tudom, újmagyar, a grammar nazikat lehet zavarni fogja, majd szednek nyugtatót. Felírja nekik az orvos, klaviatúrán, majd kinyomtatja a printeren. Vihetik utána a receptet az apotékába szkennelésre.
-
Frawly
veterán
Ezt még nem volt időm tesztelni, mármint a blokkméret alapján történő alignálást, de már előre rájöttem, hogy hülyeség lesz.
Tegyük fel, hogy nincsenek blokkméret alapján alignálva a partíciók. Ez csak a partíciók első és utolsó blokkját befolyásolja lényegében. Ez pedig kevés ahhoz, hogy sebességbeli hátrányt vagy élettartamnövekedést hozzon.
Nem véletlen, hogy csak ilyen ködös német fórumok írnak erről a blokkméret mentén alignálásról, és ehelyett midenki a sztenderd 1 megás partícióeltolást használja, amit a particionálóprogik és telepítők alapból alkalmaznak.
Persze ki fogom próbálni, mert nem kerül semmibe, de már előre látom, hogy nincs értelme, nem javít majd semmin. Nem is egy nagy áldozat, csak felesleges.
-
-
Sziasztok!
Canoscan LiDe 300 scannert vettem, de a sane nem ismeri fel.
Az Arch wiki ezen oldalán minden idevágó módosítást megtettem, de csak nem ismeri fel.$ sane-find-scanner
# sane-find-scanner will now attempt to detect your scanner. If the
# result is different from what you expected, first make sure your
# scanner is powered up and properly connected to your computer.
# No SCSI scanners found. If you expected something different, make sure that
# you have loaded a kernel SCSI driver for your SCSI adapter.
# Also you need support for SCSI Generic (sg) in your operating system.
# If using Linux, try "modprobe sg".
found USB scanner (vendor=0x04a9 [Canon], product=0x1913 [LiDE 300]) at libusb:003:003
# Your USB scanner was (probably) detected. It may or may not be supported by
# SANE. Try scanimage -L and read the backend's manpage.
# Not checking for parallel port scanners.
# Most Scanners connected to the parallel port or other proprietary ports
# can't be detected by this program.
$ scanimage -L
No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).Bármi ötletetek van?
-
eddie1978
senior tag
válasz
vinibali
#5913
üzenetére
Annyival nem. Talan meg itt Arch alatt a legjobb a helyzet a video vagas teren. Win alatt meg rosszabb. Ugy latom, hogy ez a gep nem erre valo. Keves a DellE7270 ehhez. Marad a jol bevalt Arch. Talaltam egy jol megirt telepitesi leirast systemd efi bootra. Ebbol linkel a teljes telepitest bemutato cikkre. Nekem ez egyertelmubb volt mint az Arch wiki.
Win alatt nem szamoltam mennyi figyeljuk es gyujtjuk az infot rolad jovahagyast kellett elfogadni vagy visszautasitani a telepites soran. Egy oprendszer ne gyujtson semmi adatot reklamozas celbol.
Arch marad. Nem is ertem milyen elmebaj miatt probaltam ki mast. Nekem ez megfelel. -
vinibali
őstag
válasz
eddie1978
#5912
üzenetére
szerintem annyival nem gyorsabb az a nagyon sok Intelre optimalizált csomag, hogy megérje.
de szerintem az valamelyik linux-ck-{broadwell,haswell,ivy...} kernelt megpróbálhatod(#5910) Frawly: nyilván nem Debian initrd és Arch vmlinuz párossal próbálkoztam, mert szerintem akkor is el kellett volna indulnia valamilyen boot folyamatnak, de itt úgy dob vissza, az image-ek betöltése után, mintha kértem volna tőle.
-
-
vinibali
őstag
PXE-boottal próbálkozott valaki?
OpenWrt routeren fut - tftp és http alapon - a fájlok megosztása, Debianos 50MB körüli netboot.tar.gz maga a tökély, de Arch alapon még a memtest sem indul el.
látszólag sikeresen átmegy a fájl a router és a kliens között, de mégsem történik semmi.Sat Aug 10 16:26:17 2019 daemon.info dnsmasq-tftp[8545]: sent /mnt/sda3/tftp/boot/memtest to 192.168.1.238
ugyan ez az eset, ha kernel és initrd fájlokat címzek meg. átmennek, majd mintha mi sem történt volna, újra beugrik a syslinux indítója azonnal. -
#5905
Siriusb
veterán
SteveBeard
#5903
Siriusb
veterán
válasz
SteveBeard
#5903
üzenetére
A hibaüzenetre a megoldás pedig az. Valószínű lesz más függőség is.
Ha kényelmesebben akarod megoldani, először telepíts egy AUR wrapper-t, például pikaur és az kezelni fogja a függőségeket is. -
#5904
vargalex
félisten
SteveBeard
#5903
vargalex
félisten
válasz
SteveBeard
#5903
üzenetére
Nézd meg, hogy hol keresi a wget-et. Lehet, hogy csak nem jó helyen...
-
#5903
SteveBeard
senior tag
SteveBeard
senior tag
Sziasztok!
Bocs a buta kérdésért, de ha ezzel az üzenettel találkozom, akkor mi a teendőm.
Build dependency: Please install GNU 'wget'A wget-et már telepítettem, de eszerint az nem elég.
-
Shyciii
veterán
Valakinek van ötlete, hogy miért lehet az, hogy bár zsh-t használok (oh-my-zsh), akkor miért lehet az, hogy a .zlogin filera nem reagál ha beleírok egy scriptet, hogy elinduljon, mikor console-ból lépek be, míg ha a .bash_profile -ba írom, akkor elindul, pedig ugye a shell-t átváltottam már rég zsh-ra. Igazából nem zavar, hogy a bash-nek a konfigjába kell írni, csak a miértje érdekelne.
Új hozzászólás Aktív témák
Hirdetés
- Telefon felvásárlás!! Apple Watch Series 9/Apple Watch Ultra/Apple Watch Ultra 2
- REFURBISHED - DELL Thunderbolt Dock WD19TBS docking station (210-AZBV)
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS!Gigabyte B650M R7 7800X3D 64GB DDR5 1TB SSD RTX 3080Ti 12GB Corsair 4000D Airflow TG 750W
- Lenovo ThinkCentre M910q Mini PC / i7 7gen/8GB RAM/240GB M2 SSD/12 hónap jótállással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest