[fedora-arm] Re: [aarch64 - fedora28 - Fedora-Server-28-20180327.n.0.aarch64.raw.xz ]

2018-04-02 Thread Peter Robinson 
On Tue, Apr 3, 2018 at 5:02 AM, Richard Ryniker <ryni...@alum.mit.edu> wrote:
> I used Fedora-Workstation-28-20180402.n.0.aarch64.raw.xz and can boot
> successfully on my Raspberry Pi model 3B-plus.  I used:
>
> fedora-arm-image-installer  --target=rpi3 --media=/dev/sdi --norootpass 
> --resizefs --selinux=off 
> --image=fedora/F28/Fedora-Workstation-28-20180402.n.0.aarch64.raw.xz

Why disable SELinux, there should be no need to do that, is there a
particular reason or "just because"?

> to prepare a new SD card, but the root file system was not resized.  I
> had to do that manually.  A dtb file for the 3-plus is already in this
> image, there is no need to do anything about that.

Correct, rc7 is now stable and it includes that file, there's been
further updates and improvements that will be going out stable soon.

> There was some hesitation early in the boot process. (Maybe fsck? Maybe
> some First Boot procedure timing out, or perhaps some parameter-setting
> activity - there was something that looked like a text menu but it
> disappeared before I could read it.)  It lasted around two minutes.

When in the boot process? Was it the grub2 menu, that should be the
only text menu you get with a Workstation install.

> After boot, I logged on as root, created a user, enabled sshd, and can
> now connect to the machine using ssh.
>
> Note that before I booted the system, I changed the default target from
> graphical to multi-user, in order to avoid gnome-shell troubles:

So why not just use the minimal image?

> https://bugzilla.redhat.com/show_bug.cgi?id=1561184
>
> I suspect the wired Ethernet port is not operational (I used a USB
> Ethernet dongle for my ssh connection.)  I have not tried any wi-fi
> activity.

I've had reports of this working fine, that said it should be much
improved with the 4.16.0-300 or later kernel when that lands including
stable MAC address.

> There are problems, but a lot is working.  Certainly enough to make
> it reasonable to explore and learn what needs work.

Well the support has just landed, I've also been traveling so not had
the time to actually focus on it, we should have it to parity with the
original RPi3 in time for GA freeze in a couple of weeks.
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: [aarch64 - fedora28 - Fedora-Server-28-20180327.n.0.aarch64.raw.xz ]

2018-04-02 Thread Richard Ryniker 
I used Fedora-Workstation-28-20180402.n.0.aarch64.raw.xz and can boot
successfully on my Raspberry Pi model 3B-plus.  I used:

fedora-arm-image-installer  --target=rpi3 --media=/dev/sdi --norootpass 
--resizefs --selinux=off 
--image=fedora/F28/Fedora-Workstation-28-20180402.n.0.aarch64.raw.xz

to prepare a new SD card, but the root file system was not resized.  I
had to do that manually.  A dtb file for the 3-plus is already in this
image, there is no need to do anything about that.

There was some hesitation early in the boot process. (Maybe fsck? Maybe
some First Boot procedure timing out, or perhaps some parameter-setting
activity - there was something that looked like a text menu but it
disappeared before I could read it.)  It lasted around two minutes.

After boot, I logged on as root, created a user, enabled sshd, and can
now connect to the machine using ssh.

Note that before I booted the system, I changed the default target from
graphical to multi-user, in order to avoid gnome-shell troubles:

https://bugzilla.redhat.com/show_bug.cgi?id=1561184

I suspect the wired Ethernet port is not operational (I used a USB
Ethernet dongle for my ssh connection.)  I have not tried any wi-fi
activity.

"dnf upgrade" wqs successful, and updated 60 packages.

There are problems, but a lot is working.  Certainly enough to make
it reasonable to explore and learn what needs work.  

___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: RPi 3, Rawhide-20180330: hangs on "fb: switching to vc4drnfb from EFI VGA"

