I understand this is a long shot but if anyone can point me in the right direction I would appreciate it:
I have made several attempts to clone my OpenSUSE 12.2 installation to a larger drive with no success. I am starting to think that cloning is not an option. I have tried sector by sector cloning using Acronis & PartedMagic and on both the clone completes but it boots to emergency mode, my guess is because initrd or fstab can’t find the / partition because it’s guid has changed.
I installed this with Grub2efi and 3 partitions, an EFI boot that is FAT16, a Swap partition, and a BTRFS root partition. I think that after the clone is complete I must do something with EFI to tell it about the new disk but I don’t know what I would need to do.
Alternatively, I don’t really need to clone it inasmuch as I could use to recreate it. If there was someway to save repositories and package information say in a kickstart or otherwise and then build a new one based on that rather than a few days of manual work that would work too, but again no idea where to start doing that.
On Wed, 19 Dec 2012 20:36:01 +0000, witchbutter wrote:
> I have made several attempts to clone my OpenSUSE 12.2 installation to a
> larger drive with no success. I am starting to think that cloning is
> not an option. I have tried sector by sector cloning using Acronis &
> PartedMagic and on both the clone completes but it boots to emergency
> mode, my guess is because initrd or fstab can’t find the / partition
> because it’s guid has changed.
In YaST’s partition manager, change the “mount by” option to “device
path” rather than “device ID”. “Volume label” probably would also work.
Then create your disk image/clone.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On 2012-12-19 21:36, witchbutter wrote:
> Alternatively, I don’t really need to clone it inasmuch as I could use
> to recreate it. If there was someway to save repositories and package
> information say in a kickstart or otherwise and then build a new one
> based on that rather than a few days of manual work that would work too,
> but again no idea where to start doing that.
A wild idea.
Fresh install in the target disk, but create a separate /boot partition.
Make sure you use the same kernel version on both old and new systems.
Second step is to copy file by file from old system to new system,
everything except boot.
No guarantee - I have never done this, but it should work.
I’m not sure how grub2 should be installed in the sacrificial first
install, maybe someone knows.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
On 2012-12-19 21:48, Jim Henderson wrote:
> In YaST’s partition manager, change the “mount by” option to “device
> path” rather than “device ID”. “Volume label” probably would also work.
Doesn’t grub2 also use device ids?
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
On Wed, 19 Dec 2012 21:08:09 +0000, Carlos E. R. wrote:
> On 2012-12-19 21:48, Jim Henderson wrote:
>> In YaST’s partition manager, change the “mount by” option to “device
>> path” rather than “device ID”. “Volume label” probably would also
>> work.
>
> Doesn’t grub2 also use device ids?
Possibly, though I seem to recall that changing it in the partitioner
takes care of the bootloader as well - but it would be good to check the
grub2 equivalent of the device.map file to make sure that got updated as
well.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
No. It uses filesystem UUID if available, otherwise it creates file with generated UUID and searches for it. It may also use GPT partition UUIDs,but here I am not sure.
On 2012-12-20 04:26, arvidjaar wrote:
>
> robin_listas;2512027 Wrote:
>> Doesn’t grub2 also use device ids?
>
> No. It uses filesystem UUID if available, otherwise it creates file
> with generated UUID and searches for it.
Ah, ok, something of the sort. It no longer uses the (hdX,Y) naming,
that’s the important thing.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
Thanks for pointing me in the correct direction. As it turns out the default install used a mixture of UUIDs and GPT IDs, but reverting to the old way of identifying partitions worked for me.
/etc/fstab before:
/dev/disk/by-id/ata-G.SKILL_FALCON_128GB_SSD_DCGS10270ABA40001-part2 swap swap noatime 0 0
UUID=d25e9bea-3399-4f06-984f-b82c9f233cdc / btrfs noatime 1 1
/dev/disk/by-id/ata-G.SKILL_FALCON_128GB_SSD_DCGS10270ABA40001-part1 /boot/efi vfat umask=0002,utf8=true 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
tmpfs /tmp tmpfs nodev,nosuid,noexec,mode=1777 0 0
/etc/fstab after:
/dev/sda2 swap swap noatime 0 0
/dev/sda3 / btrfs noatime 1 1
/dev/sda1 /boot/efi vfat umask=0002,utf8=true 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
tmpfs /tmp tmpfs nodev,nosuid,noexec,mode=1777 0 0
To date this is the only way I know to modify grub2efi is in Yast.
In ‘Boot Loader Options’ I had to change:
Optional Kernel Command Line Parameter:
resume=**/dev/sda2** splash=silent quiet showopts noop
I assume this just tells the kernel where to put memory contents to hibernate.
After that the clone worked perfectly using partclone inside PartedMagic.