Linux-kysymyksiä & yleistä keskustelua Linuxista

huomioi, että nuo parametrit ottavat Isot ja pienet kirjaimet huomioon joten kopsaa rimpsut sellaisenaan. "quiet splash" on yleisesti pienillä kirjaimilla (vaikkakin kerneli saattaa hyväksyä ne noinkin)

Kirjoitin sen tohon väärin, kun vetäisin ulkomuistista. Se on pienillä.
Mutta ei toimi siltikään. Kun tässä testasin niin vahvarin sammuttaminen nollaa edelleen näytön säädöt takaisin oletuksiin. Tällaiset jutut pystyn itse tarkistamaan.
Tässä noi mitä koitin käskyttää Linuxia tekemään:
Ensin terminaaliin tämä
sudo mkdir /lib/firmware/edid
ja enterin jälkeen tämä
sudo cp /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1/edid /lib/firmware/edid/hdmi_edid.bin
ja enter.
Ei tullut kyllä mitään ilmoituksia, joten kai se onnistui. Tuo on copy-pastattu, joten just noin tein.

Tämän pystyn tsekkaamaan, että /lib/firmware/edid hakemistossa on hdmi_edid.bin-tiedosto.
Kaksoisnapauttamalla tulee vain ilmoitus, että Could not display “hdmi_edid.bin”. the file is of an unknown type.
Mites ton pystyy tarkistamaan, että siellä on oikeat tiedot?

grubin rivi on näin:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash drm_kms_helper.edid_firmware=HDMI-A-1:edid/hdmi_edid.bin"
Tämäkin copy-pastattu eli mahdolliset virheet ovat oikeita eikä kirjoitusvirheitä.

Sitten tein myös tämän sudo update-grub ja jotain se teki eikä tullut mitään virheilmoituksiakaan.

Sinänsä kyllä ei ole tärkeä homma ja pystyy elämään ton kanssa, mutta toisaalta olishan se kiva saada säädettyä kuntoon.
 
Tämän pystyn tsekkaamaan, että /lib/firmware/edid hakemistossa on hdmi_edid.bin-tiedosto.
Kaksoisnapauttamalla tulee vain ilmoitus, että Could not display “hdmi_edid.bin”. the file is of an unknown type.
Mites ton pystyy tarkistamaan, että siellä on oikeat tiedot?

Esimerkiksi parse-edid osaa tulkata tuon tiedoston.
Koodi:
sudo apt install read-edid
parse-edid < /lib/firmware/edid/hdmi_edid.bin

Sitten tein myös tämän sudo update-grub ja jotain se teki eikä tullut mitään virheilmoituksiakaan.

Voit varmistaa onko tuo parametri käytössä vaikkapa:
Koodi:
cat /proc/cmdline

Tässä pitäisi näkyä jossakin kohdassa tuo GRUB_CMDLINE_LINUX_DEFAULT:iin asetettu litania.
 
Sitten tein myös tämän sudo update-grub ja jotain se teki eikä tullut mitään virheilmoituksiakaan.
Tuo luo uuden /boot/grub/grub.cfg tiedoston, vaikka "grep drm_kms_helper /boot/grub/grub.cfg" komennolla näkee menikö optiot kernelien perään.
 
Nyt menee hämäräksi. Barbarossan ohjeen cat /proc/cmdline komennolla tulee tällainen litania:
BOOT_IMAGE=/vmlinuz-4.4.0-119-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro quiet splash drm_kms_helper.edid_firmware=HDMI-A-1:edid/hdmi_edid.bin vt.handoff=7

Eli se lienee oikein. Tolla Pertin ohjeella tulee pirun paljon enemmän kaikkea, mutta voin sen tarvittaessa kopsata, jos siitä on hyötyä.
Mutta tuo hdmi_edid.bin ei liene oikein. Siellä kai pitäisi myös olla jossain tämä "pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1", mutta ei ole

Tällä käskyllä parse-edid < /lib/firmware/edid/hdmi_edid.bin tulee tällainen selittely:

Checksum Correct



Section "Monitor"

Identifier "LG TV"

ModelName "LG TV"

VendorName "GSM"

# Monitor Manufactured week 1 of 2012

# EDID version 1.3

# Digital Display

DisplaySize 1600 900

Gamma 2.20

Option "DPMS" "false"

Horizsync 30-83

VertRefresh 58-62

# Maximum pixel clock is 150MHz

#Not giving standard mode: 640x480, 60Hz

#Not giving standard mode: 800x600, 60Hz

#Not giving standard mode: 1024x768, 60Hz

#Not giving standard mode: 1152x864, 60Hz

#Not giving standard mode: 1280x1024, 60Hz



#Extension block found. Parsing...

Modeline "Mode 16" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync

Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

Modeline "Mode 1" 74.25 1920 2008 2052 2200 540 542 547 562 +hsync +vsync interlace

Modeline "Mode 2" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

Modeline "Mode 3" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync

Modeline "Mode 4" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync

Modeline "Mode 5" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync

Modeline "Mode 6" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace

Modeline "Mode 7" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace

Modeline "Mode 8" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync

Modeline "Mode 9" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync

Modeline "Mode 10" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync

Modeline "Mode 11" 74.250 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync

Modeline "Mode 12" 74.250 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync

Modeline "Mode 13" 74.250 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

Modeline "Mode 14" 27.000 1440 1464 1590 1728 576 578 581 625 -hsync -vsync interlace

Modeline "Mode 15" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync

Modeline "Mode 17" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

Modeline "Mode 18" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync

Option "PreferredMode" "Mode 16"
 
Tolla Pertin ohjeella tulee pirun paljon enemmän kaikkea, mutta voin sen tarvittaessa kopsata, jos siitä on hyötyä.
Mutta tuo hdmi_edid.bin ei liene oikein. Siellä kai pitäisi myös olla jossain tämä "pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1", mutta ei ole
Ei tuota pci juttua kuulu olla, se oli sys-tiedostojärjestelmän polkua josta edid kopioitiin /lib/firmwaren alle.

Se grep komento listaa jokaisen asennetun kernelin käynnistysrivit Grub käynnistyslataajan asetustiedostosta joista löytyy "drm_kms_helper" rimpsu eli muokkaukset ja päivitys onnistui, kun tulee osumia.

BOOT_IMAGE näyttää äkkiseltään oikealta, pysyykö näytön tilat ja ääniasetukset nyt samoina vaikka vahvistinta/näyttöä sammuttelee ja käynnistelee?
 
BOOT_IMAGE näyttää äkkiseltään oikealta, pysyykö näytön tilat ja ääniasetukset nyt samoina vaikka vahvistinta/näyttöä sammuttelee ja käynnistelee?

Ei pysy ja siksi mä ton tohon laitoinkin. Eli ilmeisesti on oikein, mutta vika oli jossain muualla.
Onko tämä homma mitä tässä tehtiin periaatteessa sellainen, että jos mä olisin laittanut tuohon sellaisen liitännän, mikä ei ole käytössä, niin kuvaa ei tulisi ollenkaan?
 
Jos liitännässä on joku vastaanotin päällä, se näyttää connected.

Koodi:
$ xrandr | grep connected
DP1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 1600mm x 900mm
HDMI1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 1600mm x 900mm
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Mutta sehän näyttää myös disconnected.
 
Jos liitännässä on joku vastaanotin päällä, se näyttää connected.

Mutta sehän näyttää myös disconnected.
Tällaisen luettelon antaa.
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 160mm x 90mm
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis
 
No, näköjään tällaista on muillakin.
In Ubuntu, why does the menu bar and title scaling reset when my screen is detected?

Täytyy koittaa osaanko asentaa tällaisen unity paketin sitten.
Better Unity for HiDPI displays : Park Ju Hyung

