I have the exact same issue on a Kinoite 39 ISO? I didnt have this before...

On 2 laptops, also on a Thinkpad T495.

From the other reported issue with the multipath NVME, I removed the NVME and still had the same issue

I can reproduce the same on a pretty old Laptop, but still using the Kinoite 40-1.14 ISO

This is really problematic, I needed to clone my install with Clonezilla multiple times, and luckily had a backup. I cannot install it on new computers. 

I see that 1.14 is still the current ISO to download. I will try to find a nightly ISO and try that.

Help highly appreciated.

Found Kinoite Nightly ISOs on https://openqa.fedoraproject.org/nightlies.html

Will try Fedora-Kinoite-ostree-x86_64-Rawhide-20240716.n.0.iso

boot failed there too, same issue

I have not tried if this is Kinoite specific. It is odd that I should be the only one to experience this.

I now tried 3 different laptops, all had NVMEs, 3 different ISO releases, same result.

I can still reproduce this on the Kinoite 41 beta ISOs (https://torrent.fedoraproject.org/torrents/Fedora-KDE-Live-x86_64-41_Beta.torrent)

Device: Lenovo Flex Chromebook, Jasperlake Intel 11th Gen processor, running Coreboot with EDK2 firmware.

Booted from a USB stick.

ERRORS:

dracut-initqueue:
It seems that the boot has failed. Possible causes include missing inst.stage2 or inst.repo boot parameters on the kernel cmdline. Please verify that you have specified inst.stage2 or inst.repo.
Please also note that the "inst." prefix is now mandatory.

#### Installer errors encountered during boot: ####
#
Reason unknown
#
########## Anaconda installer errors end #######
dracut-initqueue: timeout, still waiting for following initqueue hooks:
/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x22froot.sh: "[ /e "/dev/root"]"
dracut/initqueue? starting timeout scripts

### repeat above

The Chromebook uses eMMC storage

I used Fedora Media Writer to flash the thumbdrive if this is relevant

ChatGPT gave me this answer (I corrected it a bit)

1. **`inst.stage2`**: This tells the installer where to find the installation image (which contains the Anaconda runtime). You typically point this to the ISO or installation source.
   
   Example:
   ```
   inst.stage2=hd:LABEL=Fedora-WS-Live-<version>-<arch>:/path
   ```
   - The label should match the filesystem label of the installation media. You can verify this by checking the thumbdrive label (e.g., using `lsblk` or `blkid`).
   
   If you mounted the ISO or image somewhere else, adjust accordingly (e.g., `LABEL=Fedora-Kinoite-Live-...`).

2. **`inst.repo`**: This tells the installer where to find the actual repository with the installation packages.
   
   Example:
   ```
   inst.repo=hd:LABEL=Fedora-WS-Live-<version>-<arch>:/path
   ```
   This can be set to the same ISO location as `inst.stage2`, or it could point to a network location, like a specific repository URL:
   ```
   inst.repo=http://download.fedoraproject.org/pub/fedora/linux/releases/<version>/Everything/<arch>/os/
   ```

### Evaluation for your case (Fedora Kinoite):

For Fedora Kinoite, the values would be different but follow the same format. Since it is OSTree-based, you might point to a different repository.

Try the following for your thumbdrive:

WRONG

```bash
inst.stage2=hd:LABEL=Fedora-Kinoite-Live-<version>-<arch>
inst.repo=hd:LABEL=Fedora-Kinoite-Live-<version>-<arch>
```

Make sure that:
- `<version>` is the correct Fedora version number you are using.
- `<arch>` is your architecture (`x86_64`, `aarch64`, etc.).
- The `LABEL` matches the actual filesystem label on your thumbdrive. Use `blkid` or `lsblk` to check the label.

### Correct usage examples:

If your thumbdrive is labeled `Fedora-Kinoite-41-x86_64`, the arguments might look like this:
```bash
inst.stage2=hd:LABEL=Fedora-Knt-ostree-x86_64-41
inst.repo=hd:LABEL=Fedora-Knt-ostree-x86_64-41
```


my thumbdrive is labelled "Fedora-Knt-ostree-x86_64-41" so I will try and use that

getting to system-vconsole-setup.service

I tried adding inst.repo behind the already correct and present inst.stage2 argument, with no effect

Created attachment 2050836 [details]
rdsosreport

Got the report

meanwhile, Fedora 37 Kinoite (ISO from the archives) still installs normally. I needed to disable secureboot, but it works.

So to summarize from what I can tell:
- very old image seems to work (Fedora 37)
- there are sometimes issues with even putting the image on a flash drive
-> this could be a hardware failure on the flash drive side (suggest trying with different drive, just to eliminate this possibility)
-> this could be an issue with the installation flash drive creation tool (Fedora media writer, etc.)
-> this could be an issue with your downloaded image (suggest verifying the downloaded file chekcsumm if possible *and* using the "test this image and install" boot option if you can get this far)
- could this be an overall Fedora regression for your hardware ?
-> I would suggest trying the same flash drive + installable flesh drive creation tool, but a different Fedora edition (Workstation of Server) to see if it also has issues with booting

you are right!

I have 2 flashdrives by the same brand. I reformatted them quite a lot, maybe 50 times?

I now tried on a different one, different brand and it worked.

Before, "Impression" Flatpak always crashed at the end. Fedora media writer didnt show any issues, just as dd.

I had the same on HeliumOS, based on AlmaLinux.

Well, that was strange.

Just an additional thought (and I think I was hit with something similar once) - try zeroing the drive first (dd if=/dev/zero of=/dev/xxx) before writing new ISO. Since the new ISO might be smaller to the previous one, some remaining structures may linger at the end of the new ISO data and might confuse the tools.

I certainly hope that any commonly used media writers will at least call `wipefs` first or something else that understands the Hybrid ISO structures.