I agree that the jump from 13.2 to 15.1 is very large. This is why I will update 42.3 to 15.0 or 15.1. I have another hard drive with this installation (Leap 42.3/ windows 7) for the same laptop.
I have also a live usb with 42.3, which probably has gparted on it. So don’t worry for 13.2. I will just ditch that hard drive.
Well, windoze 10 , as you call it, is real nasty stuff. I don’t want to mess with this garbage for the time being. I use windoze to run skype and office. No internet browsing etc. Suse I use mainly as a login terminal, but do some occasional internet browsing and coding.
I agree that I have to update to 15.0 or 15.1, but this I will do after I have cloned the drive. I don’t want the update to screw grub and spoil the original hdd.
Basically you need to perform:
- Copy the data from old partition to the new one: dd if=/dev/old of=/dev/new bs=4M
- Install grub: Loading...
Ah, 42.3, that is a bit newer than 13.2. That sounds good.
Would be good if you check if gparted is installed on that live USB.
Boot from it, and either search for “gparted” in the application menu, which in KDE is popping up from the lower left corner of your screen, or open a terminal and enter “gparted” or “sudo gparted” and see what happens.
gparted (Gnome Partition Editor) isn’t the same as parted - gparted has a graphical user interface, whereas parted is a command line tool (the latter you know). It would be amazing if gparted would be installed on that live USB.
If gparted should start either way, you could look in its Help menu > About for the version that you have.
Actually was hoping, that by copying the entire old drive to the new one with dd, no grub tuning will be needed. The last time I updated to 42.3 grub got corrupted and it took quite some time to fix it.
Tuning grub might be a show stopper for the entire enterprise.
Note also if there are multiple partition changing size may entail moving partitions since you can only add space to the ends.
[quote="“john_snow,post:45,topic:137932”]
Actually was hoping, that by copying the entire old drive to the new one with dd, no grub tuning will be needed. The last time I updated to 42.3 grub got corrupted and it took quite some time to fix it.
Tuning grub might be a show stopper for the entire enterprise.[/QUOTE]
What exactly is “old”, and what is “new” in the dd command of karlmistelberger’s posting?
sdb? sdb1? What else?
The dd command that I posted somewhere above and which I explained to you clones the whole disk.
Including the boot loader. “Byte by byte”.
That way there is no need to reinstall the boot loader.
Or would you have liked to reinstall the boot loader of your windoze 7 ??
Don’t worry.
And if you want to read a bit more on dd and disk cloning, have a look at
https://wiki.archlinux.org/index.php/Dd
Indeed, there are multiple partitions, and resizing /home is going to be a lot of fun. I hope that I will be able to do it.
There is no “tuning” grub. You simply install it. The running system needs to closely match the system for which you install grub. For bios/mbr see: Grub2 einrichten | Karl Mistelberger
For uefi/gpt the running system needs to run under efi. Verify directory /sys/firmware/efi.
mount /dev/sda3 /mnt # system partition
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
mount -t proc /proc /mnt/proc
chroot /mnt /bin/bash
mount /dev/sda2 /boot/efi # efi partition
grub2-install
grub2-mkconfig -o /boot/grub2/grub.cfg
Ctrl-D
You’re right in that.
The OP isn’t that experienced with respect to installing/moving openSUSE or other systems, as many user won’t be, because it isn’t their daily business. So he/she might have chosen the wrong terms.
This thread up to now is about cloning the whole contents an old HDD, that is to be replaced, to a new SSD. The dual boot on the old HDD includes an installed windoze 7 and an older openSUSE.
No copying of single partitions. Instead cloning will comprise the whole contents of the old HDD, including the MBR, and the boot loader as well.
Hi john_snow,
a few last hints before you proceed.
After booting from the live USB with the HDD and the SSD plugged, what you should NOT do, is to mount any partition of your HDD, as it is done when you e.g. click on the icon of such a partition in the left sidebar of a Dolphin window in KDE (which would mount that partition and display its contents in that Dolphin window, possibly asking for the root password beforehand, which in turn running from a live USB may not even be asked for).
In order to detect which drive is /dev/sda, /dev/sdb, /dev/sdc, etc., before running dd you can use the commands “parted -l” or “fdisk -l”, which won’t mount anything.
Given the output from “parted -l” or “fdisk -l” you can as well see if there exists any partition on your new SSD. In general the SSD should be blank. But I as well had the case that an external HDD was pre-formatted with NTFS, and that the manufacturer had copied windows software to it. If that should be the case you would probably like to make 1-2 backups of that on external media, because this will be overwritten when you clone the contents of your HDD to the SSD using dd. And yes, making such backups means to mount the partition on the SSD beforehand, if there is one. So, after such a backup either unmount that partition, or just reboot.
Another thing you could do before you clone is to check the version of dd that you have by the command “dd --version”. The dd parameter “status=progress” should work starting from version 8.24 of dd. If you have a lower version of dd on your live USB then it is possible to get some information about progress using the “kill” command. Just ask if you like to know.
When I cloned the contents of a failing 2TB hard disk to a new one a few years ago, as far as I remember that took more than 24 hours, but I had used the default block size (dd parameter bs=) of 512 Bytes then. So I felt comfortable beeing able to look what dd is doing from time to time.
Cloning the contents of a 256GB hard disk to a SSD later on took significantly less time.
I use clonezilla - use the disk to disk copy - it only copies the in use sectors. I have done this to dozens of Dell E7440 moving from HDD to mSATA - as long as the new drive is larger - it works wonderfully.
http://www.clonezilla.org/downloads.php I use the stable debian based version - it is for 64 bit cpu’s.
There are tutorials on the site as well.
I actually don’t plan to reuse the old HDD and will keep it as a backup. I think that there should be no software on the msata, but this has to be verified once i get hold of it.
On suse leap 42.3 I have
dd (coreutils) 8.25
Copyright (C) 2016 Free Software Foundation, Inc.
A cording to the man page the status option is supported.
status=LEVEL
The LEVEL of information to print to stderr; 'none' suppresses everything but error messages, 'noxfer'
suppresses the final transfer statistics, 'progress' shows periodic transfer statistics
I will not mount any drives and will make the best use out of parted -l , in order not to mix up the drives.
Actually, is it possible to check the drives also with lsblk?
The only thing I am not so sure about is resizing with gparted. This i have to check.
Hi again!
Good.
That has an additional advantage: rotating hard disks may get damaged quite easily when the laptop is shaken while they are spinning/rotating. The reason for that is physics. An SSD has nothing in it that rotates, so shaking or vibrations won’t do no harm to them even if the laptop is switched on.
That is what one would expect. But you will see. Maybe there would be some software for windows that would enable TRIM under windows? The software that I then found on that external hard disk wasn’t of much use …
Ah, in that context I wrote
By the last I meant that you would have to reboot from the live USB to have nothing mounted from your HDD or SSD, before you run dd.
That as well looks good, so you will easily be able to monitor what progress dd actually has made.
Good.
I’ve no experience with lsblk, but I looked around a bit.
It doesn’t seem to mount anything either.
But I don’t see any advantage of lsblk compared to “parted -l”: when I call “parted -l” I get an information like “Disk model: Samsung SSD 850” prior to the other informations about that device. So one really knows of which kind of hardware that device is. Such kind of information isn’t displayed by lsblk, lsblk just seem to list the /dev/sdaX along with their mount points (not applicable to your new SSD) and possibly UUIDs (not applicable to your new SSD either). So where is the advantage of using “lsblk” compared to using “parted -l”?
I just made some experiments, creating a primary partition and then an extended partition with 2 logical volumes on a USB stick, similar to the setup that can be seen from your output from “parted -l” of your 2nd posting. And I cloned that to a USB stick with more memory using dd.
Using YaST > Partitioner of openSUSE Leap 15.1 to then try to increase the size of the extended partition of the cloned copy on the larger USB stick, that partitioner just says “Extended partitions cannot be resized.” Period.
But GParted as installed under openSUSE Leap 15.1 knows it better: right-clicking on the extended partition in the list of the partitions below (not the graphical representation above) I could very well increase the size the extended partition on the larger USB stick and afterwards create new logical volumes, or increase the size of the last logical volume within the extended partition.
Using YaST > Partitioner afterwards again, these changes were very well recognized.
If you would have installed Leap 15.1 on a USB stick including gparted you could have probably found the same …
OK, so, good luck! And don’t damage your laptop or the devices by electric discharges. This seems to be the biggest risk now.
Just ensure that you have the right /dev/sdX for dd.
To all those besides, who may be reading this thread, and who are considering to clone a disk that according to “parted -l” has a partition table of the type ‘gpt’ (instead of ‘msdos’):
If the destination disk is larger than the source disk, then after cloning using dd, the situation has to be fixed that the backup copy of the ‘gpt’ type partition table on the larger destination disk isn’t at the end of disk anymore.
To read more on this - and on how to fix that then - have a look at the following thread starting from posting #2
https://forums.opensuse.org/showthread.php/537526-mount-advice-needed
Which was already explained earlier in thie (endless) thread in post #27:
[/QUOTE]
Only partly, I would say, because in posting #27 you didn’t explain how, on disks with a partition table of type ‘GPT’, to fix the wrong position of the (backup) copy of the partition table.
As I wrote, it is described in the thread
https://forums.opensuse.org/showthread.php/537526-mount-advice-neededhow to fix this - to which thread I found it useful to include a link here, because this hasn’t been a main topic of the thread here, as the OP of the thread here has a partition table of type ‘MSDOS’ (or a legacy setup).