Home Home > Tag > openSUSE@ARM
Sign up | Login

Posts Tagged ‘openSUSE@ARM’

inadyn and openSUSE Raspberry Pi

May 20th, 2015 by

We’ve seen how to install no-ip.
Fortunately, there’s not only this service but other services too. Just for reference, here are some (not only free):

http://www.dyndns.org
http://freedns.afraid.org
http://www.zoneedit.com
http://www.no-ip.com
http://www.easydns.com
http://www.tzo.com
http://www.3322.org
http://www.dnsomatic.com
http://www.tunnelbroker.net
http://dns.he.net/
http://www.dynsip.org
http://www.sitelutions.com
http://www.dnsexit.com
http://www.changeip.com
http://www.zerigo.com
http://www.dhis.org
https://nsupdate.info
http://duckdns.org
https://www.loopia.com
https://www.namecheap.com
https://domains.google.com
https://www.ovh.com
https://www.dtdns.com
http://giradns.com

Let’s see one of them https://freedns.afraid.org. After you register, go to Dynamic DNS link (on the left top box-for members).
Add your host with type A and subdomain and domain what you like as host.

Now there’s going to be a list of your host names. Right click on the Direct Link and copy the link. You should keep the alpha-numeric key. The address will be something like http://freedns.afraid.org/dynamic/update.php?[alpha-numeric-key]

Now it’s time to install the client. I’ve found it from https://github.com/troglobit/inadyn.

1. First of all, install the needed programs to build the service.

$ zypper in gcc-c++ gcc git libopenssl-devel make nano

2. Then

$ mkdir inadyn

$ cd inadyn

3. Download the program from ftp://troglobit.com/inadyn/

$ wget ftp://troglobit.com/inadyn/inadyn-1.99.9.tar.xz

and decompress it

$ tar xvfJ inadyn-1.99.9.tar.xz

4. Go to the directory

$ cd inadyn-1.99.9

5. Compile and install

$ make

$ make install

6. Create the confing file

$ nano /etc/inadyn.conf

with the following content

--username USERNAME
--password PASSWORD
--update_period 3600
--forced_update_period 14400
--alias HOSTNAME,alphanumeric key
--background
--dyndns_system default@freedns.afraid.org
--syslog

The bold words are the ones you should change. Remember the alphanumeric key is the one you got from right click on the Direct Link.

7. Start the client. Create the service file.

$ nano /usr/lib/systemd/system/inadyn.service

8. Add the following content.

[Unit]
Description=inadyn Dynamic DNS Update Client
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/sbin/inadyn

[Install]
WantedBy=multi-user.target

9. Start the service

$ systemctl start inadyn.service

and enable the service

$ systemctl enable inadyn.service

10. Reboot and check if the service is running.

$ ps -A | grep inadyn

you should get results something like:

1526 ? 00:00:00 inadyn

openSUSE 12.3 on Android

May 9th, 2013 by

Here is a new image for your armv7l powered phone or tablet(any recent dual core device should work), you can get openSUSE 12.3 XFCE running on it without the need for repartition, formats, bootloader hacks or sacrificing your nicely running latest android on it. What you need is rooted device with busybox, Android VNC and terminal app installed and 4GB free space on sdcard(internal or external).

Instructions to run it are same as mentioned earlier. In addition to those you can also use LinuxonAndroid app with patched bootscript.sh. Replace /data/data/com.zpwebsites.linuxonandroid/files/bootscript.sh on your device with the patched one and follow the directions shown here(last 3 images):

openSUSE on android

openSUSE ARM image

January 21st, 2012 by

When I wrote this week, how I ran openSUSE on my genesi smarttop some people asked for a ready-to-use image. After spending less than 8 hours fiddling with u-boot-scripts, partition tables, tuning ext3 and initrds, it was done… and is now so easy:

wget http://www.zq1.de/efika.img.xz # 83MB
xz -cd efika.img.xz | dd of=/dev/sdX bs=1M

