Raptor Computing Systems Community Forums (BETA)
Software => Operating Systems and Porting => Topic started by: tle on October 31, 2024, 11:09:34 pm
-
"Fedora 41 features a number of package updates like going to LLVM 19, LXQt 2.0, Python 3.13, DNF5, RPM 4.20, PyTorch 2.4, AMD ROCm 6.2, GIMP 3.0 (near final form), replacing Redis with Valkey, and many others. Fedora 41 also features interesting features like self-encrypting drives support within the Anaconda installer, Intel IPU6 camera support for newer Intel Core laptops, Wayland-only GNOME Workstation media, NVIDIA driver support on Secure Boot systems, the new fedora-repoquery tool, a new alternative spin for Fedora Miracle, and more."
More details on changeset could be found at https://fedoraproject.org/wiki/Releases/41/ChangeSet
It's yet another great version from Fedora. Everything runs as expected for PPC64LE arch
-
I upgraded to 41 and boom, after having installed everything correctly, when booting from petit boot it tells me an initrd error and Fedora doesn't start anymore... It's incredible how an upgrade can actually break everything, it's never happened to me with anything. But unfortunately you have to expect anything from Fedora, luckily I switched to Debian a long time ago as my first choice because honestly Fedora always disappoints me, every time I use it it always has a thousand problems and now it's even completely broken after the upgrade, a real disgrace with all due respect!
-
I look forward to the upgrade, pending any weird issues that crop up. I may defer to ClassicHasClass's probable writeup before taking the plunge.
-
Guys I confirm that currently Fedora 41, at least as far as I'm concerned, has a large system bug that does not even allow the start. After updating mine and lost it, I reformed everything and redo the installation from scratch. Well even by doing this, at the time of the start from Petit Boot, Initrd and end error does not start. So watch out for those who want to update ...
-
What exactly appears on screen? If you boot it from the BMC web interface, what appears on the virtual serial port output?
-
Exactly what I wrote in the previous two posts... From petit boot, you select a version of Fedora 41 with any Kernel that is installed and it immediately writes "INITRD error and does not boot... I'm sure that it is not a Kernel problem since it does it with any you use and I had installed 3 other Kernels in addition to the last one that until the previous use with Fedora 40 worked perfectly. The problem is at startup, at boot...
-
I can confirm MauryG5's issue. When trying to update from 40 to 41 via console it would not install due to a "watchman" issue. After being pestered via notifications to update I decided to give "Software" a shot at the update. It installed 41 but now NO version of Fedora will load. "Error loading initrd" is the error given. Even after rolling back via Timeshift I get the same error. On a side note that may be related, my openSUSE will start but is very slow and will not fill windows. For example if I open any file browser I get the window outline but it is filled with the desktop image and no radio gadgets.
-
Exactly, this time Fedora has outdone itself with a bug so big that it compromises the entire distro. I strongly advise you not to update because you will lose everything if you do not have another distro installed on another hard disk to be able to download all the files you may need... Be very careful!
-
What exactly appears on screen? If you boot it from the BMC web interface, what appears on the virtual serial port output?
[img/]https://ibb.co/mqy2ps8[/img]
-
Thanks for the screenshot. Can you enter the shell and inspect the system logs? Is only Fedora 41 initrd affected and F-40 would boot OK ? Is there a significant size difference between initrd sizes of F-40 and F-41?
-
All Fedora versions on sda and sdd as seen in the screen shot fault with initrd. Since that screen shot was taken I have used Timeshift on sdd to rollback to before the F41 install. Same results. I wiped out sda and installed F41 from scratch, same result. Then I tried to install F40 from scratch on sda. The results of this endeavor are in this screen shot.
(https://ibb.co/xfVBny3)
https://ibb.co/xfVBny3
I will try to get system logs later today.
-
On my T2 v/AMD graphics, I upgraded to F41 from the terminal in Gnome via the dnf plugin as described on the Fedora website.
After restarting, the screen went blank for more than five minutes, during which time the machine didn't show up on the network. From experience I knew not to restart. I played a game of chicken with myself regarding connecting to the BMC via ethernet, which I won.
Eventually the login manager appeared.
I don't know if this will help anyone else, but it was my experience. :D
-
Not sure why my pics don't post directly, but I can't seem to attach files either. I get this error.
"The upload folder is full. Please try a smaller file and/or contact an administrator."
My file is well under the limit.
-
On my T2 v/AMD graphics, I upgraded to F41 from the terminal in Gnome via the dnf plugin as described on the Fedora website.
After restarting, the screen went blank for more than five minutes, during which time the machine didn't show up on the network. From experience I knew not to restart. I played a game of chicken with myself regarding connecting to the BMC via ethernet, which I won.
Eventually the login manager appeared.
I don't know if this will help anyone else, but it was my experience. :D
That's typical and expected. You can tail the log by logging in as root on another VTY. I didn't get a chance to update the Blackbird yet, but I plan to do so no later than the Thanksgiving long weekend.
-
My upgrade from F-40 to F-41 on a bare metal IBM LC912 (aka Boston) went OK, no problems booting after the upgrade. But I spoke with a colleague today and he reminded me some old(er) issues that were related to grub.cfg not being compatible with the parser in petitboot or grub-mkconfig failing to run (depends on petitboot / firmware version). I think that's what we are seeing here. If that's true, then the fix should be to recreate grub.cfg.
-
My upgrade from F-40 to F-41 on a bare metal IBM LC912 (aka Boston) went OK, no problems booting after the upgrade. But I spoke with a colleague today and he reminded me some old(er) issues that were related to grub.cfg not being compatible with the parser in petitboot or grub-mkconfig failing to run (depends on petitboot / firmware version). I think that's what we are seeing here. If that's true, then the fix should be to recreate grub.cfg.
I agree in your assessment that it appears to be related to petitboot/grub.cfg. Is there a help page somewhere that shows the proper way to recreate grub.cfg?
-
It should be matter of running
grub2-mkconfig --output=/boot/grub2/grub.cfgfrom some kind of rescue environment, eg. after booting Fedora installer ISO with the rescue parameter. IIRC there are versions of petitboot that do not support BLS directly and versions that do support it. So knowing the details about the initrd load failure would be useful. The usual "make backups, etc." applies before doing any changes :-)
-
And the easiest thing should be to check how the boot entry looks like and possibly fix the errors from petitboot by using the "Edit" option.
-
All three hard drives/OS's have a different version of Grub2. All three are dated the same day I upgraded Fedora 40 to 41.
-
for the record, PowerNV aka bare metal systems only use the grub.cfg (or a config file from another bootloader), not the actual grub2 bootloader
-
From the Wiki (https://wiki.raptorcs.com/w/index.php?title=POWER9_Hardware_Compatibility_List/PCIe_Devices&oldid=4688#NVIDIA):
... If you're booting a 64KiB kernel, you may need to blacklist the Nouveau driver to prevent a kernel oops (observed in Fedora 41).
-
Does anybody know what this is?
None CALLOUT_DEVICE_PATH=/sys/devices/platform/gpio-fsi/fsi0/slave@00:00/raw
CALLOUT_ERRNO=0
_PID=25760
I have 200 of these events all logged on the morning of Nov. 5th.
-
Does anybody know what this is?
None CALLOUT_DEVICE_PATH=/sys/devices/platform/gpio-fsi/fsi0/slave@00:00/raw
CALLOUT_ERRNO=0
_PID=25760
I have 200 of these events all logged on the morning of Nov. 5th.
I wish I could help but this is too my first time seeing this kind of error
-
This Fedora 41 update has left me with a very expensive door stop. Somehow it changed something on the motherboard. I pulled all my hard drives out and started over with a freshly formatted drive only to get the same results. I don't really know where to go from here.
-
The FSI (https://wiki.raptorcs.com/wiki/FSI) is the communication bus between the CPU and BMC.
Maybe re-flashing the BMC firmware will fix it?
-
The FSI (https://wiki.raptorcs.com/wiki/FSI) is the communication bus between the CPU and BMC.
Maybe re-flashing the BMC firmware will fix it?
I have v2.3 installed and tried to update to v2.10 but the BMC/PNOR from RCS's website unpacks as v1.2 and will not "Activate"
https://ibb.co/NSKshRx
-
I couldn't get the web interface update to work either. It would always show an error when 'activating', even though the file is uploaded to /tmp.
I had to use the other method with the pflash program.
-
I see that the situation is getting worse and worse guys... I just disassembled the Fedora hard disk and that's it, I wouldn't want it to cause problems to other parts of the computer as I'm seeing happen to Markr87... In short, it's absurd that a distro should create all these problems all of a sudden, I was just finishing singing the praises for the return of Fedora on Power in a decent way and boom, more problems and bugs... Total disappointment, without taking into account that until recently Chromium for example, continued to crash in the same way...
-
As a contrary point, I've got F41 running fine on both the Blackbird and T2 here, and didn't have even many teething problems with the update. I wonder if a hardware glitch occurred at around the same time - Fedora doesn't do anything with the system firmware that I'm aware of. I agree with atomicdog that the pflash method is more reliable if you're concerned the BMC or PNOR firmware glitched.
-
Please advise me as to what I am doing wrong here.
https://ibb.co/gzQBvs8
-
The scp command needs the -o option.
Someone recently on this forum had that problem, it has something to do with new default settings in scp.
-
The scp command needs the -o option.
Someone recently on this forum had that problem, it has something to do with new default settings in scp.
Note: Uppercase -O, not lowercase -o. And I think it was this post:
the scp transfer worked after I added the option -O, I found that on a forum: "it an issue with OpenSSH client. Since OpenSSH 9.0, the client uses SFTP protocol by default. To use the legacy protocol, the -O option must be specified."
-
Thank you @atomicdog and jcsiblesei for the help. Yes it is an uppercase oh (O). My other operating systems are working again, sadly my original Fedora 40 is not booting still. The drive is not corrupted and is readable so I can get all my data off of it.
The thing I don't understand is pnor was still showing version 2.3. The only clue it had downgraded was the linux version had reverted to 4.19. To upgrade the pnor you have to ssh in from another computer and enter passwords, it then deletes the existing and writes the new version. How did upgrading from Fedora 40 to 41 change my pnor?
-
Chromium is running stably on the latest dnf update on my T2/AMD box. :D
-
I don't see how (or why) a Fedora install would change the pnor. There is a write protect switch on the motherboard that will prevent the BMC from writing to the FLASH chips.
-
I don't see how (or why) a Fedora install would change the pnor. There is a write protect switch on the motherboard that will prevent the BMC from writing to the FLASH chips.
it doesn't have a WP range by default so afaik flipping the dip switch as it is out of the box won't do anything..
-
Oh, so (after reading the datasheet) the FLASH chip hardware WP isn't enabled by default. It would need to be configured by the BMC or external programmer.
-
A PreRelease of Fedora 42 is available here:
https://kojipkgs.fedoraproject.org//packages/Fedora-KDE-Desktop-Live/42/20250302.n.0/images/Fedora-KDE-Desktop-Live-42-20250302.n.0.ppc64le.iso
-
Is it likely that I can jump from 40 to 42 without incident? I gave 41 a pass.
-
Probably, but it's always cleaner if you minimize the update delta. 41 has been working OK for me so far. That said, you could upgrade to 41 after 42 comes out, and then immediately upgrade to 42.
-
Fedora 42 is still a bit rough, the whole GCC15's new C23 has introduced quite a number of breaking changes / regressions in many softwares. I am still in the progress of going through all softwares that I am actually using to see if I could get them properly working before the final release day. I greatly welcome extra hands from the community in beta testing
-
Now I’ve been bitten by the gdm Xorg snafu in F41. Managed to squirm into Gnome Classic, switched the display manager to lightdm, rebooted, and the system now only lets me into the onboard video via Gnome Classic and Wayland. What’s the solution here? I’m about this close to just switching to RHEL 10 when it lands.
-
I realize this sounds like a non-solution, but the solution for me is to textboot and bring up X11 (or, if I'm feeling masochistic, Wayland) manually -- no display manager at all.
-
I realize this sounds like a non-solution, but the solution for me is to textboot and bring up X11 (or, if I'm feeling masochistic, Wayland) manually -- no display manager at all.
Honestly, that sounds fine. In days of yore (read: Slackware on x86) I'd just change the runlevel at boot; what's the approved methodology in systemd-land?
-
Point the symlink /etc/systemd/system/default.target to /lib/systemd/system/multi-user.target and reboot, and it should come up with a text console login. Log in, do a startx (assuming your .xinitrc is configured) and away you go.
-
Point the symlink /etc/systemd/system/default.target to /lib/systemd/system/multi-user.target and reboot, and it should come up with a text console login. Log in, do a startx (assuming your .xinitrc is configured) and away you go.
You are very nice. Thank you!