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
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
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
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
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
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
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-Laptophttps://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
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