Edit: Hyvin asentui, mutta eipä vika korjaantunut. Vaikka kuvauksessa on juuri tämä bugi, minkä tämä paketti pitäisi korjata.
- Scaling reset upon display wake

Enköhän anna vaan olla ja totea, että paskan möivät.
Sellainen tässä tuli mieleen, että varmastikin on olemassa komentorivikäsky, jolla voin määrätä skaalaamisen vaikka 1,3:een. Onko Linuxissa mahdollisuus tuollaiseen autoexec.bat tyyliseen systeemiin, että mulla on työpöydällä valmiina tuo säätö ja tuplaklikkaamalla sitä saan sen säädettyä eikä tarvitse joka kerta mennä sitä graafisen käyttöliittymän kautta?
 
Viimeksi muokattu:
Cinnamon työpöytää voisi kokeilla, siinä pitäisi olla hyvät skaalaustoiminnot jo vakiona. Sen voi asentaa nykyisen rinnalle.
 
No, näköjään tällaista on muillakin.
In Ubuntu, why does the menu bar and title scaling reset when my screen is detected?

Täytyy koittaa osaanko asentaa tällaisen unity paketin sitten.
Better Unity for HiDPI displays : Park Ju Hyung

Edit: Hyvin asentui, mutta eipä vika korjaantunut. Vaikka kuvauksessa on juuri tämä bugi, minkä tämä paketti pitäisi korjata.
- Scaling reset upon display wake

Enköhän anna vaan olla ja totea, että paskan möivät.
Sellainen tässä tuli mieleen, että varmastikin on olemassa komentorivikäsky, jolla voin määrätä skaalaamisen vaikka 1,3:een. Onko Linuxissa mahdollisuus tuollaiseen autoexec.bat tyyliseen systeemiin, että mulla on työpöydällä valmiina tuo säätö ja tuplaklikkaamalla sitä saan sen säädettyä eikä tarvitse joka kerta mennä sitä graafisen käyttöliittymän kautta?
En tiedä mitä on tapahtunut, mutta nyt asetus tuntuu pysyvän. Muistaakseni jopa käynnistin tietokoneen uudestaan sen jälkeen kun olin ton unity-paketin asentanut, mutta ei vaikutusta. Nyt sitten tuntuu jokin asetus menneen perille ja toimii kuten pitääkin.
 
Koodi:
#!/bin/bash

while true
do
    ping -c 1 www.google.fi > /dev/null 2>&1 || echo Ping failed at $(date +%Y.%m.%d-%H.%M.%S) >> /path/to/ping.log
    sleep 5
done
Ensinnäkin valtavasti kiitoksia tästä.

Toiseksikin. Voi prkl. että sitä on käsi tuon linuxin kanssa. Kopsasin täältä tuon koodin windowsin notepadiin ja tallensin .sh ja sitten siirsin Linux koneelle ja koitin saada toimimaan ja ei. ei millään. Heitti "no such file or directory" virhettä kun yritti suorittaa. Noooooh, aikamoisen kuukkeloinnin jälkeen opin hieman miten diagnosoida mikä mättää ja selvisi että wintoosan notepädi lisää sinne jotain rivinvaihtoja yms jotka ei suoraan näy mutta jotka sotkee sriptin. Nooooh, löysin jonkun komentorimpsun millä siistiä tuon mutta se ei toiminut niin päätin linuxilla kirjoitella manuaalisti koko homman uudelleen ja sehän lähti toimimaan.

Wiresharkilla näkyy icmp ping liikenne. Nyt vaan kyttäilemään miten usein tuo nettiliikenne katkeaa.
 
Koodi:
#!/bin/bash

while true
do
    ping -c 1 www.google.fi > /dev/null 2>&1 || ping -c 1 1.1.1.1 > /dev/null 2>&1 || echo Ping failed at $(date +%Y.%m.%d-%H.%M.%S) >> /path/to/ping.log
    sleep 5
done

Tuohon voisi lisätä vielä toisen pingin eri paikkaan, esim. tuohon Cloudflaren DNS palvelimeen niin saa hivenen enemmän varmuutta katkosta. Nimen kanssa virheen voi aiheuttaa pelkkä toimimaton DNS palvelu, mutta IP lisänä varmistaa, että ongelma on myös alemmalla tasolla.

Tuohon löytynee kyllä parempia valmiita skriptejä ja työkaluja.
 
Koodi:
#!/bin/bash

while true
do
    ping -c 1 www.google.fi > /dev/null 2>&1 || ping -c 1 1.1.1.1 > /dev/null 2>&1 || echo Ping failed at $(date +%Y.%m.%d-%H.%M.%S) >> /path/to/ping.log
    sleep 5
done

Tuohon voisi lisätä vielä toisen pingin eri paikkaan, esim. tuohon Cloudflaren DNS palvelimeen niin saa hivenen enemmän varmuutta katkosta. Nimen kanssa virheen voi aiheuttaa pelkkä toimimaton DNS palvelu, mutta IP lisänä varmistaa, että ongelma on myös alemmalla tasolla.

Tuohon löytynee kyllä parempia valmiita skriptejä ja työkaluja.
Tuollakin tiedolla koska tietoliikenne stoppaa ja kuinka pitkäksi aikaa tekee jo paljon. Ei vain oikein tiedä millä tuota parhaiten diagnosoisi tai mitä siis kannattaisi tarkkailla.

Olen tästä tuolla tietoliikenne alueella pulissut ja ongelma on siis se että pitäisi jotenkin setviä miksi Telian kaapelilaajakaista lakkaa siirtämästä dataa silloin tällöin (1-4 kertaa pvm). Modeemi itsessään pysyy linjoilla mutta jostain syystä data vai ei kulje. Modeemi on siltaavana ja siitä on otettu kahdelle eri reitittimelle yhteys ja katkos tapahtuu molemmissa samaan aikaan.

Ongelmaa ainakin näyttää olevan siinä että Telian DHCP ei aina näytä vastaavan DHCP kyselyihin ainakaan järkevissä ajoissa (Minutttien, joskus kymmenienkin viive ennen kuin onnistuu koko prosessi)

Ehdotuksia saa heittää. Teliasta ei hirveästi apua ole, siellä vaan nostetaan kädet ylös kun yhteys toimii fyysisesti ja sanotaan että se on sun vehkeissä tai talonyhtiön sisäverkossa.
 
Modeemi on siltaavana ja siitä on otettu kahdelle eri reitittimelle yhteys ja katkos tapahtuu molemmissa samaan aikaan.
Kannattaa varmuudeksi ottaa se toinen reititin pois linjoilta ja käyttää vain yhtä, jotta voit varmistaa ettei yhteysongelmat johdu niistä. Onko sun liittymään luvattu enemmän kuin yksi julkinen ip-osoite?
e: Yhtenä vaihtoehtona on lyödä yksi tietokone suoraan siihen sillattuun kaapelimodeemiin kiinni. Mikä kaapelimodeemi sulla muuten on? Monella on ollut ongelmia halpismodeemien kanssa ja usein ne operaattorin omat modeemit on paskimmasta päästä. Kannattaa koittaa myös eri kaapeleilla ja eri pistokkeista, jos mahdollista.
 
Kannattaa varmuudeksi ottaa se toinen reititin pois linjoilta ja käyttää vain yhtä, jotta voit varmistaa ettei yhteysongelmat johdu niistä. Onko sun liittymään luvattu enemmän kuin yksi julkinen ip-osoite?
Telian liittymissä on se 5kpl vaihtuvaa julkista ip osoitetta joten siitä ei pitäisi olla kiinni. Enkä oikein muutakaan keksi miksei toimisi ellei sitten tuo Telian toimittama cisco epc3825 jumi. Harmillisesti tuolla kaapelimodeemi puolella ei hirveästi vaihtoehtoja ole, varsinkaan jos modeemin pitäisi toimia pelkkänä siltana.
 