2018-04-02 Thread Tomasz Kłoczko 
On 3 April 2018 at 03:38, Peter Robinson  wrote:
[..]
> What if you do a "touch .autorelabel" in the root of the root
> filesystem to force a relabel on the first boot before initial-setup
> runs.

I'm almost sure that it will not help because with default selinux=1
boot is stuck still in initrd.
Just checked dmesg:

[..]
[   18.402415] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi
mapping ok
[   18.422995] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[   18.450260] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[   18.468053] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4])
[   18.486261] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops
vc4_crtc_ops [vc4])
[   18.506146] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops
vc4_crtc_ops [vc4])
[   18.506777] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops
vc4_crtc_ops [vc4])
[   18.569543] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[   18.569581] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   18.580844] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops [vc4])
[   18.595795] hub 1-1:1.0: USB hub found
[   18.609021] checking generic (3e914000 6d9000) vs hw (0 )
[   18.626159] hub 1-1:1.0: 5 ports detected
[   18.640066] fb: switching to vc4drmfb from EFI VGA

<< with default selinux=1 it stops here >>

[   18.671393] Console: switching to colour dummy device 80x25
[   18.702393] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[   18.709790] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   18.716637] [drm] Driver supports precise vblank timestamp query.
[   18.805698] Console: switching to colour frame buffer device 240x67
[   18.879057] vc4-drm soc:gpu: fb0:  frame buffer device
[   18.988315] usb 1-1.1: new high-speed USB device number 3 using dwc2
[   19.011445] systemd-udevd (438) used greatest stack depth: 10912 bytes left
[   19.027454] systemd-udevd (436) used greatest stack depth: 10752 bytes left
[   19.061440] systemd-udevd (442) used greatest stack depth: 10672 bytes left
[   19.120103] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[   19.128767] usb 1-1.1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[   19.268582] usb 1-1.3: new low-speed USB device number 4 using dwc2
[   19.277077] smsc95xx v1.0.6
[   19.422140] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at
usb-3f98.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:e9:2e:56
[   19.446206] usbcore: registered new interface driver smsc95xx
[   19.801281] usb 1-1.3: New USB device found, idVendor=413c, idProduct=2003
[   19.809224] usb 1-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[   19.817078] usb 1-1.3: Product: Dell USB Keyboard
[   19.822257] usb 1-1.3: Manufacturer: Dell
[   20.235616] input: Dell Dell USB Keyboard as
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:413C:2003.0001/input/input1
[   20.330813] hid-generic 0003:413C:2003.0001: input,hidraw0: USB HID
v1.10 Keyboard [Dell Dell USB Keyboard] on usb-3f98.usb-1.3/input0
[   20.345408] random: crng init done

<< and below is rootfs mount, then only after mounting rootfs presence
of the /.autorelabel may create different condition >>

[   23.289794] EXT4-fs (mmcblk0p5): mounted filesystem with ordered
data mode. Opts: (null)
[   27.888339] systemd-journald[187]: Received SIGTERM from PID 1 (systemd).
[   29.242999] systemd: 14 output lines suppressed due to ratelimiting
[   30.177243] systemd[1]: RTC configured in localtime, applying delta
of -300 minutes to system time.
[   30.253731] systemd[1]: systemd 238 running in system mode. (+PAM
+AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2
-IDN +PCRE2 default-hierarchy=hybrid)
[   30.301360] systemd[1]: Detected architecture arm64.
[   30.338705] systemd[1]: Set hostname to .
[   32.023212] systemd[1]: Stopped Switch Root.
[   32.042117] systemd[1]: systemd-journald.service: Service has no
hold-off time, scheduling restart.
[   32.042651] systemd[1]: systemd-journald.service: Scheduled restart
job, restart counter is at 1.
[   32.042752] systemd[1]: Stopped Journal Service.
[   32.144213] systemd[1]: Starting Remount Root and Kernel File Systems...
[   32.178055] systemd[1]: Set up automount Arbitrary Executable File
Formats File System Automount Point.
[   32.255864] systemd[1]: Listening on Process Core Dump Socket.
[   32.283562] EXT4-fs (mmcblk0p5): re-mounted. Opts: (null)
[   33.837208] systemd-journald[599]: Received request to flush
runtime journal from PID 1
[   34.025517] systemd-journald[599]: File
/var/log/journal/828c7422f9984510b5577d91d0ed9dae/system.journal
corrupted or uncleanly shut down, renaming and replacing.
[   42.294224] bcm2835-rng 3f104000.rng: hwrng registered
[   42.330494] bcm2835-wdt 3f10.watchdog: Broadcom BCM2835 watchdog timer

