Arm-dev

arm-dev@lists.centos.org

1 participants
685 discussions

graphics issue on CentOS-Userland-7-armv7hl-generic-GNOME-1810-sda.raw ?
by R C 07 May '19

07 May '19

Hello, I built an SD card with CentOS-Userland-7-armv7hl-generic-GNOME-1810-sda.raw, and it looks like X doesn't want to start. Is that a known issue? (any ideas on how to fix this?) I attached the Xorg log below, thanks, Ron [root@localhost ~]# cat /var/log/Xorg.0.log [ 198.934] X.Org X Server 1.20.1 X Protocol Version 11, Revision 0 [ 198.934] Build Operating System: 4.14.91-201.el7.armv7hl+lpae [ 198.935] Current Operating System: Linux localhost 4.14.111-200.el7.armv7hl #1 SMP Sun Apr 14 03:01:20 UTC 2019 armv7l [ 198.936] Kernel command line: ro root=UUID=32d34531-1bc6-4fab-aeb2-2477436d2530 LANG=en_US.UTF-8 [ 198.936] Build Date: 14 March 2019 06:11:39PM [ 198.936] Build ID: xorg-x11-server 1.20.1-5.3.el7_6 [ 198.937] Current version of pixman: 0.34.0 [ 198.937] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 198.937] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 198.940] (==) Log file: "/var/log/Xorg.0.log", Time: Sun May 5 23:30:27 2019 [ 198.943] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 198.946] (==) No Layout section. Using the first Screen section. [ 198.946] (==) No screen section available. Using defaults. [ 198.946] (**) |-->Screen "Default Screen Section" (0) [ 198.946] (**) | |-->Monitor "<default monitor>" [ 198.948] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 198.948] (==) Automatically adding devices [ 198.948] (==) Automatically enabling devices [ 198.948] (==) Automatically adding GPU devices [ 198.948] (==) Automatically binding GPU devices [ 198.948] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 198.949] (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins [ 198.949] (==) ModulePath set to "/usr/lib/xorg/modules" [ 198.949] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 198.949] (II) Loader magic: 0x626004 [ 198.949] (II) Module ABI versions: [ 198.949] X.Org ANSI C Emulation: 0.4 [ 198.949] X.Org Video Driver: 24.0 [ 198.949] X.Org XInput driver : 24.1 [ 198.949] X.Org Server Extension : 10.0 [ 198.952] (II) xfree86: Adding drm device (/dev/dri/card0) [ 198.953] (II) Platform probe for /sys/devices/platform/soc/soc:gpu/drm/card0 [ 198.961] (EE) [ 198.961] (EE) Backtrace: [ 198.962] (EE) 0: /usr/bin/X (xorg_backtrace+0x4c) [0x5cbb48] [ 198.962] (EE) 1: /usr/bin/X (0x42a000+0x1a5adc) [0x5cfadc] [ 198.963] (EE) 2: /lib/libc.so.6 (__default_rt_sa_restorer_v2+0x0) [0xb693c860] [ 198.964] (EE) 3: /lib/libc.so.6 (strncmp+0x90) [0xb698d064] [ 198.965] (EE) 4: /usr/bin/X (0x42a000+0xa4024) [0x4ce024] [ 198.965] (EE) 5: /usr/bin/X (xf86BusProbe+0x8) [0x4a6e58] [ 198.966] (EE) 6: /usr/bin/X (InitOutput+0x748) [0x4b5374] [ 198.966] (EE) 7: /usr/bin/X (0x42a000+0x4e8f8) [0x4788f8] [ 198.967] (EE) 8: /lib/libc.so.6 (__libc_start_main+0x114) [0xb6924abc] [ 198.968] (EE) [ 198.969] (EE) Segmentation fault at address 0x0 [ 198.969] (EE) Fatal server error: [ 198.970] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 198.970] (EE) [ 198.970] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 198.971] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 198.972] (EE) [ 198.974] (EE) Server terminated with error (1). Closing log file.

2 5

Weird issue with NFSv4
by Stephan Guilloux 19 Mar '19

19 Mar '19

Hi there. Strange issue with NFSv4 this morning. RPI3b+ with kernel 103 and fresh yum update, set up as NFSv4 client. Trying to copy a whole folder with a few GB (many .rpm & .tgz and a few .img), from NFS mounted source to local filesystem. (cd /shared.nfs ; tar c) | (cd /local ; tar x) After a while ... - PING to the RPI works. - SSH sessions got frozen and login is impossible, even with USB keyboard on the RPI. - Sometimes, I do see some kernel backtrace on the VGA, but not always. As I have to switch off the RPI, there is nothing left in /var/log/message when system is back. If I do this copy with full SSH, the copy works perfectly well. (ssh xxx "cd /xxx ; tar c") | (cd /local ; tar x) I have the feeling that the system hangs often on the same huge file, but when I do copy it manually, even in a loop ... nothin happens. Any idea ?

