4:37 a.m.
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.
5:05 a.m.
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(a)lists.fedoraproject.org
> To unsubscribe send an email to arm-leave(a)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
7:58 a.m.
Am 04.09.2022 um 12:05 schrieb Peter Robinson
<pbrobinson(a)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
12:57 p.m.
>> 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
3:07 p.m.
Am 04.09.2022 um 19:57 schrieb Peter Robinson
<pbrobinson(a)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
4:21 p.m.
>> 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
4:54 p.m.
Am 04.09.2022 um 23:21 schrieb Peter Robinson
<pbrobinson(a)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
2:24 a.m.
> 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-...
[2]
https://forum.armbian.com/topic/21024-rock-pi-4-does-armbian-build-their-...
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2124127
[4]
https://forum.armbian.com/topic/16195-booting-rock-pi-4abc-with-mainline-...
8:33 a.m.
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(a)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.
2:28 a.m.
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
5:36 a.m.
On Mon, Sep 5, 2022 at 8:28 AM Peter Boy <pboy(a)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.
602
days inactive
605
days old
10 comments
2 participants
participants (2)
-
Peter Boy -
Peter Robinson