linux-nyyppä kaipailee nyt vinkkejä ongelmaan:

Käytössä on Mint 18.3 ja siinä oli ensin 14.7-rc1 kernel. Se oli vielä tuollainen missä oli vain kolme pakettia:
Index of /~kernel-ppa/mainline/v4.17-rc1

Sitten tuli rc2, jossa olikin neljäntenä joku modules-paketti:
Index of /~kernel-ppa/mainline/v4.17-rc2

En ollut ikinä ennen nähnyt vastaavaa. Okei, ei se mitään... ajattelin ja latasin paketit koneelle omaan hakemistoonsa. Yritin päivittää:
sudo dpkg -i *.deb

Asennus keskeytyi johonkin virhe-ilmoitukseen, että joku riippuvuus ei ole kunnossa. Okei, meni pari päivää kunnes tajusin että tarvitaan ilmeisesti libssl1.1 niminen paketti.

Toisessa koneessa sain sen avulla asentumaan näitä nelipakettisia kerneleitä. Ei ongelmaa. Lähtötilanteessa oli kuitenkin se ero, että siihen koneeseen en ollut ehtinyt yrittää asentaa puutteellisesti (ilman sitä libssl1.1) mitään nelipakettista, koska olin todennut tällä ongelma-koneella jo että se ei onnistu.

Nyt tämä varsinainen ongelma:

1. Tuon rc2 kernelin poistaminen ei onnistu. Ei myöskään rc3 poistaminen (jonka asentamista ehdin jo kokeilemaan myös, puutteellisesti, ilman libssl1.1).

Jos komennan "sudo apt purge linux*rc2*" niin siinä käy näin:

Removing linux-image-unsigned-4.17.... (jne)...rc2-generic...
/var/lib/dpkg/info/linux-image-unsigned-4.17.... (jne)...rc2-generic-prerm:
11: /var/lib/dpkg/info/linux-image-unsigned-4.17.... (jne)...rc2-generic-prerm:
linux-check-removal: not found
dpkg: error processing package linux-image-unsigned-4.17.... (jne)...rc2-generic (--purge):
subprocess installed pre-removal script returned error exit status 127
Errors were encountered while processing:
linux-image-unsigned-4.17.... (jne)...rc2-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)


2. Mitään paketteja ei pysty päivittämään.

Jos komennan "sudo apt upgrade" niin käy näin:

(3 normaalia riviä)... ja sitten:
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
linux-image-unsigned-4.17.... (jne)...rc2-generic :
Depends: linux-modules-4.17.... (jne)...rc2-generic but it is not installable
E: Unmet dependencies. Try using -f.

Sitten kun komennan "sudo apt-get -f install" tulee näin:

(pari perusriviä ja sitten)
Correcting dependencies... Done
The following packages will be REMOVED:
linux-image-unsigned-4.17.... (jne)...rc2-generic
(valitsen YES)
Sitten tulee samat rivit erroria kuin kohdassa 1, paitsi "(--purge)" tilalla on "(--remove)".


3. Käynnistän Synaptec Package Managerin (as superuser).

Se antaa käynnistäessä heti tietoikkunan:
You have 1 broken package on your system! Use the "Broken" filter to locate it.
En ole varma mihin tuo viittaa. En osaa etsiä.

Edit-valikosta löydän kuitenkin "Fix Broken Packages" joka on valittavissa. Klikkaan sitä.
Ohjelman alareunaan tulee tietoa: "Succesfully fixed dependency problems".

Sitten vielä ohjelman toimintorivillä on painettavissa "Apply". Klikkaan sitä.
Aukeaa ikkuna jossa on varsinaisena tietona:
To be Removed: linux-image-unsigned-4.17.... (jne)...rc2-generic

Klikkaan ikkunasta vielä Apply.
Tulee jälleen sama virheilmoitus kuin kohdassa 1:
E: linux-image-unsigned-4.17.... (jne)...rc2-generic:
subprocess installed pre-removal script returned error exit status 127

Changes applied.
Not all changes and updates succeeded. For further details of the failure, please expand the 'Details' panel below.

Details:
Näkyy että kernelistä rc2 tuli samat virheilmoitukset jotka jo aiemmin.
Lisäksi rc3 kernelistä näkyy että sitä ei ole pystytty asentamaan, mutta sen ymmärränkin, koska senkin asentuminen olisi tarvinnut sen libssl1.1 paketin, jota tässä koneessa ei ole ollut missään vaiheessa.

Eli tällä hetkellä heitä ei pysty poistamaan eikä paketteja pysty päivittämään. Tuntuu että mitä tahansa muutoksia yrittää tehdä, niin aina iskee tuo rc2-naljailu silmille. Aiempia kolmipaketteisia kerneleitä pystyy kyllä asentamaan. Tällä hetkellä ongelmakoneessa on käytössä 4.16.3, joka oli 4.16-sarjan viimeinen kolmepakettinen.

Eli käytännössä nyt kysyisin, että onko jotain keinoa, jolla ensinnä tuon asentumattoman rc2-kernelin jämät saisi ns. niskaperseotteella heivattua pois koneesta? Vai kannattaako vaan laittaa käyttis uusiksi (se ei ole mikään ongelma sinänsä)?
 
linux-nyyppä kaipailee nyt vinkkejä ongelmaan:

Käytössä on Mint 18.3 ja siinä oli ensin 14.7-rc1 kernel. Se oli vielä tuollainen missä oli vain kolme pakettia:
Index of /~kernel-ppa/mainline/v4.17-rc1

Sitten tuli rc2, jossa olikin neljäntenä joku modules-paketti:
Index of /~kernel-ppa/mainline/v4.17-rc2

En ollut ikinä ennen nähnyt vastaavaa. Okei, ei se mitään... ajattelin ja latasin paketit koneelle omaan hakemistoonsa. Yritin päivittää:
sudo dpkg -i *.deb

Asennus keskeytyi johonkin virhe-ilmoitukseen, että joku riippuvuus ei ole kunnossa. Okei, meni pari päivää kunnes tajusin että tarvitaan ilmeisesti libssl1.1 niminen paketti.

Toisessa koneessa sain sen avulla asentumaan näitä nelipakettisia kerneleitä. Ei ongelmaa. Lähtötilanteessa oli kuitenkin se ero, että siihen koneeseen en ollut ehtinyt yrittää asentaa puutteellisesti (ilman sitä libssl1.1) mitään nelipakettista, koska olin todennut tällä ongelma-koneella jo että se ei onnistu.

Nyt tämä varsinainen ongelma:

1. Tuon rc2 kernelin poistaminen ei onnistu. Ei myöskään rc3 poistaminen (jonka asentamista ehdin jo kokeilemaan myös, puutteellisesti, ilman libssl1.1).

Jos komennan "sudo apt purge linux*rc2*" niin siinä käy näin:

Removing linux-image-unsigned-4.17.... (jne)...rc2-generic...
/var/lib/dpkg/info/linux-image-unsigned-4.17.... (jne)...rc2-generic-prerm:
11: /var/lib/dpkg/info/linux-image-unsigned-4.17.... (jne)...rc2-generic-prerm:
linux-check-removal: not found
dpkg: error processing package linux-image-unsigned-4.17.... (jne)...rc2-generic (--purge):
subprocess installed pre-removal script returned error exit status 127
Errors were encountered while processing:
linux-image-unsigned-4.17.... (jne)...rc2-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)


2. Mitään paketteja ei pysty päivittämään.

Jos komennan "sudo apt upgrade" niin käy näin:

(3 normaalia riviä)... ja sitten:
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
linux-image-unsigned-4.17.... (jne)...rc2-generic :
Depends: linux-modules-4.17.... (jne)...rc2-generic but it is not installable
E: Unmet dependencies. Try using -f.

