Forgive me as I am new to OpenSUSE and ARM devices. I’m trying to get an older Pi v1 running a friend gave me with Tumbleweed for ARM. However, when I download and flash my SD card with the latest image found here:
The system gets stuck in a boot loop with the only error that “gfxterm not found”. I do see some patch notes about this issue, but the problem is that this Pi is the only linux system I have access to right now. I’m flashing the SD card from a windows laptop so that gives me limited options to troubleshoot/patch. I’ve tried to drop to the U-Boot> prompt and see what I can try but I’m completely unfamiliar with it and was in way over my head.
I’m hoping someone can help me with some step by step instructions to either fix the issue, or mount the SD card from the U-Boot menu so I can manually edit the grub boot-loader files to remove the the gfxterm reference and replace it with the suggested option in the patch notes and try that next.
Any/all help greatly appreciated as this is very frustrating, since it’s not working “out of the box” and I can’t even get the system to boot to a usable state.
Also tried several other flavours including JeOS from the same location.
Boot process starts OK (apart from the message “gfxterm not found”) and loads Grub with VMX and Failsafe as options. Whichever I choose, it seems to continue OK with
“loading linux.vmx…”
“loading initrd.vmx…”
then changes graphics mode showing the Raspi icon and almost immediately throws the the first error at about +2.8s:
“initramfs unpacking failed - write error” and
“can’t find udev” then
“waiting for devices to settle” repeated many times
This is rapidly followed by further errors and eventually a kernel panic
I think this image (and possibly the entire raspi-1 set here?) is not bootable - please can anyone point me at a recent opensuse raspi-1b image that is known to work? Any desktop (though I’d prefer XFCE)
Many thanks
Richard (MQ)
long time SuSE / opensuse user
I haven’t tried a new image for the original RPi for about a month now,
But previously I found that the main problem why an image doesn’t work is because it wasn’t burned to the sdcard following the instructions to use xzcat.
That said, an image <could> be faulty… I recommend anyone using ARM and having a problem with an image to sign up and use the openSUSE ARM mailing list, the maintainers are on that List. Because of how busy they may be, your answer might not get an immediate response, but in due time it will be answered…
Have you tried the images from the HCL page(Your first link) you posted?
AFAIK the elinks from the HCL page are “official” and fully supported, images from other locations like where you’re getting your images <may> work but aren’t necessarily as “official.”
I don’t know why any kind of “gfx” should be loaded in a JeOS.
If you’re burning from a Windows machine, I found that the Windows utility everyone uses won’t work for any openSUSE images.
I wrote an article how to burn successfully by deploying openSUSE in a VM (VMware in my article, but the principles can be applied to any virtualization technology)
You can install VMware Player (free), build an openSUSE Guest and then follow the steps exactly as described in my article to write a RPi image to an SDcard.
With reference to your other message this evening: SD card created from a Leap 42.1 box using both manual (xz extraction & dd_rescue) and the bash incantation suggested on the HCL page cited:
Maybe I should try the 13.2 version which is also offered on the HCL, but this seems rather old. Or a post to the ARM list which is indeed rather low traffic. It’s that or back to Raspian
Cheers
Richard (MQ)
long time SuSE / opensuse user
Looking at the images I’ve been using, I’ve been primarily installing TW JeOS, and a few LXQt images.
You might try those. Looks like I haven’t burned the Nov 2016 image though, I’ve been running Sept 2016 images (and then updating)
Probably I should install the Nov images myself, and I’m pretty sure I saw a recent message on the mail list that a new image may be ready soon.
boot starts as expected (though it DOES include the text “gfxterm not found”)
through to Grub then “loading linux.vmx…” followed by “loading initrd.vmx…”.
Then after a pause a graphics mode change and an image of Tux (rather than the Raspi logo)
At this point it freezes, nothing further happens even after > 30 mins.
exactly the same symptoms, except that after displaying Tux I get some text with the fatal error:
[2.7s] initramfs unpacking failed: write error
[4.1s] kernel panic - not syncing: unable to mount root fs…
I will post this on the ARM list and see whether anyone can help.
Thanks
Richard
I’ve been doing a little reading about how this error can occur, understanding the issue is not difficult but I don’t know if the User can resolve (requires accessing Grub2 which is embedded in the compressed RPi image so may not be accessible without manually extracting, then editing then writing. So, in other words replace xzcat).
So, to the point…
When you exit the GRUB menu and proceed booting (or, possibly exit to a GRUB terminal), there are a number of different terminal consoles to choose from… Legacy consoles include “console” and the serial console, plus a few others. Fedora and openSUSE default to gfxterminal which supports a “graphical terminal” which supports manual resolution settings (my guess supporting the capabilities of the default VESA driver instead of the older legacy VGA driver).
This suggests to me, and should be brought to the attention of the Maintainers (Andreas?)
gfxterminal is either missing or inaccessible, which might be understandable if the image is “slimmed down” (unnecessary or less necessary apps removed)
In the short run, it’s likely possible to do what I suggested opening this post, which is instead of using xzcat, extract the image (xz?), modify the GRUB entry to specify something like “console” instead of gfxterminal, then cat or dd the image to the sdcard. The actual procedure to re-build GRUB is in the Fedora documentation.
Hi
My understanding is the JeOS images are for serial only to install… I use the xfce one at present on a Pi3, but after boot it seems to go awol with both ssh keys and graphical login, so tweak to boot to multi-user on a separate system with sd card reader, boot to this and then fix the ssh keys…
I’m expecting a serial cable to arrive this week so can try a JeOS image.
No,
I’ve used JeOS images not just for RPi, they’re just that… “Just enough OS” which makes them ideal to build a custom solution by starting with as little as possible.
That means that they’re not really intended for serial communications only,
They’re essential for instance when building a Docker image, because you start off with something very basic and then add in your custom applications and configurations for whatever your specific use. You won’t be encumbered with a lot of “useful” but not essential tools and apps that have nothing to do with a well-running and problem-free single-purpose machine.
A JeOS for RPi would be for the same purpose… not necessarily for the first time User who wants a graphical Desktop experience to toy with what it would be like to use a tiny “computer” instead of a laptop of workstation…
A JeOS on a RPi would be for the serious “embedded” Developer who wants to build a “Dedicated Use” machine, like a Server or appliance… like firewall, WiFi AP, replacement for Alexa or whathaveyou.
So, if you run a JeOS image even today without a serial cable, you should get something like an ordinary openSUSE text-only “Server” with full networking and most video out capabilities but instead of about 800MBytes or larger, your base image should be about 100MBytes (today) or about 650MBytes (about a year ago, and maybe many current images still). Only thing smaller should be something like Busybox which is pretty much the default Linux solution for embedded devices(for everything from routers to firewalls to cable consoles and more), but the diff is that Busybox is not generally updateable (so vulnerabilities are permanent). A true distro like openSUSE is now close to the same size but a far more secure solution for embedded devices.
