Raspberry Pi boot stops at grub

I have a Raspberry Pi 3+; Raspberry Pi debian OS works fine where the process loads an .iso over an existing FAT partition. Boots and runs good.

On the same RPi but different sd card I have tried to install a version of openSUSE from the collection of ARM offerings including Tumbleweed and Leap 15.3, using various window managers and they all seem to fail when the boot stops at a grub menu. The failed process often results in the host system not able to recognize the card any more as a storage device; this can be fixed by inserting the card into an Android tablet and formatting back to FAT.

Examining the xzcat … | dd … install process carefully I see that it stops about halfway to two thirds (4GB of 6 completed) with a disk write error. So not all the system is copied over, presumably the part that grub needs to see.

The sd card is new from reliable source, Kingston brand. I have run diskscan on it and it finds that the media is good. There do seem to be some weak spots but I am not sure how to interpret the output except that some sectors are slower returning their contents than others.

  20 |                                                                       
   15 |                                                                       
      |                                         ^                             
   10 |                                                                       
      |                          ^               ^                            
      |                                                        ^              
      |          ^              ^ ^                             ^             
      |                     ^                                                 
    5 | ^^^^^^^^^ ^^^^^^^^^^ ^^^   ^^^^^^^^^^^^^  ^^^^^^^^^^^^^  ^^^^^^^^^^^^^
      | **********************************************************************
      |                                   _                                   
      | __________________________________ ___________________________________

Conclusion: passed

I wonder if there is some way to break up the installation process to reveal any more information as to why the process is not completing in the install step?

Sounds like a failed download, did you check the sha256sums of your downloads?

Thanks for the suggestion, sha256 check is good.

I managed to fully reload the sd card with a Leap 15.3 LXQT, sha check is good, but the boot on Rpi again stops at grub.

Screen shows:

GNU GRUB version 2.04

Minimal BASH-like line editing is supported ... file completions.


I will try to get more info on what to enter here that might be on the card but not visible to the boot setup. My feeling is it is looking for an image to boot from but cannot see it.

And you are grabbing the right images for the RPi3? I use the following;

xzcat openSUSE-Leap-15.3.......tar.xz | dd bs=4M of=/dev/sdb iflag=fullblock oflag=direct

Yes I am pretty sure I have the right images.

Further info: If I try to mount the card on a separate openSUSE system as an external drive via USB I can view the contents of the partition EFI but trying to view the ROOT partition gives me the error:

Unable to access "ROOT"
Error mounting /dev/sdc3 at /run/media/.../ROOT: wrong fs type, bad option, 
bad superblock on /dev/sdc3, missing codepage or helper program or other error.

I don’t know if this is normal for this situation or not.

I ran fsck on /dev/sdc3 and it found a number of errors. I allowed it to fix the errors and transferred back to the RPi.
RPi went past grub this time and tried to do a file check on a partition for 1 min 30 sec and then timed out and dropped me into emergency mode. It gave me a few options, continue, reboot, etc so I allowed it to continue but it just repeated the message. I entered the root password and this gave me a root prompt. Then startx and I am now into a graphical mode. I don’t think I should really be here as root, so I have evidently missed a routine which would set me up with a regular user. I can start a console from the menu but other things like network configuration are not working, as in no response.

So did you run the command sync a couple of times before removing the sd card? I suspect it may have still been writing, even though your command had finished and showed the command line prompt.

Sync was indeed part of the

xzcat ... | dd ... sync

process I entered as per the instructions on the web page for RPi3. However I was not aware that multiple commands were needed. Then I was absolutely sure to unmount the card before removing from the host system. Linux told me that the adapter was clear to remove. If it had been busy I think it would have delayed the message until done or given the appropriate warning.

I’ll go back and try to write it again. The fact that this is giving so much trouble I think might be because the card is borderline bad. Sufficiently good to pass tests but if the tests are loose then stuff can get through that should not make it to the retail store.

Or switch to USB instead?

I decided to switch to a different sd card. I was able to write the XFCE Leap 15.3 system to the card and verified with the disks application that the partitions passed the check test. It took two tries to get it on properly but is in place on this new card. The system now boots in the RPi and gives me a graphic login screen. So to this extent the reported issue may be resolved in that the first card may be doubtful. Sorry to drag you through this but thanks anyway.

However there is now a different issue, which may have been reported elsewhere, I will have to check. The new issue is that the only account that exists on the new install is the root account. So I try to log in with root and it presents me with a blank white screen which does not go away. Being able to log in at the terminal is important since this is the main planned access in the final use. I am able to get into the pi via ssh and can start yast and create a regular user, but even using the new regular user the graphic login generates a white screen. I will do a search to see if this has been seen before.