Sitten kun komennan "sudo apt-get -f install" tulee näin:

(pari perusriviä ja sitten)
Correcting dependencies... Done
The following packages will be REMOVED:
linux-image-unsigned-4.17.... (jne)...rc2-generic
(valitsen YES)
Sitten tulee samat rivit erroria kuin kohdassa 1, paitsi "(--purge)" tilalla on "(--remove)".


3. Käynnistän Synaptec Package Managerin (as superuser).

Se antaa käynnistäessä heti tietoikkunan:
You have 1 broken package on your system! Use the "Broken" filter to locate it.
En ole varma mihin tuo viittaa. En osaa etsiä.

Edit-valikosta löydän kuitenkin "Fix Broken Packages" joka on valittavissa. Klikkaan sitä.
Ohjelman alareunaan tulee tietoa: "Succesfully fixed dependency problems".

Sitten vielä ohjelman toimintorivillä on painettavissa "Apply". Klikkaan sitä.
Aukeaa ikkuna jossa on varsinaisena tietona:
To be Removed: linux-image-unsigned-4.17.... (jne)...rc2-generic

Klikkaan ikkunasta vielä Apply.
Tulee jälleen sama virheilmoitus kuin kohdassa 1:
E: linux-image-unsigned-4.17.... (jne)...rc2-generic:
subprocess installed pre-removal script returned error exit status 127

Changes applied.
Not all changes and updates succeeded. For further details of the failure, please expand the 'Details' panel below.

Details:
Näkyy että kernelistä rc2 tuli samat virheilmoitukset jotka jo aiemmin.
Lisäksi rc3 kernelistä näkyy että sitä ei ole pystytty asentamaan, mutta sen ymmärränkin, koska senkin asentuminen olisi tarvinnut sen libssl1.1 paketin, jota tässä koneessa ei ole ollut missään vaiheessa.

Eli tällä hetkellä heitä ei pysty poistamaan eikä paketteja pysty päivittämään. Tuntuu että mitä tahansa muutoksia yrittää tehdä, niin aina iskee tuo rc2-naljailu silmille. Aiempia kolmipaketteisia kerneleitä pystyy kyllä asentamaan. Tällä hetkellä ongelmakoneessa on käytössä 4.16.3, joka oli 4.16-sarjan viimeinen kolmepakettinen.

Eli käytännössä nyt kysyisin, että onko jotain keinoa, jolla ensinnä tuon asentumattoman rc2-kernelin jämät saisi ns. niskaperseotteella heivattua pois koneesta? Vai kannattaako vaan laittaa käyttis uusiksi (se ei ole mikään ongelma sinänsä)?
Vanhoja kerneleitä kannattaa poistaa "sudo apt autoremove" tai "sudo apt-get autoremove" -komennolla eikä itse käsin.
 
Vanhoja kerneleitä kannattaa poistaa "sudo apt autoremove" tai "sudo apt-get autoremove" -komennolla eikä itse käsin.

Unohdin mainita että sudo apt autoremove oli kokeiltuna jo myös. Nuo molemmat tuottavat saman virheen kuin kohdassa 2. Unmet dependencies. Try using -f.
 
En saa XF86AudioRaiseVolume- ja XF86AudioLowerVolume-näppäimiä toimimaan. Ne löytyvät komennoilla "xev" ja "xbindkeys -k", mutta en onnistu liittämään niihin mitään komentoa xbindkeysillä. Ne eivät myöskään toimi globaaleina pikanäppäiminä Audaciouksessa. Jotain kuitenkin tapahtuu, sillä näppäinten käyttäminen väläyttää valinnan korostusta soittolistassa. Muut multimedianäppäimet toimivat. Lokiin ei tulostu virheilmoituksia. Xbindkeys toimii muiden näppäimien kohdalla. Missäköhän vika?

xev
Koodi:
KeyRelease event, serial 42, synthetic NO, window 0x600001,
    root 0x1d4, subw 0x0, time 1275284258, (406,-177), root:(409,663),
    state 0x10, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x3200001,
    root 0x1d4, subw 0x0, time 1276016811, (124,-73), root:(127,767),
    state 0x10, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

xbindkeys -k
Koodi:
Press combination of keys or/and click under the window.
You can use one of the two lines after "NoCommand"
in $HOME/.xbindkeysrc to bind a key.
"(Scheme function)"
    m:0x10 + c:123
    Mod2 + XF86AudioRaiseVolume

"(Scheme function)"
    m:0x10 + c:122
    Mod2 + XF86AudioLowerVolume


.xbindkeysrc
Koodi:
"audtool set-volume $(($(audtool get-volume) + 5))"
  m:0x10 + c:123
"audtool set-volume $(($(audtool get-volume) - 5))"
  m:0x10 + c:122

Edit. Sain toimimaan em. näppäimet Audaciouksen globaaleina pikanäppäiminä, kun muokkasin /usr/share/X11/xkb/symbols/inet-tiedostostossa olevia evdevin symbolimäärityksiä muuttamalla ko. näppäimiin liittyvät rivit kommenteiksi. Audacious tunnistaa nyt ne, vaikka niillä ei em. muokkauksen jälkeen enää ole tunnistenimiä. Näppäimet eivät toimi edelläänkään xbindkeysin kanssa, mutta enpä onneksi tarvitsekaan niitä muuhun kuin Audaciouksen äänenvoimakkuusasetuksen säätöön.
 
Viimeksi muokattu:
Linuxiin ei taida olla mitään kunnon raudantestausohjelmia?
Eikä tainnut olla mitään edes asennuksen checkkausta, että kaikki on ok?

Tässä vaan kävi tänään niin, että ei tullut kuvaa. Se on joskus aikaisemminkin tehnyt tuota ja ennen on auttanut, kun boottaa vaan uudestaan. Kolmannen kerran jälkeenkin on vain musta ruutu ja hakemaan neuvoja netissä. Ekaksi pitäisi testata, että pääseekö bootloaderiin ja ohjeen mukaan joko shiftiä tai esc:iä pohjassa pitämällä pääsee sinne. Hyvinhän sinne pääsi eli se on ilmeisesti kunnossa. Biosiinkin pääsee ongelmitta eikä sieltä nyt mitään kummallista näy.

Ajattelin, että jos nyt vaan koitan asentaa uudelleen ja jos se ei onnistu, niin sitten lienee jotain rautavikaa. Poistuin siitä bootloaderista ja menin toiselle koneelle tekemään asennus-USB:tä. Kun sitten palaan koneelle, niin eikös siellä ole kuva ruudulla. Siinä sitten pari tuntia surffailen, boottailen konetta useamman kerran jne.. Kaikki toimii kuin ei mitään ongelmaa olisi koskaan ollutkaan.

Mutta vähän kyllä tekisi mieleni ajaa koneessa läpi kaikki mahdolliset testaussoftat ja se tietänee sitä, että windows siihen olisi asennettava. Vai?

Sellainen vielä, että tarkistin näyttökaapelin olevan kunnolla kiinni, tsekkasin myös ettei av-vahvari-temppuile. Vahvarikin on joskus tehnyt sitä, että kuvaa ei tule ja siihenkin on auttanut kun vahvarin boottaa, mutta nyt tuli kaikista muista lähdöistä kuva ongelmitta ja tietokone oli ainoa pimeä.
 
@Lallijuoppo Toki softa on vähän harvemmassa, mutta kyllä ainakin benchmarkkisoftaa löytyy. Sellainen kuin hardinfo ainakin näyttää myös Windowsin laitehallinta-tyyppisen näkymän.

Millainen on asennuksen tsekkaus? Ei mahda ainakaan mitään automaattista softaa olla mikä sinulle sinun hommat tekisi.

