I have downloaded both the liveGUI and the LiveGUI for USB. I used rufus on both .iso files. I both cases the burns were aborted because of a extraction error. This proved fatal to two USB flash drives.
- Can you specify exactly the filenames you downloaded? - Did you verify the signatures or at least the checksums? - Can you provide the error output from the extraction?
The file I used is: livegui-amd64-20220515T170533Z I found the checksum on a mirror. It did not fail the check. The only error I got from rufus is "Error: ISO Image extraction failure"
> This proved fatal to two USB flash drives. Is the claim that attempting to write the LiveGUI iso to a USB drive... killed the USB drive?
I'm able to reproduce the "ISO Image extraction failure" error with this ISO. I'll try the newest ISO shortly. FYI as a workaround, I think "DD mode" will work fine, but the resulting USB drive won't be read/write vfat (so you won't be able to add your own files). Excerpt from full rufus log: Extracting files... Image is an ISO9660 image This image will be extracted using Joliet extensions (if present) libcdio: Non consecutive multiextent file parts for '' Extracting: F:\EFI\BOOT\BOOTIA32.EFI (952.7 KB) Extracting: F:\EFI\BOOT\BOOTX64.EFI (1.2 MB) Extracting: F:\EFI\BOOT\grubia32.efi (3.2 MB) Extracting: F:\EFI\BOOT\grubx64.efi (3.2 MB) Extracting: F:\EFI\BOOT\mmia32.efi (906.1 KB) Extracting: F:\EFI\BOOT\mmx64.efi (1.1 MB) Extracting: F:\README.txt (7.1 KB) Extracting: F:\boot\EFI\BOOT\BOOTIA32.EFI (952.7 KB) Extracting: F:\boot\EFI\BOOT\BOOTX64.EFI (1.2 MB) Extracting: F:\boot\EFI\BOOT\grubia32.efi (3.2 MB) Extracting: F:\boot\EFI\BOOT\grubx64.efi (3.2 MB) Extracting: F:\boot\EFI\BOOT\mmia32.efi (906.1 KB) Extracting: F:\boot\EFI\BOOT\mmx64.efi (1.1 MB) Extracting: F:\boot\System-gentoo.map (5.6 MB) Extracting: F:\boot\gentoo (10.3 MB) Extracting: F:\boot\gentoo-config (229.6 KB) Extracting: F:\boot\gentoo.igz (9.9 MB) Extracting: F:\gentoo.efimg (10.5 MB) Extracting: F:\grub\grub.cfg (512 bytes) libcdio: Non consecutive multiextent file parts for '' libcdio: Bad directory information for isolinux Could not access directory /isolinux Created: F:\syslinux.cfg → /isolinux/isolinux.cfg
It seems that libcdio (used by rufus) is having trouble reading our iso file ever since we started calling mkisofs with --iso-level 3. Here's a Rufus issue that seems to match out situation: https://github.com/pbatard/rufus/issues/1007#issuecomment-324593846 iso-info -l livegui-amd64-20220508T170538Z.iso iso-info version 2.1.0 x86_64-pc-linux-gnu Copyright (c) 2003-2005, 2007-2008, 2011-2015, 2017 R. Bernstein This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. __________________________________ ISO 9660 image: livegui-amd64-20220508T170538Z.iso Application : MKISOFS ISO9660_HFS_UDF FILESYSTEM BUILDER & CDRECORD CD_DVD_Blu System : LINUX Volume : Gentoo amd64 LiveGUI 20220508T17 Joliet Level: 3 __________________________________ ISO-9660 Information /: d [LSN 39] 2048 May 08 2022 17:02:40 . d [LSN 39] 2048 May 08 2022 17:02:40 .. d [LSN 44] 2048 May 08 2022 17:02:40 EFI - [LSN 2583540] 7236 May 08 2022 17:00:05 README.txt d [LSN 40] 2048 May 08 2022 17:00:09 boot - [LSN 50] 11036672 May 08 2022 17:02:40 gentoo.efimg d [LSN 43] 2048 May 08 2022 17:00:09 grub - [LSN 5460] 4294965248 May 08 2022 17:02:40 image.squashfs - [LSN 2102611] 984942592 May 08 2022 17:02:40 image.squashfs d [LSN 46] 2048 May 08 2022 17:00:09 isolinux - [LSN 18446744073709551600] 0 May 08 2022 17:00:05 livecd d [LSN 47] 2048 May 08 2022 17:00:05 snapshots
It seems that our latest version of libcdio in ::gentoo doesn't yet have multi-extent (>4GB) file support, and that's what I used for the test in comment #5. But upstream git master does have support, and rufus *is* using a copy of libcdio with multi-extent support. There still must be something wrong with the way our ISO is being created, because even after building libcdio locally from git master, I get errors similar to Rufus: ++ WARN: Non consecutive multiextent file parts for '' ++ WARN: Bad directory information for isolinux /isolinux/: Error getting above directory information ++ WARN: Non consecutive multiextent file parts for '' ++ WARN: Bad directory information for snapshots /snapshots/: Error getting above directory information
I was able to reproduce the problem on a new test iso creation, where test/ here is a dir with a 5GB file inside: # mkisofs -J -R -l -V "Test ISO" -o ~/test.iso -z -iso-level 3 test/ I tested a few combinations of options and found that -J seems to be the culprit. This produces an iso that can be correctly read by libcdio (git master): # mkisofs -R -l -V "Test ISO" -o ~/test.iso -z -iso-level 3 test/ I would suggest we drop Joliet support (-J) from catalyst, instead relying on Rock Ridge (-R) which should work fine for all the platforms we care about.
About the two stuned flash drives... I had to ny electronics books. I found a method still covered with a NDA to tweek the drives. I then did a little vodoo. So both dirves are usable.
Found a flash burner "FreeIsoBuner" that worked
Newest Rufus-3.19 can now successfully unpack the iso filesystem, BUT it uses NTFS (instead of vfat) for large file support, and our livegui doesn't have that driver available early enough. I've pushed a change to the releng repo which should fix this for the next autobuild. Let's check back after this weekend's new build.
