Sorry for being way too short in my email. > Am 28.10.2023 um 14:41 schrieb Peter Robinson <pbrobinson@xxxxxxxxx>: > >> 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] <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@xxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
