Zmiana slota dysku NVMe i bootowanie

[Roman Tyczka]

Ubuntu 20, nowa płyta na X570, dyski NVMe.

Mam Ubuntu 20 na dysku NVMe, jest w slocie M.2. Teraz nabyłem drugi dysk
NVMe, chcę ten z systemem wsadzić w drugi slot na płycie, a w ten
pierwszy zapakować nowy dysk, czy po tej operacji system normalnie
wstanie czy zmiana slota rozpieprzy bootowanie?

--
pzdr
Roman

[Jarosław Sokołowski]

Pan Roman Tyczka napisał:

Od dawna partycje rozpoznawane są po UUID, więc zmiana podłączenia dysków
nie powinna niczego zmącić.

--
Jarek

[Roman Tyczka]

W dniu 06.05.2021 o 15:47, Jarosław Sokołowski pisze:

>> Mam Ubuntu 20 na dysku NVMe, jest w slocie M.2. Teraz nabyłem drugi dysk
>> NVMe, chcę ten z systemem wsadzić w drugi slot na płycie, a w ten
>> pierwszy zapakować nowy dysk, czy po tej operacji system normalnie
>> wstanie czy zmiana slota rozpieprzy bootowanie?
>
> Od dawna partycje rozpoznawane są po UUID, więc zmiana podłączenia dysków
> nie powinna niczego zmącić.

No ok, ale jak skopiuję dyska A na dysk B za pomocą dd, to wtedy oba
mają taki sam UUID, co się wtedy wydarzy podczas startu systemu? Oba
dyski będą tak samo identyfikowane?

--
pzdr
Roman

[Sushi Master]

Sat, 8 May 2021 12:35:44 +0200, Roman Tyczka <roman...@hate.you.spammer> wysmarował:

https://unix.stackexchange.com/questions/12858/how-to-change-filesystem-uuid-2-same-uuid

SushiMaster

[Roman Tyczka]

W dniu 08.05.2021 o 12:57, Sushi Master pisze:

>>>> Mam Ubuntu 20 na dysku NVMe, jest w slocie M.2. Teraz nabyłem drugi dysk
>>>> NVMe, chcę ten z systemem wsadzić w drugi slot na płycie, a w ten
>>>> pierwszy zapakować nowy dysk, czy po tej operacji system normalnie
>>>> wstanie czy zmiana slota rozpieprzy bootowanie?
>>>
>>> Od dawna partycje rozpoznawane są po UUID, więc zmiana podłączenia dysków
>>> nie powinna niczego zmącić.
>>
>> No ok, ale jak skopiuję dyska A na dysk B za pomocą dd, to wtedy oba
>> mają taki sam UUID, co się wtedy wydarzy podczas startu systemu? Oba
>> dyski będą tak samo identyfikowane?
>>
>
>
> https://unix.stackexchange.com/questions/12858/how-to-change-filesystem-uuid-2-same-uuid

Dzięki, ale dla pewności jeszcze dopytam, żeby nie napytać sobie biedy ;-)
Czyli wsadzam nowy dysk w slot obecnego systemowego (bo tam mam PCIe
v4), systemowy pakuję w drugi slot, system startuje normalnie...
Teraz kopiuję dysk stary na nowy za pomocą dd, a potem od razu na nowym
(lub starym) dysku wykonuję tune2fs i zmieniam mu UUID, potem restart.
I wstanie z nowego dysku? Czy może muszę wyjąć stary przed restartem?

--
pzdr
Roman

[Jarosław Sokołowski]

Pan Roman Tyczka napisał:

>>>> Od dawna partycje rozpoznawane są po UUID, więc zmiana podłączenia
>>>> dysków nie powinna niczego zmącić.
>>>
>>> No ok, ale jak skopiuję dyska A na dysk B za pomocą dd, to wtedy oba
>>> mają taki sam UUID, co się wtedy wydarzy podczas startu systemu? Oba
>>> dyski będą tak samo identyfikowane?
>>
>> https://unix.stackexchange.com/questions/12858/how-to-change-filesystem-uuid-2-same-uuid
>
> Dzięki, ale dla pewności jeszcze dopytam, żeby nie napytać sobie biedy ;-)
> Czyli wsadzam nowy dysk w slot obecnego systemowego (bo tam mam PCIe
> v4), systemowy pakuję w drugi slot, system startuje normalnie...
> Teraz kopiuję dysk stary na nowy za pomocą dd, a potem od razu na nowym
> (lub starym) dysku wykonuję tune2fs i zmieniam mu UUID, potem restart.
> I wstanie z nowego dysku? Czy może muszę wyjąć stary przed restartem?

Nastąpiło tu materii poplątanie. To *linux* rozpoznaje partycje po UUID.
W szczególności robi to przy montowaniu tych partycji. To, z którego dysku
uruchomi się komputer, zależy od ustawienia w BIOS.

Ponadto, jeśli zmienimy UUID partycji, to system na tym dysku przestanie
działać. Bo te nowe numerki nie będą się zgadzały z wpisami w /etc/fstab
i z konfiguracją GRUB.

--
Jarek

[Roman Tyczka]

W dniu 08.05.2021 o 15:29, Jarosław Sokołowski pisze:

>> Dzięki, ale dla pewności jeszcze dopytam, żeby nie napytać sobie biedy ;-)
>> Czyli wsadzam nowy dysk w slot obecnego systemowego (bo tam mam PCIe
>> v4), systemowy pakuję w drugi slot, system startuje normalnie...
>> Teraz kopiuję dysk stary na nowy za pomocą dd, a potem od razu na nowym
>> (lub starym) dysku wykonuję tune2fs i zmieniam mu UUID, potem restart.
>> I wstanie z nowego dysku? Czy może muszę wyjąć stary przed restartem?
>
> Nastąpiło tu materii poplątanie. To *linux* rozpoznaje partycje po UUID.
> W szczególności robi to przy montowaniu tych partycji. To, z którego dysku
> uruchomi się komputer, zależy od ustawienia w BIOS.
>
> Ponadto, jeśli zmienimy UUID partycji, to system na tym dysku przestanie
> działać. Bo te nowe numerki nie będą się zgadzały z wpisami w /etc/fstab
> i z konfiguracją GRUB.

No i dupa. Być może to wina ciut większego dysku źródłowego (o około 20
MB), być może mojego niezrozumienia, ale po wykonaniu:

$ sudo dd if=/dev/nvme0n1 conv=sync of=/dev/nvme2n1
dd: zapis do '/dev/nvme2n1': Brak miejsca na urządzeniu
1953525169+0 przeczytanych rekordów
1953525168+0 zapisanych rekordów
skopiowane 1000204886016 bajtów (1,0 TB, 932 GiB), 6111,8 s, 164 MB/s

szło parę godzin i jak widać na końcu się wykopyrtnęło, a po tej
operacji dysk docelowy jest "nieznany".

fdisk -l wyświetla wspomniane dwa dyski tak:

źródłowy z systemem:

Dysk /dev/nvme0n1: 953,89 GiB, bajtów: 1024209543168, sektorów: 2000409264
Disk model: ADATA SX8200PNP
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Typ etykiety dysku: gpt
Identyfikator dysku: 9C8B609D-8E48-4494-8C1F-F7283FB6A027

