Ventoy - No PDF report and logs after successfull wipe

[BEBU88]

With the previous version of shredos nwipe logs and pdf reports where saved to my ventoy stick. I did a wipe with the latest version of shredos and all logs and pdf report are gone. Maybe they where just written to RAM. Is this a bug? Or do I need to use the images with extra writable partition on ventoy?

[PartialVolume]

It should still work but I'll run some checks to make sure.

On the system this happens to, how many discs including USB devices were on the system? Was there just one USB device?

Was the ventoy stick formatted differently than previous Ventoy sticks you made.

With ShredoS booted up and the Ventoy stick plugged in can you ALT F2 to the second virtual terminal and run fdisk -l (-l is lowercase L) and post the output here. Thanks.

[PartialVolume]

One further question. Which .iso or .img are you using?

[BEBU88]

There are 3 disks on the system. Internal ssd /dev/nvme0n1, the wiped disk which ist plugged in via usb /dev/sda and the ventoy stick dev/sdb.
This is the output of fdisk -l

I used the ventoy stick before with the previous version of shredos. Last thing I did was to update ventoy to the latest version and replaced the old iso with the new one. I used shredos-2025.11_28_x86-64_v0.40_20260204.iso for this

[PartialVolume]

I just tested shredos-2025.11_28_x86-64_v0.40_20260204.iso, copied to to my Ventoy stick and all the logs and the PDF was saved to the Ventoy stick.

Can you initiate a wipe then abort it with control C, the logs and PDF should get saved at that point, the text may tell you whats going on, however if you ALT F2 to the terminal and type ls there should be a file called transfer log. Can you post that or the last 20 lines of it. more transfer.log

[PartialVolume]

I'm just thinking of possible reasons it might not work.

1. ShredOS looks for a file on the Ventoy stick that contains shredos-2025.11_28_x86-64_v0.40_20260204 in the filename so when you copy the .iso to the Ventoy stick you must not change the filename or at least not edit that part of the filename.
2. If any of the other discs on the system contain that filename shredos-2025.11_28_x86-64_v0.40_20260204.iso in their root file system the files may get copied there instead of the ventoy stick.

The transfer logs will tell us if they failed to get copied or they were copied to a drive you were not expecting them to be copied to.

[BEBU88]

This is the output of transfer.log:

[2026/02/08 10:45:02] Transfer log
[2026/02/08 10:45:02] Created the /imported directory
[2026/02/08 10:45:02] Created the /etc/nwipe directory
[2026/02/08 10:45:02] Created the /exported directory
[2026/02/08 10:45:02] nwipe_launcher: Searching for exFAT/FAT32/FAT16 USB drive.
mount: /boot_tmp: unknown filesystem type 'BitLocker'.
dmesg(1) may have more information after failed mount system call.
umount: boot_tmp: not mounted.
[2026/02/08 10:45:03] nwipe_launcher: Found a exFAT/FAT32/FAT16 USB drive
mount: /boot_tmp: unknown filesystem type 'BitLocker'.
dmesg(1) may have more information after failed mount system call.
umount: boot_tmp: not mounted.
[2026/02/08 10:45:03] Archiving nwipe logs to mount: /boot_tmp: unknown filesystem type 'BitLocker'.
dmesg(1) may have more information after failed mount system call.
umount: boot_tmp: not mounted.
/dev/sdb1
[2026/02/08 10:45:03] archive_log.sh: FAILED to mount the FAT32 partition mount: /boot_tmp: unknown filesystem type 'BitLocker'.
dmesg(1) may have more information after failed mount system call.
umount: boot_tmp: not mounted.
/dev/sdb1 to /archive_drive
[2026/02/08 10:45:04] archive_log.sh: FAILED to unmount the FAT partition
[2026/02/08 10:45:04] archive_log.sh: FAILED to copy nwipe log files to mount: /boot_tmp: unknown filesystem type 'BitLocker'.
dmesg(1) may have more information after failed mount system call.
umount: boot_tmp: not mounted.
/dev/sdb1, exit code 7
mount: /boot_tmp: unknown filesystem type 'BitLocker'.
dmesg(1) may have more information after failed mount system call.
umount: boot_tmp: not mounted.
[2026/02/08 10:52:32] Archiving nwipe logs to mount: /boot_tmp: unknown filesystem type 'BitLocker'.
dmesg(1) may have more information after failed mount system call.
umount: boot_tmp: not mounted.
/dev/sdb1
[2026/02/08 10:52:32] archive_log.sh: FAILED to mount the FAT32 partition mount: /boot_tmp: unknown filesystem type 'BitLocker'.
dmesg(1) may have more information after failed mount system call.
umount: boot_tmp: not mounted.
/dev/sdb1 to /archive_drive
[2026/02/08 10:52:33] archive_log.sh: FAILED to unmount the FAT partition
[2026/02/08 10:52:33] archive_log.sh: FAILED to copy nwipe log files to mount: /boot_tmp: unknown filesystem type 'BitLocker'.
dmesg(1) may have more information after failed mount system call.
umount: boot_tmp: not mounted.
/dev/sdb1, exit code 7

