Last week I got my hands on a FriendlyElec NanoPC-t4
I tried to boot branch 20221008, but the boot process stopped at:
[OK] Reached target basic.target - Basic System [14.886445] dracut-initqueue[696]: WARNING: File locking is disabled. Starting dbs-broker.serv…ice - D-Bus System Message Bus … [OK] Found device dev-mapper-fe…ice - /dev/mapper/fedora-root. [OK] Reached target initrd-root...e.target – Initrd Root Device. [OK] Started dbus-broker.service – D-Bus System Message Bus.
The same is true with Beta 1.5 and with Fedora 36.
It looks similar to an error I had with my Radxa Rock Pi 4a which was resolved (the Rock Pi boots that branch without any problems, even from NVMe disk using Armbian SPI Flash, by the way).
Some branches earlier the process stopped at the same line, but after about 15 mins continued repeatedly showing the same error message again and again, and finally an emergency mode shell prompt.
Unfortunately I didn’t noted any details because I run out of time. So I retried today with the current branch. It it helps I can try to find the branch with the latter behaviour.
On Sun, Oct 9, 2022 at 1:10 PM Peter Boy pboy@uni-bremen.de wrote:
Last week I got my hands on a FriendlyElec NanoPC-t4
I tried to boot branch 20221008, but the boot process stopped at:
[OK] Reached target basic.target - Basic System [14.886445] dracut-initqueue[696]: WARNING: File locking is disabled. Starting dbs-broker.serv…ice - D-Bus System Message Bus … [OK] Found device dev-mapper-fe…ice - /dev/mapper/fedora-root. [OK] Reached target initrd-root...e.target – Initrd Root Device. [OK] Started dbus-broker.service – D-Bus System Message Bus.
The same is true with Beta 1.5 and with Fedora 36.
The above isn't particularly useful for debug, can you put the entire output of the boot process (U-Boot through dmesg) into a paste service somewhere.
It looks similar to an error I had with my Radxa Rock Pi 4a which was resolved (the Rock Pi boots that branch without any problems, even from NVMe disk using Armbian SPI Flash, by the way).
Some branches earlier the process stopped at the same line, but after about 15 mins continued repeatedly showing the same error message again and again, and finally an emergency mode shell prompt.
Unfortunately I didn’t noted any details because I run out of time. So I retried today with the current branch. It it helps I can try to find the branch with the latter behaviour.
I'm not sure what you mean by branches in this context.
Peter,
Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the kernel command line and see if that works for you?
Peter
On Mon, Oct 10, 2022 at 8:21 AM Peter Robinson pbrobinson@gmail.com wrote:
On Sun, Oct 9, 2022 at 1:10 PM Peter Boy pboy@uni-bremen.de wrote:
Last week I got my hands on a FriendlyElec NanoPC-t4
I tried to boot branch 20221008, but the boot process stopped at:
[OK] Reached target basic.target - Basic System [14.886445] dracut-initqueue[696]: WARNING: File locking is disabled. Starting dbs-broker.serv…ice - D-Bus System Message Bus … [OK] Found device dev-mapper-fe…ice - /dev/mapper/fedora-root. [OK] Reached target initrd-root...e.target – Initrd Root Device. [OK] Started dbus-broker.service – D-Bus System Message Bus.
The same is true with Beta 1.5 and with Fedora 36.
The above isn't particularly useful for debug, can you put the entire output of the boot process (U-Boot through dmesg) into a paste service somewhere.
It looks similar to an error I had with my Radxa Rock Pi 4a which was resolved (the Rock Pi boots that branch without any problems, even from NVMe disk using Armbian SPI Flash, by the way).
Some branches earlier the process stopped at the same line, but after about 15 mins continued repeatedly showing the same error message again and again, and finally an emergency mode shell prompt.
Unfortunately I didn’t noted any details because I run out of time. So I retried today with the current branch. It it helps I can try to find the branch with the latter behaviour.
I'm not sure what you mean by branches in this context.
Am 12.10.2022 um 19:14 schrieb Peter Robinson pbrobinson@gmail.com:
Peter,
Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the kernel command line and see if that works for you?
Peter
On Mon, Oct 10, 2022 at 8:21 AM Peter Robinson pbrobinson@gmail.com wrote:
On Sun, Oct 9, 2022 at 1:10 PM Peter Boy pboy@uni-bremen.de wrote:
Last week I got my hands on a FriendlyElec NanoPC-t4
I tried to boot branch 20221008, but the boot process stopped at:
[OK] Reached target basic.target - Basic System [14.886445] dracut-initqueue[696]: WARNING: File locking is disabled. Starting dbs-broker.serv…ice - D-Bus System Message Bus … [OK] Found device dev-mapper-fe…ice - /dev/mapper/fedora-root. [OK] Reached target initrd-root...e.target – Initrd Root Device. [OK] Started dbus-broker.service – D-Bus System Message Bus.
I used branch 20221009 (with „branch“ I mean https://kojipkgs.fedoraproject.org/compose/branched/ )
I had to edit the club.cfg file, because the keyboard is not initialised.
The system blows up immediately after the line to which it got without that addition: [16…] Unable to handle kernel execution from non executable memory at virtual address 000…000 [16…] Mem Abort info: [16…] ESRO ox000000...0004 [16…] EC = 0x21: ….
Would I get better and more helpful information it I get a seriell interface cable? I suppose, delivery would need 2-3 days.
And I detected another possible issue:
The arm-image-installer shows a message I previously missed (Sorry, I just noticed the last success line): … = Writing image complete!
sed: can't read /tmp/fw/EFI/fedora/grubenv: No such file or directory<<<<<<<<
= Writing idbloader.img for nanopc-t4-rk3399 .... on media /dev/mmcblk0 280+0 records in …
As I see that are lines where sed is adding some kernel configuration. If I install the rock-pi target, these lines don’t show up.
And if I install the F36 version for nanopc, that sed-line doesn’t show up either.
By the way, the F36 version works well with nanopc as long as you don’t populate the NVMe onboard m.2 interface. If you do so, when booting from mSD a warning message shows like „Use NVMe for p3 LVM instead of mmcblk0 because I saw that first“. It proceeds but finally stops and obviously can’t use NVMe for p3/LVM. I hope it is not important because everyone will use the onboard eMMC module and hopefully the problem doesn’t exist with faster emmc memory. I saved the complete installation log file, and can upload it if useful.
Thanks Peter
On Wed, Oct 12, 2022 at 6:14 PM Peter Robinson pbrobinson@gmail.com wrote:
Peter,
Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the kernel command line and see if that works for you?
So I'm pretty sure this is now fixed with kernel 5.19.15-301.fc37 or 5.19.15-201.fc36 so if you could give it a test that would be fab. It should be stable into F-37 RSN but you could also deploy a default F-36 image and update to the F-36 kernel as I think you said F-36 GA worked.
Peter
On Mon, Oct 10, 2022 at 8:21 AM Peter Robinson pbrobinson@gmail.com wrote:
On Sun, Oct 9, 2022 at 1:10 PM Peter Boy pboy@uni-bremen.de wrote:
Last week I got my hands on a FriendlyElec NanoPC-t4
I tried to boot branch 20221008, but the boot process stopped at:
[OK] Reached target basic.target - Basic System [14.886445] dracut-initqueue[696]: WARNING: File locking is disabled. Starting dbs-broker.serv…ice - D-Bus System Message Bus … [OK] Found device dev-mapper-fe…ice - /dev/mapper/fedora-root. [OK] Reached target initrd-root...e.target – Initrd Root Device. [OK] Started dbus-broker.service – D-Bus System Message Bus.
The same is true with Beta 1.5 and with Fedora 36.
The above isn't particularly useful for debug, can you put the entire output of the boot process (U-Boot through dmesg) into a paste service somewhere.
It looks similar to an error I had with my Radxa Rock Pi 4a which was resolved (the Rock Pi boots that branch without any problems, even from NVMe disk using Armbian SPI Flash, by the way).
Some branches earlier the process stopped at the same line, but after about 15 mins continued repeatedly showing the same error message again and again, and finally an emergency mode shell prompt.
Unfortunately I didn’t noted any details because I run out of time. So I retried today with the current branch. It it helps I can try to find the branch with the latter behaviour.
I'm not sure what you mean by branches in this context.
Hi,
Am 14.10.2022 um 08:54 schrieb Peter Robinson pbrobinson@gmail.com:
On Wed, Oct 12, 2022 at 6:14 PM Peter Robinson pbrobinson@gmail.com wrote:
Peter,
Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the kernel command line and see if that works for you?
So I'm pretty sure this is now fixed with kernel 5.19.15-301.fc37 or 5.19.15-201.fc36 so if you could give it a test that would be fab. It should be stable into F-37 RSN but you could also deploy a default F-36 image and update to the F-36 kernel as I think you said F-36 GA worked.
sorry for the delay, there was so much to do …
Kernel 5.19.15-201.fc36 works superb. Everything I tested works without any issue on my nanopc-t4, including the NVMe board.
Unfortunately, I couldn’t fetch a suitable image for f37, yet.
Branch 20221017 includes an older kernel, the rawhide build of today failed (https://koji.fedoraproject.org/koji/taskinfo?taskID=93172623), and rc 1.1 includes an even older kernel.
I continue to track the new builds.
Thanks Peter
On Tue, Oct 18, 2022 at 11:31 AM Peter Boy pboy@uni-bremen.de wrote:
Hi,
Am 14.10.2022 um 08:54 schrieb Peter Robinson pbrobinson@gmail.com:
On Wed, Oct 12, 2022 at 6:14 PM Peter Robinson pbrobinson@gmail.com wrote:
Peter,
Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the kernel command line and see if that works for you?
So I'm pretty sure this is now fixed with kernel 5.19.15-301.fc37 or 5.19.15-201.fc36 so if you could give it a test that would be fab. It should be stable into F-37 RSN but you could also deploy a default F-36 image and update to the F-36 kernel as I think you said F-36 GA worked.
sorry for the delay, there was so much to do …
Kernel 5.19.15-201.fc36 works superb. Everything I tested works without any issue on my nanopc-t4, including the NVMe board.
Unfortunately, I couldn’t fetch a suitable image for f37, yet.
Branch 20221017 includes an older kernel, the rawhide build of today failed (https://koji.fedoraproject.org/koji/taskinfo?taskID=93172623), and rc 1.1 includes an even older kernel.
RC 1.1 should have had the fixed kernel because it was a blocker.
Peter
On Tue, Oct 18, 2022 at 11:33 AM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Oct 18, 2022 at 11:31 AM Peter Boy pboy@uni-bremen.de wrote:
Hi,
Am 14.10.2022 um 08:54 schrieb Peter Robinson pbrobinson@gmail.com:
On Wed, Oct 12, 2022 at 6:14 PM Peter Robinson pbrobinson@gmail.com wrote:
Peter,
Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the kernel command line and see if that works for you?
So I'm pretty sure this is now fixed with kernel 5.19.15-301.fc37 or 5.19.15-201.fc36 so if you could give it a test that would be fab. It should be stable into F-37 RSN but you could also deploy a default F-36 image and update to the F-36 kernel as I think you said F-36 GA worked.
sorry for the delay, there was so much to do …
Kernel 5.19.15-201.fc36 works superb. Everything I tested works without any issue on my nanopc-t4, including the NVMe board.
Unfortunately, I couldn’t fetch a suitable image for f37, yet.
Branch 20221017 includes an older kernel, the rawhide build of today failed (https://koji.fedoraproject.org/koji/taskinfo?taskID=93172623), and rc 1.1 includes an even older kernel.
RC 1.1 should have had the fixed kernel because it was a blocker.
ah, no this is an issue https://pagure.io/releng/issue/11094
Am 18.10.2022 um 12:34 schrieb Peter Robinson pbrobinson@gmail.com:
On Tue, Oct 18, 2022 at 11:33 AM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Oct 18, 2022 at 11:31 AM Peter Boy pboy@uni-bremen.de wrote:
Hi,
Am 14.10.2022 um 08:54 schrieb Peter Robinson pbrobinson@gmail.com:
On Wed, Oct 12, 2022 at 6:14 PM Peter Robinson pbrobinson@gmail.com wrote:
Peter,
Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the kernel command line and see if that works for you?
So I'm pretty sure this is now fixed with kernel 5.19.15-301.fc37 or 5.19.15-201.fc36 so if you could give it a test that would be fab. It should be stable into F-37 RSN but you could also deploy a default F-36 image and update to the F-36 kernel as I think you said F-36 GA worked.
sorry for the delay, there was so much to do …
Kernel 5.19.15-201.fc36 works superb. Everything I tested works without any issue on my nanopc-t4, including the NVMe board.
Unfortunately, I couldn’t fetch a suitable image for f37, yet.
Branch 20221017 includes an older kernel, the rawhide build of today failed (https://koji.fedoraproject.org/koji/taskinfo?taskID=93172623), and rc 1.1 includes an even older kernel.
RC 1.1 should have had the fixed kernel because it was a blocker.
ah, no this is an issue https://pagure.io/releng/issue/11094
I see, so there is hope, we get a rc1.2 soon.
I just tested rc 1.2 / kernel 5.19.15.301.fc37 with NanoPC-t4. The system bootet without any issue now, with and without NVMe storage installed. Same is true with Radxa Rock Pi 4 with Armbian boot based SPI firmware.
Peter
Am 18.10.2022 um 12:47 schrieb Peter Boy pboy@uni-bremen.de:
Am 18.10.2022 um 12:34 schrieb Peter Robinson pbrobinson@gmail.com:
On Tue, Oct 18, 2022 at 11:33 AM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Oct 18, 2022 at 11:31 AM Peter Boy pboy@uni-bremen.de wrote:
Hi,
Am 14.10.2022 um 08:54 schrieb Peter Robinson pbrobinson@gmail.com:
On Wed, Oct 12, 2022 at 6:14 PM Peter Robinson pbrobinson@gmail.com wrote:
Peter,
Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the kernel command line and see if that works for you?
So I'm pretty sure this is now fixed with kernel 5.19.15-301.fc37 or 5.19.15-201.fc36 so if you could give it a test that would be fab. It should be stable into F-37 RSN but you could also deploy a default F-36 image and update to the F-36 kernel as I think you said F-36 GA worked.
sorry for the delay, there was so much to do …
Kernel 5.19.15-201.fc36 works superb. Everything I tested works without any issue on my nanopc-t4, including the NVMe board.
Unfortunately, I couldn’t fetch a suitable image for f37, yet.
Branch 20221017 includes an older kernel, the rawhide build of today failed (https://koji.fedoraproject.org/koji/taskinfo?taskID=93172623), and rc 1.1 includes an even older kernel.
RC 1.1 should have had the fixed kernel because it was a blocker.
ah, no this is an issue https://pagure.io/releng/issue/11094
I see, so there is hope, we get a rc1.2 soon.
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-
Peter Boy -
Peter Robinson