Hi,
I run into a problem with my RasPi Model B+ V1.2 with openSuse 13.2.
I type:
raspi:~ # cat /proc/cpuinfo
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
Features : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Hardware : BCM2835
Revision : 0000
Serial : 0000000000000000
From serveral other sources I heard that Hardware should be BCM2708,
Revision 0010 and there should be a valid serial number.
The same hardware with raspbian says:
Hardware : BCM2708
Revision : 0010
Serial : 00000000c2c2clcfbb
The problem is that many libs are looking into this information to
determine what type of raspi they are running on.
Furthermore serial not set properly means that raspi does not have a
stable MAC. Every time you boot it has another MAC.
Any suggestions how I can fix this?
--
Viele Grüße
Thomas Aichinger
----------------------------
http://www.datamagic.at
----------------------------
Data Magic Datenservice GmbH
Schönbrunner Straße 140
1120 Wien
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
I had a running image on my RPi 2B and saw kernel 4.0.1 being available. Using
zypper I updated the kernel, but after that the system was no longer bootable.
The newest image still has a 3.19 kernel.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Evening All
I require your assistance in the following two fields
Where can I find the hal package for armv7(Raspberry PI 2)? and do I
need to rebuild it for armv7?
How can I rebuild the openvpn package for armv7, to have a custom
compiled openvpn?
Greetings
Sean
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
when testing the image:
https://build.opensuse.org/package/binaries/home:frank_kunz:branches:openSU…
I got:
Internal error. Please report a bug report with logs.
Details: undefined method `ReadHardware' for #<Yast::LanItemsClass:0xf044b8>
Caller: /usr/share/YaST2/modules/LanItems.rb:988:in `ReadHw'
when I try to change the network settings in yast. Is that a new issue?
Any ideas?
Br,
Frank
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi everyone,
For one thing: I just bought a Raspberry Pi 2, and I was and am amazed
that I can use openSUSE on it, in the form of the JeOS Tumbleweed image
(and stuff I installed from the repos since). This is amazing and thanks
to everyone involved in getting this set up!
Now for the "fun":
As I wanted to get my usual system monitoring scripts running on that
system as well, I installed rrdtool.
Running it, it surprised me by a "undefined symbol
glDiscardFramebufferEXT" in libEGL.so.1 - and of course did not work.
In the end, as this is a headless system where I probably don't need
working graphics, I decided to be daring and try installing Mesa-libEGL1
instead of raspberrypi-gfx and that did get rrdtool working.
For one thing, I wanted to mention this in case anyone else stumbles
over the issue. For the other, is this a known issue with raspberrypi-gfx?
Cheers,
KaiRo
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
I tried to update a Tumbleweed system on a Raspberry Pi 1B system using
"zypper up". During downloading the kernel-default rpm the system crashes and
restarts.
I was able to update zypper and curl to the latest versions. However
retrieving kernel-default-4.0.1-1.1.armv6hl.rpm makes the system crash.
I was able to download the rpm using curl.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
a couple of updates went into Factory in the last few days that broke
ARM, mainly due to bootstrap loops that needed to be resolved
manually.
I've done that now, and things are rebuilding. Hopefully tomorrow
morning there should be a working tree again (unless something else
enters factory inbetween).
Greetings,
Dirk
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
I have managed to get oS 13.2 to boot on a cubieboard by doctoring the
installation image and transplanting the factory boot loader and kernel
into it. Steps are a bit complicated so I made a script[1]. Inputs are
the 13.2 and factory installation images, and script constants need
version adjustment.
When installing the modified image the system boots, reboots (not
something to take for granted...), and at least passes the sanity
checks. So far, so good.
Is the 13.2 kernel working on the cubieboard? I couldn't get that one to
go, it hangs at "starting kernel", even with a newer boot loader. The
13.2 boot loader is broken and needs a newer version, but that shouldn't
affect the kernel directly. Never mind.
I've updated https://en.opensuse.org/HCL:CubieBoard accordingly.
Volker
[1] http://volker.top.geek.nz/soft/script/cubieboard-oS13.2-transplant-boot
--
Volker Kuhlmann
http://volker.top.geek.nz/ Please do not CC list postings to me.
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
it seems recently qemu-linux-user 2.3.0 has been accepted to factory,
which however immediately crashes on startup, so all the builds in the
last two days (if I see correctly) have been hanging in an endless
crash/rebuild loop.
I've manually injected a qemu 2.2.0 build again and locked 2.3.0 out
to get things moving.
Greetings,
Dirk
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
it seems that the sunxi device trees are not rebuild ans still have
kernel 3.19 data included instead of version 4. This prevents (at least)
the sun4i based boards from booting due to changes in the mmc drivers
and device trees. It look that there is a build dependency missing when
the kernel is updated.
-Frank
linux:~ # zypper info dtb-sun4i
Loading repository data...
Reading installed packages...
Information for package dtb-sun4i:
----------------------------------
Repository: openSUSE-Factory-repo-oss
Name: dtb-sun4i
Version: 3.19.0-40.1
Arch: armv7hl
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 192.1 KiB
Summary: Allwinner sun4i based systems
Description:
Device Tree Files for Allwinner sun4i based systems.
linux:~ # cat /etc/os-release
NAME=openSUSE
VERSION="20150428 (Tumbleweed)"
VERSION_ID="20150428"
PRETTY_NAME="openSUSE 20150428 (Tumbleweed) (armv7hl)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:20150428"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"
linux:~ #
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org