Urządzenie Początek Koniec Sektory Rozmiar Typ
/dev/nvme0n1p1 2048 1050623 1048576 512M System EFI
/dev/nvme0n1p2 1050624 2000409230 1999358607 953,4G Linux - system plików


docelowy, nowy:

GPT PMBR size mismatch (2000409263 != 1953525167) will be corrected by
write.
Dysk /dev/nvme2n1: 931,53 GiB, bajtów: 1000204886016, sektorów: 1953525168
Disk model: Samsung SSD 980 PRO 1TB
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Typ etykiety dysku: dos
Identyfikator dysku: 0x00000000

Urządzenie Rozruch Początek Koniec Sektory Rozmiar Id Typ
/dev/nvme2n1p1 1 1953525167 1953525167 931,5G ee GPT



Jak to zrobić skutecznie? Ktoś pomoże konkretniej niż ogólnikowymi
stwierdzeniami?

--
pzdr
Roman

[Kamil Jońca]

Roman Tyczka <roman...@hate.you.spammer> writes:

> W dniu 08.05.2021 o 15:29, Jarosław Sokołowski pisze:
>>> Dzięki, ale dla pewności jeszcze dopytam, żeby nie napytać sobie biedy ;-)
>>> Czyli wsadzam nowy dysk w slot obecnego systemowego (bo tam mam PCIe
>>> v4), systemowy pakuję w drugi slot, system startuje normalnie...
>>> Teraz kopiuję dysk stary na nowy za pomocą dd, a potem od razu na nowym
>>> (lub starym) dysku wykonuję tune2fs i zmieniam mu UUID, potem restart.
>>> I wstanie z nowego dysku? Czy może muszę wyjąć stary przed restartem?
>> Nastąpiło tu materii poplątanie. To *linux* rozpoznaje partycje po
>> UUID.
>> W szczególności robi to przy montowaniu tych partycji. To, z którego dysku
>> uruchomi się komputer, zależy od ustawienia w BIOS.
>> Ponadto, jeśli zmienimy UUID partycji, to system na tym dysku
>> przestanie
>> działać. Bo te nowe numerki nie będą się zgadzały z wpisami w /etc/fstab
>> i z konfiguracją GRUB.
>
> No i dupa. Być może to wina ciut większego dysku źródłowego (o około
> 20 MB), być może mojego niezrozumienia, ale po wykonaniu:

Zaraz, zaraz. Dysk *większy* chciałeś skopiować na mniejszy i dziwisz
się, że sie nie udało?

A co to pomocy, to bez wiedzy co konkretnie jest na tych partycjach to
nie sądzę, żeby CI ktoś odpowiedział.
KJ


--
http://wolnelektury.pl/wesprzyj/teraz/

[Jarosław Sokołowski]

Pan Roman Tyczka napisał:

> No i dupa. Być może to wina ciut większego dysku źródłowego (o około
> 20 MB), być może mojego niezrozumienia, ale po wykonaniu:
>
> $ sudo dd if=/dev/nvme0n1 conv=sync of=/dev/nvme2n1
> dd: zapis do '/dev/nvme2n1': Brak miejsca na urządzeniu

Niestety, w tej sytuacji nawet zaklęcia "śmiało, zmieścisz się"
nie pomogą.

> Jak to zrobić skutecznie? Ktoś pomoże konkretniej niż ogólnikowymi
> stwierdzeniami?

Na nowym dysku założyć potrzebne partycje, niekoniecznie tak samo
jak na starym -- jest okazja, by to zmienić, zrobić lepiej niż było.
Sformatować, przekopiować pliki. Skorygować /etc/fstab, odświeżyć
grub (też wcześniej skorygować UUID, jeśli trzeba).

--
Jarek

[Roman Tyczka]

W dniu 09.05.2021 o 19:19, Kamil Jońca pisze:

>>> Nastąpiło tu materii poplątanie. To *linux* rozpoznaje partycje po
>>> UUID.
>>> W szczególności robi to przy montowaniu tych partycji. To, z którego dysku
>>> uruchomi się komputer, zależy od ustawienia w BIOS.
>>> Ponadto, jeśli zmienimy UUID partycji, to system na tym dysku
>>> przestanie
>>> działać. Bo te nowe numerki nie będą się zgadzały z wpisami w /etc/fstab
>>> i z konfiguracją GRUB.
>>
>> No i dupa. Być może to wina ciut większego dysku źródłowego (o około
>> 20 MB), być może mojego niezrozumienia, ale po wykonaniu:
>
> Zaraz, zaraz. Dysk *większy* chciałeś skopiować na mniejszy i dziwisz
> się, że sie nie udało?

I tak, i nie. Oba dyski oznaczone są jako 1TB, dopiero po podpięciu
okazało się, że samsung inaczej pojmuje TB niż Adata.
Pomijając już te 20MB różnicy 60% dysku jest pusta, więc liczyłem, że
"może się uda"

> A co to pomocy, to bez wiedzy co konkretnie jest na tych partycjach to
> nie sądzę, żeby CI ktoś odpowiedział.

Pisałem w pierwszym poście, dysk źródłowy to dysk systemowy. Chcę
przenieść system na nowy dysk.

--
pzdr
Roman

[Roman Tyczka]

W dniu 09.05.2021 o 19:46, Jarosław Sokołowski pisze:

>> No i dupa. Być może to wina ciut większego dysku źródłowego (o około
>> 20 MB), być może mojego niezrozumienia, ale po wykonaniu:
>>
>> $ sudo dd if=/dev/nvme0n1 conv=sync of=/dev/nvme2n1
>> dd: zapis do '/dev/nvme2n1': Brak miejsca na urządzeniu
>
> Niestety, w tej sytuacji nawet zaklęcia "śmiało, zmieścisz się"
> nie pomogą.

Na ten temat już Kamilowi odpisałem.

>> Jak to zrobić skutecznie? Ktoś pomoże konkretniej niż ogólnikowymi
>> stwierdzeniami?
>
> Na nowym dysku założyć potrzebne partycje, niekoniecznie tak samo
> jak na starym -- jest okazja, by to zmienić, zrobić lepiej niż było.
> Sformatować, przekopiować pliki. Skorygować /etc/fstab, odświeżyć
> grub (też wcześniej skorygować UUID, jeśli trzeba).

No to lecimy. Na starym były dwie partycje:

/boot/efi (fat32, 512MB)
/ (ext4, 953MB, z czego zajęte 345MB)

Ta druga z całym systemem Ubuntu 20.04, wraz z /home itd.
Założyłem na nowym dysku 3 partycje:
512 MB (na tę efi)
376 GB na kopię systemu z poprzedniego /
554 GB na dane, tu też chcę wsadzić /home

potem za pomocą dd skopiowałem partycję /boot/efi

$ sudo dd if=/dev/nvme0n1p1 conv=sync of=/dev/nvme2n1p1
1048576+0 przeczytanych rekordów
1048576+0 zapisanych rekordów
skopiowane 536870912 bajtów (537 MB, 512 MiB), 3,20264 s, 168 MB/s

I partycja się niby skopiowała, ale czy na pewno? Odpalam systemowy
menadżer partycji i mamy:

