Hi!
I wanted to clone my SD-card with Tumbleweed ARM installation for raspi 2, tried 2 times, but the cloned card won’t boot, after “Loading kernel” message the screen turns black and never comes back (waited for up to half an hour…).
No access via VNC or SSH either (“no route to host”), so apparently no boot (green light at raspi flashes only 2-3 times after “Loading kernel” message).
Any help? Try dd instead?
You need to describe what you mean by and the method you used to clone the Rpi image, where you got the image and whether the image has been verified working.
TSU
Hi again!
Got the Tumbleweed from here and followed the instructions to dd the image file to an SD-card:
https://en.opensuse.org/HCL:Raspberry_Pi2#Manual_installation_of_upstream_openSUSE_Tumbleweed
Worked! I did some hours of installation, updates, configuration etc. Worked!
To save my work and to be able to use the image with more raspis I extracted the image with Win32diskimager (as usual with Raspian images) and subsequently burned this image to a fresh SD-card. No boot after “Starting kernel”, tried to burn image again, same error.
More info needed? 
…in the meantime I tried to get an image with dd
dd bs=4M if=/dev/sdd of=Desktop/raspisuse090916.img
and burned it to the SD-card via
dd bs=4M of=/dev/sdd if=Desktop/raspisuse090916.img
…same result, after “Starting kernel” only 2-3 blinks of the green LED on the raspi, afterward the screen is black, no VNC, no SSH, nothing.
I know for sure that the serial console worked fine on the initial Tumbleweed
openSUSE-Tumbleweed-ARM-LXQT-raspberrypi2.armv7l-2016.08.20-Build2.2.raw.xz
installed yesterday, but after the updates Tumbleweed performed after installation, I see useful output only until
“Starting kernel”
afterwards there is only trash shown in the serial console (115200)…
This is the output from the serial console before there is boot stops
U-Boot 2016.07 (Sep 02 2016 - 23:25:44 +0000)
DRAM: 880 MiB
RPI 2 Model B (0xa01041)
MMC: bcm2835_sdhci: 0
reading uboot.env
** Unable to read "uboot.env" from mmc0:1 **
Using default environment
In: serial
Out: lcd
Err: lcd
Net: Net Initialization Skipped
No ethernet found.
starting USB...
USB0: Core Release: 2.80a
scanning bus 0 for devices... 3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 1 Ethernet Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Scanning mmc 0:2...
Found U-Boot script /boot.scr
2781 bytes read in 39 ms (69.3 KiB/s)
## Executing script at 02000000
switch to partitions #0, OK
mmc0 is current device
5352616 bytes read in 917 ms (5.6 MiB/s)
7042728 bytes read in 1072 ms (6.3 MiB/s)
14226 bytes read in 110 ms (126 KiB/s)
Kernel image @ 0x1000000 0x000000 - 0x51aca8 ]
## Flattened Device Tree blob at 00000100
Booting using the fdt blob at 0x000100
Using Device Tree in place at 00000100, end 00006891
Starting kernel ...
PS: Looks ABSOLUTELY identical when booting successfully from the initial SD-card
U-Boot 2016.07 (Sep 02 2016 - 23:25:44 +0000)
DRAM: 880 MiB
RPI 2 Model B (0xa01041)
MMC: bcm2835_sdhci: 0
reading uboot.env
** Unable to read "uboot.env" from mmc0:1 **
Using default environment
In: serial
Out: lcd
Err: lcd
Net: Net Initialization Skipped
No ethernet found.
starting USB...
USB0: Core Release: 2.80a
scanning bus 0 for devices... 3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 1 Ethernet Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Scanning mmc 0:2...
Found U-Boot script /boot.scr
2781 bytes read in 42 ms (64.5 KiB/s)
## Executing script at 02000000
switch to partitions #0, OK
mmc0 is current device
5352616 bytes read in 942 ms (5.4 MiB/s)
7042728 bytes read in 1092 ms (6.2 MiB/s)
14226 bytes read in 119 ms (116.2 KiB/s)
Kernel image @ 0x1000000 0x000000 - 0x51aca8 ]
## Flattened Device Tree blob at 00000100
Booting using the fdt blob at 0x000100
Using Device Tree in place at 00000100, end 00006891
Starting kernel ...
Without digging deeply into what you posted,
In general, “best practice” is to us a “golden image” and/or modify <that> image for installs rather than to image/clone from a working system.
To do this locally on your machine, Kiwi is in your OSS.
When you clone from a live system, your target machine hardware has to be <very> identical for the image to work, else new hardware recognition and component installation has to occur… Which <may> still work if the new components aren’t critical to how the system boots up.
In fact, I would even use your original image as a test verifying the image in general should be able to install and run.
If that works, then I would also then consider upgrading your original image to your desired end by scripting the install and any custom configurations.
TSU
Point is: I booted the cloned image on exactly the same raspi the original image was working on! To me the only option is that somewhere in the system the ID of the SD-card is incorporated and the new SD-cards ID does therefore not “fit” the image. Very Microsoft-style… Have no idea how to clone the image, maybe I try another Windows-tool, but I don’t think this well buy me much…
Maybe secure boot is enabled in your image?
Or at least enabled somehow after the base image?
TSU
Many thanks for trying to help!
I think I’m on the right way with my SD-card ID, as I found in fstab of the working copy and the non-functional copy:
/dev/disk/by-id/mmc-USDU1_0x2005889c-part3 / ext4 noatime,nobarrier 1 1
/dev/disk/by-id/mmc-USDU1_0x2005889c-part2 /boot ext3 defaults 1 2
/dev/disk/by-id/mmc-USDU1_0x2005889c-part1 /boot/efi vfat defaults 0 0
/dev/disk/by-id/mmc-USDU1_0x2005889c-part4 swap swap defaults 0 0
While in a fresh install on another SD-card I get:
/dev/disk/by-id/mmc-SL08G_0x034ba914-part3 / ext4 noatime,nobarrier 1 1
/dev/disk/by-id/mmc-SL08G_0x034ba914-part2 /boot ext3 defaults 1 2
/dev/disk/by-id/mmc-SL08G_0x034ba914-part1 /boot/efi vfat defaults 0 0
/dev/disk/by-id/mmc-SL08G_0x034ba914-part4 swap swap defaults 0 0
So my question would be: How to obtain this unique SD-card identified following “mmc-” in these examples of fstab?
If I change this to the correct identifier, I think the mount/boot process could work!
Maybe mount by labels. Note they must be unique in the system
…I found the necessary info for the SDcard via this link:
http://www.cameramemoryspeed.com/sd-memory-card-faq/reading-sd-card-cid-serial-psn-internal-numbers/
I got the MMC-name in UEVENT as well as the serial no. from file SERIAL and changed the info in fstab. But no boot. 
Apparently there are some checksums or related stuff preventing manipulation of the filesystem, I guess.
No idea where to look now.
Btw: I installed the ARM opensuse dated 20-AUG-2016:
openSUSE-Tumbleweed-ARM-LXQT-raspberrypi2.armv7l-2016.08.20-Build2.2.raw.xz
in this version the serial console output of the raspi is doing fine, however, after performing the updates to the latest Tumbleweed, after “Starting kernel” there is only nonsense in the serial output.
Does anybody know where to report this bug?
Reading the info about the CID in your reference, it’s not relevant to your problem… It’s simply the media ID so that your machine can recognize the removable media when you remove it and later re-insert. The same thing more or less exists on hard drives, and in fact is also the bane of disks that have been inserted into a MSWindows system (a drive id number is written to the disk, potentially altering the drive contents and makes the disk’s forensic integrity questionable).
As I last posted, did you check whether you have <secure boot> somehow enabled? If it is, it can prevent you from cloning unless the cloning process understands and can handle this.
As I also posted,
An easy way to avoid these cloning issues is to simply script your custom install and configuration settings… It’s not difficult and although takes a bit longer to create new instances, are generally more immune to things like hardware differences and will always result in all latest packages installed (cloning won’t) which means you can skip the highly recommended step of updating a new clone immediately.
TSU
Just one more additional,
Particularly because this is Tumbleweed,
There is even less of a reason to install and migrate the original bytes of an old image, I doubt you’d even experience any gain in time saved, needing to address problems during the almost certain instance update/upgrade and whatever stability/reliability you might expect.
In my mind, the only reasonable approach would be the “Install latest image and modify by script” approach I described.
IMO,
TSU
Hi again! Would love to learn more about this ARM opensuse, but apparently there is only a mailinglist (for pro’s) and nothing more, even the documentation available on the page linked above is outdated (e.g. in TW ARM there IS a firewall incorporated etc pp.). You simply dd the TW ARM image to an SDcard and on first boot there is actually a script re-partitioning the card and installing the software, so I have no idea if UEFI is enabled for boot… 
Would really love to learn something on this from the source, but apparently no documentation. Thought about contacting Dirk Müller (@suse), but I think there is by-design no way to simply copy SDcards for opensuse ARm. Would be a hack, I guess… 
PS: Did I get this right: This KIWI program is the right way to export system settings and transfer to fresh install?
If you prefer an online service, there is SUSE Studio.
If you prefer to do all your work on your local machine, there is Kiwi.
Kiwi enables you to build openSUSE images targeting any platform (even not the same as the current machine) so for instance you can build and modify ARM images on your x64 machine. Of course, to actually test the image you’ll need real hardware or run in an emulator (QEMU virtualization is an option).
This is consistent with the idea of building a “golden image,” ie a universal image that can be installed into devices with your customizations instead of cloning an end result.
It’s not too much different than the scripted install I strongly encourage except the effort required to maintain an image and deployment.
TSU