Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Asentaminen ja käyttöönotto => Aiheen aloitti: jarmala - 14.05.25 - klo:20.54
-
Vanhassa pöytäkoneessa on Ubuntu 18.04. Se varmaankin kaipaa päivitystä uudempiin versioihin. Samalla ajattelin vaihtaa vanhan 120 GB SSD:n isompaan 480 GB SSD:hen. Tilanne on nyt seuraava:
$ blkid
/dev/sda1: UUID="f0e6ce1c-f61c-4d10-9c62-4d4afa9a1b3f" TYPE="ext4" PARTUUID="e3f66b92-01"
/dev/sda5: UUID="39c2b1c4-bc47-4aeb-89de-3502fd527d21" TYPE="ext4" PARTUUID="e3f66b92-05"
/dev/sdb1: LABEL="100GB" UUID="b77d9e71-7ab3-4afc-a567-ae779e21edc3" TYPE="ext4" PARTUUID="95621e3e-01"
/dev/sdb5: LABEL="380GB" UUID="745aec66-bb95-4e16-b24c-435076f962d4" TYPE="ext4" PARTUUID="95621e3e-05"
/dev/sdc: LABEL="4t" UUID="f61321df-ad4c-4897-8689-f3dbfce89a7d" TYPE="ext4"
ari@ari:/$ df -h | grep -v loop | grep -v tmpfs
Tiedostojärjestelmä Koko Käyt Vapaa Käy% Liitospiste
udev 3,9G 0 3,9G 0% /dev
/dev/sda1 28G 22G 4,5G 83% /
/dev/sda5 82G 31G 48G 39% /home
/dev/sdc 3,6T 1,8T 1,7T 53% /mnt/f61321df-ad4c-4897-8689-f3dbfce89a7d
/dev/sdb1 98G 24K 93G 1% /media/ari/100GB
ari@ari:/$ ll
yhteensä 108
drwxr-xr-x 24 root root 4096 touko 14 20:33 ./
drwxr-xr-x 24 root root 4096 touko 14 20:33 ../
drwxr-xr-x 2 root root 4096 maali 8 2023 bin/
drwxr-xr-x 3 root root 4096 tammi 23 2024 boot/
drwxrwxr-x 2 root root 4096 marra 29 2017 cdrom/
drwxr-xr-x 21 root root 5040 touko 14 12:56 dev/
drwxr-xr-x 178 root root 12288 helmi 20 21:59 etc/
drwxr-xr-x 5 root root 4096 joulu 13 2018 home/
lrwxrwxrwx 1 root root 34 kesä 29 2023 initrd.img -> boot/initrd.img-4.15.0-213-generic
lrwxrwxrwx 1 root root 34 kesä 29 2023 initrd.img.old -> boot/initrd.img-4.15.0-212-generic
drwxr-xr-x 23 root root 4096 kesä 11 2022 lib/
drwxr-xr-x 2 root root 4096 touko 28 2022 lib64/
drwx------ 2 root root 16384 marra 29 2017 lost+found/
drwxr-xr-x 3 root root 4096 marra 29 2017 media/
drwxr-xr-x 6 root root 4096 elo 4 2021 mnt/
drwxr-xr-x 4 root root 4096 syys 17 2020 opt/
dr-xr-xr-x 400 root root 0 maali 3 11:58 proc/
drwx------ 9 root root 4096 tammi 19 2023 root/
drwxr-xr-x 39 root root 1240 touko 14 15:29 run/
drwxr-xr-x 2 root root 12288 elo 7 2024 sbin/
drwxr-xr-x 23 root root 4096 huhti 15 18:24 snap/
drwxr-xr-x 3 root root 4096 joulu 2 2017 srv/
dr-xr-xr-x 13 root root 0 touko 14 20:26 sys/
drwxrwxrwt 22 root root 4096 touko 14 20:33 tmp/
drwxr-xr-x 11 root root 4096 elo 5 2019 usr/
drwxr-xr-x 14 root root 4096 loka 18 2017 var/
lrwxrwxrwx 1 root root 31 kesä 29 2023 vmlinuz -> boot/vmlinuz-4.15.0-213-generic
lrwxrwxrwx 1 root root 31 kesä 29 2023 vmlinuz.old -> boot/vmlinuz-4.15.0-212-generic
Eli /dev/sda1:n sisältö pitäisi saada siirretyksi /dev/sdb1:lle niin, että se buuttaa uudesta sijainnistaan. Ajattelin umountata /home:n ja sen jälkeen kopata kaiken juuresta:
cp -arv /* /media/ari/100GB
Mutta miten se hanskaa tuon /media -alihakemiston, koska sehän on myös mountattu juureen? Miten estän /media -hakemiston kopioitumisen itseensä? Miten tämä pitäisi oikein tehdä?
Muuten, kokeilin piruuttani vetää myös dd:llä suoraan, mutta tulos ei ollut toivottu eli tiedostoja ei näy kohteessa.
$ sudo dd if=/dev/sda1 of=/dev/sdb1 bs=100M status=progress
29989273600 bytes (30 GB, 28 GiB) copied, 232 s, 129 MB/s
286+1 tietuetta sisään
286+1 tietuetta ulos
29998710784 bytes (30 GB, 28 GiB) copied, 231,781 s, 129 MB/s
ari@ari:~$ ll /media/ari/100GB/
ls: tiedostoa '/media/ari/100GB/i2c-mux.ko' ei voi käsitellä: Virheellinen viesti
ls: tiedostoa '/media/ari/100GB/busses' ei voi käsitellä: Virheellinen viesti
ls: tiedostoa '/media/ari/100GB/muxes' ei voi käsitellä: Virheellinen viesti
ls: tiedostoa '/media/ari/100GB/i2c-stub.ko' ei voi käsitellä: Virheellinen viesti
ls: tiedostoa '/media/ari/100GB/i2c-smbus.ko' ei voi käsitellä: Virheellinen viesti
ls: tiedostoa '/media/ari/100GB/algos' ei voi käsitellä: Virheellinen viesti
yhteensä 8
Miten tämä juuriosion siirto olisi fiksuinta tehdä?
-
Eipä ole käynyt mielessä, että toimiiko dd osioiden kanssa? Uskoisin että ei. Itse olen käyttänyt kyllä ilman "ykkösiä" ja ja päässyt haluttuun tavoitteeseen.
-
Eli /dev/sda1:n sisältö pitäisi saada siirretyksi /dev/sdb1:lle niin, että se buuttaa uudesta sijainnistaan. Ajattelin umountata /home:n ja sen jälkeen kopata kaiken juuresta:
cp -arv /* /media/ari/100GB
Mutta miten se hanskaa tuon /media -alihakemiston, koska sehän on myös mountattu juureen? Miten estän /media -hakemiston kopioitumisen itseensä? Miten tämä pitäisi oikein tehdä?
Vivulla -x onnistuu niin että cp ei kopioi muista kuin juuriosion tiedostojärjestelmästä, eli mm. /dev, /media ja /proc -hakemistoihin liitetyt tiedostojärjestelmät eivät siirry:
cp -ax / /media/ari/100GB/
Tuossa on sitten vielä oma virittelynsä saada GRUB käynnistymään uudelta osiolta.
-
https://wiki.archlinux.org/title/Dd auttaisko?
-
No nyt pääsin vauhtiin osioiden siirron kanssa:
- varakopiot otettu
- buutti Ubuntu 24.04 -tikulta (hämmästyin, että vanha koneeni osasi buutata tikulta - en olisi osannut kuvitellakaan...)
- tarkistus disks -ohjelmalla levyjen ja osioiden nimet
- sitten vaan reteesti: dd:llä sda sdb:lle koko levyt
- disks -ohjelmalla sdb5:n poisto ja suurentamaan sdb1 30GB -> 80 GB
- sdb5:n luonti uudelleen
Tikku irti ja buuttia: Jälleen suuri hämmästys! Kone buuttasi suoraan sdb1:ltä ilman, että olin tehnyt mitään muutoksia fstabiin tai grubiin... Täysin hämmästyttävää.
================
EDIT: dd teki työtä käskettyä ja teki yksi yhteen kopion sda1 -osiosta sdb1:lle, joten samalla kopioitui myös sda1 -osion UUID -tunniste sdb1 -osiolle. Molempien osioiden UUID -tunnukset tulivat siis dd:n jäljiltä samoiksi. Grub taas ei varsinaisesti tiennyt, kummalta ykkösosiolta olisi pitänyt buutata, koska niillä oli sama UUID -tunnus. Grub sitten vaan arpoi aina jomman kumman buutattavaksi. Oikeastihan kahden levyosion UUID -tunnukset eivät voi (saa) olla samat, koska siihen ei ole koskaan varauduttu. Eli dd:llä kun kopioi levyjä, niin kohteen UUID:ksi tulee sama kuin lähteelläkin oli. Tune2fs:llä voi vaihtaa kopion UUID:n yksilölliseksi.
================
Vielä pitää cp -a -komennolla vetää se sda5 sdb5:lle.
Tiedostojärjestelmä Koko Käyt Vapaa Käy% Liitospiste
udev 3,9G 0 3,9G 0% /dev
/dev/sdb1 74G 24G 47G 34% /
/dev/sda5 82G 42G 36G 54% /home
/dev/sdc 3,6T 1,8T 1,7T 53% /mnt/f61321df-ad4c-4897-8689-f3dbfce89a7d
-
Miten saa selville, missä sijaitsevalta grubilta kone käynnistyy? Siis sda:lta vai sdb:ltä...
-
Miten saa selville, missä sijaitsevalta grubilta kone käynnistyy? Siis sda:lta vai sdb:ltä...
Jos kyseessä on perinteinen BIOS, voit katsoa käynnistysjärjestyksen BIOS-valikon kautta, jossa se on yleensä konfiguroitavissa boot-välilehdellä. Siellä voit määrittää, miltä levyiltä ja missä järjestyksessä BIOS etsii lataajaa. Täyden varmuuden saat ottamalla toisen levyn kokonaan irti väylästä tai virrasta.
Nykyisissä UEFI-koneissa käynnistysjärjestyksen voi selvittää efibootmgr-komennolla (https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#efibootmgr). Se näyttää, millä prioriteetilla eri levyillä ja EFI-osioilla sijaitsevia lataajia yritetään käynnistää. Efibootmgr:llä voi myös muuttaa käynnistysjärjestystä ja lisätä listaan omia käynnistysvaihtoehtoja. Joissain vanhemmissa koneissa nämä asetukset voivat tosin olla bugisia, tai niiden muuttaminen UEFI-asetusvalikon ulkopuolella voi olla oletuksena estetty.
-
Jos kyseessä on perinteinen BIOS, voit katsoa käynnistysjärjestyksen BIOS-valikon kautta, oletuksena estetty.
Ok, hyvä. Epäilen kuitenkin, että kone edelleen etsii grubia sda:lta, mutta tiedä sitä. Ainakin se on buutannut.
Nyt editoin fstab:iä. jotta saisin siirretyn home:n käyttöön sdb5:ltä. Nyt sitten kaikki menee pieleen, jos on mennäkseen... Kopsasin vanhan /home -rivin ja vaihdoin siitä UUID:n sdb5:n partitiolle. Onneksi huomasin ennen buuttia, että /home:een pitää tietenkin kopsata rsyncillä sda:n home -kansio, eikä pelkkää ari -kansiota. Korjaan sen heti...
-
Ok, hyvä. Epäilen kuitenkin, että kone edelleen etsii grubia sda:lta, mutta tiedä sitä. Ainakin se on buutannut.
Pitäisikö kuitenkin ajaa
grub-install sdb
ennen kuin rupeaa käpistelemään BIOSissa buuttijärjestystä?
-
Se sanoo:
$ grub-install sdb
Asennetaan i386-pc-alustalle.
grub-install: virhe: cannot backup `/boot/grub/i386-pc/normal.mod': Lupa evätty.
ari@ari:~$ sudo grub-install sdb
[sudo] ari-käyttäjän salasana:
Asennetaan i386-pc-alustalle.
grub-install: virhe: GRUB-levyaseman etsiminen kohteelle sdb epäonnistui. Tarkista device.map-tiedostosi.
ari@ari:~$ df -h | grep -v loop | grep -v tmpfs
Tiedostojärjestelmä Koko Käyt Vapaa Käy% Liitospiste
udev 3,9G 0 3,9G 0% /dev
/dev/sdb1 74G 24G 47G 34% /
/dev/sda5 82G 34G 45G 43% /home
/dev/sdc 3,6T 1,8T 1,7T 53% /mnt/f61321df-ad4c-4897-8689-f3dbfce89a7d
/dev/sdb5 366G 34G 314G 10% /media/ari/400GB
ari@ari:~$ locate device.map
ari@ari:~$
Mistään ei löytynyt moista tiedostoa...
-
Laite on /dev/sdb:
sudo grub-install /dev/sdb
-
Laite on /dev/sdb:
Kiitän. Neuvo tepsi. Pitäisi aina vähän ajatella itsekin...
$ sudo grub-install /dev/sdb
[sudo] ari-käyttäjän salasana:
Asennetaan i386-pc-alustalle.
Asennus on päättynyt. Virheitä ei löytynyt.
-
Nyt editoin fstab:iä. jotta saisin siirretyn home:n käyttöön sdb5:ltä. Nyt sitten kaikki menee pieleen, jos on mennäkseen... Kopsasin vanhan /home -rivin ja vaihdoin siitä UUID:n sdb5:n partitiolle. Onneksi huomasin ennen buuttia, että /home:een pitää tietenkin kopsata rsyncillä sda:n home -kansio, eikä pelkkää ari -kansiota. Korjaan sen heti...
Noniin. Uskalsin vihdoin buutata koneen fstabin editoinnin jälkeen. Hip! Ainakin kone buuttasi ja osiot näyttävät olevan nyt halutulla tavalla:
$ df -h | grep -v loop | grep -v tmpfs
Tiedostojärjestelmä Koko Käyt Vapaa Käy% Liitospiste
udev 3,9G 0 3,9G 0% /dev
/dev/sdb1 74G 24G 47G 34% /
/dev/sdb5 366G 34G 314G 10% /home
/dev/sdc 3,6T 1,8T 1,7T 53% /mnt/f61321df-ad4c-4897-8689-f3dbfce89a7d
Eli a1 ja a5 ovat nyt vaihtuneet käytössä oleviin b1 ja b5:een... Tähän asti hyvä. Edelleen on hieman mysteeri se grubin sijainti, mutta kai sen saa selville, kun irrottaa sda:n piuhan ja buuttaa.
Sitten lopulta pääsee päivittämään Ubuntun 18.04:stä eteenpäin kaksivuotisaskelin... 24.04 olisi jo nykyaikaa. Ja samalla pääsee näkemään, miten Ubuntun LTS -päivitykset sujuvat.
-
Ajoin päivityksen Ubuntuun 18.04 -> 20.04. Tunti siihen meni SSD -levyllä.. Ja kone buuttasi päivityksen jälkeen. Hip!
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
Nyt pitää päivä tai kaksi seurata toimintaa ettei mitään hämminkejä ole syntynyt.
-
Nyt pitää päivä tai kaksi seurata toimintaa ettei mitään hämminkejä ole syntynyt.
Kas, tomboy oli lakkautettu versioiden 18.04 ja 20.04 välillä. Onneksi on gnote, joka osaa käyttää tomboyn datatiedostoja, kunhan ne vaan siirtää gnoten hakemistoon. Kivaa, koska muistiinpanoja on vuosien mittaan kertynyt jo melko paljon...
-
Ostin halvalla 2 x 4 GB käytettyä DDR3 -muistia, joten nyt sitä on 16 GB. Kokeillaan nyt tällä jonkin aikaa.
-
Nyt päivitin Ubuntu 20.04 LTS:n uudempaan versioon, mutta se sanoo:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.6 LTS
Release: 18.04
Codename: bionic
ari@ari:~$ uname -a
Linux ari 5.15.0-161-generic #171-Ubuntu SMP Sat Oct 11 08:17:01 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Mitä ihmettä?
-
Nyt päivitin Ubuntu 20.04 LTS:n uudempaan versioon, mutta se sanoo:
Mitä ihmettä?
Ubuntu onkin buutannut vanhalta sda -levyltä eikä uudelta sdb -levyltä:
$ df -h | grep -v loop | grep -v tmpfs
Tiedostojärjestelmä Koko Käyt Vapaa Käy% Liitospiste
udev 7,7G 0 7,7G 0% /dev
/dev/sda1 28G 24G 2,7G 90% /
/dev/sda5 82G 34G 45G 43% /home
/dev/sdc 3,6T 1,8T 1,7T 53% /mnt/f61321df-ad4c-4897-8689-f3dbfce89a7d
$ lsblk | grep sd
sda 8:0 0 111,8G 0 disk
├─sda1 8:1 0 28G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 83,9G 0 part /home
sdb 8:16 0 447,1G 0 disk
├─sdb1 8:17 0 74,5G 0 part
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 372,6G 0 part
sdc 8:32 0 3,7T 0 disk /mnt/f61321df-ad4c-4897-8689-f3dbfce89a7d
Mikäs nyt tähän neuvoksi?
Vaikka grubista valitsee uusimman kernelin 5.15 niin silti mounttaatuvat vanhat osiot levyltä sda. Mitä paikkaa nyt pitäisi puukottaa?
-
Kaivelin vähän lisää. Grubin tiedostoissa viitataan buuttilevyyn UUID:llä f0e6ce..a1b3f. Sitten buutti ja tarkastamaan, mikä osio se on:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy
ari@ari:~$ lsblk | grep sd
sda 8:0 0 111,8G 0 disk
├─sda1 8:1 0 27,9G 0 part
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 83,8G 0 part
sdb 8:16 0 447,1G 0 disk
├─sdb1 8:17 0 74,5G 0 part /
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 372,6G 0 part /home
sdc 8:32 0 3,6T 0 disk /mnt/f61321df-ad4c-4897-8689-f3dbfce89a7d
ari@ari:~$ lsblk -f | grep sd
sda
├─sda1 ext4 1.0 f0e6ce1c-f61c-4d10-9c62-4d4afa9a1b3f
├─sda2
└─sda5 ext4 1.0 39c2b1c4-bc47-4aeb-89de-3502fd527d21
sdb
├─sdb1 ext4 1.0 f0e6ce1c-f61c-4d10-9c62-4d4afa9a1b3f 44,4G 35% /
├─sdb2
└─sdb5 ext4 1.0 400GB f47b7030-a042-4869-9feb-2a1b8bd57159 284,1G 17% /home
sdc ext4 1.0 4t f61321df-ad4c-4897-8689-f3dbfce89a7d 1,6T 50% /mnt/f61321df-ad4c-4897-8689-f3dbfce89a7d
Ja nyt yhtäkkiä Ubuntun versio onkin 22.04 LTS. MITÄ? Ja myös juuriosio ja home ovatkin nyt sdb -levyltä. Syypää tähän voi hyvinkin olla se, että sda- ja sdb -levyjen osioiden UUID:t ovat samat! Grub -ressukka ei ilmeisesti tiedä varmasti, kumman levyn ykkösosiolta pitäisi buutata...
Mitäs nyt tehdään?
Muutanko sda1:n UUID:tä? Siihen löytyy tekoälyn ohje googlella.
Vai nykäisenkö sda -levystä kaapelit irti?
-
Noniin:
$ sudo umount /dev/sda1
[sudo] ari-käyttäjän salasana:
umount: /dev/sda1: not mounted.
$ sudo e2fsck -f /dev/sda1
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Vaihe 4: Tarkastetaan viittausmääriä
Pass 5: Checking group summary information
/dev/sda1: 513698/1831424 tiedostoa (0.3 % epäjatkuvia), 6252687/7323904 lohkoa
ari@ari:~$ sudo tune2fs -U random /dev/sda1
tune2fs 1.46.5 (30-Dec-2021)
Setting the UUID on this filesystem could take some time.
Proceed anyway (or wait 5 seconds to proceed) ? (y,N) <jatketaan>
ari@ari:~$ lsblk -f | grep sd
sda
├─sda1 ext4 1.0 ced5f701-fa73-43a7-943e-5e8cf727a5c8
├─sda2
└─sda5 ext4 1.0 39c2b1c4-bc47-4aeb-89de-3502fd527d21
sdb
├─sdb1 ext4 1.0 f0e6ce1c-f61c-4d10-9c62-4d4afa9a1b3f 44,4G 35% /
├─sdb2
└─sdb5 ext4 1.0 400GB f47b7030-a042-4869-9feb-2a1b8bd57159 284G 17% /home
sdc ext4 1.0 4t f61321df-ad4c-4897-8689-f3dbfce89a7d 1,6T 50% /mnt/f61321df-ad4c-4897-8689-f3dbfce89a7d
Sitten kokeilemaan, buuttaako kone enää ollenkaan.
Vartokaa...
Jippii, buuttaa ja toistaiseksi näyttää hyvältä.