Dear all, Possibly this topic was discussed several times, and there are a number of "tutorials" found on the web. Maybe too much. So: I would like to move my root partition to a brand new SSD, and keep /home on the old disk. I copied the existing one with dd and gave it a new UUID. How can I proceed? This is an UEFI machine. Since /boot/efi is tiny, I think it can remain where it is now. Should I create a swap on the SSD? And possibly the most important: how can I tell the laptop to use the root on the SSD.? I tried to unmount the existing /, but since it is in use, I cannot umount it. Thanks for the help. Albert ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 06/02/2021 20.43, oszko@chem.u-szeged.hu wrote:
Dear all,
Possibly this topic was discussed several times, and there are a number of "tutorials" found on the web. Maybe too much.
So: I would like to move my root partition to a brand new SSD, and keep /home on the old disk. I copied the existing one with dd and gave it a new UUID. How can I proceed? This is an UEFI machine. Since /boot/efi is tiny, I think it can remain where it is now. Should I create a swap on the SSD? And possibly the most important: how can I tell the laptop to use the root on the SSD.?
I tried to unmount the existing /, but since it is in use, I cannot umount it.
There are two methods. One is to clone the rotating rust disk totally to the SSD. You need the sector size to be the same. I did this for the laptops. Then I expand the last partition, or create more partitions. One laptop was classic BIOS, the other was UEFI. They both just booted, I think. On the desktop machine I did not clone the disk. It is not trivial. I have done it, but I don't know exactly how I did it. First, I installed a small system on the SSD, and booted it. Using that, I created target partitions where I copied the system partitions over from the rotating rust media, using rsync. Once done, I chrooted the new system (don't forget to bind mount /sys, /proc, /dev) and run yast in text mode to install a boot loader (uefi). I needed several iterations to get it to boot, but I finally got it to boot, and it is the system I'm using right now. Ah, to complicate things, source and destination were on different computers, old and new. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Idézet ("Carlos E.R." <robin.listas@gmx.es>):
On 06/02/2021 20.43, oszko@chem.u-szeged.hu wrote:
Dear all,
Possibly this topic was discussed several times, and there are a number of "tutorials" found on the web. Maybe too much.
So: I would like to move my root partition to a brand new SSD, and keep /home on the old disk. I copied the existing one with dd and gave it a new UUID. How can I proceed? This is an UEFI machine. Since /boot/efi is tiny, I think it can remain where it is now. Should I create a swap on the SSD? And possibly the most important: how can I tell the laptop to use the root on the SSD.?
I tried to unmount the existing /, but since it is in use, I cannot umount it.
There are two methods. One is to clone the rotating rust disk totally to the SSD. You need the sector size to be the same. I did this for the laptops. Then I expand the last partition, or create more partitions. One laptop was classic BIOS, the other was UEFI. They both just booted, I think.
On the desktop machine I did not clone the disk. It is not trivial. I have done it, but I don't know exactly how I did it.
First, I installed a small system on the SSD, and booted it. Using that, I created target partitions where I copied the system partitions over from the rotating rust media, using rsync.
Once done, I chrooted the new system (don't forget to bind mount /sys, /proc, /dev) and run yast in text mode to install a boot loader (uefi). I needed several iterations to get it to boot, but I finally got it to boot, and it is the system I'm using right now. Ah, to complicate things, source and destination were on different computers, old and new.
-- Cheers / Saludos,
Carlos E. R. (from 15.2 x86_64 at Telcontar)
Dear Carlos, Thanks for your tips! I guess it would be an even longer way to go than I first thought. Regards, Albert ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 07/02/2021 16.59, oszko@chem.u-szeged.hu wrote:
Idézet ("Carlos E.R." <robin.listas@gmx.es>):
On 06/02/2021 20.43, oszko@chem.u-szeged.hu wrote:
...
Thanks for your tips! I guess it would be an even longer way to go than I first thought. I think it is easier to do than to explain :-)
The issue of sector size I would like confirmation from others. I don't know if is possible to clone (dd) a disk using dd when the source uses 4 KB sectors and the destination 512 bytes. All my current big hard disks use 4 KB sectors, and all my SSDs, smaller, use 512 bytes. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 07.02.21 21:20, Carlos E.R. wrote:
On 07/02/2021 16.59, oszko@chem.u-szeged.hu wrote:
Idézet ("Carlos E.R." <robin.listas@gmx.es>):
On 06/02/2021 20.43, oszko@chem.u-szeged.hu wrote:
...
Thanks for your tips! I guess it would be an even longer way to go than I first thought. I think it is easier to do than to explain :-)
The issue of sector size I would like confirmation from others. I don't know if is possible to clone (dd) a disk using dd when the source uses 4 KB sectors and the destination 512 bytes. All my current big hard disks use 4 KB sectors, and all my SSDs, smaller, use 512 bytes.
It depends. Most 4k disks have an emulation built in to allow 512 byte sector size, so from the outside, they can be viewed as disks haveing that sector size. Agreed: when you change a single 512-byte sector, the disk itself has to read 4k, then modify the 512 bytes and then write the 4k back, but that is invisible (but measurable) from the outside. Josef -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On 08/02/2021 08.21, Josef Moellers wrote:
On 07.02.21 21:20, Carlos E.R. wrote:
On 07/02/2021 16.59, oszko@chem.u-szeged.hu wrote:
Idézet ("Carlos E.R." <robin.listas@gmx.es>):
On 06/02/2021 20.43, oszko@chem.u-szeged.hu wrote:
...
Thanks for your tips! I guess it would be an even longer way to go than I first thought. I think it is easier to do than to explain :-)
The issue of sector size I would like confirmation from others. I don't know if is possible to clone (dd) a disk using dd when the source uses 4 KB sectors and the destination 512 bytes. All my current big hard disks use 4 KB sectors, and all my SSDs, smaller, use 512 bytes.
It depends. Most 4k disks have an emulation built in to allow 512 byte sector size, so from the outside, they can be viewed as disks haveing that sector size. Agreed: when you change a single 512-byte sector, the disk itself has to read 4k, then modify the 512 bytes and then write the 4k back, but that is invisible (but measurable) from the outside.
I know. For instance, my disks show this: Telcontar:~ # fdisk -l /dev/sda Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: ST2000DM001-1CH1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes Thus, logically they are used in blocks of 512 disks, so there would be no problem with the migration. My ssds are this type, no emulation: Isengard:~ # fdisk -l Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors Disk model: KINGSTON SMS200S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt The problem I worry about is if the source disk says: Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes and the destination ssd says 512. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 08.02.21 10:51, Carlos E. R. wrote:
On 08/02/2021 08.21, Josef Moellers wrote:
On 07.02.21 21:20, Carlos E.R. wrote:
On 07/02/2021 16.59, oszko@chem.u-szeged.hu wrote:
Idézet ("Carlos E.R." <robin.listas@gmx.es>):
On 06/02/2021 20.43, oszko@chem.u-szeged.hu wrote:
...
Thanks for your tips! I guess it would be an even longer way to go than I first thought. I think it is easier to do than to explain :-)
The issue of sector size I would like confirmation from others. I don't know if is possible to clone (dd) a disk using dd when the source uses 4 KB sectors and the destination 512 bytes. All my current big hard disks use 4 KB sectors, and all my SSDs, smaller, use 512 bytes.
It depends. Most 4k disks have an emulation built in to allow 512 byte sector size, so from the outside, they can be viewed as disks haveing that sector size. Agreed: when you change a single 512-byte sector, the disk itself has to read 4k, then modify the 512 bytes and then write the 4k back, but that is invisible (but measurable) from the outside.
I know.
For instance, my disks show this:
Telcontar:~ # fdisk -l /dev/sda Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: ST2000DM001-1CH1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes
Thus, logically they are used in blocks of 512 disks, so there would be no problem with the migration.
My ssds are this type, no emulation:
Isengard:~ # fdisk -l Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors Disk model: KINGSTON SMS200S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt
The problem I worry about is if the source disk says:
Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes
and the destination ssd says 512.
Yes, indeed, you then have a problem because the block numbers used throughout the filesystem metadata refer to the logical block size of the disk and this won't be OK after a "dd". So your best bet would be to make a new filesystem and then copy all the directories and files over. Josef -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On 08/02/2021 11.02, Josef Moellers wrote:
On 08.02.21 10:51, Carlos E. R. wrote:
On 08/02/2021 08.21, Josef Moellers wrote:
On 07.02.21 21:20, Carlos E.R. wrote:
...
Thus, logically they are used in blocks of 512 disks, so there would be no problem with the migration.
My ssds are this type, no emulation:
Isengard:~ # fdisk -l Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors Disk model: KINGSTON SMS200S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt
The problem I worry about is if the source disk says:
Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes
and the destination ssd says 512.
Yes, indeed, you then have a problem because the block numbers used throughout the filesystem metadata refer to the logical block size of the disk and this won't be OK after a "dd".
So your best bet would be to make a new filesystem and then copy all the directories and files over.
"would have" a problem, I don't have that combo :-) Was a theoretical question on my side - wondering about what the OP has. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (4)
-
Carlos E. R. -
Carlos E.R. -
Josef Moellers -
oszko＠chem.u-szeged.hu