How to diagnose Fedora 45 KDE live ISO not bootable from Ventoy

Ask Fedora
1

(Edit: I checked. The ISO does work when copied normally to a thumb drive, without Ventoy).

I had recently set up and tested two other ISOs on the same Ventoy media:

Fedora-KDE-Desktop-Live-44-1.7.x86_64

and

F44-KDE-x86_64-LIVE-20260731

I got each of those working both with and without Ventoy persistence. (Lots of subtle issues still unresolved by basically working). So I think at this point I’m confident of my Ventoy media and my use of it.

Then I tried:

Fedora-KDE-Desktop-Live-45-20260829

I tried that in many combinations: Ventoy’s “normal” mode in addition to its “grub2” mode (which I normally use). With and without Ventoy persistence. With and without disabling selinux (something I normally do). The failure is the same in all cases.

I could report what little I can observe. But I expect there are some basic actions I could take to capture better detail on what is failing. Do you have suggestions for what I might do to capture better information.

I have gotten to some limited kind of command prompt after some of the failures (I forget what I did to get there). I expect I could mount some writeable media and copy some logging from somewhere to there to examine on a healthier system (not sure I can and not sure of commands for trying). Suggestions appreciated.

Edit: I instantly forgot where I got the pre-release live-45 ISO from as soon as I had it (having found the link in some forum post that I also can’t find again). Google AI interferes with every attempt I made to find it again. Likely this is something other experienced Fedora users just know. But where to get pre-release ISO’s was surprisingly hard for me to find. So having found them again, I’m inserting this reminder here:

2

Please mention the ventoy version. I did try ventoy-1.1.17 and had a boot fail on an old iMac but haven’t had time to see if it will boot on newer systems.

3

It is ventoy-1.1.17; Since that version of ventoy successfully boots two different versions of F44-KDE-x86_64-LIVE on the same media and same hardware, I obviously don’t have any incompatibility of ventoy - hardware or ventoy - bios.

My question is about extracting diagnostic information from a failure of the live ISO to finish assembling the file system (before trying to bring up the GUI). The fact that I’m using ventoy is less likely to be relevant to the answer I hope to get on how to extract diagnostic info (than to the more distant answer of what is going wrong in 45 with Ventoy that worked in 44 with Ventoy).

4

I think you are saying there are two issues.

Does f45 kde install if you do not use ventoy? e.g. write to a USB stick with mediawriter.

5

For me the F45 Workstation iso failed to run using Ventoy 1.1.17 but did work when as a standalone USB.

6

Thanks for confirming it isn’t just me.

I and others I know heavily depend on Ventoy. Writing each ISO to an individual USB stick is far less useful. So I want to understand why it doesn’t work: What changed from Fedora 44 to Fedora 45 to break Ventoy?

Is there a work around or a change that should be made to Ventoy to fix it, or a change we might convince the Fedora maintainers to make to fix it?

7

@john2fx
Seams to be an older issue we already had in the past.

Have you tested the everything ISO which still contains the old anaconda. So we can have an idea if the new anaconda is involved in this issue?

I made the instructions more readable in the topic you answered last:

8

I will try that soon.

Correct me if I’m wrong, but anaconda could only be involved much later in the sequence. It fails well before it even tries to switch to GUI mode.

9

Sorry, I was not observing that we talk specific about F45. In this case it could indeed have something dodo with the new anaconda, since we are implementing it also soon on the the everything ISO.

This is also a bit unhappy with the Rawhide/Development section we do have. However you found it out.
When re-basing Rawhide to a new version, then the newest “stable” to test is, the soon being released, beta version. In this time period we are using the “development” sub directory on the mirrors. This way we can talk about old rawhide as the new “stable” pre-release.

If you can remember that, then you cracked the code of how the mirror structure looks like.
As soon as we do release the next stable version, the now existing /45 directory in /development will be moved into the /releases directory which is on the same level under /linux

Index of /pub/fedora/linux

 Icon   Name                    Last modified      Size  Description
  ___________________________________________________________________________
 [PARENTDIR]  Parent Directory                             -
 [DIR]  core/                   2006-10-17 12:46    -
 [DIR]  development/            2026-08-11 19:31    -
 [DIR]  extras/                 2013-04-25 08:55    -
 [DIR]  releases/               2026-04-24 10:18    -
 [DIR]  updates/                2026-08-11 17:33    -
  ___________________________________________________________________________

as you can see F45 is not available in /releases yet:

Index of /pub/fedora/linux/releases

 Icon   Name                    Last modified      Size  Description
  ___________________________________________________________________________
 [PARENTDIR]  Parent Directory                             -
 [DIR]  10/                     2013-04-25 08:48    -
 [DIR]  11/                     2013-04-25 08:48    -
 [DIR]  12/                     2013-04-25 08:48    -
 [DIR]  13/                     2013-04-25 08:48    -
 [DIR]  14/                     2013-04-25 08:48    -
 [DIR]  15/                     2013-09-05 19:09    -
 [DIR]  16/                     2013-09-05 19:20    -
 [DIR]  17/                     2013-09-05 19:25    -
 [DIR]  18/                     2015-02-24 00:45    -
 [DIR]  19/                     2015-02-24 00:57    -
 [DIR]  20/                     2015-07-16 17:32    -
 [DIR]  21/                     2016-05-17 20:38    -
 [DIR]  22/                     2017-09-21 17:00    -
 [DIR]  23/                     2017-09-21 17:27    -
 [DIR]  24/                     2017-09-22 17:36    -
 [DIR]  25/                     2018-07-09 23:26    -
 [DIR]  26/                     2018-07-09 23:31    -
 [DIR]  27/                     2019-04-01 20:08    -
 [DIR]  28/                     2019-09-02 20:37    -
 [DIR]  29/                     2020-02-21 19:15    -
 [DIR]  30/                     2020-10-05 19:56    -
 [DIR]  31/                     2020-12-02 17:55    -
 [DIR]  32/                     2022-05-25 13:26    -
 [DIR]  33/                     2022-05-25 13:33    -
 [DIR]  34/                     2023-05-18 12:08    -
 [DIR]  35/                     2023-01-17 10:02    -
 [DIR]  36/                     2023-07-27 05:31    -
 [DIR]  37/                     2024-06-05 04:56    -
 [DIR]  38/                     2024-06-05 05:14    -
 [DIR]  39/                     2025-07-17 12:41    -
 [DIR]  40/                     2025-07-17 12:33    -
 [DIR]  41/                     2025-12-29 12:51    -
 [DIR]  42/                     2026-07-02 10:53    -
 [DIR]  43/                     2025-10-25 18:05    -
 [DIR]  44/                     2026-04-24 15:49    -
 [DIR]  7/                      2016-05-21 03:28    -
 [DIR]  8/                      2016-05-21 02:12    -
 [DIR]  9/                      2013-04-25 08:48    -
 [DIR]  test/                   2026-05-12 16:38    -
  ___________________________________________________________________________
10

Meanwhile I guessed what I should look at: I think this says something important about the problem. But I don’t understand enough about it:

[    1.581934] fedora dracut-cmdline[424]: Using kernel command line parameters:    BOOT_IMAGE=(loop)/boot/x86_64/loader/linux selinux=0 root=live:CDLABEL=Fedora-KDE-Live-45 rd.live.image rdinit=/vtoy/vtoy  root=live:/dev/ventoy
[    1.610698] fedora dracut-cmdline[424]: livenet: no url handler for /dev/ventoy
[    1.631024] fedora kernel: loop: module loaded
[    1.631287] fedora dracut-cmdline[424]: root was live:/dev/ventoy, is now live:/dev/ventoy
...
[  134.180378] fedora dracut-initqueue[740]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
[  134.185662] fedora dracut-initqueue[740]: Warning: /var/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh: "[ -e "/dev/root" ]"
[  134.188711] fedora dracut-initqueue[740]: Warning: /var/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fventoy.sh: "[ -e "/dev/ventoy" ]"```
11

I’m not sure if this is a Fedora issue or a Ventoy issue. I seem to recall Ventoy having to specifically add support for different ISOs, so it’s possible that something changed in F45 that requires a Ventoy update. Might check on Ventoy.

12

It may be specific to the system hardware. I have:

% inxi -Mzxx
Machine:
  Type: Desktop System: Apple product: iMac14,2 v: 1.0
    serial: <superuser required> Chassis: type: 13 v: Mac-27ADBB7B4CEE8E61
    serial: <superuser required>
  Mobo: Apple model: Mac-27ADBB7B4CEE8E61 v: iMac14,2
    serial: <superuser

Ventoy 1.1.7 would not boot the pre-release test days F45 Workstation ISO, so I had to use a normal F45 Installer USB. That install was unstable. It was on an external SSD, so I just updated it using a Dell laptop, but haven’t had time to see if the updates fixed the instability on the iMac.