Sorry for being way too short in my email.
> Am 28.10.2023 um 14:41 schrieb Peter Robinson :
>
>> Just a question: Now, that the f39 release is delayed by a week, do we have
>> a chance of a fix for the server variant?
>
> I will en devour to fix it.
That would be really great. Currently F39 is unusable for Server at all.
>
>> For one thing, the problem of the failed mount of the image would have to be
>> fixed on the server variant. As far as I understand the arm installation
>> script, either something is wrong with the disk image or it has been changed
>> and that needs to be addressed in the script now.
>
> Is there a RHBZ for this? We would need it for blocker/FE process.
> From the reply from Adam on the thread there it's not clear what the
> exact problem is. Help as always is appreciated.
On the go/no-go meeting
(https://meetbot.fedoraproject.org/fedora-meeting/2023-10-26/f39-final-go_no_go-meeting.2023-10-26-17.00.log.html)
it was kind of dealt with as a variant of
https://bugzilla.redhat.com/show_bug.cgi?id=2244305
See Adam:
[20:44:38] #info we also discovered a bug in the
fedora-arm-image-installer script which means it will not write Server images
correctly. this can be corrected outside of the compose process
I described the issue in an earlier post:
> At the end of arm-installer you get a message:
>
> = Writing image complete!
> mount: /tmp/root: unknown filesystem type 'LVM2_member'.
> dmesg(1) may have more information after failed mount system call.
> sed: /tmp/fw/EFI/fedora/grubenv kann nicht gelesen werden: Datei oder
> Verzeichnis nicht gefunden
> = No U-Boot files found for rock-pi-4-rk3399.
>
> = Installation Complete! Insert into the rock-pi-4-rk3399 and boot.
The „sed issue“ is quite old, was never fixed but didn’t do any harm.
The mount issue is new. I had it here on my RockPi4, Pine64 RockPro and
LibreComputer Roc3399PC
The effect is, the device doesn’t boot at all, or at least I get no internet
connection. (Not surprising without u-boot files written to the image). With
f38 / f37 everything works fine with those boards and the same connection to
monitor/keyboard/ network
The don’t remember whether I got the message with mit RasPi, too, But, in any
case, the terminal went black short after the first bunch of boot messages, but
the internet connection and ssh worked.
The bad thing is, the Raspi is quite unimportant for Server. The other boards
are those Server can be meaningful used with. So, at the moment we are without
a distributable for SBC.
There is no specific bug report at the moment, as far as I know.
>
>> And furthermore it would be very helpful if the workaround for the black
>> screen could also be done transitionally with the script.
>
> I'm not sure what you mean here. Could you elaborate.
>
It’s bug https://bugzilla.redhat.com/show_bug.cgi?id=2241252 I suppose.
A nomedeset entry should fix that, at least for Rpi4. I don’t know how it will
impact or cure the other devices I mentioned above.
My question is, if you have to modify the arm-installer script, if you could
include the nomodeset fix temporary until the cause is fixed, to make it easier
for user.
I can do any testing, if it helps. I have even a serial cable for additional
debug messages (but never used it so far), just in case :-)
Thanks.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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
