No boot after disk clonning

English Install/Boot/Login
#1

Hi, guys.

Sorry to bother you but I have a problem that I cannot fix by myself.

I have made an image with dd of a working openSuse 15.0 installation and then clone that image to a new raid 1 virtual disk (Marvell controller with 2 disks in RAID 1). So far so good, new VD boots but it won’t load the whole OS.

It asks for login but even with the wright credentials it will time out and ask for the credentials again.

Something is broken and I cannot tell what it is.

Thank you in advance for your help.

#2

None of my many successful clones have ever involved RAID or Linux VMs, so I’m just thinking out loud here.

Was the source also a VM?

Was the source mounted when dd’d?

Was the source also RAID1?

Were the destination’s fstab and bootloader correctly adjusted for differences?

#3

This is already very vague indeed.

What do you call "the installation? Only a root partition, or also other partitions included (when there are any)?

dd of one or more partitions? dd of one or more disks? dd of one or more Logical Volumes, dd of something else?

#4

No, the source was a simple disk installation

Since fstab has the UUIDs of the disk and that value is clone along the rest of the disk I did not change anything.

#5

Sorry if I have not expressed myself clearly. The whole disk, including all partitions with their respective subvolumes were cloned.

#6

The system while booting throws the message

**GPT:Alternate GPT header not at the end of the disk.

**I think that’s because the new disk is bigger than the original.

Don’t know how to solve it yet.

#7

Your though is correct.

#8

I don’t really know either. But if you can run “gdisk” on that disk, there’s a good chance that it can fix the problem and rewrite a correct partition table.

#9

I have just read a thread about gparted. I will try and get back to you.

#10

IIRC there is a command in gdisk to recreate the alternative table at the end of the physical disk. Try it.

I have had a good result in rewriting the main table (from the alternative one) using gdisk (again IIRC).

#11

Gparted showed the GTP problem right up when launched and corrected it but system still keeps me from loggin in.

I have decided to reinstall everything from scratch since the time taking to find a solution seems be more than starting from zero.

Thank you for your help and support.

#12

I did not expect this to cure your login problem, it was mentioned by you as a side step and we showed the way how to cure that one.

#13

I know.

I like to solve problems since it’s a good way to learn but I have to get this server up and running by tomorrow and it’s very time consuming.

Thank you.

#14

I understand your first concern is now to get it up and running, but when this really is a system of some importance, I suggest strongly to upgrade to openSUSE 15.2 ASAP.

#15

Yeah, I’m going for openSuse Leap 15.2 :good:

#16

This is a carry over from https://forums.opensuse.org/showthread.php/564262-Cloning-OpenSUSE-only-dd-has-no-issues.

My idea is to use the original OSS 15.3 on 256GB SSD as a backup as I continue my business on the cloned OSS 15.3 on 2TB SSD.

These SSDs exhibited weird behavior - I would login into one SSD, but the PC acted as if I wanted to login to the other; I was able to login these SSDs a few times to observe their perspective of each other. 2TB is sbc, the other sbd.

After the latest update on both drives, I can’t login to either: At login, the 2TB complains of systemd problems. The 256GB complained that it was trying to start the 2TB sbc3. I disconnected the 2TB. Then I could login to the 256GB.

I did not try reconnecting 2TB / disconnecting 256GB yet. If OSS 15.3 clones are possible on the same system, then what is the best solution to have them operate independently? Thanks in advance.

#17

IMO you’re asking too much by extending an old thread you didn’t start and referring to another thread you didn’t start. You should start a new thread, giving us output of parted -l and blkid for every disk involved, output from efibootmgr -v, and /etc/fstab, /etc/default/grub and /boot/grub2/grub.cfg for every installation.

This sounds to me like results from cloning that was followed by incomplete and/or defective assignment of new UUIDs (and LABELs if you use them, which I recommend for all multiboot systems) to the involved filesystems; and openSUSE’s assignment of /boot/efi/EFI/opensuse to every installation not having been appropriately taken into account, and not adjusted for.

You may be able to make some headway on your own by adjusting every involved /etc/default/grub to include a unique value for GRUB_DISTRIBUTOR=, such as GRUB_DISTRIBUTOR=“s153-25g” for one and GRUB_DISTRIBUTOR=“suse153-1t” or GRUB_DISTRIBUTOR=“opensuse153a” for another. In UEFI multiboot, the space between “” for GRUB_DISTRIBUTOR= needs something unique that you will readily recognize on any visit to /boot/efi/EFI/. Naturally, once /etc/default/grub has been adjusted, /boot/grub2/grub.cfg needs to be regenerated either via grub2-mkconfig or YaST.

#18

As this is a 15.0 problem (which was already unsupported at the time it was started), it can’t be very productive to ask a 15.3 question here as @mrmazda explained already. This one will be closed.

The OP should start a new and fresh thread that will then be shown as a new and fresh thread.