4 10

Re: [Arm-dev] CentOS 7 KDE on Pi 3B+ video issue - strange
by kht-lists 18 Mar '19

18 Mar '19

I hope I am replying in the proper way. I am not very familiar with using mailing lists. Please allow me extend my thanks for the replies to my original post. I do have a couple of extra adapters. I seem to loose them or give them away that is why I purchased a couple more. I burned a CentOS Gnome image to a new SD card and tried it. Same issue as with the CentOS KDE image. I have installed the new, problematic ones on an Intel based PC and a Pi running Ubuntu. I now have 3 which will work with CentOS or Ubuntu or Raspbian. Ken p.s. On another list I have used I would get the individual replies to my post to which I could reply. On the Adm-dev list I get only Digests. Is there something I need to change in my account setup? It seems it would be easier to reply to a reply.

1 0

CentOS 7 KDE on Pi 3B+ video issue - strange
by kht-lists 17 Mar '19

17 Mar '19

I downloaded the referenced image a couple of days ago, burned it to a 16 GB SD card and booted my Pi 3B+. Fantastic! The Pi was connected with a HDMI to DVI cable to a Dell 19" monitor. I received in the mail a couple of HDMI to VGA adapters. The $4 generic ones which are all over ebay. I have several which I have purchased over the years and the generally work fine. [adapter.png] I decided to test the new adapters with the Pi. I connected one to the Pi and to a VGA cable to the same monitor (which has two inputs). I had NO video. No rainbow screen, no 4 raspberries screen, not test. Same for the second adapter. I tested the adapters on an Intel based PC. They worked fine. But it gets stranger... I booted the same Pi, same new adapter, connected to the same monitor from an Ubuntu SD card. The video was fine! And stranger still... I tried 3 older adapters with the Pi, CentOS and the same cable and monitor. The video was again fine! These adapters have no manufacturer markings. They probably all came from the same factory in China. Obviously something changed in the devices and I do not expect to ever be able to figure that out. However, something is also different in the video (driver I guess?) signal from the Pi with CentOS vs. Ubuntu. Can someone shed any light on this mystery? TIA, Ken Sent with [ProtonMail](https://protonmail.com) Secure Email.

4 3

raspi kernel upgrade activates not the latest kernel version
by Thorsten Holtkämper 17 Mar '19

17 Mar '19

