UEFI-määritysten mukaan firmiksen ei kuuluisi välittää isojen/pienten kirjainten eroista, mutta jotkut UEFI-toteutukset ovat mokanneet tässä kohdassa.
Itsellä ainakin kaikki 7.1.2021 julkaistut versiot toimii 5.10.7 kernelin kanssa, eli 460.32.03, 450.102.04 ja 390.141 toimii. Myös 340.108 toimii pätchättynä.
Niin loppujen lopuksi vielä siirryin 5.9.16 (EOL) kernel versioon takaisin (monista syistä johtuen, omassa käytössä havaittuja juttuja), piti vielä asentaa NVIDIA ajurit uudestaan kun ilmeisesti 5.11 RC3 sääti jotain ylimäärästä eikä palautunut takaisin. Katsotaan nyt milloin omassa käytössä uskaltaa siirtyä takaisin uudempaan "stable" 5.10 kernel versioon, mutta ei ole mikään kiire.
Oliko tämä siis epäonnistuneen bootin dmesg?
Kyllä, tuo dmesg oli epäonnistuneen bootin. Menenpä tästä käynnistelemään konetta uudelleen, saattaa mennä 1 bootti, saattaa mennä 20
Noniin, 8 bootin jälkeen sain sen rikki taas. En tajunnut siinä vaiheessa, että tuossa ekassa komennossa tarkoitit varmaan /usr/bin/xorg, mutta tuon Xorg.0.login sain talteen. Voin kyllä senkin kaivaa esiin, jos tästä ei ole hyötyä.
Olisikohan jonkinlainen ajurisotku? Äkkiseltään näyttäisi dmesgin perusteella että kernelissä on ladattu Nvidian proprietary binaariajuri mutta Xorg.0.logissa ei näy kuin nouveau, joka ei saa DRM laitetta avattua (tuon proprietaryajurin vuoksi ehkä?) ja lopulta käytetään fallbackina framebufferia.
Komento voi Linux Mintissä olla myös "journalctl -e _COMM=Xorg.bin" tms. mutta Xorg.0.log:ista oli siis tässäkin kyse, tietyt distrot ei vaan enää näitä logeja levylle erillisinä tiedostoina kirjoita. Tosiaan virhe viittaisi juurikin siihen, mitä Barbarossa edellisessä viestissä kertoi, tämän voi toki vielä verifioida, vaikka seuraavalla komennolla onnistuneen ja epäonnistuneen bootin jälkeen:
Toimiva:
[09:09] user@PC:~$ lsmod | grep -e nvidia -e nouveau
nvidia_uvm 983040 0
nvidia_drm 57344 3
nvidia_modeset 1224704 5 nvidia_drm
nvidia 34037760 194 nvidia_uvm,nvidia_modeset
drm_kms_helper 184320 1 nvidia_drm
drm 491520 6 drm_kms_helper,nvidia_drm
i2c_nvidia_gpu 16384 0
Rikki:
[09:22] user@PC:~$ lsmod | grep -e nvidia -e nouveau
nvidia_uvm 983040 0
nvidia_drm 57344 0
nvidia_modeset 1224704 1 nvidia_drm
nvidia 34037760 2 nvidia_uvm,nvidia_modeset
drm_kms_helper 184320 1 nvidia_drm
drm 491520 3 drm_kms_helper,nvidia_drm
i2c_nvidia_gpu 16384 0Tämä vahvisti tämän ajurisotkun vääräksi, koska molemmissa tapauksissa NVIDIA on ladattuna, eikä nouveau.
Kokeile disabloida secure boot kokonaan.
Tehty tuo disablointikin vaikeaksi, erään opasvideon mukaan "Clear secure boot keys" pitäisi disabloida Sercure bootin, eikä selkeää enable/disable -valintaa ole, mutta itsellä se vain vaihtoi Staten userista setuppiin, ei disabled niin kuin videossa. Tämä ei ainakaan vikaan auttanut.
Ihan mielenkiinnosta, miltäs Xorg.0.log näyttää silloin kun kaikki toimii?
Tommonen ohje tuli googlella, itsellä ei Asuksen emoa niin en pysty tsekkaamaan:
In order to disable boot on z 390 ASUS motherboard on my TUF Gaming Plus Wi-Fi set one has to go to firmware> Advanced. From advanced to secure boot and change secure boot mode from UEFI to other, exit and save changes. This disables secure boot. To enable it, the reverse is done.
ethtool eth0 | grep -i speedUnohtuikin päivittää tänne tilannetta. Testasin toisen kaapelin, sama homma. Kättelyn tulos alla.
ethtool eth0 | grep -i speed
Speed: 1000Mb/s
Joo kannattaa huomata että speedtest itse tarjoaa virallisen version Speedtest CLI - Internet connection measurement for developers tuolta, se speedtest-cli paketti mikä löytyy suurimman osan distroista repositorioista on kolmannen osapuolen työkalu joka käyttää jotain vanhaa apia eikä tuota oikeanlaisia tuloksia.
Kiitos!
cd /usr/share/pulseaudio/alsa-mixer/paths/
sudo nano analog-output-headphones.conf; On some machines Front is actually a part of the Headphone path
[Element Front]
switch = mute --> off
volume = zero --> off
Ei missään nimessä ole eri. Win10 ajaa kovalevyltä valmiiksi löytyvän EFI-partition sileäksi ja täyttää Windowsilla, vaikka siellä olisi linux tai mac valmiina. Ei auta, vaikka tekisi Diskpartilla uuden EFI-osion, koska käytettävää EFI-partitiota ei voi asennusvaiheessa valita. Windows valitsee ensimmäisen levyn alusta katsoen löytyy.
Tätä soveltamalla varmaan helpointa.
Siis tuolla antaa oikeudet ajaa komento käyttäjälle ja sitten lisätä se komentorivi käynnistettäviin sovelluksiin?
Tuollahan se lukee:
Automaattisesti joka käynnistyksessä ajettava komento on sudo modprobe -r lp niin mitenkäs tuo rivi pitäisi lisätä? On kyllä niin perseelleen kirjoitettu tuo wikisivu, kuten 99% kaikista Linux manuaaleista, joista ei tavan käyttäjä ota mitään selkoa.Tuollahan se lukee:
Jos halutaan, että eskon ei tarvitse syöttää salasanaa komennon yhteydessä, lisätään riville NOPASSWD-optio. Useat komennot erotetaan toisistaan pilkulla:
esko ALL=(root) NOPASSWD: /sbin/shutdown,/sbin/reboot
Ihan turhaa. Laita lp blacklistille niin sitä ei ladata eikä tarvitse ajaa komentoa käynnistyksessä.
Tuota ei kannata sudon kanssa laittaa vaan ihan suoraan käynnistysskripteihin rootilla ajettavaksi. Mikä distro sulla on, niin voin auttaa tarkemmin.
Ubuntu server 20.04
$ sudo nano /etc/modprobe.d/blacklistblacklist lp$ sudo update-initramfs -u$ sudo rebootTäytyypä kokeilla. Tuo kai pysyy voimassa vaikka ydin välillä päivittyykin?
Pysyy.
Jos perusteluna on vain että mikä on ”paras” niin käytä sitä defaultia. Jos keksit jonkun tarpeen mikä pitäisi paketoidulla custom kernelillä ratketa niin käytä sitä.
Taitaa koneet nykyään olla niin nopeita, että itse buildatun kernelin ja ainoastaan tarpeellisilla varustetuilla ajureilla ei taida nopeuttaa käyttöä yhtään. Tai marginaalisesti ainakin.
Jatketaan tarinaa. Uudet levyt matkalla ja kohta pääsee toteuttamaan.
Wanhana gentoo-kaulapartana sanoisin, että erikoiskernelit on erikoiskaulaparroille. Nopeushyötyä niistä ei tosiaan ole ollut pitkään aikaan, mutta yhteensopivuusongelmia senkin edestä. Ainut syy, mitä tänäpäivänä keksin erikoiskernelin käyttöön on, että siitä löytyy jokin tarvitsemasi kokeellinen ajuri tai ominaisuus, mitä et saa muuten käyttöösi.
Vanhana Gentoo-kokopartana kysyn että mikä on Gentoon kontekstissa erikoiskerneli?
Lukisin erikoiskerneleiksi vähintään kaiken, mitä ei portagen oletusreposta löydy arch tai ~arch.
Minustakin käyttämäni gentoo-sources-kerneli käsin tehdyllä konffilla ja muutamalla itse tehdyllä user patchilla on ihan normaalia Gentoon käyttöä eikä mitään erikoista
Olihan sulla swap-tiedosto/-osio määritetty? Mulla toki hidastuu kun muisti loppuu, muttei se jumiin jää.
Sulla ei oo ilmeisesti swap-osiota ollenkaan, sen pitäisi estää tuo lähes totaalinen jäätyminen.
Onhan tuo aavistuksen pieni, jos satut rajoilla avaamaan ohjelman joka vaatii useamman gigan niin jumiinhan se menee. Yleensä on ohjeena 0,5-1 kertaa RAM-muistin määrä, riippuu käyttökohteesta.
Eikös tämä meinaa että olis kuitenki määritelty? Onko 1,8gb sitten liian pieni koko tuolle?
