Ubuntu Suomen keskustelualueet
Muut alueet => Muut käyttöjärjestelmät ja Linux-jakelut => Aiheen aloitti: putte prossu - 06.09.12 - klo:10.54
-
Eli löytiyiskö ohjetta tai tutoa tuollaiselle operaatiolle missä debian pitäisi saada siirrettya 250GB PATA-levyltä 120GB SSD:lle?
edittiä:
Käynnistä suht uudella LiveCD:llä. Lähes kaikki komennot vaatii root oikeudet. Joten rootiksi su - tai Ubuntussa sudo su -. Oletan että pata on sda ja SSD on sdb!!!!
Tee osiot - yleensä 1. primaari eli käynnistyvä ja loput laajennetulle osiolle.
Tee tarvittavat osiot Gparted jos se on tuttu. Sillä voit tehdä myös tiedostojärjestelmät.
tai mkfs.ext4 -L ssd_levy -m 3 /dev/sdb1
-L on levyn nimi (valitse sopiva)
-m 3 kuinka paljon valitaan rootille oletus on 5% - valitse mieleisesi.
man mkfs.ext4 kertoo lisää optioita.
tune2fs -c 50 /dev/sdb1
Tämä asettaa levyn tarkistuksen joka 50:s kerta. Valitse mieleisesi.
Swap osio ei tarvitse tiedostojärjestelmää.
/home osiolle teet tiedostojärjestelmän samoin kuin yllä.
Itse teen yleensä levylle yhden primaariosion ja loput pistän laajennetulle
osiolle joten home liitetään silloin /dev/sdb5 ja swap /dev/sdb6
Kun osiot on tehty niin uusi käynnistys varmuuden vuoksi!!!!!
Näin kerneli näkee muutetun levyn varmasti oiken. Riippuu hieman
systeemistä päivittyykö osiotaulu muuttamisen jälkeen kernelille.
Käynnistyksen jälkeen tee kaksi liitospistettä
mkdir /mnt/uusi
mkdir /mnt/vanha
mount /dev/sda1 /mnt/vanha
mount /dev/sdb1 /mnt/uusi
df -h näyttää levyjen tilankäytön.
jos näyttää oikealta niin kopioidaan
cp -ax /mnt/vanha/ /mnt/uusi
tässä menee hetki....
kopioinnin jälkeen
umount /mnt/uusi
umount /mnt/vanha
Muille levyille tehdään samoin.
jos mount /dev/sdXX valittaa että levy on jo liitetty
niin unmount dev/sdXX auttaa. Levyhän voi olla jo
liitetty automaattisesti
Nyt pitäisi olla tiedostot kopioitu.
Sitten pitäisi korjata fstab ja grub.
Tähän on useampi vaihtoehto. Riippuu paljolti siitä
mitä teet vanhalla pata-levyllä. Nyt voi ottaa vaikka sen
pata-levyn pois ja uusi startti.
Asennetaan grub chrootin alla....
liitetään ssd-levy /mnt/uusi alle
blkid kertoo UUID
nano -w /mnt/uusi/etc/fstab
ja korjataan UUID
Valmistellaan chroot
mount --bind /sys /mnt/uusi/sys
mount --bind /dev /mnt/uusi/dev
mount --bind /proc /mnt/uusi/proc
chroot /mnt/uusi
grub-install /dev/sda
update-grub
TÄSSÄ OLETETAAN /dev/sda jos muuta niin
oikea tilalle. Tarkasta myös grub device.map.
Noin sen pitäisi mennä. Toivottavasti ei montaa
pilkkuverhettä....
Aikaa meni noin tunti meikäläiseltä joten suosittelen tätä lämpöisesti vaihtoehtona Clonezilloille ym.
-
Kutista debian osio vaikka gpartedilla 120GB tai pienemmäksi ja kopioi sitten dd:llä se SSD-levylle http://linux.fi/wiki/Dd
-
Ei välttämättä tarvitse kutistaa. esim näin
cd /polku/lähteeseen
cp -a -x . /polku/kohteeseen/
Piste on tärkeä. -x estää liitettyjen levyjen kopioinin.
Turvallisempi kopioida liveCd:llä kuin käynnissä olevasta järjestelmästä.
Grub täytyy asentaa uusiksi.
Samoin fstab pitää päivittää.
Homma sujuu melko nopeasti kun SDD levy kyseessä.
Osiointi ja tiedostojärjestelmä pitää tehdä tietysti ensiksi.
Samalla tiedostojen pirtoutuminen poistuu.
Kunhan fstab on päivitetty koneen saa käyntiin vanhan
käyttislevyn lataajalla kun painaa 'e' ja editoi oikean
kernelin ja juuren. Kun kone käynnissä niin grub asennetaan
uusiksi.
Ei mitään levykokojen muutoksia, joissa kuluu vaan aikaa...
osaava tekee tuon alle tunnissa.
-
cp -a -x . /polku/kohteeseen/
Säilyttääkö cp tiedostojen oikeudet? Ne olisi syytä säilyttää.
cp:n man sivulta:
-p same as --preserve=mode,ownership,timestamps
--preserve[=ATTR_LIST]
preserve the specified attributes (default: mode,ownership,time‐
stamps), if possible additional attributes: context, links,
xattr, all
eli -p saattaisi olla myös tarpeen. Myös rsynciä voisi tuohon käyttää, mutta taitaa olla tarpeettoman järeä, kun samalla koneella kopioidaan. Siihenkin pitää laittaa jotain vipuja.
Itsekin kyllä suosittelen käyttämään tuota kopiointia uudellee osiolle ja sitten fstabin korjaamista. Tulee samalla defragattua se osio (kuten Postimies näköjään mainitsi). Lisäksi dd:llä kopioidaan myös tyhjä tila, mikä ei ole kovin fiksua. Grubin voi kyllä asentaa sille uudelle levylle sieltä asennuslevyltäkin, mutta muutoksia listaan on hieman hitaampi tehdä (onnistuu toki).
-
Eikö tuon nyt mahda hoitaa esim. Clonezilla aivan automaattisesti. Itse ainakaan en jaksaisi alkaa kuljaileen tuolla tavoin.
-
Eikö tuon nyt mahda hoitaa esim. Clonezilla aivan automaattisesti. Itse ainakaan en jaksaisi alkaa kuljaileen tuolla tavoin.
Ei ole kovin kummosta:
1. Tehdään osiointi
2. Kopsataan tiedostot (cp -ax /media/vanha /media/uusi)
3. Korjataan fstab (ei kovin vaikeaa)
4. Asennetaan Grub
5. Korjataan Grubin valikkoa levyn kautta tai sitten käynnistyksen aikana ja lopuksi update-grub.
En ole käyttänyt CloneZillaa, mutta osaako se tehdä tuon fiksusti vai kopioiko se kaiken tiedon raakana? Mietin vain, että en ehkä SSD:lle kopsaisi tyhjää tilaa joka pitäisi luultavasti trimmata lopuksi.
cp -a -x . /polku/kohteeseen/
Säilyttääkö cp tiedostojen oikeudet? Ne olisi syytä säilyttää.
Oho. Olisi pitänyt lukea tarkemmin, -a = --preserve=all...
-
cp -a /media/vanha /media/uusi riittää kun käytetään liveCD tai vastaavaa. /temp /dev/ /sys kansioilla ei tarvitse silloin temppuilla. -a on lyhennys monesta valitsimesta eli aikaleimat, polut, oikeudet sun muut kopioituu. Se on oikeasti noin yksinkertaista. rsync hyvä vaihtoehto, mutta hitaampi koska laskee md5 summia. rsync -avx muistaakseni. Linux komennot ovat oikeasti lyhyitä ja tehokkaita. Olen itse tehnyt noin.
-
Anteeksi tietämättömyyteni mutta varmistetaan asia nyt vielä rautalangalla ;D
1. Tehdään osiointi
Eli 3 samanlaista osiota kuin lähde levyllä (swap, extended ja "juuri" mikä tietysti sovitetaan tuon 120GB mukaan?
2. Kopsataan tiedostot (cp -ax /media/vanha /media/uusi)
ihan vaan kylmästi tuo "cp -ax /dev/lähde /dev/kohde" ja tämä yksi komento siirtää kaiken suoraan oikeille partitioille jne?
3. Korjataan fstab (ei kovin vaikeaa)
Muokkaan tiedostoon /dev/kohde/etc/fstab uuden levyn UUID:n vanhan levyn tilalle?
4. Asennetaan Grub
5. Korjataan Grubin valikkoa levyn kautta tai sitten käynnistyksen aikana ja lopuksi update-grub.
Tähän jos vielä saisi rautalankaohjeet niin olisin oikein kiitollinen? Vieläkin kuumottaa nuo grub muokkailut vaikka tästä on jo lähemmäs 10v. kun onnistuin silloisilla linux kokeiluillani tuon sössimään, vaikka tuohon alkuperäiseen levyynhän nämä ei ilmeisesti vaikuta millään tavalla :D
-
1. Tehdään osiointi
Eli 3 samanlaista osiota kuin lähde levyllä (swap, extended ja "juuri" mikä tietysti sovitetaan tuon 120GB mukaan?
Miten vaan haluat tehdä. Tiedot pitää sijoittaa sinne mistä ne liitetään vastaavaan kohtaan tiedostojärjestelmässä.
2. Kopsataan tiedostot (cp -ax /media/vanha /media/uusi)
ihan vaan kylmästi tuo "cp -ax /dev/lähde /dev/kohde" ja tämä yksi komento siirtää kaiken suoraan oikeille partitioille jne?
Ei, vaan jokaiselle osiolle erikseen. Myöskään suoraan dev:in alla olevia laitetiedostoja ei voi käyttää, vaan osiot pitää liittää jonnekin.
3. Korjataan fstab (ei kovin vaikeaa)
Muokkaan tiedostoon /dev/kohde/etc/fstab uuden levyn UUID:n vanhan levyn tilalle?
Juu, kaikki osiot mille on vastineet sinne korjataan, poistettujen merkinnät poistetaan ja uudet lisätään.
4. Asennetaan Grub
5. Korjataan Grubin valikkoa levyn kautta tai sitten käynnistyksen aikana ja lopuksi update-grub.
Tähän jos vielä saisi rautalankaohjeet niin olisin oikein kiitollinen? Vieläkin kuumottaa nuo grub muokkailut vaikka tästä on jo lähemmäs 10v. kun onnistuin silloisilla linux kokeiluillani tuon sössimään, vaikka tuohon alkuperäiseen levyynhän nämä ei ilmeisesti vaikuta millään tavalla :D
Grubin asennukseen on ainakin seuraava ohje: http://wiki.ubuntu-fi.org/Grub2-kaynnistyslataaja
Tuohon toiseen varmaan Postimies osaa etsiä ohjeen eli miten sitä Grubin valikkoa pitää säätää, jotta käynnistetään oikealta levyltä.
Alkuperäiselle levyllehän ei tehdä mitään, jos et erehdy kirjoittamaan komentoja väärin.
-
Pakko myöntää että on ole itse käyttänyt kuin pari kertaa CloneZillaa, mutta ei ainakaan enemmän käyttämäni Acronis kopioi lainkaan tyhjää tilaa. Toki optiona ns. sektorikopio, mutta eihän kyseiselle ominaisuudelle ole juuri koskaan käyttöä.
Minusta tuo homma vain hoituisi huomattavasti nopeammin ja kivuttomammin, kuin noilla kopiointiohjeilla ja tekemällä nuo konffit.
-
Tuo clonezilla vaikuttaisi kyllä suht kivuttomalta, sillä homma sujuisi ilmeisesti niin että tuolla gpartedilla muutan osiointia 120GB tilaan sopivaksi ja ajan device to device kopioinnin? Tuohan näyttää asentavan myös grubin samalla?
-
Jotenkin muistelen että CloneZilla olisi tukenut automaattisesti tuota kloonausta pienemmälle osiolle, jos siis tietysti tila vain sillä riittää. Avoimeksi ohjelmaksi se kuitenkin sisältää melkoisen paljon ihan kaupallisen tason ohjelmien ominaisuuksia. Varmaksi en kuitenkaan tätä väitä, eli ihan omaa mutua.
-
Tuo clonezilla vaikuttaisi kyllä suht kivuttomalta, sillä homma sujuisi ilmeisesti niin että tuolla gpartedilla muutan osiointia 120GB tilaan sopivaksi ja ajan device to device kopioinnin? Tuohan näyttää asentavan myös grubin samalla?
En ole ihan varma, mutta saat kaksi levyä joissa on sama UUID mikä tuo oman sotkunsa, jos jatkat vanhan levyn käyttöä. Mbr:n saa tietysti kopioitua myös dd:llä, mutta dd on vaarallinen komento ja ei sovi vasta-alkajalle. Ja pata-levy alkaa sektorista 63? Mikä ei ole hyvä SDD-levylle. SDD-levyn osioinnista on paljon juttua netissä - miten se tehdään optimaaliseksi.
Levyn koon muuttamisessa myös omat riskinsä. Sulla kuitenkin nopea SDD levy. Voit varmistaa datat sinne..vaikka sitten tar, dar ym.. pakettina ja odotella tunnin verran. Muuttaa levyn kokoa ja taas odotella tunti, testata toimiiko oikein ja verrata data varmuuskopioon. Menee tunti tai pari. Sitten kloonata ja odotella... ja saat levyn jossa tiedostot eivät ole ehyitä ja sektoreiden lomittelu ei ole optimaalinen SDD levylle. ;D
Jonkun ajan päästä huomaat ottaa trimin käyttöön kun levy hidastuu.. Sitten huomaat ....
Image tyyppinen kopio on loistava jos kaksi samanlaista levyä. Ja kyllä niistä laiteistakin voi lukea esim. cat /dev/sda1, mutta ei järkeä tässä tapauksessa. Kokeilematta on vielä cat m.iso > /dev/sdb
-
Onkos näiden SSD-levyjen kanssa nyt niin että tiedostojärjestelmän pitäisi olla ext4 että noihin saa TRIM:n päälle?
Ainakin tämän artikkelin (http://visei.com/2011/08/how-to-enable-trim-for-ssds-in-debian-6-0-squeeze/) mukaan asia olisi noin joten laitetaan nyt jatkokysymyksenä että onnistuuko tuo käyttiksen kopiointi ext3-tiedotojärjestelmältä ext4:lle, mikäli laitan tuon SSD:n siihen muotoon? Vai onko oikea tapa kopioida ext3 -> ext3 ja convertoida levy tämän jälkeen ext4?
-
Onkos näiden SSD-levyjen kanssa nyt niin että tiedostojärjestelmän pitäisi olla ext4 että noihin saa TRIM:n päälle?
Ainakin tämän artikkelin (http://visei.com/2011/08/how-to-enable-trim-for-ssds-in-debian-6-0-squeeze/) mukaan asia olisi noin joten laitetaan nyt jatkokysymyksenä että onnistuuko tuo käyttiksen kopiointi ext3-tiedotojärjestelmältä ext4:lle, mikäli laitan tuon SSD:n siihen muotoon? Vai onko oikea tapa kopioida ext3 -> ext3 ja convertoida levy tämän jälkeen ext4?
Järkevin tapa tietysti osioida SSD levy ja tehdä sille tiedostojärjestelmä. Sitten kopioidaan tiedostot sinne. Ext4 sisältää tuen trimmille. Tästä kannattaisi tehdä ohje. On kaikenlaista ehdotusta. Ihan turhia levynkoon muutamisia ym. . cp -a riittää useimmissa tapauksissa. Mitä järkeä konvertoida jos käyttämätön tyhjä levy? Ajanhukkaa. Ei siinä pääse parempaan tulokseen jos pyörittää tunteja Gparted ohjelmaa (pienentää levyä, kloonaa, konvertoi...).
-
Mitä järkeä konvertoida jos käyttämätön tyhjä levy? Ajanhukkaa. Ei siinä pääse parempaan tulokseen jos pyörittää tunteja Gparted ohjelmaa (pienentää levyä, kloonaa, konvertoi...).
Noinhan se on ja itsekkin mielelläni välttäsin näitä "purkkaviritelmiä" mutta osaamattoman näkökulmasta asian tekee mielummin turvallisesti, vaikka siinä nyt tovi aikaa vierähtäisin enemmän. Tarkoitan tällä siis sitä että näihin ohjeistuksiin, missä eri käyttäjät huutelee tee sitä ja asenna se, verrattuna tuohon Clonezilla-metodiin löytyy 10x selkeämmät ohjeet, minkä päälle jopa meikäläinen tajuaa :D
ELIKKÄ... nythän mulla jää käteen 2x samanlaista PATA-levyä kun tuon SSD saapuu ja ajatuksena on että teen tästä nykyisestä levystä 1:1 kopion ettei ole pienintäkään vaaraa että alkuperäinen levy muuttuu käyttökelvottomaksi. Tämä ilmeisesti onnistuu niinkin helposti yhdellä komennolla kuin dd if=/dev/pata1 of=/dev/pata2 eikä vaadi mitään osiointeja tai muutakaan kohde-levylle vaan tuo tekee kaiken tarvittavan? Sitten päästään varsinaiseen topicin aiheeseen missä mun käsityksen mukaan levylle tehdään 3 partitiota (jotka ilmeisesti voi olla suoraan tuota ext4 vaikka kopioitava levy on ext3?) ja tämän jälkeen kopioidaan tiedot yksittäin jokaiselta partitiolta toisen levyn partitioille missä vaiheessa hämmennys alkaa. Eli tarviiko tuohon nyt käyttää mitään muita edellä mainittuja vipuja kuin tuo -a, eli ei x, ei p, eikä tuota pistettä, vaan ihan vain cp -a /dev/sda1 /dev/sdb1 (noinko yksittäiset osiot kopioidaan?).
Tämän jälkeen vaihdan uuden SSD-levyn UUID:n SSD:llä sijaitsevaan fstabiin.
Sitten se grub, eli tarviiko siinä käynnistys vaiheessa nyt tehdä jotain (mitä tarkalleen) vai voinko asentaa grubin yllä mainitun linkin tapaan Live-CD:n avulla samalla kertaa kuin kopioin sillä nuo levytkin ja that´s it, vanha pata-levy irti ja boottia SSD:ltä?
Kiitos ja anteeksi vielä :)
-
Myönnän, että tämä on hieman sotkuinen ketju. dd if=/dev/pata1 of=/dev/pata2. Lukee suoraan laitteesta ja tekee identtisen levyn. Edellyttäen, että osiot ovat samankokoiset. Siinä saa olla velho että saa tehtyä sektorilleen samankokoiset levyt. Jos kaksi samanlaista levyä homma on helppo. Tuossa siirtyy myös tiedostojärjestelmä (Ext3 oletan). dd on aloittelijalle vaarallinen komento. Sillä saa helposti tuhottua levyn sisällön jos tulee kirjoitusvirhe.
Onko tuo pata levy IDE väylässä kiinni? Eli masterina IDE piuhassa. SSD-levy tulee sitten sata-väylään.
Pata-levyltä voi putsata /temp ja muut väliaikaistiedostot.
Käynnistä suht uudella LiveCD:llä. Lähes kaikki komennot vaatii root oikeudet. Joten rootiksi su - tai Ubuntussa sudo su -. Oletan että pata on sda ja SSD on sdb!!!!
Tee osiot - yleensä 1. primaari eli käynnistyvä ja loput laajennetulle osiolle.
Tee tarvittavat osiot Gparted jos se on tuttu. Sillä voit tehdä myös tiedostojärjestelmät.
tai mkfs.ext4 -L ssd_levy -m 3 /dev/sdb1
-L on levyn nimi (valitse sopiva)
-m 3 kuinka paljon valitaan rootille oletus on 5% - valitse mieleisesi.
man mkfs.ext4 kertoo lisää optioita.
tune2fs -c 50 /dev/sdb1
Tämä asettaa levyn tarkistuksen joka 50:s kerta. Valitse mieleisesi.
Swap osio ei tarvitse tiedostojärjestelmää.
/home osiolle teet tiedostojärjestelmän samoin kuin yllä.
Itse teen yleensä levylle yhden primaariosion ja loput pistän laajennetulle
osiolle joten home liitetään silloin /dev/sdb5 ja swap /dev/sdb6
Kun osiot on tehty niin uusi käynnistys varmuuden vuoksi!!!!!
Näin kerneli näkee muutetun levyn varmasti oiken. Riippuu hieman
systeemistä päivittyykö osiotaulu muuttamisen jälkeen kernelille.
Käynnistyksen jälkeen tee kaksi liitospistettä
mkdir /mnt/uusi
mkdir /mnt/vanha
mount /dev/sda1 /mnt/vanha
mount /dev/sdb1 /mnt/uusi
df -h näyttää levyjen tilankäytön.
jos näyttää oikealta niin kopioidaan
cp -ax /mnt/vanha/ /mnt/uusi
tässä menee hetki....
kopioinnin jälkeen
umount /mnt/uusi
umount /mnt/vanha
Muille levyille tehdään samoin.
jos mount /dev/sdXX valittaa että levy on jo liitetty
niin unmount dev/sdXX auttaa. Levyhän voi olla jo
liitetty automaattisesti
Nyt pitäisi olla tiedostot kopioitu.
Sitten pitäisi korjata fstab ja grub.
Tähän on useampi vaihtoehto. Riippuu paljolti siitä
mitä teet vanhalla pata-levyllä. Nyt voi ottaa vaikka sen
pata-levyn pois ja uusi startti.
Asennetaan grub chrootin alla....
liitetään ssd-levy /mnt/uusi alle
blkid kertoo UUID
nano -w /mnt/uusi/etc/fstab
ja korjataan UUID
Valmistellaan chroot
mount --bind /sys /mnt/uusi/sys
mount --bind /dev /mnt/uusi/dev
mount --bind /proc /mnt/uusi/proc
chroot /mnt/uusi
grub-install /dev/sda
update-grub
TÄSSÄ OLETETAAN /dev/sda jos muuta niin
oikea tilalle. Tarkasta myös grub device.map.
Noin sen pitäisi mennä. Toivottavasti ei montaa
pilkkuverhettä....
-
Iso KIITOS tarkoista mutta silti samalla erittäin selkeistä ohjeista, näillä uskaltaa kädetönkin alkaa hommaan ;)
PATA levy on tosissaan kiinni masterina ja SSD tulee sitten normaalisti SATA-väylään. PATA levyä ei ole tarkoitus enää käyttää ollenkaan, vaan pitää se hyllyssä siltä varalta että SSD päättää sanoa työsopimuksen irti.
Eli tuo dd vaatii kuitenkin osioinnin kohde-levylle ennen kopiointia? Tämä onnistuu ilmeisesti parhaiten komennolla "sfdisk -d /dev/pata1 | sfdisk /dev/pata2"? Levyt ei ole täysin identtiset mutta kohde-levy inan verta isompi vaikka molemmat on 250GB.
-
Sellainen kysymys tuosta cp -komennosta:
Onko se Linuxissa tosiaan varma tapa? Vai olisiko rsync -suositeltavampi? Huomasin, jo edeltä että rsync on hitaampi.
Kysyn siksi, että Windows-maailmassa interaktiivinen kopiointi on kaiken pahan alku ja juuri (siis kriittisissä operaatioissa) ja komentoriviltä ajettava robocopy taasen erittäin hyvä ja 100%:nen tapa. Vai onko Linux-maailmassa jo cp varma tapa?
-
Yksi pieni lisäys: Kun liität kolmannen levyn niin muista tarkastaa sen jälkeen mikä on nyt mikä (sda, sdb, sdc) ennen kuin kopioit. Noiden merkitykset heittävät volttia helposti levyn lisäyksen yhteydessä eli se uusin/viimeksi lisätty levy ei välttämättä olekaan "sdc".
-
Sellainen kysymys tuosta cp -komennosta:
Onko se Linuxissa tosiaan varma tapa? Vai olisiko rsync -suositeltavampi? Huomasin, jo edeltä että rsync on hitaampi.
Ei tuossa ole mitään ihmeellistä. Tiedoston kopiointi toiselle levylle. Ja levyt samassa koneessa. Jos kopsaan muistikortilta vaikka 1000 kuvaa en niitä yleensä vertaa diffillä läpi. Voihan kopioinnin jälkeen ajaa diff -r /lähde /kohde komennon ja verrata kaikki tiedostot. Kestää kyllä tovin.
rsync varmempi kun laskee md5summat. Mutta tarpeen lähinnä verkon yli tai jos epäilystä rautaviasta.
Parempi silloin kun halutaan kaksi levyä 'ajan tasalle' kun tehdään esim. varmistus. Silloin pitää tiedostoja vertailla. Tässä tapuksessa ei.
mkfs.ext4 -m optiolla voi pienentää rootille varattavaa tilaa. Levyjen suurentuessa oletus 5% minusta turhan paljon. Ja onko tarpeen datalevyllä?
Laitenimissä saa olla tarkkana. Ja on vaikea ennalta veikata miten ne menee. Onko SATA, IDE levyjä, miten kiinni, bios asetukset, ...ahci tuki, fdisk -l auttaa.
dd on hankala. Kyllä sillä voisi kopioida mbr:n helposti. Tai koko levyn ilman osiointia. Tai sitten osioi ensiksi. dd ja väärä laitenimi, niin voi tuhota kaiken datan. Mutta on parempi, että ei kopioida PATA levyn osiotaulua uudelle SSD-levylle. SSD-levy toimii nopeammin kun alligment (lomittelu) on oikein. Parempi siis tehdä uusi taulu ja uusi tiedostojärjestelmä. Myös cat toimii laitteiden kanssa. Esim. cat /dev/sda >levy.iso. Myös cp... Mutta jos tuntematonta maailmaa jätetään väliin.
cp:llä vaikeampi saada tuhoa aikaan...Mutta kyllä silläkin onnistuu. En kerro miten.
Välissä kannattaa bootata varmuudeksi... Kernelille voi kyllä kertoa, että osiotaulu on muutettu. Mutta voi käydä niin että kerneli muistaa vanhan osiotaulun ja kopioinnit menee pieleen. En jaksa selostaa tätä paremmin - parempi vain uskoa.
-
dd on hankala. Kyllä sillä voisi kopioida mbr:n helposti. Tai koko levyn ilman osiointia. Tai sitten osioi ensiksi. dd ja väärä laitenimi, niin voi tuhota kaiken datan. Mutta on parempi, että ei kopioida PATA levyn osiotaulua uudelle SSD-levylle. SSD-levy toimii nopeammin kun alligment (lomittelu) on oikein. Parempi siis tehdä uusi taulu ja uusi tiedostojärjestelmä.
Tällä dd:llä meinasin siis tehdä, ihan vain varmuuden vuoksi, 1:1 kopion tuosta 250GB käyttis-levystä toiselle PATA 250GB levylle ennen kuin alan noilla sun ohjeilla kopioimaan käyttis-levyä SSD:lle. Tarkoituksena olisi siis tehdä boottaava kopio käyttiksestä, ihan vaan siltä varalta että tuossa SSD:lle kopioinnissa joku menee pieleen.
-
Tällä dd:llä meinasin siis tehdä, ihan vain varmuuden vuoksi, 1:1 kopion tuosta 250GB käyttis-levystä toiselle PATA 250GB levylle ennen kuin alan noilla sun ohjeilla kopioimaan käyttis-levyä SSD:lle. Tarkoituksena olisi siis tehdä boottaava kopio käyttiksestä, ihan vaan siltä varalta että tuossa SSD:lle kopioinnissa joku menee pieleen.
Ei tuossa mitään vahinkoa kun vain katsot että kopioiti menee oikeaan suuntaan.
-
Tällä dd:llä meinasin siis tehdä, ihan vain varmuuden vuoksi, 1:1 kopion tuosta 250GB käyttis-levystä toiselle PATA 250GB levylle ennen kuin alan noilla sun ohjeilla kopioimaan käyttis-levyä SSD:lle. Tarkoituksena olisi siis tehdä boottaava kopio käyttiksestä, ihan vaan siltä varalta että tuossa SSD:lle kopioinnissa joku menee pieleen.
Ehkä hieman liioittelua. Sitten on lopulta 3 kpl levyjä joilla sama käyttis. cp eli kopiointi ei poista tiedostoja ja jos menee väärin tiedostot kopioituu vain väärään paikkaan. Mikä on korjattavissa. Jos dd menee väärin niin data on oikeasti hukassa. Siis ihan oikeasti. Sitä ei pelasta millään palautusohjelmalla. Mitä enempi samanlaisia levyjä sen helpompi mennä sekaisin mikä on mikä.
Tee se SSD-levy ja kopioi siitä image pata-levylle. Luku laitteesta tiedostoon ei ole vaarallinen dd:llä. dd:llä kirjoitus laitetiedostoihin on. Jos menee väärin voit hukata alkuperäisen datan. Jos ei yhtään tunne Linuxin toimintaa ja miten laitenimet toimii ja näkyy on parempi jättää ne rauhaan.
-
Tää koko homma kuulostaa melkoisen raskaalta tavalta hoitaa tuollainen homma. Jollei käyttistä ole kustomoitu oikein tosissaan tekisin itse näin. Kotikansio talteen. Mahdolliset muut asetustiedostot talteen. Osioidaan SD-levy, asennetaan käyttis, asennetaan halutut lisäohjelmat, siirretään varmuuskopioidut tiedostot.
-
Sellainen kysymys tuosta cp -komennosta:
Onko se Linuxissa tosiaan varma tapa? Vai olisiko rsync -suositeltavampi? Huomasin, jo edeltä että rsync on hitaampi.
Ei tuossa ole mitään ihmeellistä. Tiedoston kopiointi toiselle levylle. Ja levyt samassa koneessa. Jos kopsaan muistikortilta vaikka 1000 kuvaa en niitä yleensä vertaa diffillä läpi. Voihan kopioinnin jälkeen ajaa diff -r /lähde /kohde komennon ja verrata kaikki tiedostot. Kestää kyllä tovin.
Tuo ei oikein vakuuta. Kun puhutaan sisäisistä levyistä, voidaan lähtökohdaksi ottaa se, että ne ovat kunnossa. Sen sijaan kun puhutaan ulkoisista medioista, voihan niissä milloin hyvänsä olla "rautavika" eli tiedostojärjestelmä sekaisin, puhumattakaan cd/dvd-medioista, jotka voivat helposti olla jo mekaanisesti rikki (pelkkä likatahra suojaamattomalla pinnalla riittää tähän). Ymmärrän kyllä, että diff:n voi ajaa, mutta eikö olisi parempi kopioida siten, että lopputulos on varmasti oikein? (Eli siis käyttää suoraan rsync:iä).
Kysehän tuossa on siitä että a) käykö virhe mitenkään selville, b) mitä tapahtuu jos virhe on lopputuloksessa? Kun vertasin Windowsiin, niin tarkoitin sitä, että virheen sattuminen ei käy välttämättä mistään selville - en tiedä mitä cp tekee. Kun kopioidaan käyttistä, niin virhe lopputuloksessa on luokkaa "katastrofaalinen", koska se voi aiheuttaa ihan mitä hyvänsä.
Tuollainen irtolevy ja sen käyttö on mielestäni jotakin sisäisen ja ulkoisen median välimaastosta - tällöin valitsisin varmimman tavan. Esimerkkisi kuvista on sikäli erilainen, että kuvassa oleva virhe näkyy heti kun kuvaa katsoo ja yleensä kuvat katsotaan läpi.
-
Itse olen monesti siirtänyt käytiksen levyltä toiselle kun rauta on vaihtunut. Kopioinnissa ei mitään ongelmia ikinä. Enempi miettimistä käynnistyslataajassa ja fstabin muokkaamisessa. Varsinkin jos useampia levyjä ja käyttöjärjestelmiä, niin enempi muokkaamista. Usein olen käyttänyt myös mc:tä rootin alla.
Jos kaverille vaihtaa levyn niin aikaikkuna tulee vastaan. Niin silloin muokkaan fstab ja mitä nyt pystyy jo kopionnin aikana. Ja kun homma valmis niin kotiin.
SSD-levyt kivoja. Mahtuu taskuun ja nopeutta piisaa. Tuollaiselta purkaa käyttiksen nopeasti (esim. tar paketti) alle 10 min. Ja siltä saa koneen pystyyn myös äkkiä. Ei sitä tarvitse aina tunteja käyttää siihen mikä voi hoitua nopeastikin. Noin tuli tehtyä yksi HTPC äkkiä. Ei päivien virittelyä.
-
"JaniAlander": in ehdottama tapa on on pieniriskinen ja ongelmaton vaikka ei varsinaisesti tuo otsikon "kloonaus". Lieneekö "kloonaus" sitten varsinaisesti se ajateltu tehtävän määritys ? Oletetaan nyt tässä ehdotelmassa niin.
Jos pelkää kirjoitus- tai ajatusvirheitä komentorivillä, tms. niin osion kopiointi käy graafisestikin esimerkiksi Gparted: in avulla. Tehty on tavallisilla levyillä systeemin kloonaus toiselle levylle mutta vaati asentamaan Grubin perässä. Sen jälkeen toimi ok.
Huomaa sitten heti kloonauksen jälkeen (teit millä hyvänsä välineellä): Koneessa on nyt kaksi osiota jotka ovat saman nimisiä, näköisiä ja mikä pahinta samalla UUID-tunnuksella --- irrota se toinen pois ennen kuin jatkat. Jos haluat käyttää molempia osioita samassa koneessa edelleen niin joudut muuttamaan jomman kumman levyn UUID: n ( katso päätteessä "sudo blkid").
Tuossa kohdassa on oikeastaan kaksi vaihtoehtoa edetä joilla omat seurauksensa:
- Levyn tilapäinen UUID-muutos
- Levyn pysyvä UUID-muutos + käynnistyksen päivitys uudelle UUID: lle
"Tilapäinen" tarkoittaa että kirjaat ylös levyn UUID: n (no sehän on sinulla kyllä tallessa toisellakin levyllä kun tämä oli klooni siitä) ja muutat levyn UUID: n siksi aikaa kun haluat tarkastella sitä samassa koneessa ja palautat alkuperäisen lopuksi. Pysyvä muutos on monimutkaisempi, käynnistyminenkin/fstab pitää korjata tuolle UUID: lle.
Pelkkä kopiointivaihe Gparted: ssa on helpon oloinen. Ei havaintoa SSD: n tapauksessa aiheuttaako se jotain omia juttujaan tuohon.
Tarkka kuvaus olisi aika pitkä, tärkeää on muistaa että UUID on se asia jolla yksiselitteinen tunnistus tapahtuu.
-
PATA-levyt lähtee kyllä molemmat hyllyyn jahka ne tuolla verkkokaupassa saisi kiikutettua tuon SSD:n joskus edes postiin asti. Eli niitä ei ole aikomustakaan käyttää enää tuon SSD:n kanssa.
Mitä tuohon "raskauteen" tulee niin mun mielestä nuo postimiehen kirjoittamat mainiot ohjeet kuullostaa oikein simppeliltä toimenpiteeltä verrattuna siihe että asentelisi kaiken tuolla servulla olevan uusiksi, mihin ei taida edes yksi kokonainen viikonloppu riittää.
-
UUID:n kanssa puljaaminen on turhaa kun pistää fstab-tiedostoon laitetunnuksen /dev/sda1. Käytännössä tuo muuttuu harvoin. Levylle nimi on hyvä antaa. UUID on Ubuntun tapa. Itse pidän enemmän laitetunnuksista tai vaihtoehtoisesti LABEL määreestä esim LABEL=leffat on helpompi muistaa kuin UUID=12345... joka ei kerro mitään. Ja tuo liitetään automaattisesti /media/leffat eikä typerällä UUID arvolla.
Ei yksinkertaisesta asiasta kannata tehdä turhan monimutkaista. Eikä käyttiksen kokokaan ole kovin suuri. Jos pitäisi siirtää vaikka teran verran TV-tallenteita, niin voisi jo pysähtyä miettimään kannattaako kaikea pistää kerralla. Nykyiset levyt mahdollistavat aikamoisia datamääriä ihan kotikoneissa.
-
Eikä käyttiksen kokokaan ole kovin suuri.
Onhan tuolta käyttis-levyllä kaiken kaikkiaan melkein 7GB käytetty, mitä tietty saa vielä siivottuakin tarvittaessa :D Kaikki muu oleellinen löytyy siis raid-pakan takaanta tässä tapauksessa.
-
UUID:n kanssa puljaaminen on turhaa kun pistää fstab-tiedostoon laitetunnuksen /dev/sda1. Käytännössä tuo muuttuu harvoin. Levylle nimi on hyvä antaa. UUID on Ubuntun tapa. Itse pidän enemmän laitetunnuksista tai vaihtoehtoisesti LABEL määreestä esim LABEL=leffat on helpompi muistaa kuin UUID=12345... joka ei kerro mitään. Ja tuo liitetään automaattisesti /media/leffat eikä typerällä UUID arvolla.
Olen käsittänyt että UUID: t on otettu käyttöön juuri sen takia kun ne pysyvät toisin kun sda/sdb/sdc, jne. Tuossa mielessä UUID on hyvä idea. Joskus toki voi mennä mistä aita on matalin (sda/sdb/sdc..) ellei ole mahdollisuutta tehdä sitä heti paremmin mutta se voi myös kolahtaa omaan tai seuraavan ylläpitäjän nilkkaan levykokoonpanoa muutettaessa.
"Label" on kyllä erittäin suositeltava, havainnollistaa käyttötarkoitusta ja tuota käytän aina UUID: n lisäksi.
-
Olen vaihtanut serverissä ja muuallakin missä sillä on väliä, levyjen kiinnitykset UUID:ksi. Ei levykokoonpanon tarvitse edes muuttua, vaan bootissa levyt muuttuvat muutoin hallitsemattomasti, edes takaisin aina välillä - siis verrattuna sda,b,c ...
Ulkoisilla levyillä pärjää järkevällä labelilla ja sen mukaisella käytöllä. Järkevä labelihan on joka tapauksessa hyvä olla, koska ulkoisia levyjä liikutellaan järjestelmästä toiseen. Kiinteillä levyillä on ihan sama vaikka käyttää UUID:täkin - eihän siitä oikeasti mitään vaivaa ole.
-
Ei levykokoonpanon tarvitse edes muuttua, vaan bootissa levyt muuttuvat muutoin hallitsemattomasti, edes takaisin aina välillä - siis verrattuna sda,b,c ...
ÖÖÖ. Missä tilanteessa? Bootissa muuttuvia levyjä... Tämähän menee hauskaksi. Jos kummitus vetää piuthat irti ja pistää satunnaisesti takaisin? No vitsi... Jos kunnon sähkökatko ja bios nollautuu tai jotain vastaavaa.. Omakotitalossa, maalla, .. ups voi olla hyvä idea.
-
Päivitysten latausten jälkeen ja sitten taas seuraavassa kylmässä bootissa. Noin viidennen kerran jälkeen sain tarpeekseni. Saattoi olla että myös restart ja kylmä bootti toimivat eri tavalla.
-
Ei todellakaan vaadi paljoa, että törmää tuohon sda,sdb jne. muuttumiseen. Eihän tuo vaadi kuin, että irroitat asemat koneesta ja tökkäät ne eri portteihin takaisin. Varmasti on määritykset solmussa jos ei käytä UUID:tä.
Tai sopivasti bios-asetuksia muuttamalla. Ei siitä upsista ole mitään hyötyä tuossa tapauksessa.
-
Ei todellakaan vaadi paljoa, että törmää tuohon sda,sdb jne. muuttumiseen. Eihän tuo vaadi kuin, että irroitat asemat koneesta ja tökkäät ne eri portteihin takaisin. Varmasti on määritykset solmussa jos ei käytä UUID:tä.
Tai sopivasti bios-asetuksia muuttamalla. Ei siitä upsista ole mitään hyötyä tuossa tapauksessa.
Harvempi irrottelee huvikseen levyjä ja pistää sitten takaisin eri järjestyksessä. Tietysti silloin muutuu. Samoin jos muuttaa bios-asetuksia. Mutta noin normaalisti ei tehdä. UUID:stä on etua. Mutta jos vähän muuttaa levyn kokoa niin UUID muuttuu, mutta laitetunnus pysyy samana. Kaikessa on puolensa.
Oli tuolla sellainenkin neuvo - muuta levyn kokoa ja unohtu sanoa, että jos UUID käytössä niin käynnistyksessä tulee sitten ongelmia, jos ei UUID:tä korjaa.
-
Ei todellakaan vaadi paljoa, että törmää tuohon sda,sdb jne. muuttumiseen. Eihän tuo vaadi kuin, että irroitat asemat koneesta ja tökkäät ne eri portteihin takaisin. Varmasti on määritykset solmussa jos ei käytä UUID:tä.
Tai sopivasti bios-asetuksia muuttamalla. Ei siitä upsista ole mitään hyötyä tuossa tapauksessa.
Harvempi irrottelee huvikseen levyjä ja pistää sitten takaisin eri järjestyksessä. Tietysti silloin muutuu. Samoin jos muuttaa bios-asetuksia. Mutta noin normaalisti ei tehdä. UUID:stä on etua. Mutta jos vähän muuttaa levyn kokoa niin UUID muuttuu.
No tuohan se varsin yleinen skenaario sitten onkin muutella osioiden kokoa ::)
-
Oli tuolla sellainenkin neuvo - muuta levyn kokoa ja unohtu sanoa, että jos UUID käytössä niin käynnistyksessä tulee sitten ongelmia, jos ei UUID:tä korjaa.
En ole tuollaista ilmiötä tai ongelmaa koskaan havainnut ja melko paljon on osioita säädelty eri kokoisiksi. UUID: n saa halutessaan pakotettua toiseksi mutta se pitää erikseen tekemällä tehdä, ei tuo nyt aivan vahingossa muutu. Jos tarve tulee vastaan niin uuden UUID: n saa arvottua helposti:
uuidgen35fdcc0f-af6d-44e9-ae5d-e97bcddc88db
ja tuon voi pakottaa osiolle tähän tyyliin:
sudo tune2fs /dev/sdaX -U 35fdcc0f-af6d-44e9-ae5d-e97bcddc88db
kunhan tuo osio ei ole mountattu/käytössä. Toki tuo on mahdollista ajaa yli myös "dd": n avulla jos on urheilumieltä :)
-
Minä olen 4½ vuotta kloonannut (Ubuntu ja Debian) käyttikset Remastersysillä. Sillä voi tehdä vanhasta asennuksesta asennettavan iso-backupin, joka mahtuu rajoituksena olevaan 4 Gtavun tilaan, kun siirtää kaikki videot ym. ulkoiselle levylle tai palvelimelle.
Hyvänä puolena on, että oman käyttiksen voi käynnistää sellaisenaan DVD:ltä tai nykyisin aina USB:ltä. Asentaa sen voi sitten vaikka minkä kovalevyn mille tahansa partitiolle (esim. Windowsin rinnalle) eikä tarvitse fundeerata noita UUID:ta ym. koodeja.
Huonona puolena on tietysti se, että Remastersysin sujuva käyttö vaatii hieman harjoittelua ja fragadelicin foorumin Remastersys and AVLinux Forum (http://www.remastersys.com/forums/index.php) seuraamista mahdollisten ongelmien ratkaisemiseksi.
Ilmeisesti viimeisin ongelma oli sellainen, ettei backup-optiolla tehty levykuva (minulla Lubuntu 12.04) käynnistynyt oikein, eli ei antanut kirjautua sisään. Siihen löytyi ratkaisu ilmeisesti ketjusta: stuck at creating user when installing remater with encrypting home (http://www.remastersys.com/forums/index.php?topic=2549.0). (remastersys.txt -tiedoston lataaminen vaatinee kirjautumisen?)
Ainakin 3 viimeistä remasterointia ja toiselle levylle (tai virtuaalikoneeseen) asennusta ovat onnistuneet ilman ongelmia.
-
Eli löytiyiskö ohjetta tai tutoa tuollaiselle operaatiolle missä debian pitäisi saada siirrettya 250GB PATA-levyltä 120GB SSD:lle?
Jos levytilaa riittää, ei itse järjestelmän kopiointi ole vaikeampaan kuin cp -komennolla sopivilla määritteillä.
/etc/fstab on tiedosto, jolla määritellään liitettävät hakemistot. Ja kuten jo ohjeistettu, grub-käynnistys voidaan määritellä vaikka ko. levyn mrb:ään, jos bios tukee ko. levyä.
-
Eli löytiyiskö ohjetta tai tutoa tuollaiselle operaatiolle missä debian pitäisi saada siirrettya 250GB PATA-levyltä 120GB SSD:lle?
Jos levytilaa riittää, ei itse järjestelmän kopiointi ole vaikeampaan kuin cp -komennolla sopivilla määritteillä.
/etc/fstab on tiedosto, jolla määritellään liitettävät hakemistot. Ja kuten jo ohjeistettu, grub-käynnistys voidaan määritellä vaikka ko. levyn mrb:ään, jos bios tukee ko. levyä.
Tätä olen yrittänyt selostaa. cp -ax riittää kopiointiin. On turvallinen verrattuna esim dd tai levyn pienenys ja kloonaus juttuihin jotka ovat vain ylimääräistä aikaa vievää touhua. Ei tiedostojen tai isommankaan hakemistopuun kopiointi ole mikään ihmeellinen juttu.
-
Noniin, SSD saapui tänään ja nyt se on asennettu ja hienosti pelaa! Kiitos kaikille vastanneille, varsinkin postimiehelle, kenen ohjeilla homma meni kuin elokuvissa :)
EDIT. pientää ongelmaa näyttäisi vielä olevan, eli levy näkyy aivan oikean kokoisena ym. mutta silti järjestelmä näyttää että levyllä olisi vain noin 70GB vapaa tilaa vaikka mulla ei ole tuolla mitään muuta kuin itse käyttöjärjestelmä?
-
Paljonko meni aikaa kopioinnissa? olen utelias.. milläs katsoit tilan? df -h?
-
Aikaa meni reilu tunti koko hommassa, eli helposti jää voitolle verrattuna noihin Clonezilloihin ym. Kopiointi vei ehkä 45min mutta joku 40-50GB tuolla oli "turhaa tavaraa", mitä en jaksanut alkaa siirtelemään, paitsi nyt siirtelin nekin tuolta pois.
df -h näyttää sda1 size 106G, used 29G, avail 72G ja use 29% ja järjestelmän, home osioin ym. pitäisi viedä noin 7GB.
Eihän tuolle tarvi käskyttää mitään resize2fs tms?
-
df -h näyttää sda1 size 106G, used 29G, avail 72G ja use 29% ja järjestelmän, home osioin ym. pitäisi viedä noin 7GB.
Eihän tuolle tarvi käskyttää mitään resize2fs tms?
Kyllä suuruusluokka näyttää oikealta. root näköjään 106G ja home 7G, niin yhteensä vähän alle 120G. Systeemi vie näköjään 29G. Vaikuttaa hieman paljolta.
Tiedostojen yhteenlaskettu koko ja niiden viemä tila levyltä on hieman eri asia. Kääntelin äsken xbmc-pvr - yhteensä yli 18 000 tiedostoa lähdepuussa. Vie yllättävästi tilaa levyltä, vaikka yhteenlaskettu koko 1G luokkaa.
df= disk free du=disk usage. du komennolla voit tarkastella myös tilankäyttöä
-
En ole sinänsä ottanut kantaa asian kätevyyteen tai helppouteen, kun ei ole asiasta kokemusta, mutta sinänsä tuntuu hienolta, että Postimiehen "normaaleilla tavoilla" voi hyvin kloonata myös käyttöjärjestelmän. Tämä mielestäni kuvastaa hyvin avoimen järjestelmän etuja, jossa asioista ei tarvitse tehdä salaista, vaan kaikki keinot ovat käytettävissä kun järjestelmä on jo lähtökohtaisesti sopivasti "modulaarinen".
Periaatteessa on hienoa, että ei tarvitse mitään erillistä ohjelmaa, jos pelkkä osiointi ja kopiointi riittää + pari normaalia systeemin toimintaan liittyvää asiaa.