openSUSE ARM January 2019

arm@lists.opensuse.org

15 participants
12 discussions

[opensuse-arm] cubox-i / leap 42.3: problems with automatic module loading after upgrade
by Miklos Vajna 13 Apr '19

13 Apr '19

Hi, Just asking if this is only me or it's a wider problem: I recently updated my cubox-i with zypper, pulling in kernel-default-4.4.114, and after reboot the box boots, but several drivers are missing, so there is no wired ethernet, no mmcblk, etc. After booting and waiting for a while, dmesg starts to complain about driver detection did not finish in time (sadly I don't have the backtrace at hand, it already went out of the buffer of the serial console). For now I worked around the problem this way: - download the repo-oss (ie. non-update) kernel-default-4.4.76 rpm on an other machine, copied it to an usb stick - install the old kernel-default from the usb stick - copy the /boot from the root fs to the usb stick - use the other machine to update the /boot on the mmcblk device where u-boot reads it So is this only me or do other cubox-i users see the same? Thanks, Miklos

2 3

[opensuse-arm] Continuously rebuilt and tested Leap 15.1 images
by Fabian Vogt 18 Feb '19

18 Feb '19

Hi, For Leap 15.x on x86_64, images (Live media, JeOS and the base container) are continuously rebuilt, tested and published in openSUSE:Leap:15.x. It's also the location the official opensuse/leap base image is released from (into openSUSE:Containers:Leap:15.1). Currently there is a similar project for :ARM at openSUSE:Leap:15.1:ARM:Live, but it does not support building/releasing after the main project is finalized and is also not coupled to openQA AFAICT. As I'd like to have the base container setup the same for all archs (continuous testing and updates is a requirement) it would be very useful to use the same setup as x86_64 Leap. What's missing is a subproject :ToTest with similiar config to openSUSE:Leap:15.1:Images:ToTest and some mostly trivial changes to the totest-manager configuration. It might also require some mapping changes inside OBS so that the released images end up in the right location on download.opensuse.org. Once that's done, some openQA tests for the JeOS-EFI flavor could be added and that would then also run the docker_ and podman_image tests. What do you think? Thanks, Fabian -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 13

[opensuse-arm] nanopi neo air - updated u-boot to the most recent from friendlyarm
by Per Jessen 29 Jan '19

29 Jan '19

The latest u-boot from friendlyarm still doesn't appear to support efi boot - the openSUSE TW Jeos does not boot. Personally I'm happy with using the leap15 applicance for nanopi neo (without air), and updating the dtb and the firmware so I can get wifi. Should I update our wiki and make people aware the current setup won't actually work, as described? FriendlyARM provides their "eflasher" utility, which is just a custom Ubuntu system with a script/binary for flashing the eMMC. I just don't see where I would put my own (newer) u-boot in. -- Per Jessen, Zürich (-0.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] Web browser falkon seems to seek libraries in wrong directory
by Jogchum Reitsma 29 Jan '19

29 Jan '19

Hi, I installed Leap 15.0 on a Raspberry PI, with the intent to make it a nextcloud server. I encounter a few difficulties, and I would like to report them here in different posts. It might well be that for some or all of these difficulties, this list is not the appropriate one. In that case, please let me know, and my apologies. Installing Leap itself (the X-version), apache2, mariadb and nextcloud itself went without problem. After creating a database and user for nextcloud one has to open http://localhost/nexcloud in a browser. Since the default X-install contains no browser (there is a "Web browser" icon on the taskbar, but no application connected to it) I had to install one. I decided to use falkon, mainly because it is small (5.8 MB, vs 148MB for Firefox). But when starting falkon, it terminates complaining that /usr/bin/libGLESv2.so is not found. Just to see what would happen I copied the GLES lib from /usr/lib64 to /usr/bin; now falkon complained about /usr/bin/libEGL.so not being found... Those libs reside in /usr/lib64, not in /usr/bin. Is this an upstream problem, or caused by packaging? Jogchum Reitsma -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 3

[opensuse-arm] Re: [opensuse-project] Raspi3 boot imes
by Matthias Brugger 28 Jan '19

28 Jan '19