Kuulostaa vähän ajuriongelmalta. Millainen näytönohjain? Tai sitten näyttöserverissä on joku häikkä, onko kaikki tarvittava asennettu ja päivitetty?
Valmistajien omat testaussoftat sun muut on aina saatavilla vain Windowsille.

Jos hyviä softia Windowsille tiedät niin asenna menemään ja testaa pois.
 
Linuxiin ei taida olla mitään kunnon raudantestausohjelmia?
Eikä tainnut olla mitään edes asennuksen checkkausta, että kaikki on ok?

Tässä vaan kävi tänään niin, että ei tullut kuvaa. Se on joskus aikaisemminkin tehnyt tuota ja ennen on auttanut, kun boottaa vaan uudestaan. Kolmannen kerran jälkeenkin on vain musta ruutu ja hakemaan neuvoja netissä. Ekaksi pitäisi testata, että pääseekö bootloaderiin ja ohjeen mukaan joko shiftiä tai esc:iä pohjassa pitämällä pääsee sinne. Hyvinhän sinne pääsi eli se on ilmeisesti kunnossa. Biosiinkin pääsee ongelmitta eikä sieltä nyt mitään kummallista näy.

Ajattelin, että jos nyt vaan koitan asentaa uudelleen ja jos se ei onnistu, niin sitten lienee jotain rautavikaa. Poistuin siitä bootloaderista ja menin toiselle koneelle tekemään asennus-USB:tä. Kun sitten palaan koneelle, niin eikös siellä ole kuva ruudulla. Siinä sitten pari tuntia surffailen, boottailen konetta useamman kerran jne.. Kaikki toimii kuin ei mitään ongelmaa olisi koskaan ollutkaan.

Mutta vähän kyllä tekisi mieleni ajaa koneessa läpi kaikki mahdolliset testaussoftat ja se tietänee sitä, että windows siihen olisi asennettava. Vai?

Sellainen vielä, että tarkistin näyttökaapelin olevan kunnolla kiinni, tsekkasin myös ettei av-vahvari-temppuile. Vahvarikin on joskus tehnyt sitä, että kuvaa ei tule ja siihenkin on auttanut kun vahvarin boottaa, mutta nyt tuli kaikista muista lähdöistä kuva ongelmitta ja tietokone oli ainoa pimeä.
Sitten kun vielä saisi tietoon että mikä Distro ja mitä näyttiksiä koneesta löytyy. Lähes varmasti ajuri ongelma ja helposti korjattavissa.
 
@Lallijuoppo Toki softa on vähän harvemmassa, mutta kyllä ainakin benchmarkkisoftaa löytyy. Sellainen kuin hardinfo ainakin näyttää myös Windowsin laitehallinta-tyyppisen näkymän.

Millainen on asennuksen tsekkaus? Ei mahda ainakaan mitään automaattista softaa olla mikä sinulle sinun hommat tekisi.

Kuulostaa vähän ajuriongelmalta. Millainen näytönohjain? Tai sitten näyttöserverissä on joku häikkä, onko kaikki tarvittava asennettu ja päivitetty?
Valmistajien omat testaussoftat sun muut on aina saatavilla vain Windowsille.

Jos hyviä softia Windowsille tiedät niin asenna menemään ja testaa pois.


Sitten kun vielä saisi tietoon että mikä Distro ja mitä näyttiksiä koneesta löytyy. Lähes varmasti ajuri ongelma ja helposti korjattavissa.

Joo siis, kyseessä on ubuntu 16.04. Mitään näyttöajureita en ole asentanut erikseen asentanut ja näytönohjaimena on prossun sisäinen ja prossu on Intel Skylake Pentium G4400.

Tässä tuli mieleen, että pari kertaa on myös tapahtunut sellainen outo juttu, että yhtäkkiä kone on alkanut tahmaamaan. Toimii siis kuin täi tervassa, hiiren kursori liikkuu hyppien ja kun saa jostain klikattua, niin kestää ikuisuuden että mitään tapahtuu. Sammutusyrityksen seurauksena pääsee työpöydältä pois ja ruudulla vilistää jotain ihme koodia. Siihen se jämähtää eikä sammu, täytyy ottaa sähköt pois. Sitten kun käynnistää taas, niin ei mitään ongelmaa.

Mutta mitään kovin raskastahan en tee, joten siksi tekisi mieleni katsoa, että menevätkö testiohjelmat ongelmitta läpi. Memtest86 näköjään toimii Linuxissakin ja se on nyt pyörimässä. Jos hardinfo vain luettelee koneen sisuskalut, niin sillä en kyllä tee mitään. Sisuskalut kyllä on tiedossa.
Pitäisi vielä saada joku prossu-ja näytönohjaintesti, mitkä rasittaisivat niitä ja näkisi että jaksaako kone pyöriä vai kaatuuko siihen. Jolloin voisi alkaa sitä rautavikaa epäilemään ettei turhaan ala Linuxia syyttämään.

Kun se kone toimii siis jotain kuukauden täysin ongelmitta ja sitten yhtäkkiä tekee jotain tälläistä ihme juttua ja sitten taas ei mitään ongelmia. Päivityksiähän tulee ihan säännöllisesti, joten sekin on aina mahdollista että joku päivitys käy aina välillä hajottamassa jotain. Mutta se on outoa, että se silti "korjaantuu" muka itsestään. Jos päivityksessä tulisi jotain, mikä kaataisi koneen, niin luulisi sen sitten olevan jatkuvaa. Epämääräiset laiteviat lähinnä noin käyttäytyvät, että välillä toimii ja sitten yhtäkkiä ei toimikaan.
 
Mikä kovo? HDD/SSD? Itsellä läppärissä vanha oikutteleva/hajoava HDD teki sellaista satunnaisesti, että koneen herättely sleep-tilasta joskus jumitti koko käyttiksen täysin jopa yli 10 minuutiksi, ilmeisesti kun kovalevy teki jotain sisäistä tsekkausta/error controllia. Aina kun jumitus loppui, CrystalDiskInfo näytti varoituksen kuinka "current pending sector count" oli muuttunut/kasvanut x-lukemalla. Ettei olisi sinulla vastaavaa? Se oma kovo oli jännä kyllä, se jatkuvasti "epäili" sektoreita mutta jonkun käyttöajan jälkeen "current pending sector count":it meni aina takaisin nollaan (eikä muut SMART sectorindikaattorit muuttuneet), kunnes joku päivä jumitti uudestaan ja nosti ne pending countit johonkin lukemaan taas.
 
Kovon kunnon tarkistuksen lisäksi voisi olla ihan hyvä asentaa uusin LTS (18.04). Tuo prossu kun on kuitenkin on juuri julkaistu ennen 16.04 tuloa joten voi olla jotain hassuja ongelmia tuen kanssa, etenkin jos siellä vielä pyörii suht vanha kernel alla.
 
Mikä kovo? HDD/SSD? Itsellä läppärissä vanha oikutteleva/hajoava HDD teki sellaista satunnaisesti, että koneen herättely sleep-tilasta joskus jumitti koko käyttiksen täysin jopa yli 10 minuutiksi, ilmeisesti kun kovalevy teki jotain sisäistä tsekkausta/error controllia. Aina kun jumitus loppui, CrystalDiskInfo näytti varoituksen kuinka "current pending sector count" oli muuttunut/kasvanut x-lukemalla. Ettei olisi sinulla vastaavaa? Se oma kovo oli jännä kyllä, se jatkuvasti "epäili" sektoreita mutta jonkun käyttöajan jälkeen "current pending sector count":it meni aina takaisin nollaan (eikä muut SMART sectorindikaattorit muuttuneet), kunnes joku päivä jumitti uudestaan ja nosti ne pending countit johonkin lukemaan taas.

