PartialVolume/shredos.x86_64 v2023.08.2_25.0_x86-64_0.35

on GitHub

v2023.08.2_25.0_x86-64_0.35

Other software versions used within ShredOS for disc related operations

Issue No.1 workaround

Nvidia graphics or displayport: If ShredOS doesn't boot to nwipe but you do see the percentage progress and some initial kernel boot text but then nothing appears to happen on screen.

Solution: You may need to add nomodeset to /boot/grub/grub.cfg and /EFI/BOOT/grub.cfg on the USB flash drive as in the example below. As there still seems to be an issue with the Nvidia DRM drivers or displayport hardware.

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 nomodeset
}

Issue No.2 workaround

Unable to boot 0.35 on HP proliant dl360 g9 - kernel hangs at clocksource:switched to clocksource tsc with loglevel set to 7

Solution: Add noapic to both /boot/grub/grub.cfg and /EFI/BOOT/grub.cfg on the USB flash drive as in the example below.

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 noapic
}

Issue No.3 workaround - Shim lock protocol not found

UEFI boot: The kernel loads to 100% then the following error is displayed:

shim_lock protocol not found
...
failed to boot both default and fallback entries

Some bios have a setting where you select either Windows or other O.S. Makesure you select other, else you will get the above error.

Notable changes in this release - ShredOS

• Updated buildroot from 21.08.2 to 23.08.2, many changes to the Linux kernel and other software, too numerous to mention!
• Updated hexedit, hdparm, smartmontools, SG3_utils and nwipe to the latest versions.
• Nwipe PDF documents are also sent to the boot USB
• ShredOS waits for upto 30 seconds for the all USB devices to be initialised before launching nwipe, so that USB devices consistently show up in nwipe's device list on the first run after boot. Usually all USB devices have initialised after a 10-15 second delay.
• Nwipe reads /etc/nwipe/nwipe.conf and /etc/nwipe/nwipe_customers.csv from the USB flash drive at boot.
• Nwipe writes /etc/nwipe/nwipe.conf and /etc/nwipe/nwipe_customers.csv from ShredOS's ram drive back to USB flash drive on nwipe exit. This means any changes to nwipe's configuration via nwipes configuration screen or any changes manually made to the files will be saved back to the flash drive.
• Increased ShredOS's vfat partition size to 250MB which leaves about 25MB free space. This was done so that approximately 75 PDF certificates could be stored on the ShredOS partition.
• Added new driver: ChromeOS device drivers
• Added new driver: Surface Pro device drivers
• Added new driver: QLogic QLA2XXX Fibre Channel Support
• Added new driver: QLogic QEDI 25/40/100Gb iSCSI Initiator Driver Support
• Added new driver: Emulex LightPulse Fibre Channel Support
• Added new driver: Intel Carillo Ranch Backlight Driver
• Added new driver: Unified support for USB4 and Thunderbolt (USB4 and Thunderbolt driver. USB4 is the public specification based on the Thunderbolt 3 protocol. This driver is required if you want to hotplug Thunderbolt and USB4 compliant devices on Apple hardware or on PCs with Intel Falcon Ridge or newer.)

Notable changes in this release - Nwipe

