[opensuse] Clone disk
I have a user (openSUSE 12.3 - I know...) that wants to clone the root disk. In fact, long ago, they did this. But apparently both they and I have forgotten exactly what we did... The disk copy went ok. dd the entire thing from one disk to another of the same type. We always mount by_id since there may be multiple disks. So, after the dd, one needs to mount the new disk and edit /etc/fstab with the new disk's ID. This has been done. The boot seems to then be looking for the correct disk. However, the boot does not happen. It just hangs. The kernel command line is the only thing printed. I do not have the disk in my possession (it's on a different continent). So, before I tell them to send it to me, I just want to be sure that I have not missed another step. Could there be a need to remake the initial ram disk? Is the disk id in there as well? If one has to do mkinitrd, how can one do that on a mounted disk (not the system's root disk)? Or maybe it is something else? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/07/2019 08:57, Roger Oberholtzer wrote:
I have a user (openSUSE 12.3 - I know...) that wants to clone the root disk. In fact, long ago, they did this. But apparently both they and I have forgotten exactly what we did...
The disk copy went ok. dd the entire thing from one disk to another of the same type.
We always mount by_id since there may be multiple disks. So, after the dd, one needs to mount the new disk and edit /etc/fstab with the new disk's ID. This has been done. The boot seems to then be looking for the correct disk.
However, the boot does not happen. It just hangs. The kernel command line is the only thing printed.
I do not have the disk in my possession (it's on a different continent). So, before I tell them to send it to me, I just want to be sure that I have not missed another step. Could there be a need to remake the initial ram disk? Is the disk id in there as well?
If one has to do mkinitrd, how can one do that on a mounted disk (not the system's root disk)?
Or maybe it is something else?
Cloning a disk results in it having the same UUID, you need to use the file system's utility to generate a new UUID if you are using it on the same computer. Regards Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 30/07/2019 à 13:04, Dave Plater a écrit :
Cloning a disk results in it having the same UUID, you need to use the file system's utility to generate a new UUID if you are using it on the same computer.
use clonezilla that do the job on the fly :-) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/30/2019 06:09 AM, jdd@dodin.org wrote:
Le 30/07/2019 à 13:04, Dave Plater a écrit :
Cloning a disk results in it having the same UUID, you need to use the file system's utility to generate a new UUID if you are using it on the same computer.
use clonezilla that do the job on the fly :-)
jdd
Clonezilla (Debian based) is hard to beat for cloning both Linux and Window disks (or partitions) whatever. One of the best features is that you can create a bootable clonezilla image on the new disk, which you then install where it will live and then boot from the new drive which boots entirely to ram, releasing the disk it was booted from, and then clone from old-to-new. All that remains is to yank the old drive. This works amazingly well. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Jul 31, 2019 at 7:48 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On 07/30/2019 06:09 AM, jdd@dodin.org wrote:
Le 30/07/2019 à 13:04, Dave Plater a écrit :
Cloning a disk results in it having the same UUID, you need to use the file system's utility to generate a new UUID if you are using it on the same computer.
It is not the UUID assigned by the OS. It is the disk's hardware ID that is assigned by the disk manufacturer. When changing the disk, this must be changed in /etc/fstab (as we use that when referencing the disk). I'm not sure openSUSE was using a disk UUID in 12.3. I think I remember the missing step. We also need to edit /boot/grub/device.map which defines hd0, which grub needs. I will confirm when the user reports what happens.
use clonezilla that do the job on the fly :-)
I will investigate clonezilla. But unless it modifies /etc/fstab and /boot/grub/device.map with the new disk manufacturer ID, I'm in the same position. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2019 03:10 AM, Roger Oberholtzer wrote:
I will investigate clonezilla. But unless it modifies /etc/fstab and /boot/grub/device.map with the new disk manufacturer ID, I'm in the same position.
Oh, sorry, it is more than worth the investigation, but I don't think it modifies fstab or device.map on the fly. So you would have to add a step after cloning to boot with the old disk, mount the new disk and change the fstab and device.map entries and then finally reboot. I can't believe I don't have a specific memory of doing that... After 50 it's a dice roll... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/07/2019 10:10, Roger Oberholtzer wrote:
It is not the UUID assigned by the OS. It is the disk's hardware ID that is assigned by the disk manufacturer. When changing the disk, this must be changed in /etc/fstab (as we use that when referencing the disk).
I'm not sure openSUSE was using a disk UUID in 12.3.
I think I remember the missing step. We also need to edit /boot/grub/device.map which defines hd0, which grub needs.
I will confirm when the user reports what happens. As far as the mount point goes you can still use /dev/sxxx to mount. Use
If the partition/s don't have unique UUID's they can't exist together. the boot installed system function on the installation disk and then run yast2 bootloader to fix grub. Regards Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Aug 2, 2019 at 9:30 AM Dave Plater <dplater.list@gmail.com> wrote:
On 31/07/2019 10:10, Roger Oberholtzer wrote:
It is not the UUID assigned by the OS. It is the disk's hardware ID that is assigned by the disk manufacturer. When changing the disk, this must be changed in /etc/fstab (as we use that when referencing the disk).
If the partition/s don't have unique UUID's they can't exist together.
This was about openSUSE 12.3, where disk UUIDs were not yet used (at least not in my installations). The ID I am referring to is the disk's manufacturer ID number.
As far as the mount point goes you can still use /dev/sxxx to mount. Use the boot installed system function on the installation disk and then run yast2 bootloader to fix grub.
We specifically do not use /dev/sdX because there are removable disks in the system. If a disk is added/removed, then the disk layout changes, and the disk assigned to sdX also change. The manufacturer's ID number never changes, This also why we do not use the generic network device ids, as their assignment, by default, is not consistent. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/07/2019 08.57, Roger Oberholtzer wrote:
I have a user (openSUSE 12.3 - I know...) that wants to clone the root disk. In fact, long ago, they did this. But apparently both they and I have forgotten exactly what we did...
The disk copy went ok. dd the entire thing from one disk to another of the same type.
Are you sure you used: dd if=/dev/sda of=/dev/sdb or equivalent? Ie, the entire hard disk? If you did that, the IDs are also cloned and no need to mess with them. If you have to change the IDs, you cloned differently. How exactly, please?
We always mount by_id since there may be multiple disks. So, after the dd, one needs to mount the new disk and edit /etc/fstab with the new disk's ID. This has been done. The boot seems to then be looking for the correct disk.
However, the boot does not happen. It just hangs. The kernel command line is the only thing printed.
I do not have the disk in my possession (it's on a different continent). So, before I tell them to send it to me, I just want to be sure that I have not missed another step. Could there be a need to remake the initial ram disk? Is the disk id in there as well?
Certainly the initrd can have a copy of the old fstab. Also, there is grub, which has references to the old IDs.
If one has to do mkinitrd, how can one do that on a mounted disk (not the system's root disk)?
Or maybe it is something else?
First let's make sure that the IDs changed and why. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Le 30/07/2019 à 13:31, Carlos E. R. a écrit :
First let's make sure that the IDs changed and why.
I guess he didn't. I made the same mistake once, and got the same symptoms, one can keep the ID, but only if you swap the disks, removing the old one jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/07/2019 13.38, jdd@dodin.org wrote:
Le 30/07/2019 à 13:31, Carlos E. R. a écrit :
First let's make sure that the IDs changed and why.
I guess he didn't. I made the same mistake once, and got the same symptoms, one can keep the ID, but only if you swap the disks, removing the old one
As the original disk is "on a different continent" that is not a problem. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Le 30/07/2019 à 13:43, Carlos E. R. a écrit :
On 30/07/2019 13.38, jdd@dodin.org wrote:
Le 30/07/2019 à 13:31, Carlos E. R. a écrit :
First let's make sure that the IDs changed and why.
I guess he didn't. I made the same mistake once, and got the same symptoms, one can keep the ID, but only if you swap the disks, removing the old one
As the original disk is "on a different continent" that is not a problem.
I don't think one can clone a disk from a different continent :-(. I guess the OP was giving instructions to someone else. He will say jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/07/2019 13.50, jdd@dodin.org wrote:
Le 30/07/2019 à 13:43, Carlos E. R. a écrit :
On 30/07/2019 13.38, jdd@dodin.org wrote:
Le 30/07/2019 à 13:31, Carlos E. R. a écrit :
First let's make sure that the IDs changed and why.
I guess he didn't. I made the same mistake once, and got the same symptoms, one can keep the ID, but only if you swap the disks, removing the old one
As the original disk is "on a different continent" that is not a problem.
I don't think one can clone a disk from a different continent :-(. I guess the OP was giving instructions to someone else. He will say
Well, you can, but that is not what he said. He or they cloned the HD "somehow", and *now* the disk is in another continent. Maybe someone came with the disk, and now returned or travelled to somewhere. Or the disk was originally "here" and now travelled with someone elsewhere to be deployed. Whatever. Does not matter. What matters is that it is no longer locally available. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 2019-07-30 5:58 a.m., Carlos E. R. wrote:
On 30/07/2019 13.50, jdd@dodin.org wrote:
I don't think one can clone a disk from a different continent :-(. I guess the OP was giving instructions to someone else. He will say
Well, you can, but that is not what he said. He or they cloned the HD "somehow", and *now* the disk is in another continent.
No, Carlos, that is *not* what he said. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/07/2019 14.10, Darryl Gregorash wrote:
On 2019-07-30 5:58 a.m., Carlos E. R. wrote:
On 30/07/2019 13.50, jdd@dodin.org wrote:
I don't think one can clone a disk from a different continent :-(. I guess the OP was giving instructions to someone else. He will say
Well, you can, but that is not what he said. He or they cloned the HD "somehow", and *now* the disk is in another continent.
No, Carlos, that is *not* what he said.
He did. «I do not have the disk in my possession (it's on a different continent).» So at least now the disk is not in his possession, wherever it was before. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 2019-07-30 6:33 a.m., Carlos E. R. wrote:
On 30/07/2019 14.10, Darryl Gregorash wrote:
On 2019-07-30 5:58 a.m., Carlos E. R. wrote:
On 30/07/2019 13.50, jdd@dodin.org wrote:
I don't think one can clone a disk from a different continent :-(. I guess the OP was giving instructions to someone else. He will say
Well, you can, but that is not what he said. He or they cloned the HD "somehow", and *now* the disk is in another continent.
No, Carlos, that is *not* what he said.
He did.
«I do not have the disk in my possession (it's on a different continent).»
So at least now the disk is not in his possession, wherever it was before.
There is absolutely no chronological order implied by his posts. Indeed, quite the opposite is suggested: The drive is in a computer on another continent. The person running that computer asks for help in cloning the drive. Roger communicates instructions on how to do that to the other person, who then performs the cloning operation. You have assumed throughout that Roger initially said "*now* the drive is on another continent", when he did not.
On Tue, Jul 30, 2019 at 5:03 PM Darryl Gregorash <raven@accesscomm.ca> wrote:
You have assumed throughout that Roger initially said "*now* the drive is on another continent", when he did not.
Indeed I have not been in possession of either disk. I am helping a remote user. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger
On Jul 30, 2019, at 13:31, Carlos E. R. <robin.listas@telefonica.net> wrote:
If you did that, the IDs are also cloned and no need to mess with them. If you have to change the IDs, you cloned differently.
The ID I’m referring to is the hardware serial number as in /dev/disk/by-id. If you use a different physical disk then this must be updated in /etc/fatback. Maybe it’s the boot config that defines hd(0) - in /etc somewhere. I’ll check when I’m back in the office.
How exactly, please?
We always mount by_id since there may be multiple disks. So, after the dd, one needs to mount the new disk and edit /etc/fstab with the new disk's ID. This has been done. The boot seems to then be looking for the correct disk.
However, the boot does not happen. It just hangs. The kernel command line is the only thing printed.
I do not have the disk in my possession (it's on a different continent). So, before I tell them to send it to me, I just want to be sure that I have not missed another step. Could there be a need to remake the initial ram disk? Is the disk id in there as well?
Certainly the initrd can have a copy of the old fstab. Also, there is grub, which has references to the old IDs.
If one has to do mkinitrd, how can one do that on a mounted disk (not the system's root disk)?
Or maybe it is something else?
First let's make sure that the IDs changed and why.
-- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/07/2019 13.44, Roger Oberholtzer wrote:
Roger
On Jul 30, 2019, at 13:31, Carlos E. R. <> wrote:
If you did that, the IDs are also cloned and no need to mess with them. If you have to change the IDs, you cloned differently.
The ID I’m referring to is the hardware serial number as in /dev/disk/by-id. If you use a different physical disk then this must be updated in /etc/fatback. Maybe it’s the boot config that defines hd(0) - in /etc somewhere. I’ll check when I’m back in the office.
Ah! Ok, my mistake. I always use UUID, which is cloned. I don't see a reason to use by-id, which I believe I have seen changing with OS updates. What is /etc/fatback? :-? Ok, then to update initrd you do: * boot a rescue system, preferably of same approximate version as the system rescued. * mount the system being rescued. Mount its "/", "/boot" and whatever it has in correct sequence. Possibly not "/home". * mount bind the /dev, /sys, and /proc filesystems (whatever they are on version 12) * chroot to the rescued system. * Possibly you may have to edit /etc/mtab on the rescued system. * If you need internet you may have to do other things. Now you can run programs of the rescued system, possibly yast boot module (in text mode). mkinird should work, but first edit fstab and grub (maybe lilo!). -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Hi roger,
following up a private mail where i was asking for language:
i have had in 2016 a suse 11.4 with bad hdd, so i have made a ddrescue, fix it in the virual diskfile, and copy it back to a new harddisk. in 2017 i have copy a entire hard disk from a old 32bit computer suse 11.4 to a virtual disk using dd and running it in a kvm virtual machine. so i think it is the same thing you need. because i always write down the steps i do, here is what i have done, hopefully it will help you. i have not used a chroot enviorement here, i changed all files by hand. for searching of consent in files, i use always the midnight commander. booting the pc with bad harddrive and with good harddrive i would use "systemrescue cd". could be burned to cd and there is also a howto to burn it on sticks. http://www.system-rescue-cd.org/ =============================================================== BUT maybe its not neccesarry to boot with another system, see at the end of this text, for copy a harddrive to virtual system, i have found a solution to boot with the "not running system" i think this could work also in real. ================================================================ here is the german and my bad english "interpertion" of all infos i have written down. take care, my first run was not sucessfull, because of inserting wrong names, see at the end of the info's here: changing of harddrives opensuse 11.4 austauschen von festplatten (opensuse 11.4): ============================================================ after changing system did not boot because initramdisk and others have wrong names. (inside /dev there are the corret ones, see later in this text) nach austausch laeuft der rechner nicht mehr hoch, da ihm die korrekte platte zum weiterbooten nach initramdisk fehlt: (nun auf jeden fall die vorhandenen namen im /dev... (siehe unten) nochmals anschauen!!!!!) ============================================================ for the new and the old harddrive names look inside /dev/disk/by-id/ (ll > names-of-drives) do it once with old, once with new plate attached, now its clear what has to be changed. fuer die neuen und alten platten am einfachsten im. /dev/disk/by-id/ ein ll > irgendwas.txt machen da stehen die alten namen dann drin, das gleiche mit den neuen platten auch machen, nun weiss man was mit was ausgetauscht werden muss. ====================== search where this name is inside (with midnight commander): suche wo ueberall die falschen platten drin stehen: ******change****** /boot/grub device.map ****geaendert**** /boot grub menue.lst ****geaendert**** on some systems also: etc/sysconfig/bootloader (in diesem falle hier nichts drin - andere rechner schon) etc/fstab ****geaendert**** (not neccesarry to change) etc/fstab.yast2save (das vermutlich nicht aendern) (don't know, maybe ignore) etc/lvm/cache (das vermutlich ignorieren) ======================= now search for the initramdrive and copy to a save place: nun die initramdisk suchen und kopieren: /boot/initrd symbolic link to initrd-3.0.101-102-desktop /boot/vmlinuz symlink to vmlinuz-3.0.101-102-desktop ======================= according to a guide from: nach der anleitung von: http://www.thegeekstuff.com/2009/07/how-to-view-modify-and-recreate-initrd-i... http://backreference.org/2010/07/04/modifying-initrdinitramfs-files/ check how it is packed, what version: schauen was es fuer eine version, wie gepackt ist: gunzip -c initrd-3.0.101-102-desktop |file - result: ergibt: ASCII cpio archive (SVR4 with no CRC) (it is first packed with gz (always) and then with cpio processed, but its a filestructure) (ist also erstmal mit gz gepackt (immer) und dann ncoh durch cpio weiterverwurstelt, aber eigentlich eine filestruktur) unpack it and process it with cpio daher entpacken und entwursteln mit: make a new directory, 'initram-unpacked' and copy the initrd to it neues verzeichnis machen, 'initram-entpackt' das initrd dort rein kopieren gunzip -c initrd-3.0.101-102-desktop | cpio -i delte the initrd file in side this directory das initrd file loeschen!!!!!!!! now here search again where all is the haddrive id is in and change: hier drin nun wieder suchen wo ueberall die platten drin sind und austauschen: ****changed****** ./run_all.sh ****geaendert**** ./config/mount.sh ****geaendert**** ./config/storage.sh ****geaendert**** now pack it together: nun packen mit: find . | cpio -H newc -o | gzip -9 > /home/yourdir/yourpath/modified/initrd-3.0.101-102-desktop ============================================= copy all back alles zurueck kopieren: ============================================= bad result, system will still not start (because:) geht nicht (weil:) inside boot-promt do im boot-promt mittels cd /dev cd disk cd cd by-id ls -l it seems, that the system as: stelle fest dass er aus: WDC_WD1004FBYZ-01YCBB1_WD-WMC6M0D1W5ME only by scsu-sata nur beim scsi-SATA the middle part 01YCBB1 was ignored. ????????? das mittelstueck 01YCBB1 weggelassen hat ??????????? do the same again, now with correct name. mache obigen mit neuen namen success!! jetzt laeufts. ============================= what i have done to run the virtual system in virtuellen machen: (maybe interresting, because i was able to boot the "not running system" and make an mkinitrd on the running system) if system did not start because of harddrives wenn er meckert dass er die platten nicht findet (becherer1 -> nach virtuell) say "n" to all for the questions, you will end in the promt change dir to /dev/disk/by-id mv nameexisten(you see) name_old_harddrive with all entrys dann alles mit "n" bestaetigen. danach ins dev/disk/by-id gehen und dort mv nameexistent name-alt machen mit allen. now type "exit" system will now boot dann exit. system bootet dann. now change etc/fstab and boot/grub/menu.1st to /dev/sda1 danach etc/fstab und boot/grub/menu.1st alles in /dev/sda1 etc. umbenennen. now use the command mkinitrd (dont ask abvout the correct syntax). das geht hier. habe danach noch mkinitrd gemacht allerdings bringt er ne i still have a warning abut different names, but system boots. warnung ueber ungleiche namen, laeuft aber nach wie vor hoch. now i changed boot/grub/device.map danach als versuch noch im boot/grub/device.map geaendert. again, command mkinitrd jetzt noachmals mkinitrd jetzt ohne meckern abgeschlossen. succes, system boot without problems laeuft hoch. ============================ hope this will help you, simoN -- www.becherer.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
The missing bits have been re-discovered. To copy a disk that boots with grub (e.g., openSUSE 12.3) using the disk/by-id of the disk: 1. dd the old to the new. Using the same size disk and copying the entire thing is what I did. 2. Edit three files, updating the old disk/by-id to the new disk's manufacturer id: /etc/fstab /boot/grub device.map /boot grub menu.lst It was the last two files that I had forgotten... -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer composed on 2019-08-01 08:19 (UTC+0200):
The missing bits have been re-discovered. To copy a disk that boots with grub (e.g., openSUSE 12.3) using the disk/by-id of the disk:
1. dd the old to the new. Using the same size disk and copying the entire thing is what I did.
2. Edit three files, updating the old disk/by-id to the new disk's manufacturer id:
/etc/fstab /boot/grub device.map /boot grub menu.lst
In a world overcome by Grub2 and UEFI, these remain a quite simple adjustment to make for the few of us still using what ain't broke in our personal contexts. :-D
It was the last two files that I had forgotten...
As my cloning is more often partitions rather than whole disks, from one area on a disk to another on the same disk, there is for me usually a fourth task quite simply done in Grub but not so in Grub2: # grub
find /boot/grub/stage1 # verify target location ready root (hdX,Y) # grub setup phase one setup (hdX,y) # install it quit #
We are lucky openSUSE continues to offer this convenience rarely available elsewhere. :-) -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Carlos E. R. -
Darryl Gregorash -
Dave Plater -
David C. Rankin -
Felix Miata -
jdd＠dodin.org -
Roger Oberholtzer -
Simon Becherer