Above it is still

[fedora-arm] Re: RPi 3, Rawhide-20180330: hangs on "fb: switching to vc4drnfb from EFI VGA"

2018-04-02 Thread Peter Robinson 
> Batch of updates (with
> .Fedora-Minimal-Rawhide-20180401.n.0.aarch64.raw.xz image this time)
> Seems like issue which I've reported with frozen system after first
> boot after display last line with fb: switching to
> vc4drnfb from EFI VGA" message is somehow related to SELinux.
> Only when I've added to grug kernel parameters selinux=0 I was able to
> reach initial-setup propmt.

What if you do a "touch .autorelabel" in the root of the root
filesystem to force a relabel on the first boot before initial-setup
runs.

> Other found issue: sometimes before GRUB UEFI stub messages are
> displayed it takes more than half minute before grub passes control to
> the kerenel.
> On NanonPi Neo4 it takes sometimes up to 20s but on RPI3 it takes way
> longer, Looks like not everything iis OK in UEFI grub.
> I would be not surprised if ither aarch64 platforms will have simillar
> side effects.
>
> Oter issue: before initial-setup was able to start I had OOPS:
>
> [   43.561850] Bluetooth: HCI UART driver ver 2.3
> [   43.561870] Bluetooth: HCI UART protocol H4 registered
> [   43.561880] Bluetooth: HCI UART protocol BCSP registered
> [   43.565282] Bluetooth: HCI UART protocol LL registered
> [   43.565297] Bluetooth: HCI UART protocol ATH3K registered
> [   43.565306] Bluetooth: HCI UART protocol Three-wire (H5) registered
> [   43.565780] Bluetooth: HCI UART protocol Intel registered
> [   43.566496] Bluetooth: HCI UART protocol Broadcom registered
> [   43.566508] Bluetooth: HCI UART protocol QCA registered
> [   43.566519] Bluetooth: HCI UART protocol AG6XX registered
> [   43.566529] Bluetooth: HCI UART protocol Marvell registered
> [   43.570593] uart-pl011 3f201000.serial: no DMA platform data
>
> [   43.826209] ==
> [   43.826215] WARNING: possible circular locking dependency detected
> [   43.826225] 4.16.0-0.rc7.git1.1.fc29.aarch64 #1 Not tainted
> [   43.826228] --
> [   43.826235] kworker/u8:0/5 is trying to acquire lock:
> [   43.826240]  (bcm_device_lock){+.+.}, at: [<6eeac6db>]
> bcm_recv+0xb4/0x180 [hci_uart]
> [   43.826391]
>but task is already holding lock:
> [   43.967141]  (>lock){+.+.}, at: [<85c2f87e>]
> flush_to_ldisc+0x30/0xd0
> [   43.967177]
>which lock already depends on the new lock.
>
> [   44.033514]
>the existing dependency chain (in reverse order) is:
> [   44.033526]
>-> #3 (>lock){+.+.}:
> [   44.033567]lock_acquire+0xdc/0x298
> [   44.033580]__mutex_lock+0x84/0x848
> [   44.033589]mutex_lock_nested+0x3c/0x50
> [   44.033603]tty_buffer_flush+0x48/0xc8
> [   44.033611]tty_ldisc_flush+0x30/0x50
> [   44.033621]tty_port_close_start.part.2+0xfc/0x1e0
> [   44.033630]tty_port_close+0x4c/0x90
> [   44.033640]uart_close+0x38/0xa0
> [   44.033652]tty_release+0x114/0x5f0
> [   44.033663]__fput+0xb4/0x218
> [   44.033670]fput+0x20/0x30
> [   44.033680]task_work_run+0xa0/0xd0
> [   44.033693]do_notify_resume+0x104/0x120
> [   44.033702]work_pending+0x8/0x14
> [   44.033706]
>-> #2 (>ldisc_sem){}:
> [   44.033731]lock_acquire+0xdc/0x298
> [   44.033740]__ldsem_down_write_nested+0x50/0x228
> [   44.033751]ldsem_down_write+0x44/0x50
> [   44.033759]tty_ldisc_lock+0x28/0x50
> [   44.033766]tty_init_dev+0x94/0x1e0
> [   44.033773]tty_open+0x26c/0x400
> [   44.033794]chrdev_open+0x98/0x1e8
> [   44.436729]do_dentry_open+0x138/0x338
> [   44.436743]vfs_open+0x54/0x80
> [   44.436752]do_last+0x270/0x7e0
> [   44.436760]path_openat+0x9c/0x2a8
> [   44.436769]do_filp_open+0x70/0xd0
> [   44.436776]do_sys_open+0x15c/0x1f0
> [   44.436783]SyS_open+0x38/0x48
> [   44.436794]kernel_init_freeable+0x24c/0x2b8
> [   44.436805]kernel_init+0x18/0x110
> [   44.436818]ret_from_fork+0x10/0x18
> [   44.436823]
>-> #1 (>legacy_mutex){+.+.}:
> [   44.436850]lock_acquire+0xdc/0x298
> [   44.436861]__mutex_lock+0x84/0x848
> [   44.436870]mutex_lock_nested+0x3c/0x50
> [   44.436881]tty_lock+0x40/0x68
> [   44.436889]tty_init_dev+0x60/0x1e0
> [   44.436898]ttyport_open+0x30/0x148
> [   44.436911]serdev_device_open+0x30/0x48
> [   44.437036]bcm_open+0x84/0x1f0 [hci_uart]
> [   44.437142]hci_uart_register_device+0x3c/0x2d0 [hci_uart]
> [   44.699931]bcm_serdev_probe+0x94/0xe8 [hci_uart]
> [   44.699954]serdev_drv_probe+0x28/0x38
> [   44.725800]really_probe+0x204/0x3c8
> [   44.725824]driver_probe_device+0x54/0xd8
> [   44.750985]__driver_attach+0x12c/0x130
> [   44.750999]bus_for_each_dev+0x70/0xa8
> [   44.751007]

[fedora-arm] Re: RPi 3, Rawhide-20180330: hangs on "fb: switching to vc4drnfb from EFI VGA"

2018-04-02 Thread Tomasz Kłoczko 
On 1 April 2018 at 04:55, Tomasz Kłoczko  wrote:
[..]
Batch of updates (with
.Fedora-Minimal-Rawhide-20180401.n.0.aarch64.raw.xz image this time)
Seems like issue which I've reported with frozen system after first
boot after display last line with fb: switching to
vc4drnfb from EFI VGA" message is somehow related to SELinux.
Only when I've added to grug kernel parameters selinux=0 I was able to
reach initial-setup propmt.
Other found issue: sometimes before GRUB UEFI stub messages are
displayed it takes more than half minute before grub passes control to
the kerenel.
On NanonPi Neo4 it takes sometimes up to 20s but on RPI3 it takes way
longer, Looks like not everything iis OK in UEFI grub.
I would be not surprised if ither aarch64 platforms will have simillar
side effects.

Oter issue: before initial-setup was able to start I had OOPS:

[   43.561850] Bluetooth: HCI UART driver ver 2.3
[   43.561870] Bluetooth: HCI UART protocol H4 registered
[   43.561880] Bluetooth: HCI UART protocol BCSP registered
[   43.565282] Bluetooth: HCI UART protocol LL registered
[   43.565297] Bluetooth: HCI UART protocol ATH3K registered
[   43.565306] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   43.565780] Bluetooth: HCI UART protocol Intel registered
[   43.566496] Bluetooth: HCI UART protocol Broadcom registered
[   43.566508] Bluetooth: HCI UART protocol QCA registered
[   43.566519] Bluetooth: HCI UART protocol AG6XX registered
[   43.566529] Bluetooth: HCI UART protocol Marvell registered
[   43.570593] uart-pl011 3f201000.serial: no DMA platform data

[   43.826209] ==
[   43.826215] WARNING: possible circular locking dependency detected
[   43.826225] 4.16.0-0.rc7.git1.1.fc29.aarch64 #1 Not tainted
[   43.826228] --
[   43.826235] kworker/u8:0/5 is trying to acquire lock:
[   43.826240]  (bcm_device_lock){+.+.}, at: [<6eeac6db>]
bcm_recv+0xb4/0x180 [hci_uart]
[   43.826391]
   but task is already holding lock:
[   43.967141]  (>lock){+.+.}, at: [<85c2f87e>]
flush_to_ldisc+0x30/0xd0
[   43.967177]
   which lock already depends on the new lock.

[   44.033514]
   the existing dependency chain (in reverse order) is:
[   44.033526]
   -> #3 (>lock){+.+.}:
[   44.033567]lock_acquire+0xdc/0x298
[   44.033580]__mutex_lock+0x84/0x848
[   44.033589]mutex_lock_nested+0x3c/0x50
[   44.033603]tty_buffer_flush+0x48/0xc8
[   44.033611]tty_ldisc_flush+0x30/0x50
[   44.033621]tty_port_close_start.part.2+0xfc/0x1e0
[   44.033630]tty_port_close+0x4c/0x90
[   44.033640]uart_close+0x38/0xa0
[   44.033652]tty_release+0x114/0x5f0
[   44.033663]__fput+0xb4/0x218
[   44.033670]fput+0x20/0x30
[   44.033680]task_work_run+0xa0/0xd0
[   44.033693]do_notify_resume+0x104/0x120
[   44.033702]work_pending+0x8/0x14
[   44.033706]
   -> #2 (>ldisc_sem){}:
[   44.033731]lock_acquire+0xdc/0x298
[   44.033740]__ldsem_down_write_nested+0x50/0x228
[   44.033751]ldsem_down_write+0x44/0x50
[   44.033759]tty_ldisc_lock+0x28/0x50
[   44.033766]tty_init_dev+0x94/0x1e0
[   44.033773]tty_open+0x26c/0x400
[   44.033794]chrdev_open+0x98/0x1e8
[   44.436729]do_dentry_open+0x138/0x338
[   44.436743]vfs_open+0x54/0x80
[   44.436752]do_last+0x270/0x7e0
[   44.436760]path_openat+0x9c/0x2a8
[   44.436769]do_filp_open+0x70/0xd0
[   44.436776]do_sys_open+0x15c/0x1f0
[   44.436783]SyS_open+0x38/0x48
[   44.436794]kernel_init_freeable+0x24c/0x2b8
[   44.436805]kernel_init+0x18/0x110
[   44.436818]ret_from_fork+0x10/0x18
[   44.436823]
   -> #1 (>legacy_mutex){+.+.}:
[   44.436850]lock_acquire+0xdc/0x298
[   44.436861]__mutex_lock+0x84/0x848
[   44.436870]mutex_lock_nested+0x3c/0x50
[   44.436881]tty_lock+0x40/0x68
[   44.436889]tty_init_dev+0x60/0x1e0
[   44.436898]ttyport_open+0x30/0x148
[   44.436911]serdev_device_open+0x30/0x48
[   44.437036]bcm_open+0x84/0x1f0 [hci_uart]
[   44.437142]hci_uart_register_device+0x3c/0x2d0 [hci_uart]
[   44.699931]bcm_serdev_probe+0x94/0xe8 [hci_uart]
[   44.699954]serdev_drv_probe+0x28/0x38
[   44.725800]really_probe+0x204/0x3c8
[   44.725824]driver_probe_device+0x54/0xd8
[   44.750985]__driver_attach+0x12c/0x130
[   44.750999]bus_for_each_dev+0x70/0xa8
[   44.751007]driver_attach+0x30/0x40
[   44.751015]driver_attach_async+0x20/0x60
[   44.751027]async_run_entry_fn+0x4c/0x188
[   44.751038]process_one_work+0x264/0x700
[   44.751045]worker_thread+0x4c/0x408
[   44.751055]kthread+0x134/0x138
[

[fedora-arm] Re: Raspberry Pi 3+

2018-04-02 Thread Eric Sandeen 
On 4/2/18 7:05 PM, Peter Robinson wrote:
> On Mon, Apr 2, 2018 at 7:42 PM, Tomáš Frolík  wrote:
>> Peter, I would like to as You, whether the onboard-wired-ethernet problem on 
>> RPi3+ was solved in current F28 test release (31.3.2018). If not, can You 
>> provide any indication when it could be?
> 
> I don't know what you mean by "I would like to as You", please note
> that I provide the support for RPi in my own time as and when I have
> spare time.
> 
> That said I did pull in some patches that should improve a bunch of
> things on the 3+but they're not in an official build just yet, you can
> get a scratch kernel [1] and report back whether they improved your
> situation. There's a couple of patches that might improve the wired
> lan but I've not currently got access to ethernet to test as I'm
> currently traveling.
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=26121358

That kernel did fix the "mac address changes every reboot" for me.
And yes, the ethernet port does still work.  ;)
Thanks!

And the ethernet port LEDS ... I seem to have a flashing amber
activity LED, and the green LED is off.

-Eric
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: [aarch64 - fedora28 - Fedora-Server-28-20180327.n.0.aarch64.raw.xz ]

2018-04-02 Thread Peter Robinson 
On Mon, Apr 2, 2018 at 8:46 PM, Pierre-Francois RENARD
 wrote:
> Hi again,
> I was not able to boot this way.
>
> I tried then to do all the stuffs (update to latest 28 ) with a rpi2 and it 
> worked.
> But when I try to boot this sd card on the rpi3b+ it is not working.
> I can see the EFI boot + grub menu.
> Then the screen goes black and nothing more.

HDMI based screen? Serial console? More details please.

I have rebased a bunch of stuff around the support for the 3+, there's
not an official Fedora kernel build just yet but you can get a scratch
 and test it [1]

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=26121358
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Raspberry Pi 3+

2018-04-02 Thread Peter Robinson 
On Mon, Apr 2, 2018 at 7:42 PM, Tomáš Frolík  wrote:
> Peter, I would like to as You, whether the onboard-wired-ethernet problem on 
> RPi3+ was solved in current F28 test release (31.3.2018). If not, can You 
> provide any indication when it could be?

I don't know what you mean by "I would like to as You", please note
that I provide the support for RPi in my own time as and when I have
spare time.

That said I did pull in some patches that should improve a bunch of
things on the 3+but they're not in an official build just yet, you can
get a scratch kernel [1] and report back whether they improved your
situation. There's a couple of patches that might improve the wired
lan but I've not currently got access to ethernet to test as I'm
currently traveling.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=26121358
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: [aarch64 - fedora28 - Fedora-Server-28-20180327.n.0.aarch64.raw.xz ]

2018-04-02 Thread Pierre-Francois RENARD 
I did it already.
I checked the /boot/dtb/broadcom/ directory and I have 2 files

-rw-r--r--.  1 root root 12611 Mar 26 18:10 bcm2837-rpi-3-b.dtb
-rw-r--r--.  1 root root 12933 Mar 26 18:10 bcm2837-rpi-3-b-plus.dtb


