Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 1831269 [details] journal -a Description of problem: When we write a live-iso to a USB-key on a fat/fat32/ntfs partition using the livecd-iso-to-disk.sh script, the script uses a UUID if available to identify the root device. On USB-keys with fat there is no real UUID but this is more like a serial number in the form XXXX-XXXX. Thus we end up with the following command line in syslinux.cfg: append initrd=initrd.img root=live:UUID=XXXX-XXXX rd.live.image rw quiet The UUID in those cases consists of upper letters only. During boot dracut parses the UUID to lower case and thus starts an endless loop wating for the divese to appear. The divice is mapped correctly by the kernel (which doesn't tweak the UUID) but because we are waiting for a name with lower charachters the expeted device never appers which drops us at the emergency shell leaving the live-iso unbootable. So don't mess with the UUID and use it the way it's presented by the device. This was introduced by https://github.com/dracutdevs/dracut/commit/d3532978de04c78f53664dad7b37705a49a7ee54 Version-Release number of selected component (if applicable): dracut-055-4.fc35 How reproducible: Download the latest liveiso and write it using livecd-tools to any usb-key with fat Steps to Reproduce: 1. 2. 3. Actual results: Boot fails because dracut-initqueue() checks for a wrong device-name Expected results: Boot should work I'm attaching a patch for this. Additional info:
Created attachment 1831270 [details] patch to fix the problem This patch fixes the problem.
Why did you add me to the cc:? Don't just add people without and explanation as to what/why you're expecting of them.
(In reply to Peter Robinson from comment #2) > Why did you add me to the cc:? Don't just add people without and explanation > as to what/why you're expecting of them. I added you because you are the package maintainer at fedora. I thought you maybe interested to look at this issue.
> I added you because you are the package maintainer at fedora. I thought you > maybe interested to look at this issue. I am not the package maintainer of dracut, the maintainers of dracut are added automatically.
(In reply to Peter Robinson from comment #4) > > I added you because you are the package maintainer at fedora. I thought you > > maybe interested to look at this issue. > > I am not the package maintainer of dracut, the maintainers of dracut are > added automatically. ok, I'm sorry. Please ignore the request.
Any chance to get this moved forward and merged into master? Or should I file a bug report at github? This actually affects all current versions of dracut and thus applies to F33, f34 and F35, not just rawhide.
> livecd-iso-to-disk.sh script, the script uses a UUID if available to Where does this script come from? Could it be a bug in what that script does as opposed to dracut?
It's part of the official livecd-tools-28.3-1.fc34 package (actually livecd-iso-to-mediums-28.3-1.fc34.x86_64.rpm) and have worked fine for more than a decade. The script is ok but what dracut does is that it tempers the UUID. The problem occurs every time we address a fat/ntfs disk by the UUID since those are in capital letters. This can be seen if one tries to make new partition let's say in gparted or so. When you look at the offending commit you can see that before the change the UUID was passed unchanged to the system. And the kernel doesn't tamper the UUID either.
Any chance to see this updated in fedora?
This bug prevents me from using livecd-iso-to-disk to create a Fedora 35 EFI bootable stick with persistence from any released Fedora 35 LiveISO, since --efi requires the stick to be formatted as FAT. However, the Fedora 34 LiveISO image is unaffected by this bug. I used the following command to create my test sticks: livecd-iso-to-disk --noverify --efi --format --reset-mbr --unencrypted-home --home-size-mb 300 /home/alex/instaladores-linux/isos/Fedora/35/Fedora-Workstation-Live-x86_64-35-1.2.iso /dev/sde
This is very frustrating for someone who wants fedora on a rasberry pi! Any chance we can have a working version at, https://getfedora.org/en/workstation/download/ for, Fedora 35: aarch64 raw image and Fedora 35: aarch64 DVD ISO ASAP!!! I've spent ages stuffing around with this problem since it worked in Oct & boot failed on a fedora update & newly built / rpi-imager versions subsequently fail! Also the boot menu needs a longer timeout (1 sec is not enough when there's a problem like this!)
I've updated the link with the pull request. Still waiting for it to be merged upstream, though. You can use the following workaround in the meantime: Change the following in the corresponding boot menu 'root=live:UUID=XXXX-XXXX' to 'root=live:LABEL=MyWhateverLabel' where 'MyWhateverLabel' is the exact Label of the drive. When created with livecd-iso-to-disk the label is LIVE otherwise just use your own label. This value is case sensitive! This issue affects all isos created with dracut>=054 where the squashimg is on fat/ntfs and the drive is referred to as UUID=XXXX-XXXX. Using LABEL= oder CDLABEL= is aworkaround because those don't get tampered by dracut. Let's hope the patch gets merged soon.
Created attachment 1845826 [details] revised version of the fix-patch
This issues is now fixed upstream (commit 4e858741087a5cfea891bd2c1fd51ea9b830aeaf), so I'll close this bug. It'll be nice if this is ported downstream to the current package in fedora.
Let's not close it until it's fixed in the distro.
It cannot be closed until the "downloads" at https://getfedora.org/en/workstation/download/ for, Fedora 35: aarch64 raw image and Fedora 35: aarch64 DVD ISO and 36 etc. are fixed & tested! They obviously were not previously tested! So a test/confirmation system also needs to be implemented as part of this resolution!
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
Fedora 36 development dracut-55-8.fc36.1 does not include this patch. Fedora Rawhide dracut-56-1.fc37 contains this patch. Installed on an updated Fedora 35 system it successfully generates an EFI bootable MS-DOS formatted USB flash drive.
(In reply to bcling from comment #18) > Fedora 36 development dracut-55-8.fc36.1 does not include this patch. > > Fedora Rawhide dracut-56-1.fc37 contains this patch. Installed on an updated > Fedora 35 system it successfully generates an EFI bootable MS-DOS formatted > USB flash drive. And to be clear, the live CD used to create the flash drive was generated with this version of dracut.
FEDORA-2022-c6272e49ad has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c6272e49ad
So to be even clearer... FC-36 when released & when boot media is generated will NOT boot & will still contain this bug! Is that right? Additionally there is no plan to make an FC-35 (actually bootable) media release at, https://getfedora.org/en/workstation/download/ Is that also correct?
> FC-36 when released & when boot media is generated will NOT boot & will > still contain this bug! > > Is that right? No, you said it needs the new dracut which is in updates-testing and will go to stable before freeze so if that's all it needs it will be fixed for F-36. > Additionally there is no plan to make an FC-35 (actually bootable) media > release at, > > https://getfedora.org/en/workstation/download/ > > Is that also correct? That is correct, we don't generally respin releases that are already out, there's a LOT of moving parts and other things could regress and there's limited QE people to do the testing.
FEDORA-2022-c6272e49ad has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
I can confirm that the Fedora 36: aarch64 raw image at, https://getfedora.org/en/workstation/download/ does not boot.