Viestit

1

Asentaminen ja käyttöönotto / Vs: Grub:ista avattu Ubuntu haluaa kerneliä [Ratkaistu]

« : 29.02.24 - klo:22.50 »

Onnistui! Kiitos!

2

Asentaminen ja käyttöönotto / Grub:ista avattu Ubuntu haluaa kerneliä [Ratkaistu]

« : 29.02.24 - klo:15.05 »

Tuohon puolison vanhaan läppäriin halusin asentaa UEFI -moodissa Ubuntun vanhan Winkun rinnalle. Asennus meni hyvin ja käynnistyksessä Grub -valikko tuli esiin, mutta Ubuntun käynnistyksen jälkeen tulee ilmoitus:

error: shim_loc protocol not found.
error: you need to load the kernel first.

Press any key to continue...

any key palauttaa grubin valikkoon tai ajan kanssa palaa itsekseenkin grubiin.
Missä vika?

3

Asentaminen ja käyttöönotto / Vs: Netti hukassa

« : 25.02.24 - klo:22.45 »

Ei taida kannattaa enää nähdä sen enempää vaivaa. En olisi viitsinyt hankkia tyhjää muistitikkua ja asentaa 22.04. Mutta kun tuli selväksi, että 22.04 kannattaa asentaa, niin hankin tikun ja siihen 22.04.4 Ubuntun sekä asensin sen tuohon puolison uuteen läppäriin. Siinäkin oli mutkansa, kun siinä piti ensin sulkea BitLockkeri, kun halusin säästää Windows:in parin vain siinä tomivan ohjelman vuoksi (kehityshommia). Nyt vain tiedostojen siirto ja homma pelaa. Vanha läppäri palveli hyvin 12 vuotta.
Kiitos kuitenkin neuvoista.

4

Asentaminen ja käyttöönotto / Netti hukassa [Ratkaistu]

« : 23.02.24 - klo:18.46 »

Taitaa olla niin, että Ubuntu 20.04 ei ole yhteensopiva Wi-Fi standardin 802.11 kanssa, kun ei loydä uudesta läppäristä ko Wi-Fi modulia. Kokeilin Lubuntun 22.04:llä niin se kyllä löysi WI-Fi verkon.

5

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 02.11.23 - klo:19.05 »

Ubuntu@22.04 LTS:~$ ls -l /var/crash
yhteensä 16364
-rw-r----- 1 root    whoopsie 1458678 loka   27 17:18 friendly-recovery.0.crash
-rw------- 1 root    whoopsie 1486677 loka   27 17:20 grub-pc.0.crash
-rw-r--r-- 1 root    whoopsie 1295858 loka   27 17:24 linux-image-5.15.0-87-generic.0.crash
-rw------- 1 root    whoopsie  131887 loka   27 17:48 linux-image-5.4.0-165-generic.0.crash
-rw-r----- 1 root    whoopsie 1336410 loka   27 17:13 memtest86+.0.crash
-rw-r----- 1 admin whoopsie 6030107 loka   27 17:58 _usr_bin_DigiSignApplication.bin.1002.crash
-rw-r----- 1 root    whoopsie 5000663 loka   29 23:11 _usr_lib_virtualbox_VirtualBoxVM.0.crash
Ubuntu@22.04 LTS:~$

Tällaisen listauksen sain.

6

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 02.11.23 - klo:13.29 »

Secure boot ei ole ollenkaan käytössä eli siitä ei selitystä löydy.

Hmm. Minkä virheen saat jos yrität ladata vboxdrv-moduulin manuaalisesti:

Koodia: [Valitse]

sudo modprobe vboxdrv

Mitkä virtualbox-paketit järjestelmään on nyt asennettu:

Koodia: [Valitse]

dpkg -l | grep virtualbox

Entä onko kernelin headerit asennettu:

Koodia: [Valitse]

dpkg -l |grep linux-headers
Tarvitset paketin linux-headers-generic-hwe-22.04, kun käytössä on HWE-kerneli. Jos puuttuu, asenna paketti:

Koodia: [Valitse]

sudo apt install linux-headers-generic-hwe-22.04
Käännä sitten VirtualBoxin ajurimoduulit uudelleen:

Koodia: [Valitse]

sudo dpkg-reconfigure virtualbox-dkms

Näiden kaikkien toimenpiteiden jälkeen VirtualBox alkoi toimia normaalisti. Eli sieltä puuttui tuo 'linux-headers-generic-hwe-22.04' ja luulen, että silloin päivitettäessä 20.04 -> 22.04 olisi myös tuon latauksesta valittanut, mutta kun jatkoi päivitystä siitä huolimatta ja meni loppuun, niin en sitten ollut kirjannut ylös kaikkia niitä ilmoituksia joita päivityksessä tuli esiin.
Nyt on sitten vielä jäljellä Järjestelmäohjelma-virhe. Vaikka siittä 'Ilmoita ongelmasta' -napista painaakin, niin ei mene mihinkään lokiin vaan virheilmoitus vain katoaa. Mistähän sen lokin löytäisi mistä voisi ryhtyä ongelmaa etsimään?
Suuri kiitos näistä erinomaisista ohjeista! Saatiin ainakin kaikkein haittaavin ongelma ratkaistua.

7

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 01.11.23 - klo:16.50 »

Secure boot ei ole ollenkaan käytössä eli siitä ei selitystä löydy.

8

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 01.11.23 - klo:15.05 »

Sama vastaus ilman hattu-merkkiä.

Kokeilepa

Koodia: [Valitse]

sudo apt purge virtualbox eli ilman pistettä.
https://packages.ubuntu.com/search?keywords=virtualbox&searchon=names&suite=jammy&section=all

Tuolla komennolla näytti poistavan jotakin ja uudelleen asennettuna toiminta edelleen sama eli VirtualBoxiin asennetut käyttöjärjestelmät eivät käynnisty, vaan valittaa VirtualBoxin kernelistä.

9

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 31.10.23 - klo:20.00 »

Sama vastaus ilman hattu-merkkiä.

10

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 31.10.23 - klo:19.50 »

Hyvä, mutta olen hiukan epävarma syntaksin kanssa. Voisinko saada komentojen oikean syntaksin?

Poista kaikki virtualbox-sanalla alkavat paketit:

Koodia: [Valitse]

sudo apt purge ’^virtualbox.*’

Antoi tällaisen tuloksen:

Luetaan pakettiluetteloita... Valmis
Muodostetaan riippuvuussuhteiden puu... Valmis
Luetaan tilatiedot... Valmis                 
E: Pakettia ’^virtualbox.*’ ei löydy

11

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 31.10.23 - klo:17.50 »

Olisi tietenkin kiva päästä eroon noista ilmoituksista.

12

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 31.10.23 - klo:17.34 »

Hyvä, mutta olen hiukan epävarma syntaksin kanssa. Voisinko saada komentojen oikean syntaksin?

13

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 31.10.23 - klo:13.21 »

Luultavasti VirtualBoxin kernelimoduulien kääntämisessä on ongelmaa. Poista kaikki VirtualBoxin paketit järjestelmästä ja asenna uudelleen päätteessä apt:lla. Tarkista listauksesta, että moduulit kääntyvät virheettä asennuksen yhteydessä.

Häviääkö sitten kaikki ne käyttöjärjestelmmät, jotka on VirtualBoxiin asennettu?

Niin, ei se automaattisesti sitä tee, vaan olet konfiguroinut järjestelmän niin. Tai ehkä olet kloonannut aiemmin levyjä tai osioita siten, että osioilla on identtiset UUID:t.

Tuo selitys on ilmeinen, koska juuri tuo sisäinen kovalevy on kloonattu aikanaan tuosta ulkoisesta. Silloin vaihdoin HDD:stä SSD:hen.

14

Asentaminen ja käyttöönotto / Vs: Päivityksen 20.04 - 22.04 seurannaisongelmat

« : 31.10.23 - klo:13.02 »

Joo, olen aivan varma, sillä sisäisen kiintolevyn HOME-osiolla on tietoja, jotka on sinne tehty sinä aikana kun ulkoinen kiintolevy oli irrallisena laatikossa, siis useamman kuukauden ajan ja näkyvät ulkoiselta levyltä käynnistettäessä hyvin. Ja toisaalta gparted:in mukaankin sisäisen kiintolevyn HOME -osio on mountattuna ja ulkoisen ei. Ihmettelen vain, että ulkoiselta kiintolevyltä käynnistettäessä osasi järjestelmä mountata sisäisen kiintolevyn HOME -osion automaattisesti. Sitä kyllä halusinkin, mutta ei kai se nyt ajatuksia osaa lukea.

15

Asentaminen ja käyttöönotto / Päivityksen 20.04 - 22.04 seurannaisongelmat [Ratkaistu]

« : 31.10.23 - klo:11.14 »

Edellisessä päivitykseen 20.04 - 22.04 liittyvissä asioissa kaikki näytti tulevan kuntoon ja jokin uusi päivityskin tuli asennettua. Kuitenkin huomasin, että edelleen ilmoittelee käyttöjärjestemäohjema -virheestä. No senkin kanssa voisi elää, mutta VirtualBox lakkasi toimimasta jo ennen tuota viimeisintä päivitystä eli silloin kun kerneli vaihtui uudempaan. VirtualBox kyllä käynnistyy, mutta sinne asennetut käyttöjärjestelmät eivät käynnisty. Lopulta päädyin käynnistämään ulkoiselta kovalevyltä (siltä, mistä pöytäkoneessa nyt oleva sisäinen kovalevy oli kloonattu) siinä oli siis vielä Ubuntu 20.04 ja se käynnistyi hyvin, eikä ilmoitellut mistään ongelmasta. VirtualBox:issa olevat käyttöjärjestelmät käynnistyivät myös asiallisesti. Mielenkiintoista oli se, että tämä ulkoiselta kovalevyltä käynnistetty Ubuntu käytti sujuvasti pöytäkoneen kovalevyllä olevaa HOME -osiota, eikä sitä HOME -osiota, joka on sillä ulkoisella kovalevyllä.
Nyt sitten kysymys: että voiko vain sen osion ulkoiselta kovalevyltä, jolta kone on käynnistetty, kloonata sisäiselle kovalevylle, niin että se toimii kuten nyt ulkoiselta kovalevyltä käynnistettynä? Siis jos tämä onnistuisi niin säästyisi melkoisesti vaivaa ja aikaa koko levyn kloonamisesta (siis täytyisi ensin kopioida  sisäisen kovalevyn HOME -osio ulkoiselle kovalevylle ja sitten kloonata koko levy sisäiselle kovalevylle ja asentaa ne kaikki nyt sisäisellä kovalevyllä olevat muut distrot, joita ei ulkoisella nyt ole, uudestaan).

16

Asentaminen ja käyttöönotto / Vs: Päivitysongelma 20.04 - > 22.04

« : 29.10.23 - klo:17.59 »

Siinähän se vika olikin, tosin ei x ollut liikaa, vaan välilyönneistä oli kysymys. On kysymys näytöntarkkuudesta ja siinä oli jäänyt sen kertaa merkin (x) eteen ja taakse välilyönti. Nyt kaiketi järjestelmä toiminee.

Ja nyt on sitten käynnistetty uudelleen ja kerneli on vaihtunut uudempaan: 6.2.0-35-generic. Edelleen kuitenkin ilmoittaa järjestelmäongelmasta. Joskohan tuo ilmoitus häviäisi seuraavan päivityksen myötä.

17

Asentaminen ja käyttöönotto / Vs: Päivitysongelma 20.04 - > 22.04

« : 29.10.23 - klo:14.49 »

Tässä listaus "Haluatko jatkaa? [K/e]" kysymyksen jälkeen:

(Luetaan tietokantaa... 302030 tiedostoa ja hakemistoa asennettu tällä hetkellä.)
Poistetaan linux-image-5.4.0-165-generic (5.4.0-165.182)...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-5.4.0-165-generic
/etc/kernel/postrm.d/zz-update-grub:
Sourcing file `/etc/default/grub'
/usr/sbin/grub-mkconfig: 27: /etc/default/grub: x: not found
run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return code 127
dpkg: error processing package linux-image-5.4.0-165-generic (--remove):
 installed linux-image-5.4.0-165-generic package post-removal script subprocess returned error exit status 1
dpkg: too many errors, stopping
Käsittelyssä tapahtui liian monta virhettä:
 linux-image-5.4.0-165-generic
Käsittely keskeytettiin liian monien virheiden takia.
E: Sub-process /usr/bin/dpkg returned an error code (1)

Näyttäisi ainakin grub:iin liittyvää ongelmaa olevan. Tuntuu omituiselta että ei löydä /etec/default/grub , vaikka se kyllä näyttäisi siellä olevan.

18

Asentaminen ja käyttöönotto / Vs: Päivitysongelma 20.04 - > 22.04

« : 28.10.23 - klo:22.58 »

Koitin tuota kernelin asennusta: sudo apt install linux-image-generic-hwe-22.04

Mutta "Käsittely keskeytettiin liian monien virheiden takia."

Luulen ettei tuosta oikein kunnollista tule. Eli täytynee siirtää kamat tuohon puhtaaseen asennukseen.

19

Asentaminen ja käyttöönotto / Vs: Päivitysongelma 20.04 - > 22.04

« : 28.10.23 - klo:15.54 »

No niin, sitten on päivitetty 22.04 LTS:ään. Ja koko homma meni kiville, niin kuin ounastelin. Päivitys lähti hyvin alkuun, mutta sitten tuli useita ilmoituksia, että jotain ei voitu tehdä, mutta päivitystä jatketaan. Loppuun meni, mutta ei tavanomaisesti. Kun käynnistin sitten uudelleen, niin meni kernel paniikkiin ja homma tyssäsi siihen. Kuitenkin muista vaihtoehdoista löytyi aiempi kernel, jolla suostui käynnistymään. Jotenkin molemmat kernelit näyttivät vanhoilta, kun vertasin siihen puhtaaseen asennukseen. Eli: 5.4.0-165-generic meni paniikkiin, mutta 5.4.0-163-generic käynnistyi. Suurin piirtein systeemin toimii (kaikkea en ole vielä kokeillut), mutta Firefox ei kännistynyt. Siis todella monen mutkan kautta sain sen vanhan poistettua (kun oli ja ei ollut olemassa) ja asensin uuden sekä varmuuskopiolta kirjanmerkit, niin ainakin näennäisesti toimii.
Infossa sanoo version olevan 22.04  Jammy Jellyfish eli ainakin sen kohdan on päivittänyt. Tuo kernel vain ihmetyttää.

Koska minulla on tuo puhdas asennus, niin mitä kaikkea pitäisi tehdä, että saisin erillisellä osiolla olevan HOME:n sen käyttöön. Käsittääkseni fstab:iin pitää laittaa HOME -osion UUID, mutta pitääkö sitä ennen jotain tehdä asennuksessa jo olevalle HOME -hakemistolle? Tietenkin kaikki lisäohjelmat, joita on muutamia, pitää asentaa uudestaan, mutta asetukset niihin tullenee HOME -osiolta.

20

Asentaminen ja käyttöönotto / Vs: Päivitysongelma 20.04 - > 22.04

« : 27.10.23 - klo:16.41 »

Tällaista antoi  ls /etc/apt/sources.list.d

Ubuntu@20.04 LTS:~$ ls /etc/apt/sources.list.d
nilarimogard-ubuntu-webupd8-bionic.list
nilarimogard-ubuntu-webupd8-bionic.list.distUpgrade
signal-xenial.list
signal-xenial.list.distUpgrade
teams.list
teams.list.distUpgrade
teamviewer.list
teamviewer.list.distUpgrade
teamviewer.list.save

Okei. Tuollahan se signal lähde on. Mutta pitääköhän nuo muutkin lähteet poistaa tuolta/etc/apt/sources.list.d, jotta pystyy päivittämään uudempaan Ubuntuun?

Ainakaan noita signalista eteenpäin olevia en taida tarvita mihinkään.