I am running kernel 4.16.0-0.rc7.git0.1.fc28.aarch64 and Peter was talking 
about rc6?
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: [aarch64 - fedora28 - Fedora-Server-28-20180327.n.0.aarch64.raw.xz ]

2018-04-02 Thread Richard Ryniker 
See Peter Robinson's post on March 23, 2018, at 10:42 PM that details how
to copy the Raspberry Pi device tree file for the model 3+. 
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: [aarch64 - fedora28 - Fedora-Server-28-20180327.n.0.aarch64.raw.xz ]

2018-04-02 Thread Pierre-Francois RENARD 
Hi again,
I was not able to boot this way.

I tried then to do all the stuffs (update to latest 28 ) with a rpi2 and it 
worked.
But when I try to boot this sd card on the rpi3b+ it is not working.
I can see the EFI boot + grub menu.
Then the screen goes black and nothing more.

How can I try to understand what's going on ? 

Thanks
Fox
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Raspberry Pi 3+

2018-04-02 Thread Tomáš Frolík 
Peter, I would like to as You, whether the onboard-wired-ethernet problem on 
RPi3+ was solved in current F28 test release (31.3.2018). If not, can You 
provide any indication when it could be?
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: NanoPi Neo2, Rawhide-20180330: (probably) hangs in initial-setup

2018-04-02 Thread Tomasz Kłoczko 
On 1 April 2018 at 20:36, Tomasz Kłoczko  wrote:
[..]
OK here are few more things which I fund:
1) initial-setup and ssh key generation services do not work because
something is really screwed with SElinux settings and when SELinux has
enabled those services seems are not able to write keys or apply other
modifications.

With those two modifications so far I've been able to finish first boot with:

[  OK  ] Started Secure Boot DBX (blacklist) updater.
[  OK  ] Started Hardware RNG Entropy Gatherer Daemon.
 Starting OpenSSH ecdsa Server Key Generation...
 Starting Initial Setup configuration program...
 Starting OpenSSH ed25519 Server Key Generation...
[   51.795341] bridge: filtering via arp/ip/ip6tables is no longer
available by default. Update your scripts to load br_netfilter if you
need this.
[   51.922063] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   51.933399] RTL8211E Gigabit Ethernet 0.2:07: attached PHY driver
[RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=0.2:07, irq=POLL)
[   51.974155] dwmac-sun8i 1c3.ethernet eth0: No MAC Management
Counters available
[   51.982348] dwmac-sun8i 1c3.ethernet eth0: PTP not supported by HW
[   51.994992] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   55.119566] dwmac-sun8i 1c3.ethernet eth0: Link is Up -
100Mbps/Full - flow control off
[   55.128530] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready


1) [x] Language settings 2) [x] Time settings
   (English (United States))(US/Eastern timezone)
3) [x] Network configuration 4) [x] Root password
   (Wired (eth0) connected) (Password is set.)
5) [ ] User creation
   (No user will be created)

Please make a selection from the above ['c' to continue, 'q' to quit,
'r' to refresh]:


2) --norootpass option does not work because in used to generate image
ks profiles is:

rootpw --iscrypted --lock locked

so in /etc/shadow is line:

root:!locked::0:9:7:::

when in fedora-arm-image-installer is line

sed -i 's/root:x:/root::/' /tmp/root/etc/passwd

Obviously, this is not putting empty root password and root account
still is locked.
Despite this seems this option can be removed now because anaconda
started in initial-setup service provides root password change.

I think that fedora-arm-image-installer script should be evolving now
into the direction tweaking ks profile used on first boot and/or force
as well start anaconda in non-interactive mode.
Probably the best way to fix SELinux issues is to change SELInux
settings to disabled (in ks profile used for generating images).
Seems that hostname changes are not applied because the system should
be rebooted after finish anaconda.
If in used in initial-setup ks profile would enable SELinux and before
reboot will be created /.autorelabel file all still incorrect SELinux
labels will be corrected on next reboot.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org