https://i.imgur.com/vJ6nbJX.png

1 - to te trzy nowe partycje o których mówiłem
2 - po dd nowa partycja efi od razu dostała punkt montowania...
3 - ...za to zniknęły jej informacje o zajętości i dostępnym miejscu
(stary dysk ma tu poprawne dane)
4 - chcąc się do tej partycji podpiąć, żeby zobaczyć co tam jest,
postanowiłem zmienić jej punkt montowania, bo ten jest wszak zajęty
przez dysk stary
5 - po zatwierdzeniu jest ostrzeżenie, którego nie rozumiem:

"Zastąpi to plik istniejący na twoim dysku twardym, nie można tego
cofnąć" - jaki kurfa plik? czy chodzi o plik fstab? Przecież w nim są
wpisy wszystkich pozostałych dysków, to jakim cudem zmiana punktu
montowania jednej partycji może zniszczyć montowania wszystkich? Czego
nie rozumiem?

I co teraz robić? Klikać? Jak sprawdzić co jest na tej pieprzonej
partycji nvme2n1p1?

ps. pytanie dodatkowe: co zawiera partycja /boot/efi?

--
pzdr
Roman

[Kamil Jońca]

Roman Tyczka <roman...@hate.you.spammer> writes:

> W dniu 09.05.2021 o 19:19, Kamil Jońca pisze:
>>>> Nastąpiło tu materii poplątanie. To *linux* rozpoznaje partycje po
>>>> UUID.
>>>> W szczególności robi to przy montowaniu tych partycji. To, z którego dysku
>>>> uruchomi się komputer, zależy od ustawienia w BIOS.
>>>> Ponadto, jeśli zmienimy UUID partycji, to system na tym dysku
>>>> przestanie
>>>> działać. Bo te nowe numerki nie będą się zgadzały z wpisami w /etc/fstab
>>>> i z konfiguracją GRUB.
>>>
>>> No i dupa. Być może to wina ciut większego dysku źródłowego (o około
>>> 20 MB), być może mojego niezrozumienia, ale po wykonaniu:
>> Zaraz, zaraz. Dysk *większy* chciałeś skopiować na mniejszy i
>> dziwisz
>> się, że sie nie udało?
>
> I tak, i nie. Oba dyski oznaczone są jako 1TB, dopiero po podpięciu
> okazało się, że samsung inaczej pojmuje TB niż Adata.

I w tym momwncie powinieneś wiedzieć, że sie nie uda.

> Pomijając już te 20MB różnicy 60% dysku jest pusta,

Ale dd o tym nie wie. On kopiuje surowe bloki.

KJ



--
http://wolnelektury.pl/wesprzyj/teraz/

[Pawel]

W dniu 09.05.2021 o 19:46, Jarosław Sokołowski pisze:

Nie jestem specem od partycjonowania dyskow, ale czy nie wystarczyloby
po prostu na dysku zrodlowym zmniejszyc ostatnia partycje o powiedzmy
100MB i zostawic na koncu dysku te 100 MB wolnego miejsca (nie partycji)
i wedy uzyc dd? DD skopiuje caly dysk i sie wywali, ale na nowym dysku
odpali sie fsck, lub jakis program do partycjonowania i powinny wykryc
to i naprawic.
Koniec dysku nie bedzie przedzielony do zadnej partycji, wiec nie
powinno byc chyba problemu.

[Kaczin]

W dniu 09.05.2021 o 21:45, Kamil Jońca pisze:

> I w tym momwncie powinieneś wiedzieć, że sie nie uda.
>
>> Pomijając już te 20MB różnicy 60% dysku jest pusta,
>
> Ale dd o tym nie wie. On kopiuje surowe bloki.
>
> KJ
>
>
>

Pleciesz farmazony.

--
Kaczin

[Jarosław Sokołowski]

Pan Roman Tyczka napisał:

> I co teraz robić? Klikać? Jak sprawdzić co jest na tej pieprzonej
> partycji nvme2n1p1?

Szczerze mówiąc, jakoś nie chce mi się wpatrywać w te obrazki.
Takich rzeczy nigdy nie robiłem przez klikanie. Ja bym zrobił
to mniej więcej tak:

1. sudo dd if=/dev/nvme0n1 of=/dev/nvme2n1 bs=8M count=100
To skopiuje początek dysku, wraz z tablicą partycji i partycją EFI.

2. fdisk /dev/nvme2n1
Tutaj usunąć partycję systemową (której tak naprawdę nie ma), założyć
na nowo mniejszą oraz kolejną na home.

3. mkfs.ext4 /dev/nvme2n1p2 ; mkfs.ext4 /dev/nvme2n1p3
(czyli sformatować te nowe partycje)

4. Skopipwać system na systemową, a home na home. Nie wiem, czy muszę
takie rzeczy dodawać, ale tego nie powinno się robić na żywym systemie,
najlepiej odpalić sobie to Ubuntu z USB. Stworzyć katalogi i zamontowć
w nich partycje. Do kopiowania dobrze nadaje się mc (zachowuje wszystkie
informacje o plikach).

5. Nadać nowej partycji systemowej UUID ze starej.

6. Do nowego /etc/fstab dopisać:

UUID=uuid-partycji-home /home ext4 defaults 0 2

System powinien ruszyć z miejsca. jak nie, to trzeba odświeżyć grub
(można wyguglać jak to się robi).

--
Jarek

[Kamil Jońca]

Pawel <ppf9@USUN_TOpoczta.fm> writes:

> W dniu 09.05.2021 o 19:46, Jarosław Sokołowski pisze:
>> Pan Roman Tyczka napisał:
>>
>>> No i dupa. Być może to wina ciut większego dysku źródłowego (o około
>>> 20 MB), być może mojego niezrozumienia, ale po wykonaniu:
>>>
>>> $ sudo dd if=/dev/nvme0n1 conv=sync of=/dev/nvme2n1
>>> dd: zapis do '/dev/nvme2n1': Brak miejsca na urządzeniu
>> Niestety, w tej sytuacji nawet zaklęcia "śmiało, zmieścisz się"
>> nie pomogą.
>>
>>> Jak to zrobić skutecznie? Ktoś pomoże konkretniej niż ogólnikowymi
>>> stwierdzeniami?
>> Na nowym dysku założyć potrzebne partycje, niekoniecznie tak samo
>> jak na starym -- jest okazja, by to zmienić, zrobić lepiej niż było.
>> Sformatować, przekopiować pliki. Skorygować /etc/fstab, odświeżyć
>> grub (też wcześniej skorygować UUID, jeśli trzeba).
>>
>
> Nie jestem specem od partycjonowania dyskow, ale czy nie wystarczyloby
> po prostu na dysku zrodlowym zmniejszyc ostatnia partycje o powiedzmy
> 100MB i zostawic na koncu dysku te 100 MB wolnego miejsca (nie

Jeśli już to najpierw filesystem (jaki tam jest i czy pozwala na
zmniejszanie?) , później partycję, a później skopiować.

Rzecz do zrobienia, ale trzeba wiedzieć co się robi, bo inaczej można
sobie (a raczej danym) zrobić kuku.

KJ


--
http://wolnelektury.pl/wesprzyj/teraz/

[Kamil Jońca]

A coś więcej?
KJ

--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

[Jarosław Sokołowski]

Pan Pawel napisał:

>> Na nowym dysku założyć potrzebne partycje, niekoniecznie tak samo
>> jak na starym -- jest okazja, by to zmienić, zrobić lepiej niż było.
>> Sformatować, przekopiować pliki. Skorygować /etc/fstab, odświeżyć
>> grub (też wcześniej skorygować UUID, jeśli trzeba).
>
> Nie jestem specem od partycjonowania dyskow, ale czy nie wystarczyloby
> po prostu na dysku zrodlowym zmniejszyc ostatnia partycje o powiedzmy
> 100MB i zostawic na koncu dysku te 100 MB wolnego miejsca (nie partycji)
> i wedy uzyc dd? DD skopiuje caly dysk i sie wywali, ale na nowym dysku
> odpali sie fsck, lub jakis program do partycjonowania i powinny wykryc
> to i naprawic.
> Koniec dysku nie bedzie przedzielony do zadnej partycji, wiec nie
> powinno byc chyba problemu.

Też można. Nawet fsck nie będzie wtedy potrzebne. Jednal dobrze trzymać
się takiej zasady, że jak ktoś się nie zna na czymś dobrze, to powinien
unikać gmerania przy oryginalnym dysku (zakładam, że dane są cenne), by
czegoś nie zepsuć.

--
Jarek

[Jarosław Sokołowski]

Pan Kamil Jońca napisał:

>> Pomijając już te 20MB różnicy 60% dysku jest pusta,
>
> Ale dd o tym nie wie. On kopiuje surowe bloki.

My też nie wiemy, czy akurat w tych końcowych 20MB nie ma danych.

--
Jarek

[Pawel]

W dniu 09.05.2021 o 22:35, Jarosław Sokołowski pisze:

Rozumiem i dlatego mam dwie propozycje:
- zrobić obraz dysku zrodlowego do pliku i zapisac na jakims zewnetrznym
dysku. Jak obrazz bylby za duzy, to mozna uzyc np tara z "xz". Fakt,
potrwa to znacznie dluzej, ale obraz bedzie znaczaco mniejszy i wtedy
mozna by majstrowac na adysku zrodlowym.

- jak ostatnia partycja dysku zrodlowego nie jest duza, to mozna zgrac z
niej dane i ja usunac. Nie spotkalem sie jeszcze, zeby usuwanie partycji
(zwlaszczaa ostatniej) powodowalo jakies problemy. Zakladajac, ze nie ma
jakis innych problemow z filesystemem, alvbo dyskiem.

[Jarosław Sokołowski]

Pan Pawel napisał:

>> Też można. Nawet fsck nie będzie wtedy potrzebne. Jednal dobrze trzymać
>> się takiej zasady, że jak ktoś się nie zna na czymś dobrze, to powinien
>> unikać gmerania przy oryginalnym dysku (zakładam, że dane są cenne), by
>> czegoś nie zepsuć.
>
> Rozumiem i dlatego mam dwie propozycje:
> - zrobić obraz dysku zrodlowego do pliku i zapisac na jakims zewnetrznym
> dysku. Jak obrazz bylby za duzy, to mozna uzyc np tara z "xz". Fakt,
> potrwa to znacznie dluzej, ale obraz bedzie znaczaco mniejszy i wtedy
> mozna by majstrowac na adysku zrodlowym.
>
> - jak ostatnia partycja dysku zrodlowego nie jest duza, to mozna zgrac z
> niej dane i ja usunac. Nie spotkalem sie jeszcze, zeby usuwanie partycji
> (zwlaszczaa ostatniej) powodowalo jakies problemy. Zakladajac, ze nie ma
> jakis innych problemow z filesystemem, alvbo dyskiem.

Też można. Rozwiązań są setki. Ja zaproponowałem swoje, które jest [1]
sprawdzone (wilokrotnie działałem w podobny sposób), [2] szybkie (kopiuje
się tylko dane, a nie cały dysk), [2] umożliwia zastosowanie nowych
pomysłów na partycjonowanie dysku (z czego pytający na zamiar skorzystać).

--
Jarek

[Pawel]

W dniu 09.05.2021 o 22:29, Jarosław Sokołowski pisze:

Z tego co pamietam, ja takze cos stakiego robilem przed era uefi i z
tego co pamietam, to dzialalo za kazdym razem, a backup polegal na
zrobieniu tara z partycji root i home, a nstepnie rozpakowaniu tego po
usunieciu starego systemu.

[Jarosław Sokołowski]

Pan Pawel napisał:

>> 1. sudo dd if=/dev/nvme0n1 of=/dev/nvme2n1 bs=8M count=100
>> To skopiuje początek dysku, wraz z tablicą partycji i partycją EFI.

[...]

>
> Z tego co pamietam, ja takze cos stakiego robilem przed era uefi i z
> tego co pamietam, to dzialalo za kazdym razem, a backup polegal na
> zrobieniu tara z partycji root i home, a nstepnie rozpakowaniu tego
> po usunieciu starego systemu.

Nie wiem na ile nowa era wnosi coś nowego, ale powyższy punkt powinien
zagwarantować to, że potencjalnie istotne miejsca na dysku pozostaną
takie same. Przenoszenie plików przez tar też jest bezpieczne, ale
wymaga więcej czasoprzestrzeni niż proponowane wcześniej użycie mc.
Można nawet zwykłym cp, ale to wymaga przeczytania mana, bo nie
pamiętam potrzebnych opcji. Wreszcie można kopiować (lokalnie) przy
pomocy rsync z opcją -a (to akurat pamiętam).

--
Jarek

[Roman Tyczka]

W dniu 09.05.2021 o 23:08, Pawel pisze:

> Rozumiem i dlatego mam dwie propozycje:
> - zrobić obraz dysku zrodlowego do pliku i zapisac na jakims zewnetrznym
> dysku. Jak obrazz bylby za duzy, to mozna uzyc np tara z "xz". Fakt,
> potrwa to znacznie dluzej, ale obraz bedzie znaczaco mniejszy i wtedy
> mozna by majstrowac na adysku zrodlowym.
>
> - jak ostatnia partycja dysku zrodlowego nie jest duza, to mozna zgrac z
> niej dane i ja usunac. Nie spotkalem sie jeszcze, zeby usuwanie partycji
> (zwlaszczaa ostatniej) powodowalo jakies problemy. Zakladajac, ze nie ma
> jakis innych problemow z filesystemem, alvbo dyskiem.

Jak pisałem w postach wcześniejszych dysk ma 1 TB, ma dwie partycje:

/boot/efi (fat32, 512MB)
/ (ext4, 953 GB) - wcześniej pomyliłem jednostkę i podałem MB, literówka

Ta druga z całym systemem Ubuntu 20.04, wraz z /home itd.

Pójdę chyba drogą Jarka, najmniejszy poziom ryzyka tam widzę.

--
pzdr
Roman

[Kamil Jońca]

W sumie racja :)
KJ

--
http://wolnelektury.pl/wesprzyj/teraz/

[Roman Tyczka]

W dniu 09.05.2021 o 22:29, Jarosław Sokołowski pisze:

>> I co teraz robić? Klikać? Jak sprawdzić co jest na tej pieprzonej
>> partycji nvme2n1p1?
>
> Szczerze mówiąc, jakoś nie chce mi się wpatrywać w te obrazki.

Szkoda, ale trudno.

> Takich rzeczy nigdy nie robiłem przez klikanie. Ja bym zrobił
> to mniej więcej tak:
>
> 1. sudo dd if=/dev/nvme0n1 of=/dev/nvme2n1 bs=8M count=100
> To skopiuje początek dysku, wraz z tablicą partycji i partycją EFI.

Zrobiłem, nawet count dałem większy:

$ sudo dd if=/dev/nvme0n1 conv=sync of=/dev/nvme2n1 bs=8M count=500
500+0 przeczytanych rekordów
500+0 zapisanych rekordów
skopiowane 4194304000 bajtów (4,2 GB, 3,9 GiB), 3,48807 s, 1,2 GB/s

> 2. fdisk /dev/nvme2n1
> Tutaj usunąć partycję systemową (której tak naprawdę nie ma), założyć
> na nowo mniejszą oraz kolejną na home.

A tu zaczyna się świat cudów, których nie ograniam... (moje dopiski w
nawiasach kwadratowych)


$ sudo fdisk /dev/nvme2n1

Witamy w programie fdisk (util-linux 2.34).
Zmiany pozostaną tylko w pamięci do chwili ich zapisania.
Przed użyciem polecenia zapisu prosimy o ostrożność.

GPT PMBR size mismatch (2000409263 != 1953525167) will be corrected by
write.

Główna tablica GPT jest uszkodzona, ale zapasowa wygląda dobrze, więc
zostanie użyta zapasowa. [oba powyższe zdania na czerwono]

Polecenie (m wyświetla pomoc): i
Numer partycji (1-3, domyślnie 3): 1

Device: /dev/nvme2n1p1
Start: 2048
End: 1050623
Sectors: 1048576
Size: 512M
Type: Microsoft - dane podstawowe
Type-UUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
UUID: BB524B18-1C7B-4E36-A5EC-9C9C651B751A

Polecenie (m wyświetla pomoc): i
Numer partycji (1-3, domyślnie 3): 2

Device: /dev/nvme2n1p2
Start: 1050624
End: 791578623
Sectors: 790528000
Size: 377G
Type: Linux - system plików
Type-UUID: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
UUID: FF883186-7F53-4747-A7F5-7AE7AC650487

Polecenie (m wyświetla pomoc): i
Numer partycji (1-3, domyślnie 3): 3

Device: /dev/nvme2n1p3
Start: 791578624
End: 1953523711
Sectors: 1161945088
Size: 554,1G
Type: Linux - system plików
Type-UUID: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
UUID: EB313C72-7DD2-4D3F-A3FC-55A1541CF055


Czyli nie widzi tych skopiowanych przed chwilą przez dd, tylko te stare,
które sam utworzyłem wczoraj, pewnie to przez ten komunikat na czerwono:

"Główna tablica GPT jest uszkodzona, ale zapasowa wygląda dobrze, więc
zostanie użyta zapasowa."

Co z tym zrobić w takiej sytuacji?

--
pzdr
Roman

[Roman Tyczka]

W dniu 10.05.2021 o 10:24, Roman Tyczka pisze:

Skasowałem te wszystkie partycje i jeszcze raz zrobiłem dd ale tym razem
count dałem 5000, co spowodowało skopiowanie 42GB danych.

Potem wlazłem do fdiska i ...nie widzi w ogóle partycji

~$ sudo fdisk /dev/nvme2n1

Witamy w programie fdisk (util-linux 2.34).
Zmiany pozostaną tylko w pamięci do chwili ich zapisania.
Przed użyciem polecenia zapisu prosimy o ostrożność.

GPT PMBR size mismatch (2000409263 != 1953525167) will be corrected by
write.
Główna tablica GPT jest uszkodzona, ale zapasowa wygląda dobrze, więc
zostanie użyta zapasowa.

Polecenie (m wyświetla pomoc): i

Nie zdefiniowano jeszcze partycji!


Co robię źle?

--
pzdr
Roman

[Kamil Jońca]

Nie zastanawiasz sie.

masz dysk a - 980GG z partycjami 1+ 979GB (powiedzmy)
masz dysk b - 950GB
przed dd spowodowałeś że na dysku b w tablicy partycji masz wpisy z
dysku a czyli 1+979GB.
I sorry na dysku 950 GB taki wpis będzie zły.


KJ

--
http://wolnelektury.pl/wesprzyj/teraz/

[Roman Tyczka]

W dniu 10.05.2021 o 10:57, Kamil Jońca pisze:

>> Skasowałem te wszystkie partycje i jeszcze raz zrobiłem dd ale tym
>> razem count dałem 5000, co spowodowało skopiowanie 42GB danych.
>>
>> Potem wlazłem do fdiska i ...nie widzi w ogóle partycji
>>
>> ~$ sudo fdisk /dev/nvme2n1
>>
>> Witamy w programie fdisk (util-linux 2.34).
>> Zmiany pozostaną tylko w pamięci do chwili ich zapisania.
>> Przed użyciem polecenia zapisu prosimy o ostrożność.
>>
>> GPT PMBR size mismatch (2000409263 != 1953525167) will be corrected by
>> write.
>> Główna tablica GPT jest uszkodzona, ale zapasowa wygląda dobrze, więc
>> zostanie użyta zapasowa.
>>
>> Polecenie (m wyświetla pomoc): i
>> Nie zdefiniowano jeszcze partycji!
>>
>>
>> Co robię źle?
>
> Nie zastanawiasz sie.
>
> masz dysk a - 980GG z partycjami 1+ 979GB (powiedzmy)
> masz dysk b - 950GB
> przed dd spowodowałeś że na dysku b w tablicy partycji masz wpisy z
> dysku a czyli 1+979GB.
> I sorry na dysku 950 GB taki wpis będzie zły.

Czekaj, bo chyba nie do końca tak jest. Podążam za wskazówkami Jarka, a
jeśli je zrozumiałem poprawnie to jego pomysł zasadza się na tym, że
tablica partycji jest gdzieś na początku dysku, więc zaproponował mi
skopiowanie początku dysku (count=100) i wtedy, mimo, że skopiowane
partycje są niekompletne (bo kopiuje się tylko pierwsza, mała partycja
efi w całości) to sam proces kopiuje tablicę partycji i fdisk powinien
już te partycje widzieć. W moim jednak wypadku fdisk stwierdza, że
tablica partycji jest nie teges i bierze jej kopię, która albo zawiera
to co było przed wykonaniem dd, albo bierze pustą tablicę partycji, bo
była ona pusta - tak czy owak nie pokazuje tej z dysku źródłowego (A jak
go nazwałeś).
Zatem... zastanawiam się, czasem nawet myślę, choć nie jestem w tym
biegły niestety i dlatego dopytuję uparcie.


--
pzdr
Roman

[Kamil Jońca]

Tak.

> tablica partycji jest nie teges i bierze jej kopię, która albo zawiera

Tablicę partycji, nie partycję - tka