Siinä on hdd, WD blue 500gb, 2.5". Koneessahan on kaikki vuoden vanhaa, joten iän puolesta ei pitäisi lahota. Kuten HDD:stä ja prossusta voi päätellä, niin halpiskone surffailuun ja siinä on ajanut ihan asiansa.
 
Kovo kun hajoaa niin ei se mitään vuosia kysele, ei kannata tuudittautua sellaiseen harhaan, että suhtkoht uudet tai ihan uudetkaan olisi jotenkin turvassa hajoamiselta.
 
Intelille ei tarvitse erikseen mitään asentaa. Itsekin suosittelen päivittämään uudempaan versioon.
Voit myös asentaa (ellei jo ole) sellaisen kuin gnome-disks, suomeksi näkyy otsikolla levyt. Se kertoo näppärästi GUI:ssa smart-tiedot sun muut.
Prosessorista voi yhtä ydintä koetella laskemalla md5summaa, komennolla "dd if=/dev/zero bs=1M count=100000 | md5sum"
Tämä siis pyörii kunnes se on laskenut sataan tuhanteen ja sitten kertoo millä nopeudella (MB/s) summaa laskettiin. Sinällään toimii yksydin tehon vertailussa.
Kaikille ytimille sitten vaikka Blenderin renderöintitesti ja sitä sai muistaakseni GPU:llakin pyöritettyä. Valmiita testitiedostoja saa täältä:
Demo Files — blender.org
Blender itsessään pitäisi olla Ubuntullakin repossa.
Eli aukaiset vain valmiin testitiedoston ja sitten painat render image (F12). Se renderöi kuvan yhden kerran ja kertoo siihen kuluneen ajan, mikä on myöskin eräs suorituskyvyn vertailuun käyvä mittari.
Myös prime95:n muistaakseni saisi Linuxille.
dd:llä voi helposti myös testata kiintolevyä, kunhan on komennossa varovainen koska sillä on helppo ylikirjoittaa koko levy jos ei ole asiasta perillä.

Päivitys voisi ratkaista asioita, tai sitten ei. Mutta se nyt ainakin asentaa ison läjän softaa uudelleen ja käsittellee riippuvuudet sun muut kivasti joten sitä voisi kokeilla "asennuksen tsekkauksena".
 
Viimeksi muokattu:
Voit myös asentaa (ellei jo ole) sellaisen kuin gnome-disks, suomeksi näkyy otsikolla levyt. Se kertoo näppärästi GUI:ssa smart-tiedot sun muut.

Siellä oli joku "disks" valmiina koneella ja sillä sai ajettua jonkin self testin. Kesti varmaan tunnin ja sen mukaan ei ole vikaa levyssä ja kaikki smart-tiedotkin ok. Mutta eihän ne sitä tarkoita ettei silti vikaa olisi. Ainakaan ei ole mitään ilmiselvää vikaa.

Onkos muuten Linuxissa joku tiedosto, mistä voi tutkia mitä bootatessa tapahtuu? Olettaisin että on. Mutta näkyykö siellä vaikka kaksi edellistä boottauslokia jossain, koska eihän siitä hyötyä ole, jos epäonnistuneen bootin jälkeen tekee onnistuneen bootin ja tallessa ei ole kuin sen onnistuneen boottauksen tiedot.

Täytyy jossain välissä ajella noita muita testiohjelmia myös, kiintolevy ja muistit menivät ainakin yhdestä testistä läpi.

Ja voisi sitä myös ehkä päivittää jossain välissä siihen 18.04:ään, mutta enkös mä siitäkin jostain lukenut, että jotkut eivät saa sillä edes bootattua ja piti vaan laittaa vanha takaisin.
 
Siellä oli joku "disks" valmiina koneella ja sillä sai ajettua jonkin self testin. Kesti varmaan tunnin ja sen mukaan ei ole vikaa levyssä ja kaikki smart-tiedotkin ok. Mutta eihän ne sitä tarkoita ettei silti vikaa olisi. Ainakaan ei ole mitään ilmiselvää vikaa.

Onkos muuten Linuxissa joku tiedosto, mistä voi tutkia mitä bootatessa tapahtuu? Olettaisin että on. Mutta näkyykö siellä vaikka kaksi edellistä boottauslokia jossain, koska eihän siitä hyötyä ole, jos epäonnistuneen bootin jälkeen tekee onnistuneen bootin ja tallessa ei ole kuin sen onnistuneen boottauksen tiedot.

Täytyy jossain välissä ajella noita muita testiohjelmia myös, kiintolevy ja muistit menivät ainakin yhdestä testistä läpi.

Ja voisi sitä myös ehkä päivittää jossain välissä siihen 18.04:ään, mutta enkös mä siitäkin jostain lukenut, että jotkut eivät saa sillä edes bootattua ja piti vaan laittaa vanha takaisin.

Ytimen (kernel) viestit tämänhetkiseltä käynnistyskerralta näkee dmesg-komennolla.

systemd:tä käyttävissä distroissa voi katsoa lokitiedot käynnistyskertojen mukaan:

Koodi:
journalctl -b -X

jossa X on numero. Numero 0 (tai koko numeroargumentin poisjättäminen) näyttää tiedot tämänhetkisen käynnistyksen jälkeen, numero 1 tämänhetkistä edeltäneeltä käynnistykseltä jne.
systemd - ArchWiki


/var/log -kansioon menee yleensä erilaisia lokeja, mutta en ulkoa muista, mitkä niistä ovat käynnistysten kannalta tärkeimpiä.


Kovalevyn SMART-tietojen katsomiseen on ihan hyviä ohjeita esim. tuolla:
Monitoring Hard Drive Health on Linux with smartmontools | Random Bits

Hyödyllisimmät komennot omasta mielestäni:
Koodi:
smartctl -a /dev/sdX    #lue kaikki SMART-tiedot

smartctl -t short /dev/sdX    #suorita lyhyt sisäinen testi (tulokset näkee edellisellä komennolla testin valmistuttua)
smartctl -t long /dev/sdX     #suorita pitkä sisäinen testi
 
Ytimen (kernel) viestit tämänhetkiseltä käynnistyskerralta näkee dmesg-komennolla.

systemd:tä käyttävissä distroissa voi katsoa lokitiedot käynnistyskertojen mukaan:

Koodi:
journalctl -b -X

jossa X on numero. Numero 0 (tai koko numeroargumentin poisjättäminen) näyttää tiedot tämänhetkisen käynnistyksen jälkeen, numero 1 tämänhetkistä edeltäneeltä käynnistykseltä jne.
systemd - ArchWiki

Sen verran tuohon täydentäisin, että ainakin Debianissa (ja siis mahdollisesti Ubuntussakin) tuo pysyvä logi on oletuksena pois päältä. Liekö syynä ajatus olla oletusarvoisesti tuhlaamatta levytilaa vai mikä, mutta sen saa yleensä päälle yksinkertaisesti luomalla /var/log/journal -hakemiston ja boottaamalla. Seuraavasta bootista lähtien boottilokit tallentuvat sitten "pysyvästi" niin että kun tietty levytilan maksimimäärä täyttyy, niitä aletaan automaattisesti siivoamaan pois vanhimmasta päästä alkaen.

Näin siis jos /etc/systemd/journald.conf -tiedostossa on oletusarvo "Storage=auto" tai koko asetus puuttuu/on kommentoituna.
 
Pitäisi vielä saada joku prossu-ja näytönohjaintesti, mitkä rasittaisivat niitä ja näkisi että jaksaako kone pyöriä vai kaatuuko siihen.
Asenna sellainen paketti kuin stress, voit testata prosessorin ja muistit. Näytönohjainta olen itse testannut Uniginen testiohjelmilla.
 
