Sorry for being way too short in my email.
Am 28.10.2023 um 14:41 schrieb Peter Robinson
<pbrobinson(a)gmail.com>:
> 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_...)
it was kind of dealt with as a variant of
https://bugzilla.redhat.com/show_bug.cgi?id=2244305
See Adam:
[20:44:38] <adamw> #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
PBoy(a)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