with sdX being the device name of your SD-card (e.g. “mmcblk0” on the smarttop itself) with at least 1GB (actually 1024000000 bytes) of free space.

When inserted at boot, it should just boot up within 23 seconds and let you login as root with password “linux” on SSH, serial and with a USB-keyboard on HDMI. I spent some effort on putting as few packages as possible into it. Still, you have zypper to install packages and nano to edit files.

There is still a known hangup when you try to reboot. Workaround is: init 2 ; sleep 12 ; killall rsyslogd ; umount /boot/ ; mount -o remount,ro / ; reboot

As it still uses the original linux-2.6.31 kernel, it has another bug that also happens with pre-installed Ubuntu: sometimes (in ~40% of cases), boot stopps early, before graphics is initialized, when the last line on serial is “console handover: boot [ttymxc0] -> real [tty1]”. Try turning it off and on again.

This should allow you to have a whole lot of fun…

LXDE can do it! LXDE on Android smartphone!

August 24th, 2009 by

Yes i did it. I made LXDE running on my new Android smartphoe, the latest HTC masterpiece, the HTC HERO. Here some shots:

That’s great! But there is a main problem here, I’m not running openSUSE with X11:lxde packages, but debian with their stuff. I cannot use my geeko because the phone is an ARM and our openSUSE@ARM looks to still be in an early development stage. This post wants to be a ping to or openSUSE@ARM project and of course some marketing to this great and light Desktop Enviroment. For people interested in, here some hardware infos:

# cat /proc/cpuinfo
Processor       : ARMv6-compatible processor rev 2 (v6l)
BogoMIPS        : 526.25
Features        : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant     : 0x1
CPU part        : 0xb36
CPU revision    : 2
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 32768
I assoc         : 4
I line length   : 32
I sets          : 256
D size          : 32768
D assoc         : 4
D line length   : 32
D sets          : 256

Hardware        : hero
Revision        : 0080
Serial          : 0000000000000000

# busybox free
total         used         free       shared      buffers
Mem:       197016       191024         5992            0            8
Swap:            0            0            0
Total:       197016       191024         5992

openSUSE@ARM/GSoC: Cross-compilation & speedup

June 16th, 2009 by

This weeks topic was the integration of the cross-compilation mode into the build environment. But it’s more than just a cross-toolchain – it’s a speed-boost for our ARM build environment. As of today, the source is deployed in the repository Base:build:arm:cross. It’s not fully bootstrapped because of the current high load and the upcoming downtime – so watch out for changes there and in Base:build:arm.

But what are these “speedup’s” ? First, you’ve to know that in our build environment the ARM binaries are executed through an emulation-layer. This works on the cost of speed. The goal is now, to exchange some key parts in a transparent manner with native x86 binaries: no emulation, no slowdown. Sounds reasonable, but is it easily possible ?
I had to take care not to mix stuff too much because the environment would break. But now I’ve to say:  WOW, this worked incredibly well  😉 .

The distinctive feature of our approach in comparison to usual cross-build environments is that we use the best of native environment emulation and the speed of cross-compilation. Because of this combination we don’t have to patch the individual packages to make them cross-compilation ready. This is a new way of cross-compiling suitable also for large number of packages. A detailed overview about the different crossbuild types can be found on this page.
Another feature to note is that the exchanged binaries (replacing ARM with x86 in the build environment) also don’t need heavy patching and there’s no need to compile them as static binaries. All of them are normal distribution packages.

A switch in the project enables/disables the new features. With the new changes in place, the speed could be vastly increased. Some figures:
* package rpm
* package glibc w/o locales

Build time in minutes
x86 native armv5tel native armv5tel cross factor native factor cross
rpm 8 107 17 13,38 2,13
glibc 33 505 63 15,3 1,91

overview cross-environment

Thats a drop from about x15 to x2 in comparison to the native x86 build-time !! See it yourself when the “crosscompiled” repo in Base:build:arm is up and running.

In other words: “Warp 5, Mr. Sulu !” 😉