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

[Tomasz Kłoczko]

Hi,

Like it is in subject boot process stops on display "fb: switching to
vc4drnfb from EFI VGA"
Any suggestions/advices?

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

[Peter Robinson]

Post by Tomasz Kłoczko
Hi,
Like it is in subject boot process stops on display "fb: switching to
vc4drnfb from EFI VGA"
Any suggestions/advices?

What do you mean by "hangs", do you mean the screen goes blank, or do
you mean the kernel crashes?

Also we don't have a module called vc4drmfb so can you provide more
details about the kernel you're using?
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-leave

[Tomasz Kłoczko]

On 1 April 2018 at 02:33, Peter Robinson <***@gmail.com> wrote:
[..]

Post by Peter Robinson
What do you mean by "hangs", do you mean the screen goes blank, or do
you mean the kernel crashes?

I mean that nothing mre is displayed and there is no any other signs
of progress.
As <censored> systemd does not allow interrupt boot process to start
emergency shell I'm not able to diagnose this issue.

Post by Peter Robinson
Also we don't have a module called vc4drmfb so can you provide more
details about the kernel you're using?

As it is in subject I'm using dist rawhide image written to sd card by command:

# fedora-arm-image-installer
--image=Fedora-Minimal-Rawhide-20180330.n.0.aarch64.raw.xz
--media=/dev/<sd_card> --target=rpi3 --norootpass -y

No other modifications.

kloczek

[Tomasz Kłoczko]

Post by Tomasz Kłoczko
[..]

Post by Peter Robinson
What do you mean by "hangs", do you mean the screen goes blank, or do
you mean the kernel crashes?

I mean that nothing mre is displayed and there is no any other signs
of progress.
As <censored> systemd does not allow interrupt boot process to start
emergency shell I'm not able to diagnose this issue.

Post by Peter Robinson
Also we don't have a module called vc4drmfb so can you provide more
details about the kernel you're using?

# fedora-arm-image-installer
--image=Fedora-Minimal-Rawhide-20180330.n.0.aarch64.raw.xz
--media=/dev/<sd_card> --target=rpi3 --norootpass -y
No other modifications.

I've took the picture from my tv.
https://expirebox.com/download/a0a6519bf405edb5d8d42d9913da9715.html

On the output is possible to see vc4-drm before line on which boot stops
but no errors or other warnings are reported.
Only USB device connected to RPi3 is USB keyboard.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Tomasz Kłoczko]