> to co było przed wykonaniem dd, albo bierze pustą tablicę partycji, bo
> była ona pusta - tak czy owak nie pokazuje tej z dysku źródłowego (A
> jak go nazwałeś).

wylistuj sobie partycje na z pierwszego dysku
na drugim dysku zrób partycje
pierwsza taka jak na pierwszym dysku (początek - koniec)
druga - poczatek drugiej z pierwszeg dysku , a koniec tyle il możesz
(mam tylko nadzieje, ze nie będzie tam jakichśprzesunięć)

KJ

--
http://wolnelektury.pl/wesprzyj/teraz/

[Roman Tyczka]

W dniu 10.05.2021 o 11:31, Kamil Jońca pisze:

>> tablica partycji jest nie teges i bierze jej kopię, która albo zawiera
> Tablicę partycji, nie partycję - tka
>> to co było przed wykonaniem dd, albo bierze pustą tablicę partycji, bo
>> była ona pusta - tak czy owak nie pokazuje tej z dysku źródłowego (A
>> jak go nazwałeś).
>
> wylistuj sobie partycje na z pierwszego dysku
> na drugim dysku zrób partycje
> pierwsza taka jak na pierwszym dysku (początek - koniec)
> druga - poczatek drugiej z pierwszeg dysku , a koniec tyle il możesz
> (mam tylko nadzieje, ze nie będzie tam jakichśprzesunięć)

Tak zrobiłem, ręcznie wyrzeźbiłem 3 partycje, jedna fat32 i dwie ext4.
Ta pierwsza identycznie blokami taka sama, potem zrobiłem jej kopiowanie
za pomocą dd:

~$ sudo dd if=/dev/nvme0n1p1 of=/dev/nvme2n1p1 bs=8M status=progress
64+0 przeczytanych rekordów
64+0 zapisanych rekordów
skopiowane 536870912 bajtów (537 MB, 512 MiB), 0,395852 s, 1,4 GB/s

Teraz wykonuję blkid:

$ blkid |grep nvme
/dev/nvme0n1p2: LABEL="ADATA"
UUID="c5822601-0036-473b-b749-7da044e4f569" TYPE="ext4"
PARTUUID="2dd54670-75e0-4324-a20e-1c34934c4071"
/dev/nvme0n1p1: UUID="6C17-716F" TYPE="vfat" PARTLABEL="EFI System
Partition" PARTUUID="7be0f7e5-2311-4b0c-bec1-c2085f24ab78"
/dev/nvme2n1p2: LABEL="rucik"
UUID="46873c0c-60ff-4aba-a629-75db1dc2370e" TYPE="ext4"
PARTUUID="7d3a1f4f-7dd5-2947-8fda-fb9fd68e4644"
/dev/nvme2n1p3: LABEL="dane" UUID="4c215f4c-415e-4e38-88ea-3d69bb508a38"
TYPE="ext4" PARTUUID="09beddf2-f276-3e47-9a2b-a857985aa761"

I tej partycji fat32 czyli nvme2n1p1 tutaj nie ma (a źródłowa, z
pierwszego dysku jest), co ją boli?

--
pzdr
Roman

[Pawel]

W dniu 10.05.2021 o 08:33, Roman Tyczka pisze:

Moge jeszcze jedno rozwiazanie zaproponowac i chyba bedzie dosc proste
do zastosowania.
Zerknij na program partimage -> http://www.partimage.org/Screenshots/
To jest taki odpowiednik PArtition Magic z Windowsa (swoja droga, ten
program jeszcze zyje?), ktory kopiuje tylko dane, a nie cale sektory,
wiec jest szansa, ze wyczai, ze jest mniejszy dysk i sie dostosuje.

[Pawel]

W dniu 10.05.2021 o 16:11, Pawel pisze:

Ewentualnie, partclone -> https://partclone.org/about/

[Dominik Ałaszewski]

Dnia 10.05.2021 Pawel <ppf9@USUN_TOpoczta.fm> napisał/a:

> Ewentualnie, partclone -> https://partclone.org/about/

Albo od razu z graficzną nakładką dla początkującego,
czyli Clonezilla.

Ma to jedną wadę- nie zadziała.
https://superuser.com/questions/332808/force-cloned-hard-disk-image-upon-a-smaller-hard-disk

Trzeba najpierw zmniejszyć za duży filesystem
źródłowy (nie każdy się da).

Prościej jest IMHO, jak już zaproponowano, utworzyć na nowym
dysku partycje (i ewentualnie LVM) i skopiować dane (np. rsync -a).

--
Dominik Ałaszewski (via raspbianowy slrn)
"W życiu piękne są tylko chwile…" (Ryszard Riedel)
Wyrażam wyłącznie prywatne poglądy zgodnie z Art. 54 Konstytucji RP
Pisząc na priv zmień domenę na gmail.

[Pawel]

W dniu 11.05.2021 o 07:24, Dominik Ałaszewski pisze:

> Dnia 10.05.2021 Pawel <ppf9@USUN_TOpoczta.fm> napisał/a:
>
>> Ewentualnie, partclone -> https://partclone.org/about/
>
> Albo od razu z graficzną nakładką dla początkującego,
> czyli Clonezilla.
>
> Ma to jedną wadę- nie zadziała.
> https://superuser.com/questions/332808/force-cloned-hard-disk-image-upon-a-smaller-hard-disk
>
> Trzeba najpierw zmniejszyć za duży filesystem
> źródłowy (nie każdy się da).

To jesli tak, to cofam propozycje. Nie wiedzialem o tym. Troche lipnie,
ze do takiego zadania, nie ma odpowiedniego narzedzia.

[Roman Tyczka]

W dniu 11.05.2021 o 07:24, Dominik Ałaszewski pisze:

>> Ewentualnie, partclone -> https://partclone.org/about/
>
> Albo od razu z graficzną nakładką dla początkującego,
> czyli Clonezilla.
>
> Ma to jedną wadę- nie zadziała.
> https://superuser.com/questions/332808/force-cloned-hard-disk-image-upon-a-smaller-hard-disk
>
> Trzeba najpierw zmniejszyć za duży filesystem
> źródłowy (nie każdy się da).
>
> Prościej jest IMHO, jak już zaproponowano, utworzyć na nowym
> dysku partycje (i ewentualnie LVM) i skopiować dane (np. rsync -a).

Chyba sobie odpuszczę, bo liczba problemów narasta wykładniczo, a
ponadto robię to bardzo wolno, żeby czegoś nie zepsuć i tracę masę
czasu. Nie da się prosto to nie.
Zainstaluję system od zera na nowym dysku i mozolnie przeniosę konfigi.

ps. czy to LVM dodaje duży narzut wydajnościowy? Bo poczytałem i wygląda
to bardzo interesująco od strony teorii.


--
pzdr
Roman

[Kamil Jońca]

Roman Tyczka <roman...@hate.you.spammer> writes:

[..]

> ps. czy to LVM dodaje duży narzut wydajnościowy? Bo poczytałem i

Nie zauważyłem. Wygoda (m.in. przy kopiowaniu na nowy dysk :P )
powoduje, że obecnie praktycznie nie używam sprzętu bez lvm.
KJ

--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

[Jarosław Sokołowski]

Pan Roman Tyczka napisał:

> Chyba sobie odpuszczę, bo liczba problemów narasta wykładniczo, a
> ponadto robię to bardzo wolno, żeby czegoś nie zepsuć i tracę masę
> czasu. Nie da się prosto to nie.
> Zainstaluję system od zera na nowym dysku i mozolnie przeniosę konfigi.

Da się szybko, gdy ma się już wprawę. Ale doskonale rozumiem trudność
początków. Z setek sposobów ogarnięcia tematu mogę podsunąć jeszcze dwie
myśli:

1. Zainstalować na nowo jak leci, a optem zmienić UUID nowej prtycji
i zrobić rsync z opcjami "-a --delete" (i zapewne --exclude home).

2. Na starym systemie zrobić (chyba już to kiedys proponowałem):
LANG=c apt list --installed | grep -v automatic | cut -d/ -f1
a na nowym "apt install" z uzyskaną listą jako argumentem.
Zwykle się okazune, że odtworzenie poprzedniej konfiguracji
nie jest wcale takie mozolne.

--
Jarek

[Pawel]

W dniu 11.05.2021 o 17:42, Roman Tyczka pisze:

> W dniu 11.05.2021 o 07:24, Dominik Ałaszewski pisze:
>>> Ewentualnie, partclone -> https://partclone.org/about/
>>
>> Albo od razu z graficzną nakładką dla początkującego,
>> czyli Clonezilla.
>>
>> Ma to jedną wadę- nie zadziała.
>> https://superuser.com/questions/332808/force-cloned-hard-disk-image-upon-a-smaller-hard-disk
>>
>>
>> Trzeba najpierw zmniejszyć za duży filesystem
>> źródłowy (nie każdy się da).
>>
>> Prościej jest IMHO, jak już zaproponowano, utworzyć na nowym
>> dysku partycje (i ewentualnie LVM) i skopiować dane (np. rsync -a).
>
> Chyba sobie odpuszczę, bo liczba problemów narasta wykładniczo, a

A mam takie pytanie dla osob obeznanych z maszynami wirtualnymi.
Czy daloby sie podpiac obraz dysku hhd(nie virtual) do maszyny wirtualnej?

Jesli tak, to mozna zrobic obraz dysku zrodlowego (nie ma wtedy ryzyka
uszkodzenia danych).

Podmontowac taki dysk do maszyny wirtuanej.

Podmontowany dysk, mozna zmniejszyc (przynajmniej takie cos jest w
VirtualBox) i wtedy mozna by taki dysk skopiowac uzywajac dd na nowy dysk.

Daloby sie cos takiego zrobic?

JEst tylko kjeden warunek. Musi byc odpowiednia milosc miejsca na obraz.

[Roman Tyczka]

W dniu 11.05.2021 o 18:56, Jarosław Sokołowski pisze:

>> Zainstaluję system od zera na nowym dysku i mozolnie przeniosę konfigi.
>
> Da się szybko, gdy ma się już wprawę. Ale doskonale rozumiem trudność
> początków. Z setek sposobów ogarnięcia tematu mogę podsunąć jeszcze dwie
> myśli:
>
> 1. Zainstalować na nowo jak leci, a optem zmienić UUID nowej prtycji
> i zrobić rsync z opcjami "-a --delete" (i zapewne --exclude home).

Co ten zabieg ma konkretnie na celu? Czytam i nie chwytam idei.

> 2. Na starym systemie zrobić (chyba już to kiedys proponowałem):
> LANG=c apt list --installed | grep -v automatic | cut -d/ -f1
> a na nowym "apt install" z uzyskaną listą jako argumentem.
> Zwykle się okazune, że odtworzenie poprzedniej konfiguracji
> nie jest wcale takie mozolne.

To byłoby dobre, gdybym chciał mieć wszystko jak leci, a jest trochę
rzeczy, które jednak pominę, bo na etapie zaznajamiania się z dostępnym
na Ubuntu softwarem pointstalowałem masę śmiecia, którego się teraz przy
okazji pozbędę. Tak czy owak dzięki za tipa. Może kiedyś, gdzieś się przyda.

--
pzdr
Roman

[Roman Tyczka]

W dniu 11.05.2021 o 18:49, Kamil Jońca pisze:

> [..]
>
>> ps. czy to LVM dodaje duży narzut wydajnościowy? Bo poczytałem i
> Nie zauważyłem. Wygoda (m.in. przy kopiowaniu na nowy dysk :P )
> powoduje, że obecnie praktycznie nie używam sprzętu bez lvm.

A czy LVM da się przy instalacji systemu od razu uaktywnić? I czy da się
tam wpiąć dyski z danymi, bez utraty danych?


--
pzdr
Roman

[Kamil Jońca]

Mogę się tylko za Debiana wypowiadać.
1. Instalator debiana pozwala od razu założyć lvm
2. " I czy da się tam wpiąć dyski z danym" - jeśli myślisz o LVM to nie.

KJ

--
http://wolnelektury.pl/wesprzyj/teraz/

[Jarosław Sokołowski]

Pan Roman Tyczka napisał:

>>> Zainstaluję system od zera na nowym dysku i mozolnie przeniosę konfigi.
>>
>> Da się szybko, gdy ma się już wprawę. Ale doskonale rozumiem trudność
>> początków. Z setek sposobów ogarnięcia tematu mogę podsunąć jeszcze dwie
>> myśli:
>>
>> 1. Zainstalować na nowo jak leci, a optem zmienić UUID nowej prtycji
>> i zrobić rsync z opcjami "-a --delete" (i zapewne --exclude home).
>
> Co ten zabieg ma konkretnie na celu? Czytam i nie chwytam idei.

Faktyczne sklonowanie partycji A na partycję B. Wszystko, co było na A,
zostanie skopiowane na B, a jeśli na B było coś, czego nie było na A,
zostanie skasowane. Przy tej operacji chcemy pominąć katalog /home,
który docelowo ma trafić na osobną partycję.

>> 2. Na starym systemie zrobić (chyba już to kiedys proponowałem):
>> LANG=c apt list --installed | grep -v automatic | cut -d/ -f1
>> a na nowym "apt install" z uzyskaną listą jako argumentem.
>> Zwykle się okazune, że odtworzenie poprzedniej konfiguracji
>> nie jest wcale takie mozolne.
>
> To byłoby dobre, gdybym chciał mieć wszystko jak leci, a jest trochę
> rzeczy, które jednak pominę, bo na etapie zaznajamiania się z dostępnym
> na Ubuntu softwarem pointstalowałem masę śmiecia, którego się teraz przy
> okazji pozbędę.

Wracamy do wniosków z dyskusji, która kiedyś już tu się odbyła. Na ogół
nie warto klonować dysków systemowych. Instalacja od nowa ma więcej
zalet, a problemów mniej. Za to często klonuje się partycję home --
przeprowadzka do nowego domu, gdy stary jest juz za dziasny. A to
najlepiej robi się przez rsync, pomysły z dd i zmianą rozmiaru są
słabe.

> Tak czy owak dzięki za tipa. Może kiedyś, gdzieś się przyda.

