The ext3 file system in the partition for persistence has errors

[sudodus]

Checklist

• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• I clicked the 'Log' button or pressed Ctrl-L in Rufus, and copy/pasted the log into the line that says <FULL LOG> below.
• The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.

    $ sudo badblocks -sv /dev/sdc 
    Kontrollerar block 0 till 58615703
    Letar efter dåliga block (skrivskyddad test): klar                                                 
    Pass avslutat, 0 dåliga block hittade. (0/0/0 fel)
  

• I also tried one or more of the following:

  • Using a different USB drive.
  • Plugging the USB into a different port.
  • Running Rufus on a different computer.

• If using an image, I clicked on the (✓) button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.
  I tested the checksum of the iso file separately at/after downloading

    $ md5sum lubuntu-19.10-desktop-amd64.iso 
    8b8b03366298e7489df6bc34760f89aa  lubuntu-19.10-desktop-amd64.iso
  

  Actually a got it via zsync, which has a built-in checksum test.

Issue description

When creating persistent a live drive Rufus makes an ext3 file system in the partition for persistence. This file system has errors. It is still possible to use the file system for example with
Lubuntu 19.10, but

1. Part of the drive space in the file system is lost, wasted, compared to a healthy file system, when Lubuntu or other flavours of Ubuntu is booted. This might not be seen when connected to an operating system that is already running. The size of the lost drive space is small in a 4 GB pendrive, significantly bigger in a 16 GB pendrive, and huge ina 60 GB SSD. I used an SSD in several test runs because the loss is so big, that it very easy to see, and also because it is a high speed device, so that I could do several tests within a rather short time.

2. The errors in the file system may not create any corruption of files in the beginning, but I am afraid, that it may cause severe problems later on. When booting live-only I noticed that a log directory was mounted (and some of the errors are that some inodes have 2 links).

I tested various things in three different computers and another user tested it in a fourth computer. I ran standard Windows 10 fully up to date in two computers and a 'Windows Insider' version 10 fully up to date in the third computer. After some repetitions things started to look good, but when I specified the starting conditions in a strict way I could reproduce similar (not exactly the same) size of lost drive space.

1. Original drive a standard storage device with FAT32
2. Oriignal drive zeroised (completely overwritten with zero bytes)

In these cases between 20 GiB and 40 GiB were lost, already marked as used by df -h when booting into the persistent live system for the first time. A single test starting from exFAT showed 12 GiB lost drive space.

Thinking aloud

It seems to me that the tool to create the file system is buggy, or is using some buggy or not compatible system software (dll-file?).Or maybe you could fix it by compiling with some flags for more strict, less optimized for speed operation. Or you could test if there is a version for ext2 or ext4, that is more robust. I think that ext4 gets much more attention than ext3 nowadays.

Repair

I tested that it was possible to repair the file system with e2fsck -f and then there was no lost drive space, only the normal amount reserved to management (and similar size as that of the linux tool mkusb).

Re-format

I tested also that it was possible to re-format the ext3 file system with AOMEI Parition Assistent (the freeware version), and that file system was working almost correctly, there was a "Resize inode not valid" message. But no other complaint, not the huge amount of errors caused by Rufus, and there was no obvious loss of drive space for the user.

Final words

I wish that you will fix this bug or find a way around it soon, and I am willing to help with testing, when you have new versions of Rufus or simply new ways to set the conditions to make it work.

Good luck
Nio

Log

Rufus x86 v3.8.1580
Windows version: Windows 10 64-bit (Build 18362)
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.04
System locale ID: 0x041D (sv-SE)
Will use default UI locale 0x041D
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'sv-SE'
Found non-USB removable device 'LITEONIT LMT-128M6M mSATA 128GB' => Eliminated
0 devices found
Found UAS (USB 3.0) device 'OCZ-AGIL ITY3 SCSI Disk Device' (174C:55AA)
No logical drive found (unpartitioned?)
Device eliminated because it was detected as a Hard Drive (score 3 > 0)
If this device is not a Hard Drive, please e-mail the author of this application
NOTE: You can enable the listing of Hard Drives under 'advanced drive properties'
Found non-USB removable device 'LITEONIT LMT-128M6M mSATA 128GB' => Eliminated
0 devices found
Found UAS (USB 3.0) device 'OCZ-AGIL ITY3 SCSI Disk Device' (174C:55AA)
No logical drive found (unpartitioned?)
Found non-USB removable device 'LITEONIT LMT-128M6M mSATA 128GB' => Eliminated
1 device found
No volume information for drive 0x81
Disk type: FIXED, Disk size: 60 GB, Sector size: 512 bytes
Cylinders: 7297, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 0
Disk ID: 0x00000000
Drive does not have an x86 Master Boot Record
Scanning image...
ISO analysis:
  Image is an ISO9660 image
  Will use '/isolinux/isolinux.cfg' for Syslinux
  Detected Syslinux version: 6.04/20190226 (from '/isolinux/isolinux.bin')
Disk image analysis:
  Image has an unknown Master Boot Record
  Image is a bootable disk image
ISO label: 'Lubuntu 19.10 amd64'
  Size: 1.6 GB (Projected)
  Uses: Syslinux/Isolinux v6.04
  Uses: EFI
  Note: This ISO uses symbolic links, which will not be replicated due to file system limitations.
  Because of this, some features from this image may not work...
Using image: lubuntu-19.10-desktop-amd64.iso (1.6 GB)
Will reuse 'ldlinux.sys' and 'ldlinux.bss' from './rufus_files/rufus_files/syslinux-6.04/20190226/' for Syslinux installation

Format operation started
Requesting disk access...
No drive letter was assigned...
Will use 'E:' as volume mountpoint
Deleting partitions...
Notice: Could not delete partitions: [0x00000000] Åtgärden har slutförts.
Opened \\.\PhysicalDrive1 for shared write access
No logical drive found (unpartitioned?)
Drive does not appear to be partitioned
Analyzing existing boot records...
Drive does not have an x86 Master Boot Record
Clearing MBR/PBR/GPT structures...
Erasing 2176 sectors
Deleting partitions...
Partitioning (MBR)...
● Creating Main Data Partition (offset: 1048576, size: 1.9 GB)
● Creating Linux Persistence Partition (offset: 2040434176, size: 54.0 GB)
Waiting for logical drive to reappear...
Closed Windows format prompt
Using Ubuntu-like method to enable persistence
Formatting (ext3)...
884735 possible inodes out of 14155769 blocks (block size = 4096)
707788 blocks (5.0%) reserved for the super user
Creating 432 inode sets: [1 marker = 5.4 set(s)]
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Creating 32768 journal blocks: [1 marker = 409.6 block(s)]
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Done
Formatting (Large FAT32)...
Opened \\?\Volume{000592e1-0000-0000-0000-100000000000} for exclusive write access
Size : 1.9 GB 3983175 sectors
Cluster size 16384 bytes, 512 Bytes Per Sector
Volume ID is 1b17:1d76
32 Reserved Sectors, 972 Sectors per FAT, 2 FATs
124412 Total clusters
124411 Free Clusters
Clearing out 2008 sectors for reserved sectors, FATs and root cluster...
Initializing reserved sectors and FATs...
FAT #0 sector at address: 32
FAT #1 sector at address: 1004
Writing Partition Boot Record...
Using Standard FAT32 partition boot record
Confirmed new volume has a primary FAT32 boot sector
Setting primary FAT32 boot sector for boot...
Confirmed new volume has a secondary FAT32 boot sector
Setting secondary FAT32 boot sector for boot...
Setting Label (This may take a while)...
Format completed.
Writing Master Boot Record...
Partition is already FAT32 LBA...
Set bootable USB partition as 0x80
Using Syslinux MBR
Found volume \\?\Volume{000592e1-0000-0000-0000-100000000000}\
\\?\Volume{000592e1-0000-0000-0000-100000000000}\ is already mounted as E:
Installing Syslinux 6.04...
Opened \\?\Volume{000592e1-0000-0000-0000-100000000000} for shared write access
Using existing './rufus_files/syslinux-6.04/20190226/ldlinux.sys' ✓
Using existing './rufus_files/syslinux-6.04/20190226/ldlinux.bss' ✓
Successfully wrote 'ldlinux.sys'
Successfully wrote Syslinux boot record
Successfully remounted \\?\Volume{000592e1-0000-0000-0000-100000000000}\ as E:
Extracting files...
Image is an ISO9660 image
This image will be extracted using Rock Ridge extensions (if present)
Extracting: E:\.disk\base_installable (0 bytes)
Extracting: E:\.disk\casper-uuid-generic (37 bytes)
Extracting: E:\.disk\cd_type (15 bytes)
Extracting: E:\.disk\info (56 bytes)
Extracting: E:\.disk\release_notes_url (79 bytes)
Extracting: E:\boot\grub\efi.img (3.9 MB)
Extracting: E:\boot\grub\font.pf2 (4.9 KB)
Extracting: E:\boot\grub\grub.cfg (892 bytes)
  Added 'persistent' kernel option
Extracting: E:\boot\grub\loopback.cfg (382 bytes)
Extracting: E:\boot\grub\x86_64-efi\acpi.mod (15.2 KB)
Extracting: E:\boot\grub\x86_64-efi\adler32.mod (2 KB)
Extracting: E:\boot\grub\x86_64-efi\ahci.mod (22.4 KB)
Extracting: E:\boot\grub\x86_64-efi\all_video.mod (824 bytes)
Extracting: E:\boot\grub\x86_64-efi\aout.mod (1.6 KB)
Extracting: E:\boot\grub\x86_64-efi\appleldr.mod (5.4 KB)
Extracting: E:\boot\grub\x86_64-efi\archelp.mod (4.5 KB)
Extracting: E:\boot\grub\x86_64-efi\ata.mod (8.9 KB)
Extracting: E:\boot\grub\x86_64-efi\at_keyboard.mod (6.9 KB)
Extracting: E:\boot\grub\x86_64-efi\backtrace.mod (2.6 KB)
Extracting: E:\boot\grub\x86_64-efi\bfs.mod (9.3 KB)
Extracting: E:\boot\grub\x86_64-efi\bitmap.mod (3.2 KB)
Extracting: E:\boot\grub\x86_64-efi\bitmap_scale.mod (5.4 KB)
Extracting: E:\boot\grub\x86_64-efi\blocklist.mod (3.1 KB)
Extracting: E:\boot\grub\x86_64-efi\boot.mod (3.3 KB)
Extracting: E:\boot\grub\x86_64-efi\bsd.mod (47.3 KB)
Extracting: E:\boot\grub\x86_64-efi\bswap_test.mod (3.4 KB)
Extracting: E:\boot\grub\x86_64-efi\btrfs.mod (24.5 KB)
Extracting: E:\boot\grub\x86_64-efi\bufio.mod (2.9 KB)
Extracting: E:\boot\grub\x86_64-efi\cat.mod (4.5 KB)
Extracting: E:\boot\grub\x86_64-efi\cbfs.mod (5.8 KB)
Extracting: E:\boot\grub\x86_64-efi\cbls.mod (6.2 KB)
Extracting: E:\boot\grub\x86_64-efi\cbmemc.mod (4.0 KB)
Extracting: E:\boot\grub\x86_64-efi\cbtable.mod (1.7 KB)
Extracting: E:\boot\grub\x86_64-efi\cbtime.mod (4.5 KB)
Extracting: E:\boot\grub\x86_64-efi\chain.mod (19.2 KB)
Extracting: E:\boot\grub\x86_64-efi\cmdline_cat_test.mod (4.7 KB)
Extracting: E:\boot\grub\x86_64-efi\cmp.mod (3.0 KB)
Extracting: E:\boot\grub\x86_64-efi\cmp_test.mod (6.6 KB)
Extracting: E:\boot\grub\x86_64-efi\command.lst (3.6 KB)
Extracting: E:\boot\grub\x86_64-efi\cpio.mod (4.4 KB)
Extracting: E:\boot\grub\x86_64-efi\cpio_be.mod (4.4 KB)
Extracting: E:\boot\grub\x86_64-efi\cpuid.mod (2.7 KB)
Extracting: E:\boot\grub\x86_64-efi\crc64.mod (2.3 KB)
Extracting: E:\boot\grub\x86_64-efi\crypto.lst (936 bytes)
Extracting: E:\boot\grub\x86_64-efi\crypto.mod (6.9 KB)
Extracting: E:\boot\grub\x86_64-efi\cryptodisk.mod (15.5 KB)
Extracting: E:\boot\grub\x86_64-efi\cs5536.mod (3.9 KB)
Extracting: E:\boot\grub\x86_64-efi\ctz_test.mod (2.8 KB)
Extracting: E:\boot\grub\x86_64-efi\date.mod (3.3 KB)
Extracting: E:\boot\grub\x86_64-efi\datehook.mod (3.1 KB)
Extracting: E:\boot\grub\x86_64-efi\datetime.mod (2.0 KB)
Extracting: E:\boot\grub\x86_64-efi\disk.mod (3.2 KB)
Extracting: E:\boot\grub\x86_64-efi\diskfilter.mod (14.5 KB)
Extracting: E:\boot\grub\x86_64-efi\div.mod (1.5 KB)
Extracting: E:\boot\grub\x86_64-efi\div_test.mod (8.1 KB)
Extracting: E:\boot\grub\x86_64-efi\dm_nv.mod (2.9 KB)
Extracting: E:\boot\grub\x86_64-efi\echo.mod (3.1 KB)
Extracting: E:\boot\grub\x86_64-efi\efifwsetup.mod (2.2 KB)
Extracting: E:\boot\grub\x86_64-efi\efinet.mod (10 KB)
Extracting: E:\boot\grub\x86_64-efi\efi_gop.mod (12.4 KB)
Extracting: E:\boot\grub\x86_64-efi\efi_uga.mod (7.1 KB)
Extracting: E:\boot\grub\x86_64-efi\ehci.mod (25.2 KB)
Extracting: E:\boot\grub\x86_64-efi\elf.mod (6.3 KB)
Extracting: E:\boot\grub\x86_64-efi\eval.mod (2.3 KB)
Extracting: E:\boot\grub\x86_64-efi\exfat.mod (8.0 KB)
Extracting: E:\boot\grub\x86_64-efi\exfctest.mod (2.4 KB)
Extracting: E:\boot\grub\x86_64-efi\ext2.mod (8.8 KB)
Extracting: E:\boot\grub\x86_64-efi\f2fs.mod (9.6 KB)
Extracting: E:\boot\grub\x86_64-efi\fat.mod (8.1 KB)
Extracting: E:\boot\grub\x86_64-efi\fdt.lst (0 bytes)
Extracting: E:\boot\grub\x86_64-efi\file.mod (25.5 KB)
Extracting: E:\boot\grub\x86_64-efi\fixvideo.mod (3.1 KB)
Extracting: E:\boot\grub\x86_64-efi\font.mod (16.8 KB)
Extracting: E:\boot\grub\x86_64-efi\fs.lst (219 bytes)
Extracting: E:\boot\grub\x86_64-efi\gcry_arcfour.mod (2.5 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_blowfish.mod (9 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_camellia.mod (27.9 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_cast5.mod (14.6 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_crc.mod (11.8 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_des.mod (16.2 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_dsa.mod (3.5 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_idea.mod (4.1 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_md4.mod (4.2 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_md5.mod (4.6 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_rfc2268.mod (3.3 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_rijndael.mod (20.1 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_rmd160.mod (7.9 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_rsa.mod (3.5 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_seed.mod (13.2 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_serpent.mod (16.5 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_sha1.mod (7.6 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_sha256.mod (5.2 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_sha512.mod (6 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_tiger.mod (13 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_twofish.mod (32.9 KB)
Extracting: E:\boot\grub\x86_64-efi\gcry_whirlpool.mod (22.5 KB)
Extracting: E:\boot\grub\x86_64-efi\geli.mod (9.2 KB)
Extracting: E:\boot\grub\x86_64-efi\gettext.mod (8.4 KB)
Extracting: E:\boot\grub\x86_64-efi\gfxmenu.mod (58.1 KB)
Extracting: E:\boot\grub\x86_64-efi\gfxterm.mod (16.7 KB)
Extracting: E:\boot\grub\x86_64-efi\gfxterm_background.mod (4.5 KB)
Extracting: E:\boot\grub\x86_64-efi\gfxterm_menu.mod (7.8 KB)
Extracting: E:\boot\grub\x86_64-efi\gptsync.mod (5.3 KB)
Extracting: E:\boot\grub\x86_64-efi\grub.cfg (219 bytes)
Extracting: E:\boot\grub\x86_64-efi\gzio.mod (11.7 KB)
Extracting: E:\boot\grub\x86_64-efi\halt.mod (6.7 KB)
Extracting: E:\boot\grub\x86_64-efi\hashsum.mod (8.3 KB)
Extracting: E:\boot\grub\x86_64-efi\hdparm.mod (10.3 KB)
Extracting: E:\boot\grub\x86_64-efi\help.mod (4.0 KB)
Extracting: E:\boot\grub\x86_64-efi\hexdump.mod (4.5 KB)
Extracting: E:\boot\grub\x86_64-efi\hfs.mod (10.0 KB)
Extracting: E:\boot\grub\x86_64-efi\hfsplus.mod (10.8 KB)
Extracting: E:\boot\grub\x86_64-efi\hfspluscomp.mod (4.3 KB)
Extracting: E:\boot\grub\x86_64-efi\http.mod (9.3 KB)
Extracting: E:\boot\grub\x86_64-efi\iorw.mod (4.7 KB)
Extracting: E:\boot\grub\x86_64-efi\jfs.mod (8.6 KB)
Extracting: E:\boot\grub\x86_64-efi\jpeg.mod (8.7 KB)
Extracting: E:\boot\grub\x86_64-efi\keylayouts.mod (6.4 KB)
Extracting: E:\boot\grub\x86_64-efi\keystatus.mod (3.1 KB)
Extracting: E:\boot\grub\x86_64-efi\ldm.mod (8.0 KB)
Extracting: E:\boot\grub\x86_64-efi\legacycfg.mod (43.8 KB)
Extracting: E:\boot\grub\x86_64-efi\legacy_password_test.mod (15.7 KB)
Extracting: E:\boot\grub\x86_64-efi\linux.mod (19.6 KB)
Extracting: E:\boot\grub\x86_64-efi\linux16.mod (8.8 KB)
Extracting: E:\boot\grub\x86_64-efi\linuxefi.mod (11.7 KB)
Extracting: E:\boot\grub\x86_64-efi\loadbios.mod (4.7 KB)
Extracting: E:\boot\grub\x86_64-efi\loadenv.mod (9.1 KB)
Extracting: E:\boot\grub\x86_64-efi\loopback.mod (4.8 KB)
Extracting: E:\boot\grub\x86_64-efi\ls.mod (6.4 KB)
Extracting: E:\boot\grub\x86_64-efi\lsacpi.mod (7.1 KB)
Extracting: E:\boot\grub\x86_64-efi\lsefi.mod (5.2 KB)
Extracting: E:\boot\grub\x86_64-efi\lsefimmap.mod (3.7 KB)
Extracting: E:\boot\grub\x86_64-efi\lsefisystab.mod (4.2 KB)
Extracting: E:\boot\grub\x86_64-efi\lsmmap.mod (3 KB)
Extracting: E:\boot\grub\x86_64-efi\lspci.mod (7.2 KB)
Extracting: E:\boot\grub\x86_64-efi\lssal.mod (3.8 KB)
Extracting: E:\boot\grub\x86_64-efi\luks.mod (9.6 KB)
Extracting: E:\boot\grub\x86_64-efi\lvm.mod (9.4 KB)
Extracting: E:\boot\grub\x86_64-efi\lzopio.mod (7.3 KB)
Extracting: E:\boot\grub\x86_64-efi\macbless.mod (4.9 KB)
Extracting: E:\boot\grub\x86_64-efi\macho.mod (10.7 KB)
Extracting: E:\boot\grub\x86_64-efi\mdraid09.mod (2.9 KB)
Extracting: E:\boot\grub\x86_64-efi\mdraid09_be.mod (2.9 KB)
Extracting: E:\boot\grub\x86_64-efi\mdraid1x.mod (2.7 KB)
Extracting: E:\boot\grub\x86_64-efi\memrw.mod (4.7 KB)
Extracting: E:\boot\grub\x86_64-efi\minicmd.mod (5.7 KB)
Extracting: E:\boot\grub\x86_64-efi\minix2.mod (5.6 KB)
Extracting: E:\boot\grub\x86_64-efi\minix2_be.mod (5.7 KB)
Extracting: E:\boot\grub\x86_64-efi\minix3.mod (5.7 KB)
Extracting: E:\boot\grub\x86_64-efi\minix3_be.mod (5.8 KB)
Extracting: E:\boot\grub\x86_64-efi\minix_be.mod (5.6 KB)
Extracting: E:\boot\grub\x86_64-efi\mmap.mod (9.4 KB)
Extracting: E:\boot\grub\x86_64-efi\moddep.lst (5.1 KB)
Extracting: E:\boot\grub\x86_64-efi\morse.mod (3.4 KB)
Extracting: E:\boot\grub\x86_64-efi\mpi.mod (42.5 KB)
Extracting: E:\boot\grub\x86_64-efi\msdospart.mod (3.8 KB)
Extracting: E:\boot\grub\x86_64-efi\multiboot.mod (20.4 KB)
Extracting: E:\boot\grub\x86_64-efi\multiboot2.mod (23.6 KB)
Extracting: E:\boot\grub\x86_64-efi\mul_test.mod (2.5 KB)
Extracting: E:\boot\grub\x86_64-efi\nativedisk.mod (6.6 KB)
Extracting: E:\boot\grub\x86_64-efi\net.mod (87.7 KB)
Extracting: E:\boot\grub\x86_64-efi\newc.mod (4.6 KB)
Extracting: E:\boot\grub\x86_64-efi\ntfs.mod (15.0 KB)
Extracting: E:\boot\grub\x86_64-efi\ntfscomp.mod (5.7 KB)
Extracting: E:\boot\grub\x86_64-efi\odc.mod (4.4 KB)
Extracting: E:\boot\grub\x86_64-efi\offsetio.mod (2.3 KB)
Extracting: E:\boot\grub\x86_64-efi\ohci.mod (15.6 KB)
Extracting: E:\boot\grub\x86_64-efi\partmap.lst (111 bytes)
Extracting: E:\boot\grub\x86_64-efi\parttool.lst (17 bytes)
Extracting: E:\boot\grub\x86_64-efi\parttool.mod (7.3 KB)
Extracting: E:\boot\grub\x86_64-efi\part_acorn.mod (2.4 KB)
Extracting: E:\boot\grub\x86_64-efi\part_amiga.mod (2.7 KB)
Extracting: E:\boot\grub\x86_64-efi\part_apple.mod (3.1 KB)
Extracting: E:\boot\grub\x86_64-efi\part_bsd.mod (4.3 KB)
Extracting: E:\boot\grub\x86_64-efi\part_dfly.mod (2.7 KB)
Extracting: E:\boot\grub\x86_64-efi\part_dvh.mod (2.3 KB)
Extracting: E:\boot\grub\x86_64-efi\part_gpt.mod (3.3 KB)
Extracting: E:\boot\grub\x86_64-efi\part_msdos.mod (3.1 KB)
Extracting: E:\boot\grub\x86_64-efi\part_plan.mod (2.6 KB)
Extracting: E:\boot\grub\x86_64-efi\part_sun.mod (2.3 KB)
Extracting: E:\boot\grub\x86_64-efi\part_sunpc.mod (2.6 KB)
Extracting: E:\boot\grub\x86_64-efi\password.mod (3 KB)
Extracting: E:\boot\grub\x86_64-efi\password_pbkdf2.mod (4.4 KB)
Extracting: E:\boot\grub\x86_64-efi\pata.mod (7.4 KB)
Extracting: E:\boot\grub\x86_64-efi\pbkdf2.mod (2.1 KB)
Extracting: E:\boot\grub\x86_64-efi\pbkdf2_test.mod (3.5 KB)
Extracting: E:\boot\grub\x86_64-efi\pcidump.mod (3.6 KB)
Extracting: E:\boot\grub\x86_64-efi\pgp.mod (19 KB)
Extracting: E:\boot\grub\x86_64-efi\play.mod (4.1 KB)
Extracting: E:\boot\grub\x86_64-efi\png.mod (10.1 KB)
Extracting: E:\boot\grub\x86_64-efi\priority_queue.mod (2.3 KB)
Extracting: E:\boot\grub\x86_64-efi\probe.mod (4.4 KB)
Extracting: E:\boot\grub\x86_64-efi\procfs.mod (3.9 KB)
Extracting: E:\boot\grub\x86_64-efi\progress.mod (3.2 KB)
Extracting: E:\boot\grub\x86_64-efi\raid5rec.mod (2.1 KB)
Extracting: E:\boot\grub\x86_64-efi\raid6rec.mod (3.4 KB)
Extracting: E:\boot\grub\x86_64-efi\random.mod (3.7 KB)
Extracting: E:\boot\grub\x86_64-efi\rdmsr.mod (3.1 KB)
Extracting: E:\boot\grub\x86_64-efi\read.mod (2.4 KB)
Extracting: E:\boot\grub\x86_64-efi\reboot.mod (1.7 KB)
Extracting: E:\boot\grub\x86_64-efi\regexp.mod (74.3 KB)
Extracting: E:\boot\grub\x86_64-efi\reiserfs.mod (13.6 KB)
Extracting: E:\boot\grub\x86_64-efi\relocator.mod (25.5 KB)
Extracting: E:\boot\grub\x86_64-efi\romfs.mod (5.8 KB)
Extracting: E:\boot\grub\x86_64-efi\scsi.mod (7 KB)
Extracting: E:\boot\grub\x86_64-efi\serial.mod (14.5 KB)
Extracting: E:\boot\grub\x86_64-efi\setjmp.mod (1 KB)
Extracting: E:\boot\grub\x86_64-efi\setjmp_test.mod (2.7 KB)
Extracting: E:\boot\grub\x86_64-efi\setpci.mod (8.3 KB)
Extracting: E:\boot\grub\x86_64-efi\shift_test.mod (3.2 KB)
Extracting: E:\boot\grub\x86_64-efi\shim_lock.mod (3.6 KB)
Extracting: E:\boot\grub\x86_64-efi\signature_test.mod (8.7 KB)
Extracting: E:\boot\grub\x86_64-efi\sleep.mod (3.6 KB)
Extracting: E:\boot\grub\x86_64-efi\sleep_test.mod (3.4 KB)
Extracting: E:\boot\grub\x86_64-efi\spkmodem.mod (3.3 KB)
Extracting: E:\boot\grub\x86_64-efi\squash4.mod (9.9 KB)
Extracting: E:\boot\grub\x86_64-efi\strtoull_test.mod (3.4 KB)
Extracting: E:\boot\grub\x86_64-efi\syslinuxcfg.mod (29.3 KB)
Extracting: E:\boot\grub\x86_64-efi\terminal.lst (162 bytes)
Extracting: E:\boot\grub\x86_64-efi\terminal.mod (6.7 KB)
Extracting: E:\boot\grub\x86_64-efi\terminfo.mod (18.6 KB)
Extracting: E:\boot\grub\x86_64-efi\test.mod (7.4 KB)
Extracting: E:\boot\grub\x86_64-efi\testload.mod (3.9 KB)
Extracting: E:\boot\grub\x86_64-efi\testspeed.mod (3.5 KB)
Extracting: E:\boot\grub\x86_64-efi\test_blockarg.mod (2.1 KB)
Extracting: E:\boot\grub\x86_64-efi\tftp.mod (8.6 KB)
Extracting: E:\boot\grub\x86_64-efi\tga.mod (6.4 KB)
Extracting: E:\boot\grub\x86_64-efi\time.mod (2.4 KB)
Extracting: E:\boot\grub\x86_64-efi\tpm.mod (6.3 KB)
Extracting: E:\boot\grub\x86_64-efi\tr.mod (3.7 KB)
Extracting: E:\boot\grub\x86_64-efi\trig.mod (2.2 KB)
Extracting: E:\boot\grub\x86_64-efi\true.mod (2.0 KB)
Extracting: E:\boot\grub\x86_64-efi\udf.mod (12.0 KB)
Extracting: E:\boot\grub\x86_64-efi\ufs1.mod (7.7 KB)
Extracting: E:\boot\grub\x86_64-efi\ufs1_be.mod (7.8 KB)
Extracting: E:\boot\grub\x86_64-efi\ufs2.mod (7.7 KB)
Extracting: E:\boot\grub\x86_64-efi\uhci.mod (10 KB)
Extracting: E:\boot\grub\x86_64-efi\usb.mod (15.4 KB)
Extracting: E:\boot\grub\x86_64-efi\usbms.mod (10.8 KB)
Extracting: E:\boot\grub\x86_64-efi\usbserial_common.mod (3.0 KB)
Extracting: E:\boot\grub\x86_64-efi\usbserial_ftdi.mod (3.5 KB)
Extracting: E:\boot\grub\x86_64-efi\usbserial_pl2303.mod (3.8 KB)
Extracting: E:\boot\grub\x86_64-efi\usbserial_usbdebug.mod (2.5 KB)
Extracting: E:\boot\grub\x86_64-efi\usbtest.mod (5.6 KB)
Extracting: E:\boot\grub\x86_64-efi\usb_keyboard.mod (5.8 KB)
Extracting: E:\boot\grub\x86_64-efi\verifiers.mod (3.6 KB)
Extracting: E:\boot\grub\x86_64-efi\video.lst (41 bytes)
Extracting: E:\boot\grub\x86_64-efi\video.mod (8.9 KB)
Extracting: E:\boot\grub\x86_64-efi\videoinfo.mod (5.3 KB)
Extracting: E:\boot\grub\x86_64-efi\videotest.mod (5.5 KB)
Extracting: E:\boot\grub\x86_64-efi\videotest_checksum.mod (3.8 KB)
Extracting: E:\boot\grub\x86_64-efi\video_bochs.mod (8.4 KB)
Extracting: E:\boot\grub\x86_64-efi\video_cirrus.mod (9.0 KB)
Extracting: E:\boot\grub\x86_64-efi\video_colors.mod (9.9 KB)
Extracting: E:\boot\grub\x86_64-efi\video_fb.mod (27.8 KB)
Extracting: E:\boot\grub\x86_64-efi\wrmsr.mod (2.4 KB)
Extracting: E:\boot\grub\x86_64-efi\xfs.mod (10.3 KB)
Extracting: E:\boot\grub\x86_64-efi\xnu.mod (41 KB)
Extracting: E:\boot\grub\x86_64-efi\xnu_uuid.mod (3.3 KB)
Extracting: E:\boot\grub\x86_64-efi\xnu_uuid_test.mod (3.4 KB)
Extracting: E:\boot\grub\x86_64-efi\xzio.mod (19.4 KB)
Extracting: E:\boot\grub\x86_64-efi\zfscrypt.mod (8.4 KB)
Extracting: E:\boot\grub\x86_64-efi\zstd.mod (78.1 KB)
Extracting: E:\casper\filesystem.manifest (52.4 KB)
Extracting: E:\casper\filesystem.manifest-remove (667 bytes)
Extracting: E:\casper\filesystem.size (11 bytes)
Extracting: E:\casper\filesystem.squashfs (1.5 GB)
Extracting: E:\casper\filesystem.squashfs.gpg (916 bytes)
Extracting: E:\casper\initrd (78.1 MB)
Extracting: E:\casper\vmlinuz (10.9 MB)
Extracting: E:\dists\eoan\main\binary-amd64\Packages.gz (6.3 KB)
Extracting: E:\dists\eoan\main\binary-amd64\Release (94 bytes)
Extracting: E:\dists\eoan\main\binary-i386\Packages.gz (677 bytes)
Extracting: E:\dists\eoan\main\binary-i386\Release (93 bytes)
Extracting: E:\dists\eoan\multiverse\binary-amd64\Packages.gz (40 bytes)
Extracting: E:\dists\eoan\multiverse\binary-amd64\Release (100 bytes)
Extracting: E:\dists\eoan\multiverse\binary-i386\Packages.gz (40 bytes)
Extracting: E:\dists\eoan\multiverse\binary-i386\Release (99 bytes)
Extracting: E:\dists\eoan\Release (6.4 KB)
Extracting: E:\dists\eoan\Release.gpg (819 bytes)
Extracting: E:\dists\eoan\restricted\binary-amd64\Packages.gz (40 bytes)
Extracting: E:\dists\eoan\restricted\binary-amd64\Release (100 bytes)
Extracting: E:\dists\eoan\restricted\binary-i386\Packages.gz (40 bytes)
Extracting: E:\dists\eoan\restricted\binary-i386\Release (99 bytes)
Extracting: E:\dists\eoan\universe\binary-amd64\Packages.gz (1.6 KB)
Extracting: E:\dists\eoan\universe\binary-amd64\Release (98 bytes)
Extracting: E:\dists\eoan\universe\binary-i386\Packages.gz (1.1 KB)
Extracting: E:\dists\eoan\universe\binary-i386\Release (97 bytes)
Extracting: E:\dists\stable (0 bytes)
  Ignoring Rock Ridge symbolic link to 'eoan'
Extracting: E:\dists\unstable (0 bytes)
  Ignoring Rock Ridge symbolic link to 'eoan'
Extracting: E:\EFI\BOOT\BOOTx64.EFI (1.3 MB)
Extracting: E:\EFI\BOOT\grubx64.efi (1.3 MB)
Extracting: E:\EFI\BOOT\mmx64.efi (1.2 MB)
Extracting: E:\install\mt86plus (178.4 KB)
Extracting: E:\isolinux\16x16.fnt (69.6 KB)
Extracting: E:\isolinux\aa.tr (2.0 KB)
Extracting: E:\isolinux\ab.tr (2.1 KB)
Extracting: E:\isolinux\ace.tr (2.1 KB)
Extracting: E:\isolinux\adtxt.cfg (0 bytes)
Extracting: E:\isolinux\ady.tr (2.1 KB)
Extracting: E:\isolinux\af.tr (2.4 KB)
Extracting: E:\isolinux\ak.tr (2.1 KB)
Extracting: E:\isolinux\am.tr (3.5 KB)
Extracting: E:\isolinux\an.tr (2.3 KB)
Extracting: E:\isolinux\arn.tr (2.1 KB)
Extracting: E:\isolinux\ary.tr (2.1 KB)
Extracting: E:\isolinux\as.tr (5.0 KB)
Extracting: E:\isolinux\ast.hlp (7.2 KB)
Extracting: E:\isolinux\ast.tr (2.3 KB)
Extracting: E:\isolinux\ay.tr (2.1 KB)
Extracting: E:\isolinux\az.tr (2.6 KB)
Extracting: E:\isolinux\ba.tr (2.1 KB)
Extracting: E:\isolinux\back.jpg (7.3 KB)
Extracting: E:\isolinux\be.hlp (11.4 KB)
Extracting: E:\isolinux\be.tr (4 KB)
Extracting: E:\isolinux\bem.tr (3.3 KB)
Extracting: E:\isolinux\ber.tr (2.1 KB)
Extracting: E:\isolinux\bg.hlp (11.4 KB)
Extracting: E:\isolinux\bg.tr (4.3 KB)
Extracting: E:\isolinux\bho.tr (2.1 KB)
Extracting: E:\isolinux\bn.hlp (14.8 KB)
Extracting: E:\isolinux\boot.cat (2 KB)
Extracting: E:\isolinux\bootlogo (1.2 MB)
Extracting: E:\isolinux\br.tr (2.3 KB)
Extracting: E:\isolinux\brx.tr (2.3 KB)
Extracting: E:\isolinux\bs.hlp (6.9 KB)
Extracting: E:\isolinux\bs.tr (2.3 KB)
Extracting: E:\isolinux\byn.tr (2.1 KB)
Extracting: E:\isolinux\ca.hlp (7.9 KB)
Extracting: E:\isolinux\ca.tr (2.6 KB)
Extracting: E:\isolinux\ca@valencia.tr (2.6 KB)
Extracting: E:\isolinux\ce.tr (2.7 KB)
Extracting: E:\isolinux\ceb.tr (2.4 KB)
Extracting: E:\isolinux\chain.c32 (24.4 KB)
Extracting: E:\isolinux\chr.tr (2.1 KB)
Extracting: E:\isolinux\ckb.tr (4.1 KB)
Extracting: E:\isolinux\co.tr (2.5 KB)
Extracting: E:\isolinux\crh.tr (2.1 KB)
Extracting: E:\isolinux\cs.hlp (7.2 KB)
Extracting: E:\isolinux\cs.tr (2.5 KB)
Extracting: E:\isolinux\csb.tr (2.6 KB)
Extracting: E:\isolinux\cv.tr (2.1 KB)
Extracting: E:\isolinux\cy.tr (2.3 KB)
Extracting: E:\isolinux\da.hlp (6.7 KB)
Extracting: E:\isolinux\da.tr (2.3 KB)
Extracting: E:\isolinux\de.hlp (7.6 KB)
Extracting: E:\isolinux\de.tr (2.5 KB)
Extracting: E:\isolinux\dtmenu.cfg (1.4 KB)
Extracting: E:\isolinux\dv.tr (5.1 KB)
Extracting: E:\isolinux\ee.tr (2.1 KB)
Extracting: E:\isolinux\el.hlp (13.1 KB)
Extracting: E:\isolinux\el.tr (4.6 KB)
Extracting: E:\isolinux\en.hlp (6.4 KB)
Extracting: E:\isolinux\en.tr (2.1 KB)
Extracting: E:\isolinux\en_AU.tr (2.1 KB)
Extracting: E:\isolinux\en_CA.tr (2.1 KB)
Extracting: E:\isolinux\en_GB.tr (2.1 KB)
Extracting: E:\isolinux\eo.hlp (6.7 KB)
Extracting: E:\isolinux\eo.tr (2.2 KB)
Extracting: E:\isolinux\es.hlp (7.5 KB)
Extracting: E:\isolinux\es.tr (2.3 KB)
Extracting: E:\isolinux\es_CO.tr (2.1 KB)
Extracting: E:\isolinux\et.hlp (6.6 KB)
Extracting: E:\isolinux\et.tr (2.2 KB)
Extracting: E:\isolinux\eu.hlp (7 KB)
Extracting: E:\isolinux\eu.tr (2.2 KB)
Extracting: E:\isolinux\exithelp.cfg (53 bytes)
Extracting: E:\isolinux\f1.txt (868 bytes)
Extracting: E:\isolinux\f10.txt (723 bytes)
Extracting: E:\isolinux\f2.txt (739 bytes)
Extracting: E:\isolinux\f3.txt (782 bytes)
Extracting: E:\isolinux\f4.txt (417 bytes)
Extracting: E:\isolinux\f5.txt (806 bytes)
Extracting: E:\isolinux\f6.txt (1.2 KB)
Extracting: E:\isolinux\f7.txt (916 bytes)
Extracting: E:\isolinux\f8.txt (1 KB)
Extracting: E:\isolinux\f9.txt (765 bytes)
Extracting: E:\isolinux\fa.tr (3.7 KB)
Extracting: E:\isolinux\fa_AF.tr (2.1 KB)
Extracting: E:\isolinux\ff.tr (2.1 KB)
Extracting: E:\isolinux\fi.hlp (7.0 KB)
Extracting: E:\isolinux\fi.tr (2.3 KB)
Extracting: E:\isolinux\fil.tr (2.5 KB)
Extracting: E:\isolinux\fo.tr (2.2 KB)
Extracting: E:\isolinux\fr.hlp (7.8 KB)
Extracting: E:\isolinux\fr.tr (2.5 KB)
Extracting: E:\isolinux\frp.tr (2.5 KB)
Extracting: E:\isolinux\fr_CA.tr (2.5 KB)
Extracting: E:\isolinux\fur.tr (2.2 KB)
Extracting: E:\isolinux\fy.tr (2.4 KB)
Extracting: E:\isolinux\ga.tr (2.5 KB)
Extracting: E:\isolinux\gd.tr (2.6 KB)
Extracting: E:\isolinux\gfxboot.c32 (10.1 KB)
Extracting: E:\isolinux\gfxboot.cfg (365 bytes)
Extracting: E:\isolinux\gl.hlp (7.4 KB)
Extracting: E:\isolinux\gl.tr (2.3 KB)
Extracting: E:\isolinux\gn.tr (2.1 KB)
Extracting: E:\isolinux\guc.tr (2.1 KB)
Extracting: E:\isolinux\gv.tr (2.4 KB)
Extracting: E:\isolinux\ha.tr (2.1 KB)
Extracting: E:\isolinux\haw.tr (2.1 KB)
Extracting: E:\isolinux\he.hlp (9.2 KB)
Extracting: E:\isolinux\he.tr (3.4 KB)
Extracting: E:\isolinux\hi.hlp (0 bytes)
Extracting: E:\isolinux\him.tr (2.1 KB)
Extracting: E:\isolinux\hr.tr (2.4 KB)
Extracting: E:\isolinux\hrx.tr (2.1 KB)
Extracting: E:\isolinux\hsb.tr (2.1 KB)
Extracting: E:\isolinux\ht.tr (2.1 KB)
Extracting: E:\isolinux\hu.hlp (7.6 KB)
Extracting: E:\isolinux\hu.tr (2.8 KB)
Extracting: E:\isolinux\hy.tr (4.1 KB)
Extracting: E:\isolinux\ia.tr (2.3 KB)
Extracting: E:\isolinux\id.hlp (6.9 KB)
Extracting: E:\isolinux\id.tr (2.1 KB)
Extracting: E:\isolinux\io.tr (2.1 KB)
Extracting: E:\isolinux\is.hlp (7.3 KB)
Extracting: E:\isolinux\is.tr (2.5 KB)
Extracting: E:\isolinux\isolinux.bin (38 KB)
Extracting: E:\isolinux\isolinux.cfg (179 bytes)
Extracting: E:\isolinux\it.hlp (7.0 KB)
Extracting: E:\isolinux\it.tr (2.3 KB)
Extracting: E:\isolinux\iu.tr (2.4 KB)
Extracting: E:\isolinux\ja.hlp (9.2 KB)
Extracting: E:\isolinux\ja.tr (3.5 KB)
Extracting: E:\isolinux\jbo.tr (3.3 KB)
Extracting: E:\isolinux\jv.tr (2.1 KB)
Extracting: E:\isolinux\ka.hlp (12.1 KB)
Extracting: E:\isolinux\ka.tr (5.3 KB)
Extracting: E:\isolinux\kab.tr (2 KB)
Extracting: E:\isolinux\kbd.tr (2.1 KB)
Extracting: E:\isolinux\kk.hlp (12.8 KB)
Extracting: E:\isolinux\kk.tr (4.1 KB)
Extracting: E:\isolinux\kl.tr (2.7 KB)
Extracting: E:\isolinux\km.hlp (18.2 KB)
Extracting: E:\isolinux\kn.tr (6.5 KB)
Extracting: E:\isolinux\ko.hlp (8.1 KB)
Extracting: E:\isolinux\ko.tr (2.8 KB)
Extracting: E:\isolinux\krc.tr (2.1 KB)
Extracting: E:\isolinux\ku.tr (2.5 KB)
Extracting: E:\isolinux\kw.tr (2.2 KB)
Extracting: E:\isolinux\ky.tr (3.7 KB)
Extracting: E:\isolinux\la.tr (2.2 KB)
Extracting: E:\isolinux\langlist (232 bytes)
Extracting: E:\isolinux\lb.tr (2.5 KB)
Extracting: E:\isolinux\ldlinux.c32 (116.4 KB)
Extracting: E:\isolinux\lg.tr (2.1 KB)
Extracting: E:\isolinux\li.tr (2.2 KB)
Extracting: E:\isolinux\libcom32.c32 (166.0 KB)
Extracting: E:\isolinux\libutil.c32 (22.1 KB)
Extracting: E:\isolinux\lld.tr (2.4 KB)
Extracting: E:\isolinux\ln.tr (2.5 KB)
Extracting: E:\isolinux\lo.tr (5.9 KB)
Extracting: E:\isolinux\lt.hlp (7.2 KB)
Extracting: E:\isolinux\lt.tr (2.5 KB)
Extracting: E:\isolinux\ltg.tr (2.4 KB)
Extracting: E:\isolinux\luo.tr (2.1 KB)
Extracting: E:\isolinux\lv.hlp (7.7 KB)
Extracting: E:\isolinux\lv.tr (2.5 KB)
Extracting: E:\isolinux\menu.cfg (437 bytes)
Extracting: E:\isolinux\mg.tr (2.7 KB)
Extracting: E:\isolinux\mhr.tr (3.6 KB)
Extracting: E:\isolinux\mi.tr (2.2 KB)
Extracting: E:\isolinux\miq.tr (2.1 KB)
Extracting: E:\isolinux\mk.tr (3.6 KB)
Extracting: E:\isolinux\mr.tr (6.4 KB)
Extracting: E:\isolinux\ms.tr (2.1 KB)
Extracting: E:\isolinux\mt.tr (2.1 KB)
Extracting: E:\isolinux\mus.tr (3.7 KB)
Extracting: E:\isolinux\nah.tr (2.1 KB)
Extracting: E:\isolinux\nan.tr (2.2 KB)
Extracting: E:\isolinux\nap.tr (2.1 KB)
Extracting: E:\isolinux\nb.hlp (6.8 KB)
Extracting: E:\isolinux\nb.tr (2.2 KB)
Extracting: E:\isolinux\nds.tr (2.3 KB)
Extracting: E:\isolinux\nl.hlp (7.0 KB)
Extracting: E:\isolinux\nl.tr (2.5 KB)
Extracting: E:\isolinux\nn.hlp (7 KB)
Extracting: E:\isolinux\nn.tr (2.2 KB)
Extracting: E:\isolinux\nso.tr (2.2 KB)
Extracting: E:\isolinux\ny.tr (2.4 KB)
Extracting: E:\isolinux\oc.tr (2.4 KB)
Extracting: E:\isolinux\oj.tr (2.1 KB)
Extracting: E:\isolinux\om.tr (2.1 KB)
Extracting: E:\isolinux\or.tr (2.2 KB)
Extracting: E:\isolinux\os.tr (3.2 KB)
Extracting: E:\isolinux\pam.tr (2.1 KB)
Extracting: E:\isolinux\pap.tr (2.3 KB)
Extracting: E:\isolinux\pl.hlp (7.4 KB)
Extracting: E:\isolinux\pl.tr (2.5 KB)
Extracting: E:\isolinux\pmy.tr (2.0 KB)
Extracting: E:\isolinux\prompt.cfg (176 bytes)
Extracting: E:\isolinux\ps.tr (2.1 KB)
Extracting: E:\isolinux\pt.hlp (7.4 KB)
Extracting: E:\isolinux\pt.tr (2.4 KB)
Extracting: E:\isolinux\pt_BR.hlp (7.3 KB)
Extracting: E:\isolinux\pt_BR.tr (2.5 KB)
Extracting: E:\isolinux\pt_PT.tr (2.2 KB)
Extracting: E:\isolinux\qu.tr (2.1 KB)
Extracting: E:\isolinux\ro.hlp (8.4 KB)
Extracting: E:\isolinux\ro.tr (2.5 KB)
Extracting: E:\isolinux\rom.tr (2.1 KB)
Extracting: E:\isolinux\rqtxt.cfg (135 bytes)
Extracting: E:\isolinux\ru.hlp (11.8 KB)
Extracting: E:\isolinux\ru.tr (4.1 KB)
Extracting: E:\isolinux\rw.tr (2.1 KB)
Extracting: E:\isolinux\sa.tr (2.7 KB)
Extracting: E:\isolinux\sc.tr (2.3 KB)
Extracting: E:\isolinux\sco.tr (2.1 KB)
Extracting: E:\isolinux\sd.tr (3.6 KB)
Extracting: E:\isolinux\se.tr (2.2 KB)
Extracting: E:\isolinux\shn.tr (6.6 KB)
Extracting: E:\isolinux\si.hlp (13.7 KB)
Extracting: E:\isolinux\si.tr (6.3 KB)
Extracting: E:\isolinux\sk.hlp (7.4 KB)
Extracting: E:\isolinux\sk.tr (2.7 KB)
Extracting: E:\isolinux\sl.hlp (6.8 KB)
Extracting: E:\isolinux\sl.tr (2.3 KB)
Extracting: E:\isolinux\sm.tr (2.1 KB)
Extracting: E:\isolinux\sml.tr (2.1 KB)
Extracting: E:\isolinux\sn.tr (2.3 KB)
Extracting: E:\isolinux\so.tr (2.2 KB)
Extracting: E:\isolinux\splash.pcx (25.2 KB)
Extracting: E:\isolinux\splash.png (12.2 KB)
Extracting: E:\isolinux\sq.hlp (7.8 KB)
Extracting: E:\isolinux\sq.tr (2.3 KB)
Extracting: E:\isolinux\sr.hlp (11.4 KB)
Extracting: E:\isolinux\sr.tr (4.3 KB)
Extracting: E:\isolinux\sr@ijekavianlatin.tr (2.1 KB)
Extracting: E:\isolinux\sr@latin.tr (2.1 KB)
Extracting: E:\isolinux\st.tr (2.1 KB)
Extracting: E:\isolinux\stdmenu.cfg (508 bytes)
Extracting: E:\isolinux\su.tr (2.1 KB)
Extracting: E:\isolinux\sv.hlp (7.1 KB)
Extracting: E:\isolinux\sv.tr (2.3 KB)
Extracting: E:\isolinux\sw.tr (2.2 KB)
Extracting: E:\isolinux\szl.tr (2.3 KB)
Extracting: E:\isolinux\ta_LK.tr (5.4 KB)
Extracting: E:\isolinux\te.tr (6.7 KB)
Extracting: E:\isolinux\tet.tr (2.1 KB)
Extracting: E:\isolinux\tg.tr (4 KB)
Extracting: E:\isolinux\th.hlp (12.8 KB)
Extracting: E:\isolinux\ti.tr (2.1 KB)
Extracting: E:\isolinux\tk.tr (2.1 KB)
Extracting: E:\isolinux\tl.tr (2.1 KB)
Extracting: E:\isolinux\tlh.tr (2 KB)
Extracting: E:\isolinux\tr.hlp (7.6 KB)
Extracting: E:\isolinux\tr.tr (2.4 KB)
Extracting: E:\isolinux\ts.tr (2.5 KB)
Extracting: E:\isolinux\tt.tr (4.1 KB)
Extracting: E:\isolinux\txt.cfg (613 bytes)
  Added 'persistent' kernel option
Extracting: E:\isolinux\ty.tr (2.1 KB)
Extracting: E:\isolinux\udm.tr (2.1 KB)
Extracting: E:\isolinux\ug.hlp (11.6 KB)
Extracting: E:\isolinux\uk.hlp (11.5 KB)
Extracting: E:\isolinux\uk.tr (4.2 KB)
Extracting: E:\isolinux\ur.tr (4.1 KB)
Extracting: E:\isolinux\uz.tr (2.7 KB)
Extracting: E:\isolinux\vec.tr (2.3 KB)
Extracting: E:\isolinux\vesamenu.c32 (26.1 KB)
Extracting: E:\isolinux\vi.hlp (9.5 KB)
Extracting: E:\isolinux\vi.tr (3.0 KB)
Extracting: E:\isolinux\wa.tr (2.2 KB)
Extracting: E:\isolinux\wae.tr (2.4 KB)
Extracting: E:\isolinux\wo.tr (2.1 KB)
Extracting: E:\isolinux\xh.tr (2.2 KB)
Extracting: E:\isolinux\yi.tr (2.1 KB)
Extracting: E:\isolinux\yo.tr (2.1 KB)
Extracting: E:\isolinux\zh_CN.hlp (6.1 KB)
Extracting: E:\isolinux\zh_CN.tr (2.2 KB)
Extracting: E:\isolinux\zh_HK.tr (2.4 KB)
Extracting: E:\isolinux\zh_TW.hlp (6.1 KB)
Extracting: E:\isolinux\zh_TW.tr (2.4 KB)
Extracting: E:\isolinux\zu.tr (2.1 KB)
Extracting: E:\isolinux\zza.tr (2.1 KB)
Extracting: E:\md5sum.txt (21.8 KB)
Extracting: E:\pics\blue-lowerleft.png (294 bytes)
Extracting: E:\pics\blue-lowerright.png (266 bytes)
Extracting: E:\pics\blue-upperleft.png (280 bytes)
Extracting: E:\pics\blue-upperright.png (290 bytes)
Extracting: E:\pics\debian.jpg (8.2 KB)
Extracting: E:\pics\logo-50.jpg (3.9 KB)
Extracting: E:\pics\red-lowerleft.png (353 bytes)
Extracting: E:\pics\red-lowerright.png (299 bytes)
Extracting: E:\pics\red-upperleft.png (321 bytes)
Extracting: E:\pics\red-upperright.png (344 bytes)
Extracting: E:\pool\main\e\efibootmgr\efibootmgr_15-1_amd64.deb (27.5 KB)
Extracting: E:\pool\main\g\grub2\grub-efi_2.04-1ubuntu12_amd64.deb (2.5 KB)
Extracting: E:\pool\main\g\grub2\grub-efi-amd64_2.04-1ubuntu12_amd64.deb (30.0 KB)
Extracting: E:\pool\main\g\grub2\grub-efi-amd64-bin_2.04-1ubuntu12_amd64.deb (684.7 KB)
Extracting: E:\pool\main\g\grub2\grub-efi-ia32_2.04-1ubuntu12_amd64.deb (30.0 KB)
Extracting: E:\pool\main\g\grub2\grub-efi-ia32-bin_2.04-1ubuntu12_amd64.deb (645.3 KB)
Extracting: E:\pool\main\g\grub2-signed\grub-efi-amd64-signed_1.128+2.04-1ubuntu12_amd64.deb (456.1 KB)
Extracting: E:\pool\main\l\lupin\lupin-support_0.57build1_amd64.deb (13.7 KB)
Extracting: E:\pool\main\m\make-dfsg\make_4.2.1-1.2_amd64.deb (158.5 KB)
Extracting: E:\pool\main\m\mouseemu\mouseemu_0.16-0ubuntu10_amd64.deb (16.2 KB)
Extracting: E:\pool\main\s\setserial\setserial_2.17-52_amd64.deb (35.1 KB)
Extracting: E:\pool\main\s\shim\shim_15+1533136590.3beb971-0ubuntu1_amd64.deb (561.2 KB)
Extracting: E:\pool\main\s\shim-signed\shim-signed_1.39+15+1533136590.3beb971-0ubuntu1_amd64.deb (335.4 KB)
Extracting: E:\pool\main\u\user-setup\user-setup_1.63ubuntu6_all.deb (134.5 KB)
Extracting: E:\pool\universe\c\caspar\caspar_20180315-2_all.deb (29.2 KB)
Extracting: E:\pool\universe\g\grub2\grub2_2.04-1ubuntu12_amd64.deb (2.5 KB)
Extracting: E:\preseed\cli.seed (212 bytes)
Extracting: E:\preseed\lubuntu.seed (353 bytes)
Extracting: E:\README.diskdefines (226 bytes)
Extracting: E:\ubuntu (0 bytes)
  Ignoring Rock Ridge symbolic link to '.'
Created: E:\syslinux.cfg → /isolinux/isolinux.cfg
Finalizing, please wait...
Created: E:autorun.inf
Created: E:autorun.ico

Found UAS (USB 3.0) device 'OCZ-AGIL ITY3 SCSI Disk Device' (174C:55AA)
Using autorun.inf label for drive E: 'Lubuntu 19.10 amd64'
Found non-USB removable device 'LITEONIT LMT-128M6M mSATA 128GB' => Eliminated
1 device found
Disk type: FIXED, Disk size: 60 GB, Sector size: 512 bytes
Cylinders: 7297, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 2
Disk ID: 0x000592E1
Drive has a Syslinux Master Boot Record
Partition 1:
  Type: FAT32 LBA (0x0c)
  Size: 1.9 GB (2039385600 bytes)
  Start Sector: 2048, Boot: Yes
Partition 2:
  Type: GNU/Linux (0x83)
  Size: 54.0 GB (57982030848 bytes)
  Start Sector: 3985223, Boot: No

[pbatard]

Thanks for logging an issue.

As I explained in the e-mail I sent earlier, the "tool" we use to create the ext file system is the exact same code as Linux uses which comes from e2fsprogs and which is maintainer by Theodore Ts'o, who is the main developer for the ext file systems on Linux. So, in terms of "tool", we could hardly be closer to what Linux uses for ext file system creation than we already are. Especially it should be pointed out that, because e2fsprogs has some Windows support, the core of the code was barely modified for our usage. As a matter of fact, if you clone the repository I linked to above and compare it to the code used by Rufus, you'll see that the only differences are for the backend. So really, for all intent and purposes, the code used by Rufus and the code used by the native Linux tools to create an ext file system is virtually identical and comes straight from same people.

Also, as opposed to what many other utilities do, and since Rufus doesn't have an installer in the first place anyway, we don't use external DLLs apart from the system ones (but of course, Windows does not have a system DLL that can be used to format a drive to ext). As a result, anything we reuse is pretty much the same as the official code, which we compile within the application itself. So I hope this will finish to convince you that, no, the issue is not the result of some "lazy" reuse of a dodgy DLL or us trying to (poorly) reinvent the wheel. Instead we spent a lot of effort making sure that we used the code that is closest to what Linux uses. Plus, you have to be very conscious that because Rufus is GPLv3, we can't really go around and reuse elements from closed source utilities, such as AOMEI Parition Assistant, which, last time I checked wasn't Open Source at all (please be mindful of confusing "freeware" with "Open Source", as it's not because something is gratis that it is actually free in the sense of software freedom).

Therefore, our expectation has been that, considering that the only code that we changed was for the I/O backend, and that this I/O backend doesn't appear to have much of an issue when we're writing root inodes and other stuff, the various ext2fs initialization calls we make, which again are supposed to perform the exact same operations as they do on Linux, might result in a file system that is properly initialized. If anything, this would lead us to think that the issue might be with the official code, whose Windows side probably hasn't received as much love as the Linux side, which might explain why the created file system trips e2fsck.

Which means that we now have to analyse the internals of ext2fs file system creation, to figure out why code that, for all intent and purposes, we do expect to behave in the same manner regardless of the platform, might not, and this is going to take a while since we have to familiarize ourselves with exactly the kind of stuff we were trying to avoid (i.e. getting super-knowledgeable about ext2/ext3 intrinsics) when we chose to go with "the reference" for formatting an ext file system.

Realistically then, unless someone helps us with that (for instance by providing some reports of "Rufus writes data X into inode Y at position Z whereas it should write data X' into inode Y' at position Z'", or even better, explaining precisely what we might be missing in the code to make our sequence of calls to what should be the same functions as mkfs.ext3 calls on Linux work), I expect that troubleshooting the issue is likely to take a couple of months at best, because figuring out what exactly might be wrong with ext bitmaps or inodes is not something you can achieve by taking a shortcut.

Also, as I mentioned elsewhere, whereas I did indeed see e2fsck errors (mostly Block bitmap differences on pass 5), I didn't really consider them a major issue considering that we have yet to receive a single report of effective data issues for ext partitions created with Rufus and I've seen some reports from Theodore Ts'o advising people with similar errors that "block allocation bitmap differences and free block/inode accounting information being wrong is normal" under some circumstances and that it is "unlikely (to be) anything serious".

All this to say that, whereas we will be investigating the issue to see if we can fix the e2fsck results, it's unlikely to happen as soon as you wish it will and that if some Linux folks, with knowledge of the ext2/ext3 intrinsics, want to shed some technical light as to what exactly e2fsck seems to complain about, and what we might be missing from our ext initialization (which, it should be pointed out, is not directly derived from mke2fs since, whereas the parts of the e2fsprogs code we reuse are licensed under LGPL, which allows us to include them into a GPLv3 application, unless told otherwise, mke2fs itself is licensed under GPLv2 only, which is not compatible with GPLv3, so we did have to take some guesswork about what needs to be called during ext init) we would appreciate it.

[sudodus]

Have you seen that e2fsprog is part of Cygwin? It might help in debugging (to check if it is subject to the same bug, and in general how it behaves. I guess Cygwin is FOSS (freer than AOMEI's tool).

https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86%2Fe2fsprogs%2Fe2fsprogs-1.42.12-1&grep=hat

[pbatard]

Yes, that's where the Windows support comes from in e2fsprogs, coz it sure isn't compatible with MSVC and MinGW. My worry however is that cygwin is doing so much to fool an application into believing that it runs on Linux (that's basically the whole motto of cygwin) that even the issue doesn't manifest itself there it won't tell much of anything except that code that was mostly designed for Linux like environments appears to work well in Linux-like environment... Oh, and if your idea is that Rufus could/should use cygwin behind the scenes, I'm going to have to disappoint you because any application that relies on cygwin has to rely on a (rather large) cygwin1.dll (which basically does the Windows abstraction to a Linux/Posix-like), which is a nonstarter for an application that both doesn't come with an installer and is very size conscious (i.e. I'm not going to double or triple the size of Rufus just so that I can take a shortcut in not identifying what exactly might be wrong when using MSVC/MinGW, which remains the proper way to try to address the problem).

As I said, I don't see any easy shortcut here, so troubleshooting this issue is going to take time.

[sudodus]

I understand, that you don't want to rely on any dll, and I think you have good reasons for that. As I said, it might help in debugging.

[sudodus]

Debugging results

I installed Cygwin and e2fsprogs and fdisk into it.

Then I could

1. Repair the ext3 file system created by Rufus using e2fsck so that it worked in the persistent live drive. This process was rather slow.

2. Overwrite the ext3 file system created by Rufus using mkfs.ext4 and it worked without errors in the persistent live drive and as checked afterwards with e2fsck in my main linux computer. This process was faster.

So it seems to me that Cygwin can do it. It means that the source code is healthy, and you should be able to use it successfully. Maybe the compiler options/flags used by Cygwin are available (in a makefile or similar). Maybe there is file system corruption because the write operations are not flushed completely, and you should sync and allow some time before and after creating the ext file system and before finishing Rufus.

[pbatard]

Maybe there is file system corruption because the write operations are not flushed completely, and you should sync and allow some time before and after creating the ext file system and before finishing Rufus.

I appreciate the help but I would also appreciate if you weren't trying so hard to clutch at straws.

Fixing issues is not "guesswork". It is deducing the cause from properly analysed effects, which still hasn't been done here. And for the record, we are opening the partition with FILE_SYNCHRONOUS_IO_NONALERT precisely so that having to flush the drive should not be needed. Also, if it was a flushing problem, we'd see a lot more inconsistencies than we are seeing in the e2fsck report (after all, leaving the drive plugged in for a while should make the errors go away), so it is exceedingly unlikely that this has to do with flushing the drive.

Also, a much more relevant test, since of course you've been using mkfs, which, as I explained above, we cannot use as is due to licensing, would be to port this code to cygwin and use that to format a drive, which is something I might do if I can't identify the issue through other means (because what I am not short of are ideas on how I can proceed to troubleshoot the issue. What I am short of is time).

Also, please be mindful that we're using ext3, not ext4. I am not planning to add ext4 support at this stage because this requires a lot of extra work and additional code, which doesn't seem very relevant to add for a persistent partition. As a matter of fact, my original plan for Rufus and persistence was to go for ext2 only, and a much better analysis (since it'll avoid a lot of the pitfalls that come from adding extra complexity) is to compare what Rufus does for ext2 with what Linux does for ext2 only, and fix that if needed, before moving to journalled. So that too is part of my current plan, which I will get to when I have a chance to do, but which will always be much slower than you'd like due to prioritization and time constraints.

At the moment, one of my first planned tests is going to be this: Create a virtual image in Linux (e.g. 32 MB) set with 0xFF bytes (to make it easier to see stuff that's init'd to zero) and format it to ext2 in Linux. Then do the same in Rufus and compare the inode and bitmap data, to see how they differ. Then, from that data, figure out the parts of the code used by Rufus that may introduce differences.

If you really want to help, you can actually carry out that test yourself, since, if you have a Windows platform, you can install VS2019 to run Rufus & debug Rufus, and I already have code to deal with the formatting of a 32 MB image in Rufus which all you have to do to use is uncomment the define for RUFUS_TEST at the top of rufus.h.

[sudodus]

1. I think it is OK with ext2, at least temporarily, if you think it is much easier to make it work than to make ext3 work.

2. I was only showing (with the most advanced case ext4) that the code works as it is implemented by Cygwin in Windows. I think it would have been worse, if Cygwin produced the same or similar errors as your implementation.

3. I have to think twice about taking the step into compiling and debugging the source code of Rufus.

[pbatard]

1. I think it is OK with ext2, at least temporarily, if you think it is much easier to make it work than to make ext3 work.

That's not exactly what I'm saying. What I am saying is that, to properly troubleshoot this issue it is much better to start by figuring out what needs to be done for the lowest common denominator (ext2) and then work our way up, than start with the more complex versions of the filesystem, and either have to figure out everything at once or sort out the elements that are irrelevant.

I am not planning to drop ext3 support from Rufus. I'm just saying that it will be easier to figure out what the problem is if we analyse the e2fsck issues for ext2 instead of ext3 when trying to troubleshoot this problem.

2. I was only showing (with the most advanced case ext4) that the code works as it is implemented by Cygwin in Windows.

Well, if the issue is the inode/bitmap layout (which is what e2fsck seems to report) then I don't think testing ext4 features tells us much, since my understanding is that ext4 doesn't fundamentally exert that aspect further compared to ext2.

I think it would have been worse, if Cygwin produced the same or similar errors as your implementation.

I would have been very surprised if cygwin produced an issue, as, if e2fsprogs does have a Windows implementation, and that one implementation is for cygwin, I'd expect there are quite a few people testing it for errors, as opposed to my MSVC/MinGW, which is something that I had to add myself for Rufus usage (and that I had to implement in a semi-blind manner because only part of the e2fsprogs source is compatible with Rufus) and therefore that I can only wish had as many eyeballs as e2fsprogs to check. I'm still kinda hoping the issue is a simple missing call during all the various steps that are required to set up an ext file system (as you can see from the code I linked to, there are quite a few that need to be leveraged), but I'm not exactly counting on the fix being that simple, as I'd expect very different results from e2fsck then...

It might be interesting to know if the e2fsprogs folks have a test suite that they use to validate file system creation (I haven't really looked into that), as opposed to create the file system and see if e2fsck complains...

3. I have to think twice about taking the step into compiling and debugging the source code of Rufus.

Which is not something I am requesting you to do. I am planning to do that when I have a chance. If you do have time to spare and want to help (and don't want to suffer the annoyance of having to contend with Windows), what I'd be more interested into is a technical explanation of what the e2fsck errors mean. For instance: "If e2fsck reports error X then it means that element Y, which is used to provide the file system data about <some specific thing>, is not set to its expected value Z".

That's actually one of the other avenues of what I'm planning to do: look at the e2fsck implementation to understand in details what it's really complaining about, as if we properly understand this data, it may become a lot easier to tell "Here, this is what's wrong!"

[MatthewForrester]

In the FAQ, Rufus users are urged to "remind distro maintainers that an open issue is affecting them too, rather than assume that things will get fixed on their own". So although I am basically a satisfied 'customer' of Rufus, I would like to report how this issue may be affecting me.

When Ubuntu 19.10 came out, I used Rufus to create a persistent live USB system. I got a workable system with Firefox and LibreOffice. However, even a 32GB USB stick did not have enough space for Steam (which should need <2 GB). I have described the situation in more detail in an Askubuntu question. Something seemed to be consuming huge amounts of space in the persistent partition. After posting on Askubuntu, I tried maxing out the persistent partition (same problem reoccurred) and creating the persistent 18.04LTS system recommended by Steam (triggering the expected casper bug). I have some screenshots showing oddities in disk utilization, but none of the low-level information requested above by @pbatard .

This week I tried the answer recommended by @sudodus . By using mkusb+dus (run on a non-persistent 18.04 created in Rufus), I have been able to get persistent 18.04LTS on the same USB stick as before, and to successfully install Steam.

Although this thread suggests that the two of you (@pbatard and @sudodus ) have had no previous contact, I have relied on both of your tools in order to get from Windows 7 to a working persistent Ubuntu USB, and I am grateful to both of you for the time that you have donated to your projects. Thank you!

In my opinion, Rufus is much easier to use for users coming from an English-speaking Windows background. But at the moment, it seems only mkusb is reliable. I wish both of you the best of luck in finding ways to work (together or separately) for the benefit of Linux users.

To finish, I would like to add an 'obiter dictum' on the FAQ comment chiding users for not reporting the Ubuntu casper bug. I guess that poor reporting will always be a particular headache for Rufus, and mkusb, because many of their users will also be encountering Ubuntu and/or Linux for the first time. In my case, I only started using Ubuntu as a sysadmin a few months ago, so my default assumption is that "I'm doing it wrong", rather than "I've encountered a bug"!

[sudodus]

I hope that all of us can co-operate for the benefit of Linux users :-)

Do you remember Alexander the great and the Gordian knot?

https://en.wikipedia.org/wiki/Gordian_Knot

I suggest that you let an experimental Rufus create a partition just big enough to extract everything from the iso file, extract the files, create the BIOS bootloader and add the boot option 'persistent'. Then skip creating a partition behind it (no partition, no ext3 file system) and let Ubuntu 19.10 create it automatically. It will work rather well, but maybe not perfect yet. You can see details about it at the following link,

https://help.ubuntu.com/community/Installation/iso2usb/diy

and particularly

https://help.ubuntu.com/community/Installation/iso2usb/diy#Let_Ubuntu_create_the_partition_for_persistence_automatically

If we find that it works well enough, this can be an option in Rufus (for Ubuntu 19.10 and later versions) alongside the current options.

[pbatard]

I would like to report how this issue may be affecting me.

Thanks. User reports like yours are an essential way to gauge the severity of an issue, as it provides additional elements to try to replicate an issue and come up with something that can be replicated for troubleshooting.

I'll start by restating that my main limiting factor to try to address the problem here is time. Unfortunately, even as it may look so externally, a file system intrinsic issue like this one is unlikely to be resolved in a "Oh, it behaves like this? Then I know exactly what section of the code needs to be patched and this shouldn't take more than 5 minutes to fix".

Instead, what's likely to need to happen is something closer to "In order to fix this problem, I need to understand how ext# inodes and bitmaps are created, where exactly they should be created and what content they need to hold. And I also need to understand, at the technical level, how the various elements of the file system are linked together. Then I can look at the outcome from different tests and try to devise what might actually be happening behind the scenes in order to fix it". Right now, I expect this to be a multiweek effort, which means I need to allocate enough time for it, which is the prime reason why I haven't started to look into it in earnest. Oh and sorry @sudodus but there is simply no way that, after I already spent many months adding support for ext formatting in Rufus, I'm going to drop the whole feature and tell users that they should just format the casper-rw partition in linux. First of all this is super inconvenient and second of all this type of quick and dirty workarounds does not align with what I strive for with Rufus. Plus this would require modifying the UI to add new elements which equates to waiting at least 2 months to get everything translated so that I can actually put a release out. So instead of speeding up the process it is much more likely to delay it... And yes, I do understand that it is frustrating to see your pet issue not being worked on, but that's just how real-life is. There are just too few developers for too much work, which forces prioritization and delays. But that does not mean that I do not consider this issue as an important matter that I want to see fixed ASAP. It's just the ASAP that's the root of the matter.

Now, this being said, I tried to run a few tests similar to what @MatthewForrester described (32 GB drive with a 17 GB partition) and I can confirm the problem with space allocation. Curiously, during my first test, everything seemed to be good, even after copying the Ubuntu 19.10 ISO to the casper partition (in order to see how the amount of used/free space would be reported), until I started to copy a 5 GB Windows ISO and found that I ran out of space. Then, after running the same thing a second time I found that the used space jumped way beyond what was expected after copying the Ubuntu ISO. So this would seem to indicate that the file system is pointing to inodes that haven't been set properly, which can either mean we're creating the inodes properly, but then not properly setting the table or whatever ext# uses as a means of pointing to inodes, or we are setting that table properly, but we are missing an inode initialization step so that Linux doesn't attempt to read garbage data from those inodes. Or it could be an issue with the bitmap tables (which are used in what manner, I don't know yet) if this is what's being used to report used/free space.

At any rate, as I pointed above, there's no way around getting familiar to what exactly is going on behind the scenes, by, for instance, comparing a sane file system with the one created by Rufus, to try to understand where exactly the problem lies, and then try to venture a fix. And there's no shortcut to accomplishing that besides devoting it the required time.

[sudodus]

"... tell users that they should just format the casper-rw partition in linux. First of all this is super inconvenient ..."

I'm sorry, but you did not read the link. Ubuntu 19.10 creates the partition and file system automatically the first time that the [persistent] live system is booted. It is not inconvenient, only a little delay (for this action to run).

Furthermore, Debian 10 does not have this feature, so your ext3 file system is necessary there.

[pbatard]

Ah, I heard the Ubuntu maintainers talk about adding this but I didn't realize that they had done it for 19.10. Still, it's going to be too confusing for users to handle things differently or even subvert the expectation that, if you set a persistent partition in Rufus, then it should be formatted before you boot the OS. Plus my other worry is that the bugfix will be retrofitted to 18.04, but not the automated partition creation (or other Ubuntu-based distros might not follow with the automated formatting), in which case we're going to have another slew of issues.

I'm still going to point out that what you are proposing is a workaround, whereas the proper way to address an issue is to fix it. If I had stated that I'm not planning to look into fixing this, it would make sense to try to go with a workaround. But not when my plan is and continues to be to try to address the issue when I have enough time to do so.

[MatthewForrester]

Thank you for taking the time to respond to my post.

> I'll start by restating that my main limiting factor to try to address the problem here is time. Unfortunately, even as it may look so externally, a file system intrinsic issue like this one is unlikely to be resolved in a "Oh, it behaves like this? Then I know exactly what section of the code needs to be patched and this shouldn't take more than 5 minutes to fix".

As I know nothing about filesystems, I completely accept that a solution will take time. I have made some very minor contributions to another open-source community and I know that my heart sinks when I realize that I'm going to have get my head around yet another subsystem in order to move ahead with the main project. I guess you must have a similar feeling.

Just a thought about how to manage this. As an interim step, would it perhaps be worth updating the FAQ so that Rufus users know that there is a problem? I may try to do this myself, but I won't be offended if you roll back since 'a little knowledge is a dangerous thing' and my text might be counterproductive.