Hi Tobias, Thanks for looking into that. adding opensuse-arm mailinglist, that's where further discussion should take place. Comments below. On 25/01/2019 20:54, admins wrote: > > On 25.01.19 19:59, Bruno Friedmann wrote: >> On jeudi, 24 janvier 2019 11.53:34 h CET Axel Braun wrote: >>>> Gesendet: Donnerstag, 24. Januar 2019 um 08:53 Uhr >>>> Von: "Matthias Brugger" <mbrugger(a)suse.com> >>>> An: "Basil Chupin" <blchupin(a)iinet.net.au>, opensuse-project >>>> <opensuse-project(a)opensuse.org> Cc: "nicolas saenz julienne" >>>> <nicolassaenzj(a)gmail.com> >>>> Betreff: Re: [opensuse-project] No info. re Leap 15.1 in Wikipedia >>>> >>>> I think we read about people complaining on the performance of openSUSE >>>> this week already. I haven't done any measurements but heard that on >>>> Raspberry Pi 3, Debian is significantly faster in booting then openSUSE. >>> Raspi are heavily depending on the kind of 'hard disk' you are using, >>> whether it is a SD card (connected via USB2) or an internal SSD Here is the >>> result of a Raspi using a Leap 15 LXQT image: >>> >>> /home/test # systemd-analyze blame >>> 1min 30.071s display-manager.service >>> 1min 18.481s backup-rpmdb.service >>> 14.815s ca-certificates.service >>> 13.788s postfix.service >>> 12.885s btrfsmaintenance-refresh.service >>> 11.001s apparmor.service >>> 10.121s logrotate.service >>> 9.277s backup-sysconfig.service >>> 7.925s ModemManager.service >>> 7.755s lvm2-monitor.service >>> 5.889s NetworkManager.service >>> 5.086s postgresql.service >>> 4.790s initrd-switch-root.service >>> 3.074s systemd-journal-flush.service >>> 2.868s nscd.service >>> 2.721s kbdsettings.service >>> 2.672s sshd.service >>> 2.316s ntpd.service >>> 2.191s avahi-daemon.service >>> 2.153s systemd-udevd.service >>> 1.967s polkit.service >>> 1.959s user(a)1000.service >>> 1.299s systemd-tmpfiles-setup-dev.service >>> 1.171s systemd-remount-fs.service >>> 1.095s sys-kernel-debug.mount >>> 943ms systemd-logind.service >>> 920ms upower.service >>> 803ms wpa_supplicant.service >>> 789ms dev-mqueue.mount >>> 736ms dev-hugepages.mount >>> 715ms boot-efi.mount >>> 598ms udisks2.service >>> 493ms systemd-journald.service >>> 482ms initrd-parse-etc.service >>> 440ms systemd-udev-trigger.service >>> 436ms systemd-modules-load.service >>> 435ms auditd.service >>> 403ms dracut-cmdline.service >>> 348ms systemd-random-seed.service >>> 251ms initrd-cleanup.service >>> 250ms systemd-tmpfiles-setup.service >>> 247ms systemd-sysctl.service >>> 210ms systemd-update-utmp-runlevel.service >>> 207ms >>> dev-disk-by\x2duuid-d90960ec\x2df373\x2d472d\x2d8b3f\x2d27a48d232d7a.swap >>> 193ms systemd-fsck-root.service >>> 184ms plymouth-switch-root.service >>> 170ms sysroot.mount >>> 166ms sys-fs-fuse-connections.mount >>> 159ms systemd-user-sessions.service >>> 151ms kmod-static-nodes.service >>> 112ms systemd-rfkill.service >>> 98ms plymouth-quit.service >>> 97ms plymouth-read-write.service >>> 85ms systemd-vconsole-setup.service >>> 76ms rtkit-daemon.service >>> 60ms dracut-shutdown.service >>> 51ms check-battery.service >>> 51ms systemd-update-utmp.service >>> 21ms initrd-udevadm-cleanup-db.service >>> 18ms sys-kernel-config.mount >>> 16ms plymouth-quit-wait.service >>> >>> Quite strange, btrfsmaintenance and lvm2-monitor enabled, although both are >>> not used. Clearly most time is burned on display-manager and backup of the >>> rpm-db (could this not be moved to a systemd-timer triggered event at a >>> later point in time?) >>> >>> Cheers >>> Axel >> Most of the service you see there aren't they systemd timers that run because >> it was not running during their normal schedule. >> Did you try to reboot half an hour after this boot how it behaves ? >> >> Ahrrr tests :-) >> > > I can confirm that the openSUSE boot times on a Raspi 3 are horrendous for > several reasons. I tested and tweaked the unstable tumbleweed images, so take it > with precaution, Leap might behave different: > > * It takes quite some time until even grub2 is loaded (u-boot uefi chainload), > but it brings a full grub2 with options to load different kernels or even > distributions. (So for me this is worth the wait) > With which u-boot did you test? I think there were some changes to the distroboot scripts which might add more device probing before we actually find and run the grub binary. > * It takes quite along time until the handover (uboot, uefi -> kernel) is done: > > + u-boot slow at reading the actual files (kernel+initrd) > You mean reading the grub binary. Grub is in charge to load kernel+initrd. > + a not compressed kernel image (~24MB uncompressed vs ~8MB compressed) > > + a initrd which ships (even after first installation and "mkinitrd") several > kiwi components > Which components do you refer to? > * Always triggered backup-*.timer(s) and mandb-timer > > > So to cut boot times idid several things: > > * remove all kiwi packages -> smaller initrd file > > * disable the above mentioned triggers -> this might not be applicable on a > intended stable system > > * create and use a kernel with a compressed instead of an uncompressed kernel > image [1]. > I'm not sure if we should add this to the kernel build infrastructure, as it is a RPi3 thing. Thoughts? > > With all this done boot times on my raspi 3 from a slow SD card were cut by > around a half (to multi-user console login screen). > > > [1]: https://build.opensuse.org/package/show/home:tobijk:kernel/kernel-default > > > Greetings, > > Tobias > > > > > -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 2