W takim razie tip kolejny. Na współczesnych dyskach system zajmuje
stosunkowo mało miejsca. Warto więc zrobić dwie takie same partycje
na system, a resztę dysku przeznaczyć na home. Potem w każdej
chwili na tej rezerwowej można postawić drugi system, z nadzieją,
że będzie lepszy. A jak przyjdzie czas, to i trzeci, orając ten
pierwszy. Taka trójpolówka. Już w średnioiweczu ten pomysł się
sprawdził.

--
Jarek

[Dominik Ałaszewski]

Dnia 11.05.2021 Pawel <ppf9@USUN_TOpoczta.fm> napisał/a:

> A mam takie pytanie dla osob obeznanych z maszynami wirtualnymi.
> Czy daloby sie podpiac obraz dysku hhd(nie virtual) do maszyny wirtualnej?

Ma to szanse zadziałać, tylko po co? :-)

Dużo prościej dla początkującego zapewne byłoby zmniejszyć partycję
o te ileś MB za pomocą gparted livecd. Backup i tak trzeba mieć zawsze.
(a jeśli masz kolejny dysk na pełny obraz, to gdy zmniejszanie się
nie powiedzie po prostu go przywrócisz, bez zabawy z wirtualkami).

A potem już clonezilla z przełącznikami -icds i -k1.

[Roman Tyczka]

W dniu 11.05.2021 o 23:00, Jarosław Sokołowski pisze:

>> To byłoby dobre, gdybym chciał mieć wszystko jak leci, a jest trochę
>> rzeczy, które jednak pominę, bo na etapie zaznajamiania się z dostępnym
>> na Ubuntu softwarem pointstalowałem masę śmiecia, którego się teraz przy
>> okazji pozbędę.
>
> Wracamy do wniosków z dyskusji, która kiedyś już tu się odbyła. Na ogół
> nie warto klonować dysków systemowych. Instalacja od nowa ma więcej
> zalet, a problemów mniej. Za to często klonuje się partycję home --
> przeprowadzka do nowego domu, gdy stary jest juz za dziasny. A to
> najlepiej robi się przez rsync, pomysły z dd i zmianą rozmiaru są
> słabe.

Tak, osobna partycja na /home to bardzo przydatna rzecz, dziwi mnie, że
standardowo instalator Ubuntu wpakował wszystko razem.

>> Tak czy owak dzięki za tipa. Może kiedyś, gdzieś się przyda.
>
> W takim razie tip kolejny. Na współczesnych dyskach system zajmuje
> stosunkowo mało miejsca. Warto więc zrobić dwie takie same partycje
> na system, a resztę dysku przeznaczyć na home. Potem w każdej
> chwili na tej rezerwowej można postawić drugi system, z nadzieją,
> że będzie lepszy. A jak przyjdzie czas, to i trzeci, orając ten
> pierwszy. Taka trójpolówka. Już w średnioiweczu ten pomysł się
> sprawdził.

Ten pomysł mi się bardzo podoba, zastosuję go, bo korzyści są ewidentne,
a w międzyczasie ugorem stał nie będzie, bo mogę tam wsadzać wirtualki.

Jeszcze mam jedno pytanie o partycje.
Instalowałem wczoraj wirtualkę z Kubuntu, bo potrzebuję kolejnej maszyny
do pewnych zadań, podczas instalacji wybrałem ręczne zarządzanie
partycjami, żeby trochę "podoświadczać naocznie". Założyłem więc
partycję EFI, dwie Ext4 (na / i /home) i zadowolony kazałem
instalatorowi lecieć dalej. A on mi warknął, że potrzeba jeszcze
partycji "BIOS Boot", malutkiej, 4MB chyba dałem.
O co z nią chodzi? Do czego służy? I dlaczego na dużym kompie, o którym
ten wątek jest, nie mam takiej partycji?

--
pzdr
Roman

[Jarosław Sokołowski]

Pan Roman Tyczka napisał:

> Tak, osobna partycja na /home to bardzo przydatna rzecz, dziwi mnie,
> że standardowo instalator Ubuntu wpakował wszystko razem.

Instalator musi zadowolić wszystkich, również tych, co instalują system
na małych dyskach. Tam taki podział nie jest oczywisty.

>> W takim razie tip kolejny. Na współczesnych dyskach system zajmuje
>> stosunkowo mało miejsca. Warto więc zrobić dwie takie same partycje
>> na system, a resztę dysku przeznaczyć na home. Potem w każdej
>> chwili na tej rezerwowej można postawić drugi system, z nadzieją,
>> że będzie lepszy. A jak przyjdzie czas, to i trzeci, orając ten
>> pierwszy. Taka trójpolówka. Już w średnioiweczu ten pomysł się
>> sprawdził.
>
> Ten pomysł mi się bardzo podoba, zastosuję go, bo korzyści są ewidentne,
> a w międzyczasie ugorem stał nie będzie, bo mogę tam wsadzać wirtualki.

Można też kopię aktualnego systemu (dla ochrony przed skutkami grzebactwa
eksperymentalnego).

> Jeszcze mam jedno pytanie o partycje.
> Instalowałem wczoraj wirtualkę z Kubuntu, bo potrzebuję kolejnej maszyny
> do pewnych zadań, podczas instalacji wybrałem ręczne zarządzanie
> partycjami, żeby trochę "podoświadczać naocznie". Założyłem więc
> partycję EFI, dwie Ext4 (na / i /home) i zadowolony kazałem
> instalatorowi lecieć dalej. A on mi warknął, że potrzeba jeszcze
> partycji "BIOS Boot", malutkiej, 4MB chyba dałem.
> O co z nią chodzi? Do czego służy? I dlaczego na dużym kompie, o którym
> ten wątek jest, nie mam takiej partycji?

Widać wirtualna maszyna nie emuluje EFI, tylko BIOS. BIOS ma ograniczenia,
między innymi w dostępie do dużych partycji. Na samym początku musi załadować
kernel odczytany z dysku. Na tej partycji umieszczony jest plik z kernelem.
To tak w skrócie.

--
Jarek

[Roman Tyczka]

W dniu 12.05.2021 o 13:02, Jarosław Sokołowski pisze:

>> Jeszcze mam jedno pytanie o partycje.
>> Instalowałem wczoraj wirtualkę z Kubuntu, bo potrzebuję kolejnej maszyny
>> do pewnych zadań, podczas instalacji wybrałem ręczne zarządzanie
>> partycjami, żeby trochę "podoświadczać naocznie". Założyłem więc
>> partycję EFI, dwie Ext4 (na / i /home) i zadowolony kazałem
>> instalatorowi lecieć dalej. A on mi warknął, że potrzeba jeszcze
>> partycji "BIOS Boot", malutkiej, 4MB chyba dałem.
>> O co z nią chodzi? Do czego służy? I dlaczego na dużym kompie, o którym
>> ten wątek jest, nie mam takiej partycji?
>
> Widać wirtualna maszyna nie emuluje EFI, tylko BIOS. BIOS ma ograniczenia,
> między innymi w dostępie do dużych partycji. Na samym początku musi załadować
> kernel odczytany z dysku. Na tej partycji umieszczony jest plik z kernelem.
> To tak w skrócie.

Thx, rzeczywiście w ustawieniach tej wirtuali "firmware type" ustawiony
jest na bios, a można wybrać uefi. Wszystko jasne.

--
pzdr
Roman