• Nwipe can now create a multi-page PDF certificate that shows details of a specific discs erasure. The first page forms the certificate of erasure and subsequent pages show the drives smart data. Two related options have been added to nwipe's command line options -P, --PDFreportpath=PATH Path to write PDF reports to. Default is "." If set to "noPDF" no PDF reports are written. From the drive selection screen you can now press 'c' for config. This takes you to the configuration screen where you can select various PDF certificate related options such as enabling PDF, entering customer or company data for entry onto the certificate and enabling a preview of customer/company info prior to the drive selection screen starting.
• Nwipe now supports HPA/DCO detection, aka hidden sector detection. This is where the drive has been configured to report a smaller size to the operating system (O.S.) than it actually is. The HPA/DCO status is reported on the main drive selection screen as [HS? N/A] for drive that does not support HPA/DCO such as NvMe. [HS? YES] for a drive that is reporting a size smaller than it actually is, i.e has hidden sectors and [HS? NO] where the drive is reporting it's actual size correctly to the O.S. And finally [HS? ???] where nwipe cannot determine the HPA/DCO status as the drive is not responding to the ATA commands used to detect HPA/DCO. This might be because the drive does not support HPA/DCO or the interface adapter does not support ATA passthrough as is the case with a lot of the USB adapters on the market, but not all USB adapters. Nwipe does not currently allow removal of the HPA/DCO so you will still need to use hdparm to reset the drive so it reports its correct size before using nwipe to wipe the drive. HPA/DCO reset may be added in the next version. Thanks to @mdcato for the help testing the code and HPA/DCO results as displayed in the report.
• This bug only applies to ones wipe and one or zero's verification. A very rare occurrence of a incorrect percentage on completion. The actual wipe was completed correctly it was just that the percentage calculation was wrong. #459
• Nwipe now supports a configuration file /etc/nwipe/nwipe.conf. Currently it supports settings related to the PDF certificate but more options will be added in the future.
• If you are running nwipe within the KDE konsole terminal and you resize the window by pulling on the corners, occasionally nwipe will exit with the error message: "GUI.c,nwipe_gui_select(), loop runaway, did you close the terminal without exiting nwipe? Initiating shutdown now" The loop runaway detection has been made less sensitive, i.e 32 iterations per second of the GUI update can now be completed before a loop runaway is detected. previously it was 8. In practise when sizing the konsole window, anywhere between 1 and 17 iterations will occur.#467
• Improved temperature support for SAS drives. Thanks to @ggruber for all the code and testing he contributed.
• Disc sizes are now shown differently to provide more information about their size, a 1.2TB drive was shown as 1TB, now it is shown as 1200GB. Thanks to @ggruber for his code contribution.
• Interface/bustype type was reported as UNK for SAS drives, now reported correctly as SAS. Thanks to @ggruber for his code contribution.
• Interface/bustype type has been enhanced to show SAS-SSD when a SSD drive is present. Thanks to @ggruber for his code contribution.
• Nwipe's temperature retrieval code has been placed in it's own thread in order to reduce any delays in obtaining the temperature which previously resulted in a momentary freeze in the GUI wipe screen when updating it's stats. This wasn't noticeable if you were erasing a small number of drives but become apparent when wiping many, 20+ drives.
• Nwipe now automatically sorts drives alphabetically by device name that are the same length. i.e /dev/sda - /dev/sdz will be in order, followed by drives /dev/sdaa - /dev/sdaz in order followed by nvme or loop being at the end of the list.
• Increased the maximum excluded drives command line option from 10 to 30 drives.

Download Counters

Architecture/format/mode	Download link
i586_32bit .iso for CD/DVD Vanilla
i586_32bit .img for USB Vanilla
x86-64 .img for USB Vanilla
x86-64 .iso for CD/DVD/Ventoy nomodeset
x86-64 .iso for CD/DVD/Ventoy Vanilla

.iso and .img Notes

• The .img file for writing to a USB flash drive is both legacy (bios) and UEFI bootable.
• The .iso file for CD-R/DVD-R is legacy bootable only if burned to DVD/CD, however if you copy the .iso to a Ventoy USB stick it is bootable on both UEFI & legacy hardware.

Ventoy Notes

If Ventoy's 'normal' mode does not work try 'Ventoy's 'grub2' mode. To enable grub2 mode in Ventoy, when the Ventoy list of Iso/img files appear type control +r to toggle into grub2 mode, then select the ShredOS .iso. If you try to boot the ShredOS .iso using Ventoy's 'normal' mode you will end up at the grub prompt on some systems.

What's the difference between Ventoy's normal & grub2 modes?
Well it appears that in normal mode Ventoy uses ShredOS's own grub code to boot ShredOS, while in grub2 mode Ventoy uses it's own code. Using Ventoys own grub code when in grub2 mode may allow you to boot when normal mode doesn't work however, Ventoy's grub does not load the progress module so you won't see the progress percentage as the ShredOS kernel is loaded. ShredOS also includes modules for PXE booting.

The ShredOS .iso labeled nomodeset disables the Linux Direct Rendering Manager (DRM) and so remains in simple framebuffer mode. This mode is compatible with most graphics hardware and avoids any buggy graphics drivers.

64bit .img and .iso for modern Intel & compatible processors post Pentium 4.

The .iso is for burning to DVD/CD and copying onto a Ventoy USB stick.

32bit .img and .iso for Pentium 4 and earlier CPUs.

Pentium MMX, K5, K6, K6-II, K6-III, Pentium Pro, Pentium II, Pentium III, Athlon, Athlon XP, Opteron*, Athlon FX-51*, Athlon FX-53*, Athlon 64* Pentium 4 (32 bit).

. * = 32-bit/64-bit. The x86 32 bit version of ShredOS will often run on x86 64 processors but not all 64 bit processors due to limitations in the CPU or bios.

Checksums

sha1 1a8bffffbc3c04479e9f0557b8e0e0ee19420957  shredos-2023.08.2_25.0_i586_0.35_20240210.iso
sha1 5ff6ce56a468e902b03bc306c82ed8cef06439ba  shredos-2023.08.2_25.0_i586_0.35_20240219.img
sha1 c0e7c6a1260979280543b95d6faca6addf7195ac  shredos-2023.08.2_25.0_x86-64_0.35_20231110.img
sha1 c98389b64b2314d3ce39ed3c40b6d80a6cc9db68  shredos.x86_64-2023.08.2_25.0_x86-64_0.35_nomodeset.iso
sha1 04d1ce8127818140a30376fdd9a2ed5586e5c617  shredos-2023.08.2_25.0_x86-64_0.35_20240207.iso