---

Looks like BitLocker partition is causing problems here. I had to manually mount the ventoy partition to copy over the file.

[PartialVolume]

It does look like it. Is that Ventoy flash drive encrypted by Bitlocker?

[BEBU88]

No, but the PC I used is.

[PartialVolume]

You said you manually mounted the Ventoy stick from ShredOS and that worked. I'm wondering whether references to Bitlocker, is ShredOS trying to mount your main drive and failing, it should then go on to look for the Ventoy drive or further drives until it either found the ShredOS boot drive or tested all drives and then gives up.

I'm puzzled as to why it's not mounting the drive if you can manually mount it from ShredOS.

[PartialVolume]

According to the log it does attempt to mount /dev/sdb1 and fails with the Bitlocker unknown filesystem error. It looks like Bitlocker does change the Ventoy partition table in some way even though it might not be encrypted. Strange one indeed.

[BelgianMonster]

Hi, I wanted to let you know that I'm having the same issue. I've never used shredos before, so I can't compare with previous versions. But I'm testing on a laptop with a bitlocker enabled drive. Plugged in a nvme ssd with a usbdock + shredos on a normal usb stick. Wiping works, but saving the pdf doesn't work. It says unknown filesystem type 'bitlocker" and it asks to save to a usb, I choose to save to usb but gives the same error

[desertwitch]

I'm also experiencing this problem not from Ventoy but also with /dev/sdb1, will investigate more.

[desertwitch]

@PartialVolume

Found the issue:
https://github.com/PartialVolume/shredos.x86_64/blob/master/board/shredos/fsoverlay/usr/bin/find_shredos_boot_disc.sh

All these lines:
mount $drive $drive_dir 2>&1 | tee -a transfer.log

Specifically this part (not just in mount lines, multiple occasions):
2>&1 | tee -a transfer.log

Print also to standard output, not just to the logfile.
With tee, the calling script will see errors on standard output, not standard error.

This mangles the expected result of the find_shredos_boot_disc.sh script.
It's also why the user sees all these error messages as interleaved on their screen.
The calling launcher script expects one device path as return, not an error message.

Fixing all lines with 2>&1 | tee -a transfer.log to &>> transfer.log
(redirect all to log, don't print out) resolved the problem for me entirely.

Alternatively you could try printing the error messages to standard error instead.
Then a calling script will not see them in standard output, where it expects the result.

The specific issue is that it found two suitable devices, /dev/sda1 (Bitlocker), /dev/sdb1 (USB).
It tried to mount the first one, failed, the resulting error message polluted the standard output.
After the standard output was polluted, even the successful device could not be parsed anymore.

This probably didn't surface more often because 99% of devices will mount fine, just not Bitlocker.

[desertwitch]

Also note $? will return the exit code of the last command in the pipe, so tee not mount - that's another problem with the first mount check (will resolve if you use my correction, or need to use PIPESTATUS if you keep the pipes).

[PartialVolume]

@desertwitch nice catch, did you want to do a PR or shall I do it?

[desertwitch]

I'll fix it up and do a PR, no problem. 😉