Running on Raspberry Pi 3, with updates to April 19:
[ryniker@RPi3-2 ~]$ uname -a Linux RPi3-2 4.11.0-0.rc5.git0.1.fc26.armv7hl #1 SMP Mon Apr 3 21:06:36 UTC 2017 armv7l armv7l armv7l GNU/Linux [ryniker@RPi3-2 ~]$ /usr/bin/python3.6 --version Python detected LC_CTYPE=C: LC_ALL & LANG coerced to C.UTF-8 (set another locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion behaviour). Python 3.6.0 [ryniker@RPi3-2 ~]$ env | grep LC LC_ALL=C [ryniker@RPi3-2 ~]$
I downloaded and built the current 3.6.1 Python with only default configuration, and there is no complaint:
[ryniker@RPi3-2 ~]$ /usr/local/bin/python3.6 --version Python 3.6.1 [ryniker@RPi3-2 ~]$
If Fedora packages Python configured to complain about awkward locale settings, it would be nice if Fedora starts after installation with a non-objectionable value.
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the vc4 module to avoid a kernel failure (https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the default target can be multi-user, but not graphical. Consequently, the first boot application never runs. Is first boot where appropriate locale configuration should occur?
El mié, 19-04-2017 a las 10:31 -0400, Richard Ryniker escribió:
Running on Raspberry Pi 3, with updates to April 19:
[ryniker@RPi3-2 ~]$ uname -a Linux RPi3-2 4.11.0-0.rc5.git0.1.fc26.armv7hl #1 SMP Mon Apr 3 21:06:36 UTC 2017 armv7l armv7l armv7l GNU/Linux [ryniker@RPi3-2 ~]$ /usr/bin/python3.6 --version Python detected LC_CTYPE=C: LC_ALL & LANG coerced to C.UTF-8 (set another locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion behaviour). Python 3.6.0 [ryniker@RPi3-2 ~]$ env | grep LC LC_ALL=C [ryniker@RPi3-2 ~]$
I downloaded and built the current 3.6.1 Python with only default configuration, and there is no complaint:
[ryniker@RPi3-2 ~]$ /usr/local/bin/python3.6 --version Python 3.6.1 [ryniker@RPi3-2 ~]$
If Fedora packages Python configured to complain about awkward locale settings, it would be nice if Fedora starts after installation with a non-objectionable value.
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the vc4 module to avoid a kernel failure (https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the default target can be multi-user, but not graphical. Consequently, the first boot application never runs. Is first boot where appropriate locale configuration should occur?
this is a generic issue not arm specific so is more appropriate on the devel list however it is related to https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale there are a few ways to work around it. one of which is to set your locale to C.UTF-8 or to make sure that you have the glibc-langpack-<foo> locale installed for your running locale
Dennis
this is a generic issue not arm specific so is more appropriate on the devel list however it is related to https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale there are a few ways to work around it. one of which is to set your locale to C.UTF-8 or to make sure that you have the glibc-langpack-<foo> locale installed for your running locale
Thank you for the link. I admire the Python folk who understood the importance of encoding support for character data, and suffered the pain necessary to implement a correct, robust implementation.
My concern for Fedora is whether a default installation can select locale data that avoids this situation. Have the current problems with the Raspberry Pi platform scuttled the usual process to define locale for a Fedora installation? Or is this an outstanding issue for every F26 user?
----- Original Message -----
Running on Raspberry Pi 3, with updates to April 19:
[ryniker@RPi3-2 ~]$ uname -a Linux RPi3-2 4.11.0-0.rc5.git0.1.fc26.armv7hl #1 SMP Mon Apr 3 21:06:36 UTC 2017 armv7l armv7l armv7l GNU/Linux [ryniker@RPi3-2 ~]$ /usr/bin/python3.6 --version Python detected LC_CTYPE=C: LC_ALL & LANG coerced to C.UTF-8 (set another locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion behaviour). Python 3.6.0 [ryniker@RPi3-2 ~]$ env | grep LC LC_ALL=C [ryniker@RPi3-2 ~]$
I downloaded and built the current 3.6.1 Python with only default configuration, and there is no complaint:
[ryniker@RPi3-2 ~]$ /usr/local/bin/python3.6 --version Python 3.6.1 [ryniker@RPi3-2 ~]$
If Fedora packages Python configured to complain about awkward locale settings, it would be nice if Fedora starts after installation with a non-objectionable value.
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the vc4 module to avoid a kernel failure (https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the
Hopefully this is no longer the case. On the 20170416 nightly images[1] I didn't need to blacklist on my problematic monitor (Haier 21").
default target can be multi-user, but not graphical. Consequently, the first boot application never runs. Is first boot where appropriate locale configuration should occur?
The display and initial-setup should come up even with the module blacklisted (perhaps not on workstation, not tested there), you lose some performance but it should be very usable.
Paul
[1] - https://kojipkgs.fedoraproject.org/compose/branched//Fedora-26-20170416.n.0/...
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the vc4 module to avoid a kernel failure (https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the
Hopefully this is no longer the case. On the 20170416 nightly images[1] I didn't need to blacklist on my problematic monitor (Haier 21").
It is still true (for me), using Fedora-Workstation-armhfp-26-20170419.n.0-sda.raw.xz
Full log at: http://ryniker.org/Fedora/arm/log_02
My monitor displays several hundred lines during boot before the failure, which presumably occurs during the attempt to start a graphical environment for first boot.
Apr 20 09:46:35 localhost kernel: ------------[ cut here ]------------ Apr 20 09:46:35 localhost kernel: WARNING: CPU: 0 PID: 34 at drivers/gpu/drm/drm_atomic_helper.c:1122 drm_atomic_helper_wait_for_vblanks+0xdc/0x1e8 [drm_kms_helper] Apr 20 09:46:35 localhost kernel: [CRTC:65] vblank wait timed out Apr 20 09:46:35 localhost kernel: Modules linked in: xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 fuse tun nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c crc32_arm_ce iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables joydev brcmfmac brcmutil cfg80211 rfkill vc4 snd_soc_core ac97_bus snd_pcm_dmaengine bcm2835_rng bcm2835_wdt bcm2835_dma leds_gpio nfsd auth_rpcgss nfs_acl lockd grace hid_logitech_hidpp hid_logitech_dj smsc95xx usbnet mii mmc_block snd_pcm snd_timer Apr 20 09:46:35 localhost kernel: snd soundcore drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm dwc2 udc_core sdhci_iproc sdhci_pltfm sdhci bcm2835 i2c_bcm2835 mmc_core pwm_bcm2835 sunrpc scsi_transport_iscsi Apr 20 09:46:35 localhost kernel: CPU: 0 PID: 34 Comm: kworker/0:1 Tainted: G W 4.11.0-0.rc6.git0.1.fc26.armv7hl #1 Apr 20 09:46:35 localhost kernel: Hardware name: Generic DT based system Apr 20 09:46:35 localhost kernel: Workqueue: events vc4_seqno_cb_work [vc4] Apr 20 09:46:35 localhost kernel: [<c0311700>] (unwind_backtrace) from [<c030c430>] (show_stack+0x18/0x1c) Apr 20 09:46:35 localhost kernel: [<c030c430>] (show_stack) from [<c0639384>] (dump_stack+0x80/0xa0) Apr 20 09:46:35 localhost kernel: [<c0639384>] (dump_stack) from [<c034c874>] (__warn+0xe4/0x104) Apr 20 09:46:35 localhost kernel: [<c034c874>] (__warn) from [<c034c8d0>] (warn_slowpath_fmt+0x3c/0x4c) Apr 20 09:46:35 localhost kernel: [<c034c8d0>] (warn_slowpath_fmt) from [<bf2103f0>] (drm_atomic_helper_wait_for_vblanks+0xdc/0x1e8 [drm_kms_helper]) Apr 20 09:46:35 localhost kernel: [<bf2103f0>] (drm_atomic_helper_wait_for_vblanks [drm_kms_helper]) from [<bf4137c8>] (vc4_atomic_complete_commit+0x5c/0xb4 [vc4]) Apr 20 09:46:35 localhost kernel: [<bf4137c8>] (vc4_atomic_complete_commit [vc4]) from [<c0364ef8>] (process_one_work+0x254/0x42c) Apr 20 09:46:35 localhost kernel: [<c0364ef8>] (process_one_work) from [<c036600c>] (worker_thread+0x2b8/0x434) Apr 20 09:46:35 localhost kernel: [<c036600c>] (worker_thread) from [<c036abdc>] (kthread+0x120/0x138) Apr 20 09:46:35 localhost kernel: [<c036abdc>] (kthread) from [<c0307e58>] (ret_from_fork+0x14/0x3c) Apr 20 09:46:35 localhost kernel: ---[ end trace f56f6c0054d1c6b0 ]---
On Thu, Apr 20, 2017 at 3:13 PM, Richard Ryniker ryniker@alum.mit.edu wrote:
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the vc4 module to avoid a kernel failure (https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the
Hopefully this is no longer the case. On the 20170416 nightly images[1] I didn't need to blacklist on my problematic monitor (Haier 21").
It is still true (for me), using Fedora-Workstation-armhfp-26-20170419.n.0-sda.raw.xz
Full log at: http://ryniker.org/Fedora/arm/log_02
My monitor displays several hundred lines during boot before the failure, which presumably occurs during the attempt to start a graphical environment for first boot.
Can you report it upstream with that crash, details of the kernel/monitor/interface used to connect to the monitor etc https://github.com/anholt/linux/issues
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the vc4 module to avoid a kernel failure (https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the
Hopefully this is no longer the case. On the 20170416 nightly images[1] I didn't need to blacklist on my problematic monitor (Haier 21").
It is still true (for me), using Fedora-Workstation-armhfp-26-20170419.n.0-sda.raw.xz
Full log at: http://ryniker.org/Fedora/arm/log_02
My monitor displays several hundred lines during boot before the failure, which presumably occurs during the attempt to start a graphical environment for first boot.
I have confirmed that when vc4 is blacklisted in this nightly build, boot will proceed (slowly) through first-boot and successfully create a user.
On Thu, Apr 20, 2017 at 4:06 PM, Richard Ryniker ryniker@alum.mit.edu wrote:
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the vc4 module to avoid a kernel failure (https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the
Hopefully this is no longer the case. On the 20170416 nightly images[1] I didn't need to blacklist on my problematic monitor (Haier 21").
It is still true (for me), using Fedora-Workstation-armhfp-26-20170419.n.0-sda.raw.xz
Full log at: http://ryniker.org/Fedora/arm/log_02
My monitor displays several hundred lines during boot before the failure, which presumably occurs during the attempt to start a graphical environment for first boot.
I have confirmed that when vc4 is blacklisted in this nightly build, boot will proceed (slowly) through first-boot and successfully create a user.
No, you've misinterpretted me, file a bug with all the issues when vc6 *isn't* blacklisted. While blacklisted the driver works around the problem it doesn't give accelerated UX and it doesn't work towards fixing the problem. If the issue isn't reported upstream the maintainer won't have the details so it can be fixed!
I understood, will report as you suggested later today. Too many balls in the air right now.
The display and initial-setup should come up even with the module blacklisted (perhaps not on workstation, not tested there), you lose some performance but it should be very usable.
I did want to state my success following Paul Whalen's remark, in case others face the same problem. I do not think the desktop is "very usable" but the important result is the system can be configured with users, etc. Access via ssh works fine, no vc4 problems there.