Onko Linuxeille mitään hyvää GUI-softaa SMART-tietojen kyttäämiseen? Esim. kuten CrystalDiskInfo Windowsin puolella joka esim. voi tsekata 10min välein levyn SMART-tietoja ja lämpötilaa ja heti ilmoitella jos tulee jotain ongelmaa.
GSmartControl :: Home & News

Smartmontools on itse ohjelma jolla tietoja voi seurata ja ainakin GSmartControl GUI löytyy.
 
Onko Linuxeille mitään hyvää GUI-softaa SMART-tietojen kyttäämiseen? Esim. kuten CrystalDiskInfo Windowsin puolella joka esim. voi tsekata 10min välein levyn SMART-tietoja ja lämpötilaa ja heti ilmoitella jos tulee jotain ongelmaa.

Graafisista työkaluista en tiedä.

smartmontools-paketissa on myös smartd, jonka voi asettaa seuraamaan levyn kuntoa taustalla. Sen saa varmaan jollain konstilla hälyttämään muutoksista.

Sitten on tietysti lähinnä palvelinjärjestelmien valvontaan tehtyjä ohjelmistoja kuten Zabbix, joihin saattaa saada smartd:n tiedot myös, ja niistä voi sitten tehdä graafisia raportteja ja muuta. Pelkästään kovalevyn seuraamiseen sellainen voi olla turhan järeä.

edit: hidas
 
Täytyy jossain vaiheessa yrittää tuota var/log/journal hakemiston luomista. Arvaan ettei se Linuxissa onnistu vaan hiiren oikeaa näppäintä klikkaamalla ja valitsemalla, että uusi hakemisto ja nimi on tälläinen.

Mutta nyt kun olen yrittänyt huolellisesti seurata tuota boottaamista, niin mitä ilmeisemmin se tietokone kaatuu boottaamisen aikana eli ei ole kyse siitä, että Linux lataantuu luonnollisesti ja kuva jää puuttumaan, vaan se kaatuu kesken kaiken.

Normi bootti menee niin, että kun biosin logosta pääsee eteenpäin, niin se miettii joku kymmenen sekuntia ja alkaa sitten lataamaan Linuxia. Siinä on koko ajan sellainen punainen tausta, sitten se tausta pimenee hetkeksi ja näytölle tulee Ubuntun logo. Sitten se pimenee taas, näytöllä on joku koodinpätkä ja taas pimenee. Siitä n. viisi sekuntia ja työpöytä tulee esiin. HD-valo palaa koko ajan työskentelyn merkiksi.

Kun kone kaatuu, niin se pääsee tuohon punaiseen taustaan, mutta kun se punainen tausta pimenee ja pitäisi tulla Ubuntun logo, niin siihen kohtaan jämähtää. HD:n merkkivalo sammuu ja mitään ei tapahdu. Sitten on vain bootattava uudestaan.

Ja kun siihen Linuxiin on päästy, niin sen jälkeen kaikki tuntuu toimivan ja voi myös bootata vaika kuinka monta kertaa uudestaan ja aina onnistuu.
 
Mulla on tapahtunut viime aikoina muutaman kerran viikossa Ubuntu 18.04:llä seuraavaa:

-tietokone käynnistyy normaalisti -> kirjautumisnäyttö tulee näkyviin -> kirjoita salasana -> Ubuntun työpöytä
mutta toisinaan käykin näin:
-typota salasana kirjautumisruudussa -> kirjoita salasana oikein -> "violetti" tausta jää näkyviin ja siihen sitten jäädäänkin eli työpöydälle ei pääse ja ainoana vaihtoehtona on käynnistää tietokone virtanapin suosiollisella avustuksella uudelleen
 
Täytyy jossain vaiheessa yrittää tuota var/log/journal hakemiston luomista. Arvaan ettei se Linuxissa onnistu vaan hiiren oikeaa näppäintä klikkaamalla ja valitsemalla, että uusi hakemisto ja nimi on tälläinen.

Mutta nyt kun olen yrittänyt huolellisesti seurata tuota boottaamista, niin mitä ilmeisemmin se tietokone kaatuu boottaamisen aikana eli ei ole kyse siitä, että Linux lataantuu luonnollisesti ja kuva jää puuttumaan, vaan se kaatuu kesken kaiken.

Normi bootti menee niin, että kun biosin logosta pääsee eteenpäin, niin se miettii joku kymmenen sekuntia ja alkaa sitten lataamaan Linuxia. Siinä on koko ajan sellainen punainen tausta, sitten se tausta pimenee hetkeksi ja näytölle tulee Ubuntun logo. Sitten se pimenee taas, näytöllä on joku koodinpätkä ja taas pimenee. Siitä n. viisi sekuntia ja työpöytä tulee esiin. HD-valo palaa koko ajan työskentelyn merkiksi.

Kun kone kaatuu, niin se pääsee tuohon punaiseen taustaan, mutta kun se punainen tausta pimenee ja pitäisi tulla Ubuntun logo, niin siihen kohtaan jämähtää. HD:n merkkivalo sammuu ja mitään ei tapahdu. Sitten on vain bootattava uudestaan.

Ja kun siihen Linuxiin on päästy, niin sen jälkeen kaikki tuntuu toimivan ja voi myös bootata vaika kuinka monta kertaa uudestaan ja aina onnistuu.
Ubuntusta en ihan liikaa tiedä, mutta kyllä se vaikuttaisi ihan siltä että luot vain tuon kansion ja se on siinä. Tarvitset vain pääkäyttäjän oikeudet, koska kyseessä on systeemihakemisto.
Tarkemmin jos ohjeita tarvitset niin Ubuntulle oli kirjattu notta:
sudo mkdir -p /var/log/journal
tai
sudo nano /etc/systemd/journald.conf
Ja "[Journal]" kohdan alta muokkaat "Storage=persistent"
Kumman tahansa valitset, pitäisi nyt käytössä olla pysyvät logit.
Datalogista selvinnee mikä sen kaataa. Siitä sitten voinee päätellä tarvittavia toimenpiteitä asian ratkaisemiseksikin.
 
Mikä on oikeaoppinen keino päästä pois siitä journalin lukemisesta terminaalissa? En keksinyt muuta kuin sulke koko terminaalin. ESC-nappi ei toiminut eikä mikään x:n painaminen, CTRL+x ei myöskään.

Ja onko mitään keinoa saada talletettua se haluttu journal johonkin erikseen? Nyt on siis kaatumisraportti ja siinä on yli 1300 riviä tekstiä ja sitä sitten voisi verrata onnistuneen boottauksen vastaavaan määrään rivejä. Olisin luullut, että kaatunut bootti olisi lyhyempi kuin onnistunut.

En tiedä sitten mitäköhän mä tollakin tiedolla osaan tehdä, mutta toki se sanoo selkeästi, että korjasi virheen, mutta reboot on välttämätön.

Enpä tiedä mikäköhän on ratkaiseva virhe, mutta pitäisi just vertailla rivi-riviltä onnistunutta ja epäonnistunutta boottia, mieluiten vielä että saan siirrettyä ne jossain tekstimuodossa tähän mun windows koneeseen. Pirun paljon helpompaa lukea tekstiä monitorin ruudulta kuin telkun näytöltä.

Mutta copy-pastasin nyt tekstinkäsittelyohjelmaan terminaalista loppupätkän raporttia.
Dropbox - kaatuminen.doc

Jos joku tosta viitsii katsoa, että mikä on syypää. Mikäli siis tosta selviää, mutta nopeasti katsoen tosta tulee eka virhe, mikä on punaisella merkattu kernelissä, mun copy-pastessa värit katosivat. Toki 1300 riviä, kun vaan äkkiä silmäilee läpi, niin ei ihan kaikki osu silmään.