Hi all, kernel upgrades on the raspi sometimes end up with not the latest kernel being "activated" in the /boot directory. The reason for this is the kernel rpm postuninstall script of the old kernel that is removed: postuninstall scriptlet (using /bin/sh): cp $(ls -1 /boot/kernel-*-*|tail -1) /boot/kernel7.img cp $(ls -1d /usr/share/raspberrypi2-kernel/*-*/|tail -1)/boot/*.dtb /boot/ cp $(ls -1d /usr/share/raspberrypi2-kernel/*-*/|tail -1)/boot/overlays/*.dtb* /boot/overlays/ It chooses the latest kernel version with "ls -1 /boot/kernel-*-*|tail -1" which fails for kernel versions that have different number of digits in the version string, e.g. 4.9 and 4.14 or 4.14.91 and 4.14.103. An additional "sort -V" should fix the problem, i.e. "ls -1 /boot/kernel-*-*|sort -V|tail -1". What do you think? Best regards, Thorsten

7 14

make aarch64 EFI bootable iso problem
by 曹瑀宏 06 Mar '19

06 Mar '19

Hello: I'm trying to make a EFI bootable arm iso based on CentOS-7-aarch64-Minimal-1810.iso. I extracted Iso and get the flie tree like this: . ├── boot.catalog ├── CentOS_BuildTag ├── EFI ├── EULA ├── GPL ├── images ├── LiveOS ├── Packages ├── repodata ├── RPM-GPG-KEY-CentOS-7 ├── RPM-GPG-KEY-CentOS-7-aarch64 └── TRANS.TBL Then I add my own rpms into Packages and repack the iso with shell command: mkisofs -o /root/myiso.iso -eltorito-alt-boot -e images/efiboot.img -c boot.catalog -no-emul-boot -boot-load-size 4 -boot-info-table -V 'CUSTOM CENTOS' -R -J -T . After that I burned the myiso.iso to disc, but I couldn't get the "EFI device 0" choice option on Arm Server's BootManager while the CentOS-7-aarch64-Minimal-1810.iso was OK, I don't know what's the problem and how to make a cutomized iso which can be recognized as a EFI device on ARM Server? Thanks!

1 0

spectre patches
by Yectli Huerta 04 Mar '19

04 Mar '19

hi, i was wondering if there centos on aarch64, has the same feature as x86_64 where you can disable some of the patches via echo 0 > /sys/kernel/debug/x86/retp_enabled thanks yah

1 0

yum update failed
by Robert Moskowitz 03 Mar '19

03 Mar '19

new build on a Cubieboard 2. I used https://armv7.dev.centos.org/repos/images/CentOS-Userland-7-armv7hl-generic… with xzcat CentOS-Userland-7-armv7hl-generic-Minimal-1810-sda.raw.xz | sudo dd of=/dev/sdb status=progress bs=4M onto a sata HD. The uSD card has uboot only. Booted fine. First step was to do a yum update and it failed: Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 Importing GPG key 0xF4A80EB5: Userid : "CentOS-7 Key (CentOS 7 Official Signing Key) <security(a)centos.org>" Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5 Package : centos-userland-release-7-6.1810.2.el7.centos.armv7hl (@instCentOS/$releasever) From : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 Is this ok [y/N]: y Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-AltArch-Arm32 Importing GPG key 0x62505FE6: Userid : "CentOS AltArch SIG - Arm32 (https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32) <security(a)centos.org>" Fingerprint: 4d9e 39f1 499c a21d d289 77f8 cafe f11b 6250 5fe6 Package : centos-userland-release-7-6.1810.2.el7.centos.armv7hl (@instCentOS/$releasever) From : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-AltArch-Arm32 Is this ok [y/N]: y Running transaction check ERROR with transaction check vs depsolve: xorg-x11-drv-vmmouse >= 14.0.0 is needed by (installed) kernel-4.14.82-201.el7.armv7hl You could try running: rpm -Va --nofiles --nodigest Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx.2019-03-03.04-01.uUyhcp.yumtx [root@localhost ~]# what do I need to do to get this install updated? thanks

2 2

Different issues with "DTOVERLAY".
by Stephan Guilloux 26 Feb '19

26 Feb '19

Hello, Small issues, today, with dtoverlay gpio-shutdown/poweroff [root@mypi ~]# dtoverlay gpio-shutdown su: user pi does not exist * Failed to apply overlay '1_gpio-shutdown' (kernel) su: user pi does not exist [root@mypi ~]# dtoverlay gpio-poweroff su: user pi does not exist su: user pi does not exist [root@mypi ~]# Even if I add a fake user "PI", this does not work better. [root@mypi ~]# useradd -r pi -p pi [root@mypi ~]# [root@mypi ~]# [root@mypi ~]# dtoverlay gpio-poweroff * Failed to apply overlay '2_gpio-poweroff' (kernel) [root@mypi ~]# dtoverlay gpio-shutdown * Failed to apply overlay '2_gpio-shutdown' (kernel) [root@mypi ~]# But when I check the overlay list, I get: [root@mypi ~]# dtoverlay -l Overlays (in load order): 0: gpio-shutdown 1: gpio-poweroff [root@mypi ~]# At least, something is done :-) Last problems: [root@mypi ~]# dtoverlay -h gpio-shutdown * Help file not found [root@mypi ~]# dtoverlay -h gpio-poweroff * Help file not found [root@mypi ~]# dtoverlay -h rpi-rtc * Help file not found [root@mypi ~]# dtoverlay -h rpi-display * Help file not found [root@mypi ~]# In case ... [root@mypi ~]# cat /proc/version Linux version 4.14.65-v7.1.el7 (mockbuild(a)armhfp-03.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)) #1 SMP Mon Aug 20 19:04:20 UTC 2018 [root@mypi ~]# [root@mypi ~]# rpm -qa 'raspberrypi-vc*' raspberrypi-vc-demo-source-20170705-502.gitaa39775.el7.noarch raspberrypi-vc-libs-20170705-502.gitaa39775.el7.armv7hl raspberrypi-vc-utils-20170705-502.gitaa39775.el7.armv7hl [root@mypi ~]# Stephan.

2 3

Re: [Arm-dev] Different issues with "DTOVERLAY".
by Stephan Guilloux 24 Feb '19

24 Feb '19

Hi Pablo, Found the cause for the Help problem. On CentOS, /boot/overlays/README is missing. It contains the help for all the dtoverlay commands... I got the file from its original distro, and I put it under /boot/overlays/README.rasp for the demo: [pi@myrpi ~]$ dtoverlay -h i2c-gpio * Help file not found [pi@myrpi ~]$ sudo mv /boot/overlays/README.rasp /boot/overlays/README [pi@myrpi ~]$ dtoverlay -h i2c-gpio Name: i2c-gpio Info: Adds support for software i2c controller on gpio pins Usage: dtoverlay=i2c-gpio,<param>=<val> Params: i2c_gpio_sda GPIO used for I2C data (default "23") i2c_gpio_scl GPIO used for I2C clock (default "24") i2c_gpio_delay_us Clock delay in microseconds (default "2" = ~100kHz) [pi@myrpi ~]$ Unfortunatelly, the files under this folder seem to belong to no package... [pi@myrpi ~]$ rpm -qf /boot/overlays/i2c-gpio.dtbo file /boot/overlays/i2c-gpio.dtbo is not owned by any package [pi@myrpi ~]$ So, I'm stuck there, for now ... Le lun. 24 sept. 2018 à 14:12, Stephan Guilloux < stephan.guilloux(a)crisalid.com> a écrit : > > > Le 24/09/2018 à 10:46, Pablo Sebastian Greco a écrit : > > > > El 24 sept 2018, a las 04:41, Stephan Guilloux < > stephan.guilloux(a)crisalid.com> escribió: > > Hello Pablo, > > Sorry for the direct mail. > > No problem. I'm on vacation this week so it is probably better > > Enjoy ;-) > > > I'll have a look, this week, but I need the sources that CentOS delivers. > I Tried to check on vault.centos.org, but no armhfp (only aarch64). > > You're right. I had touble finding it myself. It got lost when moving from > the old to the new build system. > Try here > https://armv7.dev.centos.org/repodir/c7-extras-1/raspberrypi-vc/20170705-50… > I'll update the srpm and probably github when I'm back but if you find the > problems, better. Hehe > > OK. Got it there. > Will inform you through the list, in case I find anything. > > > > Can you indicate where to find the current raspberrypi-vc-utils.src.rpm ? > > Regards, > > Stéphan. > > Thanks, Pablo > > > > Le 20/09/2018 à 13:02, Pablo Sebastián Greco a écrit : > > Stephan, sorry for the delay > El 10/9/18 a las 12:28, Stephan Guilloux escribió: > > Hello, > > Small issues, today, with dtoverlay gpio-shutdown/poweroff > > [root@mypi ~]# dtoverlay gpio-shutdown > su: user pi does not exist > * Failed to apply overlay '1_gpio-shutdown' (kernel) > su: user pi does not exist > [root@mypi ~]# dtoverlay gpio-poweroff > su: user pi does not exist > su: user pi does not exist > [root@mypi ~]# > > That seems to come from here ( > https://github.com/raspberrypi/userland/blob/master/host_applications/linux…). > If you run as root, it tries to run as the user "pi", as a normal > user(any), you shouldn't have that problem > > > Even if I add a fake user "PI", this does not work better. > > [root@mypi ~]# useradd -r pi -p pi > [root@mypi ~]# > [root@mypi ~]# > [root@mypi ~]# dtoverlay gpio-poweroff > * Failed to apply overlay '2_gpio-poweroff' (kernel) > [root@mypi ~]# dtoverlay gpio-shutdown > * Failed to apply overlay '2_gpio-shutdown' (kernel) > [root@mypi ~]# > > That bit seems to come from here ( > https://github.com/raspberrypi/userland/blob/2448644657e5fbfd82299416d21839…), > it fails to check if the overlay was actually applied > > > But when I check the overlay list, I get: > > [root@mypi ~]# dtoverlay -l > Overlays (in load order): > 0: gpio-shutdown > 1: gpio-poweroff > [root@mypi ~]# > > At least, something is done :-) > > That is a little stranger, why does it say it did something when the > command before said it failed??? > > Last problems: > [root@mypi ~]# dtoverlay -h gpio-shutdown > * Help file not found > [root@mypi ~]# dtoverlay -h gpio-poweroff > * Help file not found > [root@mypi ~]# dtoverlay -h rpi-rtc > * Help file not found > [root@mypi ~]# dtoverlay -h rpi-display > * Help file not found > [root@mypi ~]# > > > > I guess I'll have to add some debugging info and check in my rpi (as time > permits) > > In case ... > [root@mypi ~]# cat /proc/version > Linux version 4.14.65-v7.1.el7 (mockbuild(a)armhfp-03.bsys.centos.org) > (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)) #1 SMP Mon Aug 20 > 19:04:20 UTC 2018 > [root@mypi ~]# > > [root@mypi ~]# rpm -qa 'raspberrypi-vc*' > raspberrypi-vc-demo-source-20170705-502.gitaa39775.el7.noarch > raspberrypi-vc-libs-20170705-502.gitaa39775.el7.armv7hl > raspberrypi-vc-utils-20170705-502.gitaa39775.el7.armv7hl > [root@mypi ~]# > > 2 questions > 1) has it ever worked before? > 2) which rpi exactly are you using? (don't know if it is really relevant). > > Thanks. > Pablo. > > > Stephan. > > P.S.: Today we built 4.14.71 and will be released as soon as it passes the > tests. > > > >

2 1

← Newer
1
...
6
7
8
9
10
11
12
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev