Trying to install Fedora 35 KDE but it crashes

Have allocated over 50Gb on SSD, but automatic mode installation always crashes in the process.

Trying to dual boot with Win 10 UEFI.

This is not really a useful question. “It crashes” tells us nothing that we can use to help you determine what the problem is. I realize installation problems are particularly hard to track down because you can’t easily get logs of the process or capture screenshots or exact error messages, but at least tell us when it crashes, and what you did up until that point.

First step, you should look over Common F35 bugs - Fedora Project Wiki to see if your problem is listed there.

1 Like

Unfortunately, here’s the only item currently listed under “Installation issues” on that page, and it sounds like your issue is more serious than this:

When using a secondary keyboard layout in the installer, it frequently switches to the primary one

link to this item - Bugzilla: #2016613

This only affects the Workstation and KDE live images. If you boot one of these, run the installer, configure multiple keyboard layouts (or multiple layouts are automatically configured for the language you chose), and then switch to a secondary layout using the integrated layout switcher, the keyboard layout will switch back to the primary one whenever you press a modifier key (e.g. shift, alt or ctrl).

This isn’t usually a problem on Workstation, because there are few places where you are likely to use the secondary layout for typing characters. However, for KDE, it’s more likely, because user creation is available, and you might want to use the secondary layout to type the user’s real name.

One way to avoid dealing with the problem is just to not use modified characters from the secondary layout during installation; use some other character temporarily, then change it after installation.

If you do want to enter modified characters using the secondary layout during installation, you have two options. One is to select the primary layout, then hold down the modifier key and keep it held down while selecting the secondary layout; you can now type as many modified characters as you like until you release the modifier key (whereupon the primary layout will immediately become active again). Otherwise, you can log out from the live session, and on the login screen, select “Desktop Session: Plasma (X11)” (KDE) or “GNOME on X.org” (Workstation) at the very bottom of the login screen, and then login again as the “Live System User” (no password). With an X.org session, this bug will not occur.

Suppose if i wanted to, i could jot down the four or five lines of the error message.

It usually happens after about 10 min. of the installation process.
Unbelievable when you think that MX takes less than 5 min. to install.

Upon reboot in Windows, the partition manager shows two healthy partitions automatically created by Fedora on the unallocated space.

Maybe a manual installation would succeed but haven’t found sufficient info. online to do that for this Kinoite version.

Hope this helps:

Oh. You’re using Kinoite. You didn’t even mention that, initially. Fedora KDE is not necessarily Fedora Kinoite, as you can run a KDE-based Fedora without using the ostree-based system core that Kinoite is built on.

Since you are using Kinoite, I’ll refer you to the Installation docs Known Limitations section:

Known limitations

Kinoite does not provide a fully functional experience for dual booting or manual partitioning.

It is possible to make Kinoite work for both dual boot and manual partitioning, and some guidance is provided on manual partitioning below. However, there are hazards involved in both cases, and you should only attempt to use these features if you have done the necessary research, and are confident that you can overcome any issues that you might encounter.

Dual-booting with Kinoite (a brand-new release type for Fedora that just debuted last week with the Fedora 35 release) sounds like it may not be the best option right now. You may have better luck with the Fedora KDE Plasma Desktop Spin.

1 Like

@FeRDNYC - my bad Frank! :roll_eyes:

Thought it was just a new name for Fedora 35 akin to what Ubuntu does.

Thank you for your input and putting up with me.

So, off to Fedora KDE Plasma Desktop Spin we go!!

1 Like

Installing Fedora KDE spin went well.
Updating (2Gs?) did not.
After two attempts at updating (with reboots) and a third on the horizon… i gave up.
Maybe installing KDE via the Gnome version might go better?

For the record, according to DJ Ware, Silverblue Kinoite is not made for dual booting:

What could they do that would stop it from dual booting?
Does it want the whole disk to itself like Clear Linux?
Do they hide vmlinux and initrd so grub cant find them?

That is very unusual. I would like to know why or how?

2 Likes

Hi Mark,
If you want to try and debug it, you will need a lot of patience.
Install issues are difficult… it does not make a log of what it is doing, except on the screen.
Try and see where in the install runs into problems… sounds like it is right at thd end where it copies all the linux files onto your root filesystem.
Make sure you have things like uefi vs legacy boot sorted. Make sure you have made all the necessary partitions, and put the right filesystems on them. See if you can find out if it has any unusual requirements… there must be some install instructions.

Regards
Neville

2 Likes

It’s more that Kinoite (and Silverblue, and basically any other ostree-based distribution) isn’t capable of installing a dual-boot configuration.

If you could manage to get the OS fully installed and working on a system with other operating systems already in place, it would presumably be able to dual-boot just fine… but the installer invariably screws the pooch unless the system has been scrubbed clean of all remaining traces from any previously-installed OSes beforehand. (All the way down to having to reformat the EFI partition prior to starting the install, if you want it to not break.)

The installer’s fragility and intolerance for non-pristine systems is tracked as a known, still-open bug in various places. The main ones are probably:

https://bugzilla.redhat.com/show_bug.cgi?id=1575957

1 Like

That is exactly the same as Clear Linux.
So the problem is the Anaconda installer.
Only workaround I could imagine would be to avoid the installer and do an install with
Linux commands, like in Arch or Gentoo. That requires some knowledge.

Well, yes and no. Because, Anaconda is also used for installing non-ostree Fedora Workstation, and it can install dual boot configurations just fine there.

The install failures happen when Anaconda executes some ostree commands that are supposed to provision the new install; it appears that ostree has a lot of built in assumptions that non-pristine configurations break.

I dont understand what ostree is

I don’t either, really, but it’s the system underlying distros like Silverblue and Kinoite, which are Fedora’s immutable-system releases. Basically, in an ostree system, the entire OS filesystem is mounted readonly even at runtime, and changes (including package installs/upgrades) can only be made by an external administrative tool while the OS itself is in an offline state. That administrative tool is ostree.

But that’s the entirety of my knowledge about it.

It’s kind of how Apple provisions macOS in recent releases, AIUI, where there’s a readonly image of the system volume that never changes except when new OS updates are applied, and then the runtime filesystem is overlaid on top of that.

OK I get it thanks.
The Anaconda installer uses this ostree admin tool, and in some configurations it is not up to the task.
Sounds strange that a misbehaving admin tool would make it go off and interfere with other partitions in a multiboot setup. I thought that would be more a philosophy problem in designing the installer… but I accept your story, and I learnt something about readonly OS’s.

Oh, it doesn’t. The [ostree-based] linux installation just never succeeds, in those scenarios. Something about seeing the unexpected partitions breaks its fragile little mind. And with a system based on ostree, if you can’t run ostree to provision the system volume, you have no installation.

That is different to Clear Linux, then. It actually goes out and writes a new EFI system partition on your disk… bit like Windows. Thinks it owns the place.