Eli tää olisi eka virhe, aloitin kopsaamisen vähän aikaisemmin.
touko 28 20:31:15 jori-MS-7972 kernel: IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
Siinä on sitten pari riviä virheitä samasta aiheesta.

Sitten tulee vielä joku bugilmoitus.
touko 28 20:31:15 jori-MS-7972 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008

Sitten ilmoittaa, että ei onnistu, reboottia kaivataan.
touko 28 20:31:17 jori-MS-7972 kernel: Fixing recursive fault but reboot is needed!

Tonkin jälkeen on vielä vaikka kuinka monta riviä, kunnes sitten lopulta sammutan vehkeen.

Jos joku tosta tietää, että mikä on vialla, niin hyvä on.
 
Olikohan se journali auki vi:llä, siitä ainakin pääsee kirjoittamalla :q ja painamalla enter.
 
Olikohan se journali auki vi:llä, siitä ainakin pääsee kirjoittamalla :q ja painamalla enter.
Terminaalissa luin sitä. Mikä vi on ja onko sillä fiksumpaa lukea noita?
Saanko siis jotenkin talletettua sen johonkin normaaliin tektstimuotoon, niin ei tarvitse tuota journalctl -b -X komentoa käyttää ja sitten joka kerta lisätä yhdellä numerolla, että aukeaa oikea journal?
 
vi on tekstieditori, moni työkalu avaa tekstitiedostot oletusarvoisesti siinä, jos muuta ei ole määritelty environmental variablella (esim. kirjoittamalla "export EDITOR=nano" asettaa sen kyseisen session oletuseditoriksi nanon).

Tuosta löytyy tietoa miten journalctl-komento toimii: systemd - ArchWiki
 
millä komennolla luit sitä? Millä sanalla rivi alkoi? cat, vi, vim, nano, pico...

Täsmällinen komento oli journalctl -b -1 ja se aukeni suoraan siihen terminaaliin. Ainakin luulen niin, koska siltä se näytti.
Koitin vi journalctl -b -1 ja tuli ilmoitus, että -1 unkown option argument.
Jos jättää tuon -1 pois, niin ei se siltikään avaa sitä journal raporttia, vaan pelkkä ohjelma aukenee.

Koitin myös nano:a laittaa eteen, eikä aukea silläkään.
 
Terminaalissa luin sitä. Mikä vi on ja onko sillä fiksumpaa lukea noita?
Saanko siis jotenkin talletettua sen johonkin normaaliin tektstimuotoon, niin ei tarvitse tuota journalctl -b -X komentoa käyttää ja sitten joka kerta lisätä yhdellä numerolla, että aukeaa oikea journal?

Siis journalctl oli komento jolla sitä luit. Ellei sitä erityisesti kielletä tai ohjata komennon tulostusta tiedostoon, se käyttää sivutinta (pager), joita on useita vaihtoehtoja, mutta oletusarvoinen taitaa olla "less". Siitä pääsee pois painamalla q-näppäintä, ja Control-C (= yleinen "keskeytä tämä komento" -näppäinyhdistelmä) pitäisi toimia myös.

Ja tekstitiedostoon journalctl:n tulosteen saa laittamalla komennon perään suurempi kuin-merkin ja halutun tiedoston nimen. (Sen voi ajatella vaikka suppiloksi johon rivillä aiempana olevan komennon tuloste kipataan.) Journalctl on tarpeeksi fiksu hoksaamaan että tällöin ei sivutinta tarvita, eli koko sen boottikerran sisältö menee tekstitiedostoon saman tien ilman välilyönnin hakkaamista tai muuta sähellystä.

Eli näin: journalctl -b -1 > tiedosto.txt
 
Mulla on tapahtunut viime aikoina muutaman kerran viikossa Ubuntu 18.04:llä seuraavaa:

-tietokone käynnistyy normaalisti -> kirjautumisnäyttö tulee näkyviin -> kirjoita salasana -> Ubuntun työpöytä
mutta toisinaan käykin näin:
-typota salasana kirjautumisruudussa -> kirjoita salasana oikein -> "violetti" tausta jää näkyviin ja siihen sitten jäädäänkin eli työpöydälle ei pääse ja ainoana vaihtoehtona on käynnistää tietokone virtanapin suosiollisella avustuksella uudelleen

Hep,
Onko mikä näyttis ja mitkä ajurit käytössä?
Ilman virtanappia tuosta pääsee todnäk ohi käynnistämällä ikkunoinnin uudestaan terminaalin puolelta, esim. ctrl+alt+f1 -> kirjaudu sisään -> systemctl restart <ikkunointi> -> takaisin ikkunointiin, joka yleensä ctrl+alt+f7.
 
Siis journalctl oli komento jolla sitä luit. Ellei sitä erityisesti kielletä tai ohjata komennon tulostusta tiedostoon, se käyttää sivutinta (pager), joita on useita vaihtoehtoja, mutta oletusarvoinen taitaa olla "less". Siitä pääsee pois painamalla q-näppäintä, ja Control-C (= yleinen "keskeytä tämä komento" -näppäinyhdistelmä) pitäisi toimia myös.

Ja tekstitiedostoon journalctl:n tulosteen saa laittamalla komennon perään suurempi kuin-merkin ja halutun tiedoston nimen. (Sen voi ajatella vaikka suppiloksi johon rivillä aiempana olevan komennon tuloste kipataan.) Journalctl on tarpeeksi fiksu hoksaamaan että tällöin ei sivutinta tarvita, eli koko sen boottikerran sisältö menee tekstitiedostoon saman tien ilman välilyönnin hakkaamista tai muuta sähellystä.

Eli näin: journalctl -b -1 > tiedosto.txt

No niin. Nyt mulla on tallessa onnistunut bootti ja kaatumiseen johtanut tapaus. Siinä sitten katson, että missä kohtaa alkaa menemään vikaan.
On tossa onnistuneessakin bootissa jotain virheilmoituksia.

Katsotaan, jos näkyy selvästi, että mikä onnistuu toisessa ja toisessa ei.
 
@Lallijuoppo
enp2s0: link is not ready -virhe tuota ei aiheuta. Se vain kertoo ettei yhteys ollut valmis silloin kuin se olisi halunnut.
Tuota kernel bugia pitäisin tämän aiheuttajana. Pikaisella haulla varsin yleinen asia ja tästä on bugireportteja kaikkialla, mutta Debianin reportissa luki:
Found in version linux/4.4.6-1
Fixed in versions linux/4.5.4-1, 4.5.4-1

Joten tarkistappa vaikka siitä ensin mikä kerneli sinulla on ja suosittelen nyt sitä päivitystä. En tiedä onko tuolle Ubuntun versiolle uudempaa kerneliä olemassa, jos on niin sekin voisi auttaa eikä koko järjestelmää tarvitse päivittää uudempaan, jos haluat vanhalla softalla mennä.
Kernelin voi tarkistaa aukaisemalla päätteen ja syöttämällä "uname -r". Vastauksena se sylkäisee kernelin version.
 
Hep,
Onko mikä näyttis ja mitkä ajurit käytössä?
Ilman virtanappia tuosta pääsee todnäk ohi käynnistämällä ikkunoinnin uudestaan terminaalin puolelta, esim. ctrl+alt+f1 -> kirjaudu sisään -> systemctl restart <ikkunointi> -> takaisin ikkunointiin, joka yleensä ctrl+alt+f7.
Näytönohjain tónmmuistaakseni Intel HD Graphics 4400 tmv. ja ajurit todennäköisesti Ubuntun mukana tulevat kun en ainakaan muista itse mitään asennelleeni (kone on fyysisesti eri paikassa niin saatan huomenna ehtiä tsekkaamaan)
 

Statistiikka

Viestiketjuista
258 385
Viestejä
4 493 618
Jäsenet
74 123
Uusin jäsen
Eezy

Hinta.fi

Back
Ylös Bottom