Thanks Vladislav. I know, there are some other methods, however, livecd-iso-to-disk provides some advanced options, such as encrypted persistent home partition or multiple OS versions on the same pendrive.
The ISO image itself seems to be fine - I was able to boot from ISO with qemu-kvm, but based on the logs, there might be some regression in dracut(-cmd) between F34 and F35. I temporary switched back to Fedora 34 with my emergency livecd, but it would be good to catch it and fix.
A short uppercase UUID is a sign of non-native file systems like FAT and NTFS.
This could be the result of the following conversion to lowercase:
This kind of usage scenario is likely unexpected and requires patching.
So, it is best address the issue directly to the Dracut developers: Issues · dracutdevs/dracut · GitHub
That makes sense. UUID for “native” file systems are lowercased.
I don’t know if dracut supports “vfat”, however, livecd-iso-to-disk could also perform better in that case. According to the documentation:
–format [sizemb[,fstype[,blksz[,extra_attr,s]]]]
Partitions and formats the target device, creates an MS-DOS partition table or GUID partition table (GPT), if the --efi option is passed, creates 1 to 3 partitions, and invokes the --reset-mbr action.
NOTE WELL: All current disk content will be lost.
Partition 1 is sized as requested or as available & fstype formatted. fstype may be: ext[432](ext4 default)|fat|vfat|msdos|btrfs|xfs|f2fs (extra_attr,s may be passed to f2fs formatting, for example, --format f2fs,-,extra_attr,compression Until GRUB’s f2fs.mod is updated, any extra_attr will require booting with an EFI Boot Stub loader, such as the one from dracut triggered by the above format request.) Partition 1 is labelled as before or requested, flagged as bootable, and may allow an optional block size.
Partition 2 is fat16 formatted and labelled ‘EFI System Partition’.
Partition 3 is HFS+ formatted and labelled as ‘Mac’.
Creation of partitions 2 & 3 is dependent on the presence of the files /images/efiboot.img & /images/macboot.img in the source.
I would expect one at least two partitions in a default format execution (at least with --efi). One for data (ext4) and one for EFI (fat16). However, there is just one partition created - vfat/fat32 (named EFI System Partition) which also limits an ability to reuse host space by an overlay layer.
Btw, the source ISO for Fedora 35 contains both efiboot.img and macboot.img.
I’ve run into a similar problem with the boot timing out waiting for a “/dev/mapper/live-rw” job using the following command line to created the Live-USB:
I 've run into similar issues while following the syntax provided by livecd-tools/livecd-iso-to-disk.
Have you considered opening an issue directiy to the project: livecd-tools ?
This tool set (livecd-iso-to-disk and editliveos) is very powerful but the syntax presented might need more explanations and examples for some users (I’ve been tweaking with them for a couple of years now but I’am still a beginner)
@linesteppr It turned up that probably vfat is problematic and with ext4 it worked fine (might be worth to report a bug, anyway!). However, to make it work, I had to: