{{ message }}
/ rufus Public

# The ext3 file system in the partition for persistence has errors#1396

Closed
opened this issue Oct 24, 2019 · 28 comments
Closed

# The ext3 file system in the partition for persistence has errors #1396

opened this issue Oct 24, 2019 · 28 comments
Assignees

## 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.

• 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...
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)
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\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\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\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\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\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\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\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\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\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\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\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\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)
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\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:\ubuntu (0 bytes)
Ignoring Rock Ridge symbolic link to '.'
Created: E:\syslinux.cfg → /isolinux/isolinux.cfg
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 commented Oct 24, 2019 • edited

 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.

self-assigned this Oct 24, 2019

### sudodus commented Oct 25, 2019

 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 commented Oct 25, 2019 • edited

 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 commented Oct 26, 2019

 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.

## 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 commented Oct 26, 2019 • edited

 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 commented Oct 26, 2019

 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. 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. I have to think twice about taking the step into compiling and debugging the source code of Rufus.

### pbatard commented Oct 26, 2019 • edited

 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. 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... 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 , 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 commented Nov 6, 2019 • edited

 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 commented Nov 6, 2019 • edited

 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 commented Nov 6, 2019

 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 commented Nov 6, 2019 • edited

 "... 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 commented Nov 6, 2019 • edited

 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 commented Nov 7, 2019

 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.

### pbatard commented Nov 7, 2019

 Nah, what I'm planning to do is add the EXPERIMENTAL tag back to the feature in the ChangeLog because that's where you want to advertise that a new feature may still have bugs before people try to use it. It actually used to be flagged EXPERIMENTAL until the last release, since it was still too new to declare as stable, so I'm just going to reinstate it as such for a while.

### MatthewForrester commented Nov 8, 2019

 OK, I won't touch the FAQ then. Thank you for your software and best of luck.

### sudodus commented Nov 8, 2019 • edited

 It actually used to be flagged EXPERIMENTAL until the last release, since it was still too new to declare as stable, so I'm just going to reinstate it as such for a while. OK, I won't touch the FAQ then. Thank you for your software and best of luck. 👍

added a commit that referenced this issue Nov 9, 2019
 [misc] mention that ext and persistence support should still be viewe… 
 80a2bce 
…d as EXPERIMENTAL

* This is in relation to #1396
* Also fix a small typo

### pbatard commented Feb 9, 2020

 Just a small update for those who must be despairing to see progress on this. First of all to tell you that I am working behind the scenes to try to fix this issue, but, as indicated above, it does require time. I can however provide a few elements of what I've found so far: One of the e2fsck warnings seems to be due to having the resize_inode feature enabled. Once you remove that feature, the warning no longer appears. The issue only seems to manifest itself for partitions that are larger than 4 GB, and it looks like the problematic inodes are all located above 4 GB on the partition. So there's a possibility we have a 32-bit variable somewhere that's overflowing, though we're mostly using block indexes rather than byte indexes, so with 1024 or 4096-byte blocks, we should have some margin at the block level before we see an overflow. Besides, I tried to make sure to use 64-bit wherever I could (e.g. I switched from blk_t to blk64_t in parts of the code). Then again, the current code (i.e. the stuff that I didn't write) does generate a lot of warnings about arithmetic overflows from using operators on a 32-bit value and then casting the result to 64-bit value. Those are usually benign, so most codebases ignore them (with the right warning level, gcc on Linux will produce those as well) but maybe there's are instances somewhere where these warnings are relevant. I think I probably enabled or forgot to enable an ext option/feature that makes the formatting much slower than it could be, so I'll be trying to identify that as well. Once again, I have no idea when I'll get a chance to dive more deeply into these, but, despite what it may look like, progress is being made on this issue, albeit slowly.

### marcosfrm commented Feb 10, 2020

 With EXT4, uninit_bg (superseded by metadata_csum in recent e2fsprogs/kernel) will make huge difference in formatting time on large devices. FSArchiver has some logic for this: https://github.com/fdupoux/fsarchiver/blob/master/src/fs_ext2.c

### pbatard commented Feb 10, 2020 • edited

 I appreciate the help, but I'm not using ext4 at all in Rufus and I currently have no plans to add that feature (too much complexity for too little benefit). Also the code you pointed to is GPLv2 ONLY (not GPLv2 or later) which means that, even if I wanted, I couldn't use any of it in Rufus (GPLv3 or later)... which actually is probably part of the reason we're having trouble with ext2/ext3 formatting, as mke2fs is GPLv2 only, so I couldn't reuse that code for formatting (but the ext2fs library parts are LGPLv2. which makes them usable in a GPLv3 project). Still the point I was making above was about ext2/ext3 options, as I am playing with a version of mke2fs on Windows, and seeing that it formats faster than Rufus, which makes me think there's probably an option (besides lazyinit which we also try to use in Rufus) that we're missing...

mentioned this issue Feb 10, 2020

### pbatard commented Feb 12, 2020 • edited

 Okay, I think I have finally pinpointed the issue. The issue has to do with this specific line of code: offset.QuadPart = block * channel->block_size + nt_data->offset; As I mentioned above, it has to do with a 32-bit overflow when computing values, and more specifically with DUMB compilers not performing 64-bit computations when they really should. You see, in the line above, offset.QuadPart and nt_data->offset are 64-bit values, and, since compilers are allegedly supposed to do the smart thing when performing calculation, one would expect that, even as block and channel->block_size are 32-bit values, the compiler will be smart enough to compute and move the product of these 32-bit values into 64-bit registers (because, programmatically, there's absolutely no logical reason whatsoever to want to limit that multiplication to 32-bit when the result is going to end up in a 64-bit variable). Alas, a 32-bit multiplication instead of a 64-bit one is exactly what's happening here. And it looks like both MSVC and gcc suffer from that illogical behaviour, because, unless you specifically tell the compiler that you do want to compute block * channel->block_size as 64-bit (by adding an explicit cast like ((uint64_t)block) * channel->block_size), that darn multiplication is performed as 32-bit, which means that, as soon as you try to write to a block of data that resides above 4 GB on the media, you're writing to the wrong address. Hence e2fsck finding loads of issues for any inode above 4 GB, since none of them have been initialized... Ouch! Damn, and I was always told that trying to micro-manage or micro-optimise what compilers do was a waste of time because they are supposed to be designed to do the smart thing. So much for that... Heck, it almost makes one wish we were still programming in pure assembly, because such an issue would certainly not happen then (since we'd very explicitly specify that we are working on 64-bit register for that multiplication)... Oh and for those who wonder why we're not using a 64-bit block variable in the first place, or more specifically the 64-bit version of the write_blk() call, the reason is that, with a block size of 4096 bytes or more for large volumes (and code that explicitly checks for 32-bit overflow for the block variable), you're going to have to create a 16 TB or larger partition before you run into the 32-bit limit, which seems a bit unrealistic for a persistent partition. Plus the underlying ext2fs code I lifted still has tons of internal calls to the 32-bit version of write_blk(), so it didn't make much sense to bother with the 64-bit version... as long as the block * block_size computation was properly carried out using 64 bits. Now that I've seen the result of trusting compilers (and/or pre-existing code) to do the right thing, I guess I should have taken a page from what unix_io.c does, moved the core write block function to 64 bit and just added 32 → 64 bit invocation for the 32-bit calls like so: errcode_t unix_write_blk(io_channel channel, unsigned long block, int count, const void *buf) { return unix_write_blk64(channel, block, count, buf); } Now, as to the reason why cygwin seems to be fine, it's because, from what I could see, it uses the UNIX I/O manager rather than the NT I/O manager for low level disk I/O, so of course, the 32-bit truncation of the multiplication, that (unless it's a side effect of adding the offset, which I don't believe it is) you do get in the original ext2fs code, does not apply since this specific code is actually not the one the official e2fsprogs uses on Windows/cygwin. Oh well, I already had a few fixes I picked, that I was planning to upstream to e2fsprogs once I had finalized ext formatting in Rufus, so I guess I'll just have to add one more...

### sudodus commented Feb 12, 2020 • edited by pbatard

 Congratulations to this good catch, Pete :-) Best regards Nio

### pbatard commented Feb 12, 2020

 Okay, I will close this issue with the next commit I push, since this should now be fixed. There's a TEST version of Rufus 3.9 you can use, that includes the fix, and which you can download here if you want to confirm for yourself that the problem reported above has been addressed.

closed this as completed in  67d324f  Feb 12, 2020

### sudodus commented Feb 12, 2020 • edited by pbatard

 Hi Pete, I made a persistent live Lubuntu 19.10 with this TEST version of Rufus. It looks good. - I tested the ext3 file system with e2fsck and it was healthy. - When booted into the persistent live system, it worked as it should. Congratulations! Now I feel happy with Rufus again :-) Best regards Nio

### pbatard commented Feb 12, 2020

 Great! Thanks for reporting.

### sudodus commented Feb 17, 2020 • edited by pbatard

 Hi Pete, I noticed a regression. Our new kind of persistence no longer works in the developing version of Ubuntu. I wrote a bug report. I am rather sure that it will also affect Rufus, so I suggest that check if it'affects you and in that case that you add heat to the bug report by clicking on 'affects me too'. https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672 You find the current daily iso files via the ubuntu iso tracker http://iso.qa.ubuntu.com/qatracker/milestones/408/builds Best regards Nio

### pbatard commented Feb 17, 2020

 Thanks for the heads up. I'll try to test this when I get a chance.

pushed a commit to heichalot/rufus that referenced this issue Mar 13, 2020
 [extfs] fix inodes not being initialized above 4 GB 
 eb52f59 
* So, as it happens, when assigning the product of two 32-bit variables into a 64-bit one,
compilers default to being *DUMB* and, against all reasonable expectations, do not perform
that multiplication as a 64-bit operation (even when the code is compiled as x64). Wow,
that's really great decision making by compiler designers if I ever saw some... Whoever
decided that C developers would much rather want truncation and 32-bit overflows, instead
of the expected *LOGICAL* behaviour of conducting arithmetic operations as 64-bit when the
result will be assigned to a 64-bit variable, need to be condemned to a lifetime of trying
to help elderly folks trying to conduct simple computing tasks as a punishment...
Anyhoo, nt_write_blk()'s offset.QuadPart = block * channel->block_size + nt_data->offset
was overflowing 32-bit as soon as block * channel->block_size went over the 4 GB mark,
with the disastrous results one can expect. Considering that this is code we practically
lifted verbatim from e2fsprogs, I guess e2fsprogs' NT I/O manager was never properly
tested with anything larger than a 4 GB. Awesome!
* We fix the above by doing what unix_io.c does and setting the 32-bit read/write_blk()
calls to be wrappers around their 64-bit counterpart (since, once you deal with a 64-bit
block variable, the computation is conducted as 64-bit).
* Also remove a bunch of stuff we don't need from config.h
* Closes pbatard#1396

### lock bot commented May 20, 2020

 This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.

bot locked and limited conversation to collaborators May 20, 2020