[opensuse-arm] Latest Tumbleweed for Raspberry Pi 2 fails to boot
by Freek de Kruijf 28 Jan '19

28 Jan '19

First I upgraded Tumbleweed on my RPi2, which gave me an system that does not boot anymore. After that I installed openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2019.01.08- Snapshot20190121.raw.xz on that system, which gives more or less the same problem. See the first few lines below. The output on the console is: [ 0.356882] Initramfs unpacking failed: junk in compressed archive [ 0.487556] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 0.495835] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-1-lpae #1 openSUSE Tumbleweed (unreleased) [ 0.505224] Hardware name: BCM2835 [ 0.508660] [<c04469a0>] (unwind_backtrace) from [<c043f270>] (show_stack+0x1c/0x28) [ 0.516411] [<c043f270>] (show_stack) from [<c0dfdad4>] (dump_stack+0xac/ 0xd8) [ 0.523641] [<c0dfdad4>] (dump_stack) from [<c0482508>] (panic+0x108/0x29c) [ 0.530612] [<c0482508>] (panic) from [<c1601790>] (mount_block_root+0x260/0x30c) [ 0.538099] [<c1601790>] (mount_block_root) from [<c1601a24>] (prepare_namespace+0x158/0x1a0) [ 0.546628] [<c1601a24>] (prepare_namespace) from [<c1601328>] (kernel_init_freeable+0x3f8/0x410) [ 0.555506] [<c1601328>] (kernel_init_freeable) from [<c0e15e30>] (kernel_init+0x10/0x11c) [ 0.563775] [<c0e15e30>] (kernel_init) from [<c04011cc>] (ret_from_fork+0x14/0x28) [ 0.571343] Exception stack(0xef12bfb0 to 0xef12bff8) [ 0.576394] bfa0: 00000000 00000000 00000000 00000000 [ 0.584573] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 0.592750] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 0.599378] CPU2: stopping [ 0.602091] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.20.0-1-lpae #1 openSUSE Tumbleweed (unreleased) [ 0.611479] Hardware name: BCM2835 [ 0.614890] [<c04469a0>] (unwind_backtrace) from [<c043f270>] (show_stack+0x1c/0x28) [ 0.622637] [<c043f270>] (show_stack) from [<c0dfdad4>] (dump_stack+0xac/ 0xd8) [ 0.629863] [<c0dfdad4>] (dump_stack) from [<c04433dc>] (handle_IPI+0x3f4/0x41c) [ 0.637261] [<c04433dc>] (handle_IPI) from [<c040217c>] (__irq_svc+0x5c/ 0x94) [ 0.644394] Exception stack(0xef145f60 to 0xef145fa8) [ 0.649446] 5f60: 00000000 00000000 2dff7000 40000093 ffffe000 c1805dd4 c1805e1c 00000004 [ 0.657625] 5f80: 00000000 c171d558 c18f982f 00000000 c1963ab8 ef145fb0 c043b948 c043b94c [ 0.665800] 5fa0: 40000013 ffffffff [ 0.669293] [<c040217c>] (__irq_svc) from [<c043b94c>] (arch_cpu_idle+0x30/0x64) [ 0.676694] [<c043b94c>] (arch_cpu_idle) from [<c04b9074>] (do_idle+0x1fc/ 0x2a4) [ 0.684095] [<c04b9074>] (do_idle) from [<c04b9400>] (cpu_startup_entry+0x24/0x2c) [ 0.691670] [<c04b9400>] (cpu_startup_entry) from [<0040326c>] (0x40326c) [ 0.698461] CPU3: stopping [ 0.701173] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.20.0-1-lpae #1 openSUSE Tumbleweed (unreleased) [ 0.710561] Hardware name: BCM2835 [ 0.713970] [<c04469a0>] (unwind_backtrace) from [<c043f270>] (show_stack+0x1c/0x28) [ 0.721718] [<c043f270>] (show_stack) from [<c0dfdad4>] (dump_stack+0xac/ 0xd8) [ 0.728943] [<c0dfdad4>] (dump_stack) from [<c04433dc>] (handle_IPI+0x3f4/0x41c) [ 0.736342] [<c04433dc>] (handle_IPI) from [<c040217c>] (__irq_svc+0x5c/ 0x94) [ 0.743474] Exception stack(0xef147f60 to 0xef147fa8) [ 0.748527] 7f60: 00000000 00000000 2e009000 40000093 ffffe000 c1805dd4 c1805e1c 00000008 [ 0.756706] 7f80: 00000000 c171d558 c18f982f 00000000 c1963ab8 ef147fb0 c043b948 c043b94c [ 0.764880] 7fa0: 40000013 ffffffff [ 0.768373] [<c040217c>] (__irq_svc) from [<c043b94c>] (arch_cpu_idle+0x30/0x64) [ 0.775772] [<c043b94c>] (arch_cpu_idle) from [<c04b9074>] (do_idle+0x1fc/ 0x2a4) [ 0.783172] [<c04b9074>] (do_idle) from [<c04b9400>] (cpu_startup_entry+0x24/0x2c) [ 0.790744] [<c04b9400>] (cpu_startup_entry) from [<0040326c>] (0x40326c) [ 0.797532] CPU1: stopping [ 0.800243] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.20.0-1-lpae #1 openSUSE Tumbleweed (unreleased) [ 0.809632] Hardware name: BCM2835 [ 0.813042] [<c04469a0>] (unwind_backtrace) from [<c043f270>] (show_stack+0x1c/0x28) [ 0.820790] [<c043f270>] (show_stack) from [<c0dfdad4>] (dump_stack+0xac/ 0xd8) [ 0.828015] [<c0dfdad4>] (dump_stack) from [<c04433dc>] (handle_IPI+0x3f4/0x41c) [ 0.835414] [<c04433dc>] (handle_IPI) from [<c040217c>] (__irq_svc+0x5c/ 0x94) [ 0.842546] Exception stack(0xef143f60 to 0xef143fa8) [ 0.847599] 3f60: 00000000 00000000 2dfe5000 40000093 ffffe000 c1805dd4 c1805e1c 00000002 [ 0.855778] 3f80: 00000000 c171d558 c18f982f 00000000 c1963ab8 ef143fb0 c043b948 c043b94c [ 0.863952] 3fa0: 40000013 ffffffff [ 0.867446] [<c040217c>] (__irq_svc) from [<c043b94c>] (arch_cpu_idle+0x30/0x64) [ 0.874845] [<c043b94c>] (arch_cpu_idle) from [<c04b9074>] (do_idle+0x1fc/ 0x2a4) [ 0.882244] [<c04b9074>] (do_idle) from [<c04b9400>] (cpu_startup_entry+0x24/0x2c) [ 0.889816] [<c04b9400>] (cpu_startup_entry) from [<0040326c>] (0x40326c) [ 0.896622] Rebooting in 90 seconds.. [ 91.909884] Reboot failed -- System halted -- 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

2 3

[opensuse-arm] nanopi neo - blue led ?
by Per Jessen 28 Jan '19

28 Jan '19

I was hoping to make the blue led flash in "heartbeat" mode. With the on-flash Ubuntu 15.10, kernel 3.4.39, the interface looks like this: # cat /sys/class/leds/blue_led/trigger none mmc0 mmc1 mmc2 timer [heartbeat] backlight gpio default-on rfkill0 rfkill1 rfkill2 With Leap15 kernel 4.12.14: # cat /sys/class/leds/nanopi:blue:status/trigger [none] kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usb-gadget usb-host disk-activity ide-disk mtd nand-disk cpu cpu0 cpu1 cpu2 cpu3 panic mmc0 mmc1 rfkill-any rfkill0 The interface name change is due to an updated dtb, but where do the changed options come from? Specifically, what happened to the 'heartbeat' option? It looks it can be emulated by the timer trigger, and the /sys/class/leds/<device>/delay_{on,off} values, but neither seems to be available on the nanopi neo air? (hardly a critical issue, I'm just curious). -- Per Jessen, Zürich (2.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 2

[opensuse-arm] trying out Jeos for nanopi neo air
by Per Jessen 27 Jan '19

27 Jan '19

I've just booted a nanopi neo air with http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Nan… and I am greeted with: Ubuntu 15.10 FriendlyARM ttyS0 FriendlyARM login: ??? The default login as per https://en.opensuse.org/HCL:NanoPi_Neo_Air doesn't work either. -- Per Jessen, Zürich (3.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 5

[opensuse-arm] Olimex Teres-I boots openSUSE
by Torsten Duwe 14 Jan '19

14 Jan '19

Hi all! just to let you know I got all the neccessary pieces together now to boot an unmodified kernel with a sort-of mainline U-Boot with some hacks on the open source hardware laptop Teres-I https://www.olimex.com/Products/DIY-Laptop https://linux-sunxi.org/Olimex_Teres-A64 My first goal was to use the same device tree for U-Boot and kernel, and getting the hardware I²C to work was the biggest task. It allows the use of i2c0 to enable the built-in LCD in the boot loader. As a weird side effect, this mysteriously breaks the WiFi; any pointers welcome! With the LCD working, U-Boot provides an EFI frame buffer to the kernel, and the kernel messages appear until user land is started. This is all work in progress and I need to find out how the hacks could fit into the upstream trees cleanly, but I thought you might be interested in the progress already made. You can have a look at the current status in OBS:/home:duwe:branches:hardware:boot:staging Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] VPP
by Alexander Graf 13 Jan '19

13 Jan '19

Hi Guillaume, To your question on IRC: > [14:37:37] <guillaume_g> dirk: is there a mean to be scheduled only on one type of machine (e.g. TX1 or TX2) in OBS? Maybe there is a flag or something? > [14:40:41] <guillaume_g> it would be for next VPP version, which perform some runtime checks at configure and if scheduled on TX1 (and maybe HiSi) it would not run on other machines. And if it is build on TX2 (or others), it would not be efficient on TX1. That sounds like we'd (short term) need to patch the configure script to explicitly be tuned for a particular target platform. Then build the binary n times - one for each optimization target. The long term fix is to work with OSEC for example and make sure that this becomes a real runtime check via IFUNCs for example, nothing checked at compile time. The same binary ideally runs fast everywhere then. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM January 2019