On 1 April 2018 at 04:55, Tomasz Kłoczko <***@gmail.com> 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: [<000000006eeac6db>]
bcm_recv+0xb4/0x180 [hci_uart]
[ 43.826391]
but task is already holding lock:
[ 43.967141] (&buf->lock){+.+.}, at: [<0000000085c2f87e>]
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 (&buf->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 (&tty->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 (&tty->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
[ 44.751067] ret_from_fork+0x10/0x18
[ 44.751073]
-> #0 (bcm_device_lock){+.+.}:
[ 44.751105] __lock_acquire+0xb14/0x1060
[ 44.751114] lock_acquire+0xdc/0x298
[ 44.751128] __mutex_lock+0x84/0x848
[ 44.751137] mutex_lock_nested+0x3c/0x50
[ 44.751263] bcm_recv+0xb4/0x180 [hci_uart]
[ 44.751362] hci_uart_receive_buf+0x7c/0xa8 [hci_uart]
[ 44.751371] ttyport_receive_buf+0x5c/0x108
[ 44.751383] flush_to_ldisc+0xa8/0xd0
[ 44.751392] process_one_work+0x264/0x700
[ 44.751399] worker_thread+0x4c/0x408
[ 44.751409] kthread+0x134/0x138
[ 44.751417] ret_from_fork+0x10/0x18
[ 44.751421]
other info that might help us debug this:

[ 44.751425] Chain exists of:
bcm_device_lock --> &tty->ldisc_sem --> &buf->lock

[ 44.751448] Possible unsafe locking scenario:

[ 44.751451] CPU0 CPU1
[ 44.751455] ---- ----
[ 44.751457] lock(&buf->lock);
[ 44.751467] lock(&tty->ldisc_sem);
[ 44.751476] lock(&buf->lock);
[ 44.751484] lock(bcm_device_lock);
[ 44.751493]
*** DEADLOCK ***

[ 44.751500] 3 locks held by kworker/u8:0/5:
[ 44.751503] #0: ((wq_completion)"events_unbound"){+.+.}, at:
[<000000002d869021>] process_one_work+0x1a8/0x700
[ 44.751529] #1: ((work_completion)(&buf->work)){+.+.}, at:
[<000000002d869021>] process_one_work+0x1a8/0x700
[ 44.751551] #2: (&buf->lock){+.+.}, at: [<0000000085c2f87e>]
flush_to_ldisc+0x30/0xd0
[ 44.751573]
stack backtrace:
[ 44.751584] CPU: 2 PID: 5 Comm: kworker/u8:0 Not tainted
4.16.0-0.rc7.git1.1.fc29.aarch64 #1
[ 44.751589] Hardware name: raspberrypi rpi/rpi, BIOS 2018.03 03/20/2018
[ 44.751605] Workqueue: events_unbound flush_to_ldisc
[ 44.751614] Call trace:
[ 44.751626] dump_backtrace+0x0/0x148
[ 44.751636] show_stack+0x24/0x30
[ 44.751650] dump_stack+0xb0/0xe8
[ 44.751661] print_circular_bug.isra.18+0x270/0x2d8
[ 44.751670] check_prev_add.constprop.24+0x48c/0x750
[ 44.751679] __lock_acquire+0xb14/0x1060
[ 44.751687] lock_acquire+0xdc/0x298
[ 44.751696] __mutex_lock+0x84/0x848
[ 44.751705] mutex_lock_nested+0x3c/0x50
[ 44.751804] bcm_recv+0xb4/0x180 [hci_uart]
[ 44.751901] hci_uart_receive_buf+0x7c/0xa8 [hci_uart]
[ 44.751911] ttyport_receive_buf+0x5c/0x108
[ 44.751919] flush_to_ldisc+0xa8/0xd0
[ 44.751926] process_one_work+0x264/0x700
[ 44.751933] worker_thread+0x4c/0x408
[ 44.751942] kthread+0x134/0x138
[ 44.751950] ret_from_fork+0x10/0x18
[ 44.908450] Bluetooth: hci0: BCM: chip id 94
[ 44.919635] Bluetooth: hci0: BCM: features 0x2e

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

[Peter Robinson]

Post by Tomasz Kłoczko
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.

Post by Tomasz Kłoczko
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.
[ 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.826240] (bcm_device_lock){+.+.}, at: [<000000006eeac6db>]
bcm_recv+0xb4/0x180 [hci_uart]
[ 43.826391]
[ 43.967141] (&buf->lock){+.+.}, at: [<0000000085c2f87e>]
flush_to_ldisc+0x30/0xd0
[ 43.967177]
which lock already depends on the new lock.
[ 44.033514]
[ 44.033526]
[ 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]
[ 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]
[ 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
[ 44.751067] ret_from_fork+0x10/0x18
[ 44.751073]
[ 44.751105] __lock_acquire+0xb14/0x1060
[ 44.751114] lock_acquire+0xdc/0x298
[ 44.751128] __mutex_lock+0x84/0x848
[ 44.751137] mutex_lock_nested+0x3c/0x50
[ 44.751263] bcm_recv+0xb4/0x180 [hci_uart]
[ 44.751362] hci_uart_receive_buf+0x7c/0xa8 [hci_uart]
[ 44.751371] ttyport_receive_buf+0x5c/0x108
[ 44.751383] flush_to_ldisc+0xa8/0xd0
[ 44.751392] process_one_work+0x264/0x700
[ 44.751399] worker_thread+0x4c/0x408
[ 44.751409] kthread+0x134/0x138
[ 44.751417] ret_from_fork+0x10/0x18
[ 44.751421]
bcm_device_lock --> &tty->ldisc_sem --> &buf->lock
[ 44.751451] CPU0 CPU1
[ 44.751455] ---- ----
[ 44.751457] lock(&buf->lock);
[ 44.751467] lock(&tty->ldisc_sem);
[ 44.751476] lock(&buf->lock);
[ 44.751484] lock(bcm_device_lock);
[ 44.751493]
*** DEADLOCK ***
[<000000002d869021>] process_one_work+0x1a8/0x700
[<000000002d869021>] process_one_work+0x1a8/0x700
[ 44.751551] #2: (&buf->lock){+.+.}, at: [<0000000085c2f87e>]
flush_to_ldisc+0x30/0xd0
[ 44.751573]
[ 44.751584] CPU: 2 PID: 5 Comm: kworker/u8:0 Not tainted
4.16.0-0.rc7.git1.1.fc29.aarch64 #1
[ 44.751589] Hardware name: raspberrypi rpi/rpi, BIOS 2018.03 03/20/2018
[ 44.751605] Workqueue: events_unbound flush_to_ldisc
[ 44.751626] dump_backtrace+0x0/0x148
[ 44.751636] show_stack+0x24/0x30
[ 44.751650] dump_stack+0xb0/0xe8
[ 44.751661] print_circular_bug.isra.18+0x270/0x2d8
[ 44.751670] check_prev_add.constprop.24+0x48c/0x750
[ 44.751679] __lock_acquire+0xb14/0x1060
[ 44.751687] lock_acquire+0xdc/0x298
[ 44.751696] __mutex_lock+0x84/0x848
[ 44.751705] mutex_lock_nested+0x3c/0x50
[ 44.751804] bcm_recv+0xb4/0x180 [hci_uart]
[ 44.751901] hci_uart_receive_buf+0x7c/0xa8 [hci_uart]
[ 44.751911] ttyport_receive_buf+0x5c/0x108
[ 44.751919] flush_to_ldisc+0xa8/0xd0
[ 44.751926] process_one_work+0x264/0x700
[ 44.751933] worker_thread+0x4c/0x408
[ 44.751942] kthread+0x134/0x138
[ 44.751950] ret_from_fork+0x10/0x18
[ 44.908450] Bluetooth: hci0: BCM: chip id 94
[ 44.919635] Bluetooth: hci0: BCM: features 0x2e
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproj

[Tomasz Kłoczko]

On 3 April 2018 at 03:38, Peter Robinson <***@gmail.com> wrote:
[..]

Post by Peter Robinson
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 3f400000.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 3fc00000.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 ffffffffffffffff)
[ 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-3f980000.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/3f980000.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-3f980000.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 <localhost.localdomain>.
[ 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 3f100000.watchdog: Broadcom BCM2835 watchdog timer

Above it is still from dmesg messages of the first boot in which
initial-setup has been started.

Theoretically selinux=1 should not be affecting fb initialization but
knowing that that I had SELinux issue on NanoPi Neo2 at some point
I've prepared fresh RPi3 sd card with added selinux=0 in grub2.cfg
file and whole boot passed this critical point.
Maybe next step afer display this message is affected by selinux=1?

Will try confirm above tomorrow (now I must finish some new base setup
of some POC on this RPi3).

kloczek

[Tomasz Kłoczko]

On 3 April 2018 at 04:06, Tomasz Kłoczko <***@gmail.com> wrote:
[..]

Post by Tomasz Kłoczko
Will try confirm above tomorrow (now I must finish some new base setup
of some POC on this RPi3).

Today after finishing what I've started yesterday I've cloned grub.cfg
boot menu entry and in this cloned entry I've left original boot entry
without selinux=0.
After reboot whole boot process stops at the same point as on initial
first boot.
I was unable relabel all files because it requires to start the system
with selinux=1.

So looks like ATM on RPi3 it is possible to use radhide image only
with disabled on boot stage disabled SELinux.
Can anyone confirm this?

kloczek

[Peter Robinson]

Post by Tomasz Kłoczko
[..]

Post by Tomasz Kłoczko
Will try confirm above tomorrow (now I must finish some new base setup
of some POC on this RPi3).

Today after finishing what I've started yesterday I've cloned grub.cfg
boot menu entry and in this cloned entry I've left original boot entry
without selinux=0.
After reboot whole boot process stops at the same point as on initial
first boot.
I was unable relabel all files because it requires to start the system
with selinux=1.
So looks like ATM on RPi3 it is possible to use radhide image only
with disabled on boot stage disabled SELinux.
Can anyone confirm this?

So aarch64 boots fine for me on a 3+ using the Apr 4th images
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email