Yesterday I (re-)installed my Rock Pi4 with F36 and then did an update.
During the update there showed up various messages listed below. Afterwards the system didn’t boot anymore.
Last messages on screen:
Started Plymouth-start.ser?e - Show Plymouth Boot Screen Started systems-ask-passw*uests to Plymouth Directory Watch. Reached target paths.target - Path Units. Reached target basic.target - Basic System.
Then nothing happened anymore.
One question is, how to fix it.
The other question is how can such a disaster happen? With an item that is offered for download on the Fedora Server page, something like this should not happen.
Update messages
Updating: selinux-policy-36.14-1.fc36.noarch 240/670 Scriptlet: selinux-policy-36.14-1.fc36.noarch 240/670 Updating: selinux-policy-targeted-36.14-1.fc36.noarch 241/670 Scriptlet: selinux-policy-targeted-36.14-1.fc36.noarch 241/670 uavc: op=load_policy lsm=selinux seqno=2 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14
Scriptlet: container-selinux-2:2.188.0-1.fc36.noarch 242/670 Updating: container-selinux-2:2.188.0-1.fc36.noarch 242/670 Scriptlet: container-selinux-2:2.188.0-1.fc36.noarch 242/670 uavc: op=load_policy lsm=selinux seqno=3 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Updating: containers-common-4:1-59.fc36.noarch 243/670 Scriptlet: freeipa-selinux-4.9.10-4.fc36.noarch 244/670
Updating: freeipa-selinux-4.9.10-4.fc36.noarch 244/670 Ausgeführtes Scriptlet: freeipa-selinux-4.9.10-4.fc36.noarch 244/670 uavc: op=load_policy lsm=selinux seqno=4 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Updating: freeipa-common-4.9.10-4.fc36.noarch 246/670 Scriptlet: smartmontools-selinux-1:7.3-2.fc36.noarch 246/670 uavc: op=load_policy lsm=selinux seqno=5 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Updating: krb5-pkinit-1.19.2-11.fc36.aarch64 247/670 Updating: krb5-workstation-1.19.2-11.fc36.aarch64 248/670 ... Updating: cockpit-ws-275-1.fc36.aarch64 251/670 Scriptlet: cockpit-ws-275-1.fc36.aarch64 251/670 uavc: op=load_policy lsm=selinux seqno=6 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 … Updating: nss-3.81.0-1.fc36.aarch64 253/670 Scriptlet: nss-3.81.0-1.fc36.aarch64 253/670 Updating: certmonger-0.79.15-3.fc36.aarch64 254/670 Scriptlet: certmonger-0.79.15-3.fc36.aarch64 254/670 No CA with name "certmaster" found.
Updating: libblockdev-crypto-2.27-1.fc36.aarch64 255/670 ... Scriptlet: certmonger-0.79.15-2.fc36.aarch64 351/670 Scriptlet: nfs-utils-1:2.6.1-0.rc3.fc36.aarch64 352/670 Clean up : nfs-utils-1:2.6.1-0.rc3.fc36.aarch64 352/670 Scriptlet: nfs-utils-1:2.6.1-0.rc3.fc36.aarch64 352/670 Not supported unit type
Clean Up : sssd-tools-2.7.0-1.fc36.aarch64 353/670 Scriptlet: sssd-kcm-2.7.0-1.fc36.aarch64 354/670
Updating: nss-3.81.0-1.fc36.aarch64 253/670 Scriptlet: nss-3.81.0-1.fc36.aarch64 253/670 Updating: certmonger-0.79.15-3.fc36.aarch64 254/670 Scriptlet: certmonger-0.79.15-3.fc36.aarch64 254/670 No CA with name "certmaster" found.
Yesterday I (re-)installed my Rock Pi4 with F36 and then did an update.
During the update there showed up various messages listed below. Afterwards the system didn’t boot anymore.
Last messages on screen:
Started Plymouth-start.ser?e - Show Plymouth Boot Screen Started systems-ask-passw*uests to Plymouth Directory Watch. Reached target paths.target - Path Units. Reached target basic.target - Basic System.
What were the messages before that, there could well be a lot of other things that happen in the boot process prior to that that causes it to stop there.
Then nothing happened anymore.
Does it just hang there? Does it eventually drop you to an emergency shell?
One question is, how to fix it.
Hard tell tell. Can you start by selecting the previous booting kernel from the grub2 menu and see if that works. Debugging problems on arm is no different to debugging on x86.
The other question is how can such a disaster happen? With an item that is offered for download on the Fedora Server page, something like this should not happen.
Fedora is a complex system of software with a lot of moving parts and a lot of updates frrom F-36 GA -> latest updates.
Update messages
Updating: selinux-policy-36.14-1.fc36.noarch 240/670
You've included a very small part of the update, it shows there's 670 update transactions happening, you've included a random selection between 240-248, then 251-255 then to 351-354 and then back to the 250s. Why this selection? I'm guessing in here there's at least a new kernel. What was the previously booting kernel and what was the one you were trying to boot?
Scriptlet: selinux-policy-36.14-1.fc36.noarch 240/670 Updating: selinux-policy-targeted-36.14-1.fc36.noarch 241/670 Scriptlet: selinux-policy-targeted-36.14-1.fc36.noarch 241/670 uavc: op=load_policy lsm=selinux seqno=2 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14
Scriptlet: container-selinux-2:2.188.0-1.fc36.noarch 242/670 Updating: container-selinux-2:2.188.0-1.fc36.noarch 242/670 Scriptlet: container-selinux-2:2.188.0-1.fc36.noarch 242/670 uavc: op=load_policy lsm=selinux seqno=3 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Updating: containers-common-4:1-59.fc36.noarch 243/670 Scriptlet: freeipa-selinux-4.9.10-4.fc36.noarch 244/670
Updating: freeipa-selinux-4.9.10-4.fc36.noarch 244/670 Ausgeführtes Scriptlet: freeipa-selinux-4.9.10-4.fc36.noarch 244/670 uavc: op=load_policy lsm=selinux seqno=4 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Updating: freeipa-common-4.9.10-4.fc36.noarch 246/670 Scriptlet: smartmontools-selinux-1:7.3-2.fc36.noarch 246/670 uavc: op=load_policy lsm=selinux seqno=5 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Updating: krb5-pkinit-1.19.2-11.fc36.aarch64 247/670 Updating: krb5-workstation-1.19.2-11.fc36.aarch64 248/670 ... Updating: cockpit-ws-275-1.fc36.aarch64 251/670 Scriptlet: cockpit-ws-275-1.fc36.aarch64 251/670 uavc: op=load_policy lsm=selinux seqno=6 res=1Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 … Updating: nss-3.81.0-1.fc36.aarch64 253/670 Scriptlet: nss-3.81.0-1.fc36.aarch64 253/670 Updating: certmonger-0.79.15-3.fc36.aarch64 254/670 Scriptlet: certmonger-0.79.15-3.fc36.aarch64 254/670 No CA with name "certmaster" found.
Updating: libblockdev-crypto-2.27-1.fc36.aarch64 255/670 ... Scriptlet: certmonger-0.79.15-2.fc36.aarch64 351/670 Scriptlet: nfs-utils-1:2.6.1-0.rc3.fc36.aarch64 352/670 Clean up : nfs-utils-1:2.6.1-0.rc3.fc36.aarch64 352/670 Scriptlet: nfs-utils-1:2.6.1-0.rc3.fc36.aarch64 352/670 Not supported unit type
Clean Up : sssd-tools-2.7.0-1.fc36.aarch64 353/670 Scriptlet: sssd-kcm-2.7.0-1.fc36.aarch64 354/670
Updating: nss-3.81.0-1.fc36.aarch64 253/670 Scriptlet: nss-3.81.0-1.fc36.aarch64 253/670 Updating: certmonger-0.79.15-3.fc36.aarch64 254/670 Scriptlet: certmonger-0.79.15-3.fc36.aarch64 254/670 No CA with name "certmaster" found.
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
Am 04.09.2022 um 12:05 schrieb Peter Robinson pbrobinson@gmail.com:
Yesterday I (re-)installed my Rock Pi4 with F36 and then did an update.
During the update there showed up various messages listed below. Afterwards the system didn’t boot anymore.
Last messages on screen:
Started Plymouth-start.ser?e - Show Plymouth Boot Screen Started systems-ask-passw*uests to Plymouth Directory Watch. Reached target paths.target - Path Units. Reached target basic.target - Basic System.
What were the messages before that, there could well be a lot of other things that happen in the boot process prior to that that causes it to stop there.
Before that I got the EFI screen and could select a kernel, but the keyboard is not initialised so the system does respond to the cursor keys at all. Kernel: 15.19.6-200.fc36 default selection and obviously installed by update 15.17.5-300.fc36 I guess the kernel install by installation image
It follows the message in 1 line Booting ‚Fedora Linux (5.19.6-200.fc36.aarch64) 36 (Server Edition)‘
Displays several seconds, then a screen refresh and just the 4 lines
Then nothing happened anymore.
Does it just hang there? Does it eventually drop you to an emergency shell?
Just hanging there, no emergency shell, unfortunately.
1 time (out of several tries) I got additional output:
10.951731. Unable zu handle kernel execute from non-executable memory at virtual address (16 x 0)
and 27 lines of messages. I was able to take a picture with my phone which I am happy to send you if if helps.
One question is, how to fix it.
Hard tell tell. Can you start by selecting the previous booting kernel from the grub2 menu and see if that works. Debugging problems on arm is no different to debugging on x86.
For my case here it was a fresh installation, so there is no loss of data (though of course I'd like it up and running so I can use it productively. It runs my server monitoring software). But I think it is urgent to find the cause and fix it, before other users may be severely impaired.
The other question is how can such a disaster happen? With an item that is offered for download on the Fedora Server page, something like this should not happen.
Fedora is a complex system of software with a lot of moving parts and a lot of updates frrom F-36 GA -> latest updates.
Yes, indeed. But we managed for years now to find such issues before we published an update - at least as far as I remember the updates of all our servers.
Update messages
Updating: selinux-policy-36.14-1.fc36.noarch 240/670
You've included a very small part of the update, it shows there's 670 update transactions happening, you've included a random selection between 240-248, then 251-255 then to 351-354 and then back to the 250s. Why this selection? I'm guessing in here there's at least a new kernel. What was the previously booting kernel and what was the one you were trying to boot?
I selected all item with an „unusual“ message expecting one of those being the culprit. But obviously, it is the kernel.
I can attach the m2 board to another machine and try to reconfigure grub to use the old kernel, if that helps.
Best Peter
Yesterday I (re-)installed my Rock Pi4 with F36 and then did an update.
During the update there showed up various messages listed below. Afterwards the system didn’t boot anymore.
Last messages on screen:
Started Plymouth-start.ser?e - Show Plymouth Boot Screen Started systems-ask-passw*uests to Plymouth Directory Watch. Reached target paths.target - Path Units. Reached target basic.target - Basic System.
What were the messages before that, there could well be a lot of other things that happen in the boot process prior to that that causes it to stop there.
Before that I got the EFI screen and could select a kernel, but the keyboard is not initialised so the system does respond to the cursor keys at all.
Is it the firmware shipped by Fedora or does it come from elsewhere? Which model of Rock Pi 4 is it? Do you get all the early display output? What device is the firmware running off? A cheap USB TTL is often useful although I've send patches upstream for numerous devices to fix things like keyboard/display.
Kernel: 15.19.6-200.fc36 default selection and obviously installed by update 15.17.5-300.fc36 I guess the kernel install by installation image
It follows the message in 1 line Booting ‚Fedora Linux (5.19.6-200.fc36.aarch64) 36 (Server Edition)‘
Displays several seconds, then a screen refresh and just the 4 lines
By "displays several seconds" do you mean kernel output or something else?
Then nothing happened anymore.
Does it just hang there? Does it eventually drop you to an emergency shell?
Just hanging there, no emergency shell, unfortunately.
I've tried two
1 time (out of several tries) I got additional output:
10.951731. Unable zu handle kernel execute from non-executable memory at virtual address (16 x 0)
and 27 lines of messages. I was able to take a picture with my phone which I am happy to send you if if helps.
One question is, how to fix it.
Hard tell tell. Can you start by selecting the previous booting kernel from the grub2 menu and see if that works. Debugging problems on arm is no different to debugging on x86.
For my case here it was a fresh installation, so there is no loss of data (though of course I'd like it up and running so I can use it productively. It runs my server monitoring software). But I think it is urgent to find the cause and fix it, before other users may be severely impaired.
The other question is how can such a disaster happen? With an item that is offered for download on the Fedora Server page, something like this should not happen.
Fedora is a complex system of software with a lot of moving parts and a lot of updates frrom F-36 GA -> latest updates.
Yes, indeed. But we managed for years now to find such issues before we published an update - at least as far as I remember the updates of all our servers.
Update messages
Updating: selinux-policy-36.14-1.fc36.noarch 240/670
You've included a very small part of the update, it shows there's 670 update transactions happening, you've included a random selection between 240-248, then 251-255 then to 351-354 and then back to the 250s. Why this selection? I'm guessing in here there's at least a new kernel. What was the previously booting kernel and what was the one you were trying to boot?
I selected all item with an „unusual“ message expecting one of those being the culprit. But obviously, it is the kernel.
I can attach the m2 board to another machine and try to reconfigure grub to use the old kernel, if that helps.
So you're running it off a NVME card?
I've tested my Pinebook Pro which has a NVME in it and is a rk399 device and it's booting OK with the latest 5.19.6 F-37 kernel.
Peter
Am 04.09.2022 um 19:57 schrieb Peter Robinson pbrobinson@gmail.com:
Yesterday I (re-)installed my Rock Pi4 with F36 and then did an update.
During the update there showed up various messages listed below. Afterwards the system didn’t boot anymore.
Last messages on screen:
Started Plymouth-start.ser?e - Show Plymouth Boot Screen Started systems-ask-passw*uests to Plymouth Directory Watch. Reached target paths.target - Path Units. Reached target basic.target - Basic System.
What were the messages before that, there could well be a lot of other things that happen in the boot process prior to that that causes it to stop there.
Before that I got the EFI screen and could select a kernel, but the keyboard is not initialised so the system does respond to the cursor keys at all.
Is it the firmware shipped by Fedora or does it come from elsewhere?
Fedora doesn’t include a spi Version, so I used spi firmware from Armbian late 2020, which is according to Arabian docu mainline U-Boot. And everything worked since then.
But when the kernel issue arises, the system is already running from NVMe device, isn’t it?
Everything else is plain Fedora. I used arm-installer to copy everything to NVMe instead of SD.
Which model of Rock Pi 4 is it?
It is the Rock Pi 4a (without wifi), Board revision 1.4 which is the first revision with a soldered SPI module.
Do you get all the early displayoutput?
I get after the update the same output as with the installation kernel. That is the EFI selection screen, the the display goes blank so some seconds, then the online message in the first line „BootingFedora …, then the display goes blank again for some seconds, and the output as I wrote in my previous mail. The keyboard is with both kernels not operational when the EDI screen is displayed.
What device is the firmware running off? A cheap USB TTL is often useful although I've send patches upstream for numerous devices to fix things like keyboard/display.
I have different NVMes: Crucial, WD, transcend. The problem comes up with any of them.
I just installed the F36 distributable on another NVMe and updated just the kernel, with the same result, but a slightly different output:
Started plymouth-start.serie - Show Plymouth Boot Screen. Started systemd-ask-passwouuuwsts to Plymouth Directory Watch Readched target paths.target - Path Units. Readched target basic.target - Basic system 20.038088] dracut-initqueue[462]: Configuration node devices/filter not found 20.089369] dracut-initqueue[465]: Configuration node devices/global_filter not found 20.190685] dracut-initqueue[470]: WARNING: File locking is disabled. Found device dev-mapper-fe... - /dev/mapper/fedora_fedora-root. Reached target initrd-root...e.target - Initrd Root Dewvice.
I think I will install it again and exclude the kernel from update and see what happens.
Kernel: 15.19.6-200.fc36 default selection and obviously installed by update 15.17.5-300.fc36 I guess the kernel install by installation image
It follows the message in 1 line Booting ‚Fedora Linux (5.19.6-200.fc36.aarch64) 36 (Server Edition)‘
Displays several seconds, then a screen refresh and just the 4 lines
By "displays several seconds" do you mean kernel output or something else?
After the Line Booting Fedora Linux, the display goes blank for some seconds (no sync according to the display LED) and said lines are displayed.
Then nothing happened anymore.
Does it just hang there? Does it eventually drop you to an emergency shell?
Just hanging there, no emergency shell, unfortunately.
I've tried two
1 time (out of several tries) I got additional output:
10.951731. Unable zu handle kernel execute from non-executable memory at virtual address (16 x 0)
and 27 lines of messages. I was able to take a picture with my phone which I am happy to send you if if helps.
One question is, how to fix it.
Hard tell tell. Can you start by selecting the previous booting kernel from the grub2 menu and see if that works. Debugging problems on arm is no different to debugging on x86.
For my case here it was a fresh installation, so there is no loss of data (though of course I'd like it up and running so I can use it productively. It runs my server monitoring software). But I think it is urgent to find the cause and fix it, before other users may be severely impaired.
The other question is how can such a disaster happen? With an item that is offered for download on the Fedora Server page, something like this should not happen.
Fedora is a complex system of software with a lot of moving parts and a lot of updates frrom F-36 GA -> latest updates.
Yes, indeed. But we managed for years now to find such issues before we published an update - at least as far as I remember the updates of all our servers.
Update messages
Updating: selinux-policy-36.14-1.fc36.noarch 240/670
You've included a very small part of the update, it shows there's 670 update transactions happening, you've included a random selection between 240-248, then 251-255 then to 351-354 and then back to the 250s. Why this selection? I'm guessing in here there's at least a new kernel. What was the previously booting kernel and what was the one you were trying to boot?
I selected all item with an „unusual“ message expecting one of those being the culprit. But obviously, it is the kernel.
I can attach the m2 board to another machine and try to reconfigure grub to use the old kernel, if that helps.
So you're running it off a NVME card?
Yes, with the Armbian SPI as described above
I've tested my Pinebook Pro which has a NVME in it and is a rk399 device and it's booting OK with the latest 5.19.6 F-37 kernel.
That's good, So it is hopefully „just“ a problem with Rock Pi and not with a lot of other models, too.
Peter
Before that I got the EFI screen and could select a kernel, but the keyboard is not initialised so the system does respond to the cursor keys at all.
Is it the firmware shipped by Fedora or does it come from elsewhere?
Fedora doesn’t include a spi Version, so I used spi firmware from Armbian late 2020, which is according to Arabian docu mainline U-Boot. And everything worked since then.
So Fedora doesn't include a SPI version of it because neither of the Rock Pi 4 devices, rock-pi-4-rk3399 and rock-pi-4c-rk3399, have support for SPI in upstream U-Boot even with upstream master ATM. I have neither of those devices so I can't test any patches I could do to be able to send that support upstream.
But when the kernel issue arises, the system is already running from NVMe device, isn’t it?
It could be because something had changed in the firmware and the kernel isn't powering up a regulator that is needed by PCI or similar that was previously powered up by firmware.
Which model of Rock Pi 4 is it?
It is the Rock Pi 4a (without wifi), Board revision 1.4 which is the first revision with a soldered SPI module.
Do you get all the early displayoutput?
I get after the update the same output as with the installation kernel. That is the EFI selection screen, the the display goes blank so some seconds, then the online message in the first line „BootingFedora …, then the display goes blank again for some seconds, and the output as I wrote in my previous mail. The keyboard is with both kernels not operational when the EDI screen is displayed.
So you get output from U-Boot before you get a grub menu? If so what version string does the Armbian firmware return?
I may have found something, but I'm still bisecting some pieces down.
Peter
Am 04.09.2022 um 23:21 schrieb Peter Robinson pbrobinson@gmail.com:
Before that I got the EFI screen and could select a kernel, but the keyboard is not initialised so the system does respond to the cursor keys at all.
Is it the firmware shipped by Fedora or does it come from elsewhere?
Fedora doesn’t include a spi Version, so I used spi firmware from Armbian late 2020, which is according to Arabian docu mainline U-Boot. And everything worked since then.
So Fedora doesn't include a SPI version of it because neither of the Rock Pi 4 devices, rock-pi-4-rk3399 and rock-pi-4c-rk3399, have support for SPI in upstream U-Boot even with upstream master ATM. I have neither of those devices so I can't test any patches I could do to be able to send that support upstream.
So the Armbian docu pretends something that doesn’t exist - not nice.
But when the kernel issue arises, the system is already running from NVMe device, isn’t it?
It could be because something had changed in the firmware and the kernel isn't powering up a regulator that is needed by PCI or similar that was previously powered up by firmware.
Which model of Rock Pi 4 is it?
It is the Rock Pi 4a (without wifi), Board revision 1.4 which is the first revision with a soldered SPI module.
Do you get all the early displayoutput?
I get after the update the same output as with the installation kernel. That is the EFI selection screen, the the display goes blank so some seconds, then the online message in the first line „BootingFedora …, then the display goes blank again for some seconds, and the output as I wrote in my previous mail. The keyboard is with both kernels not operational when the EDI screen is displayed.
So you get output from U-Boot before you get a grub menu? If so what version string does the Armbian firmware return?
It says: U-Boot 2020.10 - Armbian May 06 2011
I may have found something, but I'm still bisecting some pieces down.
Gives ma hope.
Peter
So Fedora doesn't include a SPI version of it because neither of the Rock Pi 4 devices, rock-pi-4-rk3399 and rock-pi-4c-rk3399, have support for SPI in upstream U-Boot even with upstream master ATM. I have neither of those devices so I can't test any patches I could do to be able to send that support upstream.
So the Armbian docu pretends something that doesn’t exist - not nice.
So looking at this post I don't believe they claim to not be using patches, looking at the following forum post [1] I read it as basing their builds on the upstream code vs basing it on the Raxda vendor fork, which I suspect is based on Rockchip's ancient vendor fork, so it's nuanced but not necessarily incorrect. Also when trying to find their source I find this message which is more troubling [2].
So you get output from U-Boot before you get a grub menu? If so what version string does the Armbian firmware return?
It says: U-Boot 2020.10 - Armbian May 06 2011
I may have found something, but I'm still bisecting some pieces down.
Gives ma hope.
So the thing that I've found is a regression in U-Boot between 2022.07 rc5 and rc6 for the devices I've seen the issue on. I've filed a bug [3] so for the Fedora builds we can do a blocker but I don't know if your build would have that patch pulled in or not so it's hard to tell but I've no been able to find the Armbian source for their U-Boot builds, see [2]. If you could find their sources/patches it would be useful there.
Looking at [4] it seems they at least patch the configs which indicates they do more. Also from that post the RockPi4 has XTX SPI flash so it might not be hard for me to create a patch for upstream to support it but without one of these boards the round trips of remote low level debug of boot issues with firmware is probably too time consuming for me to do at the moment.
Peter
[1] https://forum.armbian.com/topic/16195-booting-rock-pi-4abc-with-mainline-u-b... [2] https://forum.armbian.com/topic/21024-rock-pi-4-does-armbian-build-their-own... [3] https://bugzilla.redhat.com/show_bug.cgi?id=2124127 [4] https://forum.armbian.com/topic/16195-booting-rock-pi-4abc-with-mainline-u-b...
Sorry for the late reply, due to a spacious and long lasting Internet breakdown here.
Am 05.09.2022 um 09:24 schrieb Peter Robinson pbrobinson@gmail.com:
...
it's nuanced but not necessarily incorrect. Also when trying to find their source I find this message which is more troubling [2].
That sounds not like plain mainline, indeed.
So you get output from U-Boot before you get a grub menu? If so what version string does the Armbian firmware return?
It says: U-Boot 2020.10 - Armbian May 06 2011
I may have found something, but I'm still bisecting some pieces down.
Gives ma hope.
Looking at [4] it seems they at least patch the configs which indicates they do more. Also from that post the RockPi4 has XTX SPI flash so it might not be hard for me to create a patch for upstream to support it but without one of these boards the round trips of remote low level debug of boot issues with firmware is probably too time consuming for me to do at the moment.
I found this table: https://wiki.radxa.com/Rockpi4/hardware/models
So, their new ‚plus‘ model to produced until 2029 will not include a SPI, not even as an option to solder it yourself. Instead, it includes an eMMC module by default.
So I suppose, SPI is a dead end for RockPi and it is not useful to spend too much effort into it. Instead, it makes sense to focus on an eMMC boot drive or alternatively boot the older models from SD and then mount the root file system from NVMe. I will adjust our server documentation accordingly.
[1] https://forum.armbian.com/topic/16195-booting-rock-pi-4abc-with-mainline-u-b... [2] https://forum.armbian.com/topic/21024-rock-pi-4-does-armbian-build-their-own... [3] https://bugzilla.redhat.com/show_bug.cgi?id=2124127 [4] https://forum.armbian.com/topic/16195-booting-rock-pi-4abc-with-mainline-u-b...
Just as an addition: I made an update with kernel excluded and everything went fine. All the update issues I reported seem to be related to the kernel.
There is on exception: certmonger, issues a message: „No CA with name „certmaster“ found.
By the way, there are a lot of differences in installed packages between the SBC image and Fedora Server Installation DVD for x86 that are probably not architecture or hardware specific. For example, the image installs flatpack items that we don't really want on Fedora Server.
Peter
On Mon, Sep 5, 2022 at 8:28 AM Peter Boy pboy@uni-bremen.de wrote:
Just as an addition: I made an update with kernel excluded and everything went fine. All the update issues I reported seem to be related to the kernel.
There is on exception: certmonger, issues a message: „No CA with name „certmaster“ found.
That should be reported to the component as per normal process.
By the way, there are a lot of differences in installed packages between the SBC image and Fedora Server Installation DVD for x86 that are probably not architecture or hardware specific. For example, the image installs flatpack items that we don't really want on Fedora Server.
That should be taken to the Server SIG.
-
Peter Boy -
Peter Robinson