It seems to be a more general problem, I tried a netinstall fc42 and I have the same issue

systemd.gpt_auto=no solves the issue.

Can you provide us with more info?

What exact image(s) are you trying? This is simply dding them to a usb and booting? or ?

Does a f41 image work as you expect?

This may be some systemd bug related to your env?

This kinda failure usually means "we can't find the device that root is supposed to be on for some reason".

We do test the network install images in our openQA instance and those tests are passing, so there has to be something contextual about this. How exactly are you 'trying' them? In a VM, or on bare metal? If VM, what virt system? If bare metal, what hardware? For virt, how are you attaching the image to the VM? For bare metal, are you writing the image to USB stick? Disc? Something else? How are you writing it?

Thanks!

Since January I tried to reinstall rawhide with netinstall by downloading isos from :

https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/iso/
or fedora-rawhide nightly netinstall builds.
But all fails at : Timed out waiting for device dev-gpt\x2dauto\x2droot.device - /dev/gpt-auto-root.

Today i tried the last build:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20250218.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20250218.n.0.iso and same issue.

A search on google told me to try systemd.gpt_auto=no in boot command with success.

The installation with the live-cd works ; only the netinstall have issues even with a non-rawhide fc42 iso.

Sorry I have trouble with English ...
I use mediawriter to write the usb stick for a bar metal install.

Desktop :
Intel i7 Alder-lake
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: PRIME Z690-A
Version: Rev 1.xx
Drives :
2 x Samsung SSD Controller SM981/PM981/PM983
1 x Sandisk Corp WD PC SN810 / Black SN850 NVMe SSD

Laptop:
Acer A715-71G

To be sure I just tested a netinstall of fedora 41 :
https://dl.fedoraproject.org/pub/fedora/linux/releases/41/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-41-1.4.iso
and I have no boot problem.
That's why I think the problem does not come from my machines but began with fc42 isos.

I've observed this as well with rawhide, f42 and c10s.

My environment is qemu-system-x86_64 VMs with ovmf UEFI where I can get the iso to boot and install when using
-drive file=${INI},id=vd2,media=cdrom,format=raw,cache=none,if=none -device usb-storage,drive=vd2,serial=instimg

but the error occurs when using
-drive file=${INI},id=vd2,media=disk,format=raw,cache=none,if=none -device usb-storage,drive=vd2,serial=instimg

So something seems different between booting off the ESP or doing an eltorito boot

@vtrefny is this related to https://fedoraproject.org/wiki/Changes/Anaconda_Installer_Using_GPT_on_all_architectures_by_Default ?

@vtrefny is this related to https://fedoraproject.org/wiki/Changes/Anaconda_Installer_Using_GPT_on_all_architectures_by_Default ?

I don't think so, GPT is used on x86_64 since F37 so there should be no difference for x86_64 in F42. The discoverable partitions feature was enabled in Fedora so that also shouldn't cause this.

Anyone who sees this issue, can you check if you have the correct partition types with lsblk -o+PARTTYPE?

$ lsblk -o+PARTTYPE

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS PARTTYPE
sda 8:0 1 7,5G 0 disk
├─sda1 8:1 1 913,3M 0 part ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
└─sda2 8:2 1 12,6M 0 part c12a7328-f81f-11d2-ba4b-00a0c93ec93b
zram0 252:0 0 8G 0 disk [SWAP]
nvme0n1 259:0 0 465,8G 0 disk
├─nvme0n1p1 259:2 0 500M 0 part /boot/efi c12a7328-f81f-11d2-ba4b-00a0c93ec93b
└─nvme0n1p2 259:3 0 465,3G 0 part /home 0fc63daf-8483-4772-8e79-3d69d8477de4
/
nvme2n1 259:1 0 931,5G 0 disk
└─nvme2n1p1 259:4 0 931,5G 0 part /media/data 0fc63daf-8483-4772-8e79-3d69d8477de4
nvme1n1 259:5 0 931,5G 0 disk
└─nvme1n1p1 259:6 0 931,5G 0 part /media/backup 0fc63daf-8483-4772-8e79-3d69d8477de4

sda is the netinstall usb drive

None of the target block devices have anything on them yet but are freshly made qemu-img raw images.

The iso being booted from is unmodified. The problem only occurs when booting off the ESP on the installation iso.

Our guess is that this wasn't really related to releng things, but there were a couple of general compose problems between rc3 and rc4 ... so maybe the problem is resolved?
If not, you really want to open a bug with the component that needs to change.

Installation media is booting from ESP today using:

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20250305.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20250305.n.0.iso

I was not able to determine what component was at fault. Though it seems to be fixed it would be nice to know root cause. Maybe if it happens again...

Thank you all so much for making this happen!

I am wondering if this was the same thing I was seeing on my laptop... kernels after rc2 but before rc4 didn't boot. They all would fail finding the root volume.

I was unable to determine why.

Anyhow, glad it's working now!