Boot file ? [Solved, added the ability to configure nwipe/ShredOS default wipe settings]

[miharix]

Where is the file located that starts default nwipe if using the iso?

I would like to change default wipe option.

Ps: Great work !

[PartialVolume]

If you want to change the nwipe options from within ShredOS, you'll want to edit /usr/bin/nwipe_launcher. You can then refresh nwipe with a Control-C. However, this won't be a persistent change across reboots of shredos.

If you want to permanently change options to nwipe that are remembered across reboots of shredos you will need to compile Shredos yourself, again this means editing nwipe_launcher but in the buildroot directory structure, this is found at ../shredos.2020.02/board/shredos/usr/bin/

Looking at future updates to Shredos I would like to add a default nwipe_launcher to the root of the USB memory stick, so you can easily edit nwipe's default launch options, rather than having to recompile.

If you recompile, good luck!, it will take anything from 45 minutes to several hours to complete, depending on your hardware. I use dual XEON processors compiling both the 32bit and 64bit versions and it takes about 45 minutes for me.

[elipsius]

Is there parameters I can put in the kennel line to set to autonuke similar to dban. I want to use the image as an alternate boot option in my grub config (able to do with dban) to launch and start an autonuke of my system as a live boot.

[PartialVolume]

@elipsius Not with the current version but let me take a look at the code and see if I can add that feature.

[PartialVolume]

@elipsius I've taken a look at the code, yes that's doable. Can you give me an example of the change you would make to the kernel command line with DBAN.

I'm thinking along the lines of Shredos=-autonuke

Basically any valid nwipe option could be used

[PartialVolume]

I'm also thinking this would be an good way to set the keyboard type being used, i.e loadkeys=UK etc

[hameau]

Happy to find this development of shredos!

While you're looking at this enhancement, would it be possible to make such command-line options suitable for PXE (specifically, iPXE) booting ShredOS, please?

My current ShredOS (original shredos image, at the moment) looks like this:

:shredos
set base-url ${httpboot-url}boot/
kernel ${base-url}shredos console=tty3 quiet loglevel=0

where shredos is the pre-compiled shredos.img. This works well.

Ideally, adding options in the kernel line, but using a separate initrd line pointing to a config file would work, too. A similar strategy for other options (e.g., #5 ) would be good, too.

[PartialVolume]

Looks like a useful enhancement. I've no experience of PXE booting so there is a bit of a learning curve for me. Once I've read up on it, I might have a few questions for you if that's ok?

[hameau]

If I was competent with iPXE, I'd be sending a pull-request! ;-) I'm willing to help/try stuff as far as I can.

As shredos.2020.02 is a bit different to the original shredos, a slightly different approach is needed. I have managed to boot the shredos.2020.02 image with the following iPXE menu entry:

:shredos2
set base-url ${httpboot-url}boot/
kernel ${base-url}memdisk || read void
initrd ${base-url}shredos-20210106.img
imgargs memdisk raw

which puts me in the nwipe window and everything appears to work correctly. I don't have a real machine to try it on at the moment, so this is being tested in a QEMU virtual machine, but I don't expect there to be any great differences with real hardware. I hope to try this in the next day or two.

I would expect to put boot options at the end of the initrd line (I think). The URL definitions are not significant for you, they're just pointing to the file paths on the PXE server.

[PartialVolume]

@hameau Just to clarify, so you would like shredos to behave as a DHCP/TFTP PXE server so PXE or iPXE enabled clients can boot from it?

[hameau]

@hameau Just to clarify, so you would like shredos to behave as a DHCP/TFTP PXE server so PXE or iPXE enabled clients can boot from it?

Not at all. The rest of the PXE boot process is implemented elsewhere. This is just a request that internal options can be passed from the PXE/iPXE menu entry. This is similar (but not the same as), for example, putting kernel options in the grub menu. Commands on the grub kernel line are passed to the kernel on loading, so they're applied to the running system.

As shredos.2020 is distributed as a complete, bootable image, it may not be possible – don't divert from more important development for this, which is just wishlist. If nothing else, mentioning PXE in this repository may attract future searchers with better knowledge of PXE.

Edit to add: this request may require that shredos is network capable, which is surely out of scope.

[hameau]

Sorry, I'm making a mess of this issue thread.

I have unpacked the distributed .img file and extracted the contents to the PXE server (rather than just loading the .img and booting it). This is the same strategy as I use for bootable .iso images, so it sn't onerous.

This allows an iPXE menu entry like:

kernel ${base-url}boot/shredos console=tty3 loglevel=3
boot

The kernel line is copied from the shredos grub entry. This should simplify things from your side, I think.

If options can be set in the grub menu, they can also be set for iPXE – nothing further for you to consider, afaik, so a proposed scheme would be something like this (in your grub menu line and thus in the iPXE menu):

menuentry "shredos" {
        linux /boot/shredos console=tty3 loglevel=3 loadkeys=uk nwipe-method=zero
}

Would that be practical?

[elipsius]

@PartialVolume sorry for the late reply I've been busy the last week or so.

back info: So I currently extract the boot image from the dban iso and place it in the boot partition then create a grub menu in /etc/grub.d called 40_dban

This allows me to run dban from my normal system grub boot if wanted to wipe my system.

Looking to use ShredOS instead now as I have needs for uefi boot capability which dban does not really provide and also want newer kernel features and use something that is actively being worked.

but the kernel line is: linux16 /dban.bzi nuke="dwipe --autonuke --method dodshort" silent vga=785

(I had to use linux16 to get this to work with dban but with ShredOS it will be linux/linuxefi)

but looks @hameau has found a way to auto start it off in a similar way, does that method actually start the process automatically or just change the method it set to use. Basically I don't want any user interaction when this runs nwipe.

I hopefully will be taking more of a look at it myself in the next week after I finish some other tasks I'm working on.

[hameau]

but looks @hameau has found a way to auto start it off in a similar way, does that method actually start the process automatically or just change the method it set to use. Basically I don't want any user interaction when this runs nwipe.

No, nothing is auto-started – that's just a proposed scheme for shredos.2020 grub in my previous post.

By unpacking the .img file, I was doing much the same as you are with the .iso of dban. PXE booting just starts up with the nwipe screen on tty1, exactly as if booting from a USB stick, and everything is manual from there.

[PartialVolume]

exactly as if booting from a USB stick, and everything is manual from there.

unless you put "nwipe_options=--autonuke --nousb --method=zero" on the kernel command line, then it will start wiping automatically.

I've finished making additions to the code so you can configure nwipe and set the keyboard up from the kernel command line via the grub.cfg file, just final testing and debugging, so hope to release in the next couple of days. So far seems to be working ok.

[PartialVolume]

Edit to add: this request may require that shredos is network capable, which is surely out of scope.

If you ALT F3 in ShredOS I seem to remember a message saying the network is enabled. I've not tried it yet but the plan is to have network capability as I would like it to be able to FTP/sftp the certificate that shows the drive details and that erasure has been completed. The certificate is also a work in progress.

[PartialVolume]

If options can be set in the grub menu, they can also be set for iPXE – nothing further for you to consider, afaik, so a proposed scheme would be something like this (in your grub menu line and thus in the iPXE menu):

menuentry "shredos" {
        linux /boot/shredos console=tty3 loglevel=3 loadkeys=uk nwipe-method=zero
}

Would that be practical?

I think so, although I still don't quite understand the purpose of passing iPXE commands via the grub line, I think I don't understand the overall use case or something. I understand the purpose of iPXE and PXE client and server but don't quite see how ShredOS fits into that picture. Quite probably a lack of understanding in regards to iPXE which I thought was just firmware that provided PXE capability to hardware that was not PXE capable?

[hameau]

unless you put "nwipe_options=--autonuke --nousb --method=zero" on the kernel command line, then it will start wiping automatically.

I've finished making additions to the code so you can configure nwipe and set the keyboard up from the kernel command line via the grub.cfg file, just final testing and debugging, so hope to release in the next couple of days.

That's great, thanks.

... I still don't quite understand the purpose of passing iPXE commands via the grub line, I think I don't understand the overall use case or something. I understand the purpose of iPXE and PXE client and server but don't quite see how ShredOS fits into that picture. Quite probably a lack of understanding in regards to iPXE which I thought was just firmware that provided PXE capability to hardware that was not PXE capable?

In my case, there is no passing of iPXE commands by grub. Where I have mentioned grub, I'm speaking of the ShredOS-2020 grub. Have a look at https://networkboot.org/fundamentals/ for a quick overview of PXE and the enhancements that iPXE brings. The computer's boot ROM provides the initial PXE capability; the IPXE server delivers an iPXE replacement for the built-in PXE, with more capabilities; this iPXE 'firmware replacement' (for want of a better term) then calls the iPXE menu from the server.

If a computer has no built-in PXE capability (no NIC ROM, broken PXE implementation, ...) there are bootable iPXE images, usable from optical or USB media.

A configured iPXE server provides a menu (similar to syslinux on a bootable CD, for example) and serves bootable systems to the client computer. ShredOS is stored on the iPXE server and is delivered to the client computer over the network. Boot options can be configured for delivery by the iPXE server, along with the bootable image. The bootable image could be a single file (e.g., boot/shredos extracted from shredos-2020.img) or a series of files (e.g., for Linux, a kernel for initial boot, then an initrd file to add the rest of the system).

Bootable systems – ShredOS, SystemRescueCD, Clonezilla, Windows PE, Linux installers, Linux live CD images, ... – only have to be kept on any network accessible resource and can be booted from any PXE client.

(I'm not an expert and this shouldn't be read as a reference document. There may be errors and the capabilities of iPXE go far beyond what's here.)

[PartialVolume]

@hameau Thanks for that description, that was helpful, I think I understand it a little better now. So I understand the previous example you gave of changes to the grub line where the ShredOS .IMG is pulled from the iPXE server but maybe where I'm not clear is why you need to pass any other options via the grub line specifically for iPXE?

In the changes I've made the /proc/cmdline is parsed by some C code that when given a label such as nwipe_options it looks for nwipe_options= on the /proc/cmdline and returns the corresponding data. Basically the nwipe_launcher script calls this C code and depending on the results launches nwipe in either its default ncurses GUI mode or launches it with the options it found on the /proc/cmdline which is the boot line in grub.cfg. The nwipe_launcher script also sets the keyboard type using this same C code to extract loadkeys=UK etc from /proc/cmdline.

So what other iPXE information would you pass via the /proc/cmdline, if any, specifically for ShredOS and what would process it once the kernel had booted other than commands recognised by the kernel?

[PartialVolume]

In my case, there is no passing of iPXE commands by grub. Where I have mentioned grub, I'm speaking of the ShredOS-2020 grub.

@hameau Sorry, you already answered my question earlier. 👍

[hameau]

In the changes I've made the /proc/cmdline is parsed by a some C code that when given a label such as nwipe_options it looks for nwipe_options= on the /proc/cmdline and returns the corresponding data.

That looks good – I look forward to giving it a try. I appreciate your work to achieve this.

(OT: And thanks for mentioning /proc/cmdline, which has helped me understand how these things can be passed to the running system. Obvious, in hindsight!)

[PartialVolume]

Tests are complete, so subject to work commitments today I hope to commit the changes, update README.md with the new capability and what options you can add to grub.cfg to change nwipes launch configuration.

From a practical point of view, that means you can specify any nwipe option, so anybody wanting to modify the default method/verification/rounds, not show USB devices, exclude specific devices, turn your USB stick into a autonuke device (a good reason to never change your bios to have USB as the first boot device, just in case it gets plugged into a production system by mistake and the system rebooted!).

Unlike DBAN you won't need to start the options with the name dwipe or nwipe. Just list the options exactly as if you running nwipe from the command line.

Example:

nwipe_options="--method=zero --verify=off --noblank --nousb" 

[PartialVolume]

While I was rewriting the launch script I also put a pause after nwipe exits. Originally when nwipe finished the wipe and you pressed the return key or you used control-c to exit and restart nwipe. The restart happened immediately so you would never get the chance to review nwipes summary table. Now when nwipe exits, it pauses so you can read the summary table then pressing any key will restart nwipe.

[miharix]

That sounds phenomenal! Thanks for such fast implementation! I can already see this project will be worlds next "DBAN" ;-)

Would keyboard changing also be possible in this config file? (its not big deal, it's only always funny if you have qwertz not qwerty and need to press Y) Offtopic: does nwipe has shutdown PC after finish ? (So the computer isn't on if you start wipe on weekend start) ?

[PartialVolume]

Would keyboard changing also be possible in this config file?

Yes, add this to the kernel command line in grub.cfg. There are two grub.cfg's, one in /boot/grub/grub.cfg for BIOS boot and the other in /EFI/BOOT/grub.cfg for UEFI. Both grub.cfg's are currently identical.

loadkeys=uk etc

See /usr/share/keymaps/i386/ in shredos for full list of keymaps

Examples are:

(azerty:) azerty, be-latin1, fr-latin1, fr-latin9, fr-pc, fr, wangbe, wangbe2

(bepo:) fr-bepo-latin9, fr-bepo

(carpalx:) carpalx-full, carpalx

(colemak:) en-latin9

(dvorak:) ANSI-dvorak, dvorak-ca-fr, dvorak-es, dvorak-fr, dvorak-l, dvorak-la, dvorak-programmer, dvorak-r, dvorak-ru, dvorak-sv-a1, dvorak-sv-a5, dvorak-uk, dvorak, no

(fgGIod:) tr_f-latin5, trf

(include:) applkey, backspace, ctrl, euro, euro1, euro2, keypad, unicode, windowkeys

(olpc:) es, pt

(qwerty:) bashkir, bg-cp1251, bg-cp855, bg_bds-cp1251, bg_bds-utf8, bg_pho-cp1251, ... by, cf, cz, dk, es, et, fi, gr, il, it, jp106, kazakh, la-latin1, lt, lv, mk, nl, nl2, no, pc110, pl, ro, ru, sk-qwerty, sr-cy, sv-latin1, ua, uk, us (for the full list see /usr/share/keymaps/i386/qwerty)

[PartialVolume]

Offtopic: does nwipe has shutdown PC after finish ? (So the computer isn't on if you start wipe on weekend start) ?

Yes

--autopoweroff

Here's the full list for nwipe 0.30

Usage: nwipe [options] [device1] [device2] ...
Options:
  -V, --version           Prints the version number

  -v, --verbose           Prints more messages to the log

  -h, --help              Prints this help

      --autonuke          If no devices have been specified on the command line,
                          starts wiping all devices immediately. If devices have
                          been specified, starts wiping only those specified
                          devices immediately.

      --autopoweroff      Power off system on completion of wipe delayed for
                          for one minute. During this one minute delay you can
                          abort the shutdown by typing sudo shutdown -c

      --sync=NUM          Will perform a sync after NUM writes (default: 100000)
                          0 - fdatasync after the disk is completely written
                              fdatasync errors not detected until completion.
                              0 is not recommended as disk errors may cause nwipe
                              to appear to hang
                          1 - fdatasync after every write
                              Warning: Lower values will reduce wipe speeds.
                          1000000 - fdatasync after 1000000 writes etc.)

      --verify=TYPE       Whether to perform verification of erasure
                          (default: last)
                          off   - Do not verify
                          last  - Verify after the last pass
                          all   - Verify every pass

  -m, --method=METHOD     The wiping method. See man page for more details.
                          (default: dodshort)
                          dod522022m / dod       - 7 pass DOD 5220.22-M method
                          dodshort / dod3pass    - 3 pass DOD method
                          gutmann                - Peter Gutmann's Algorithm
                          ops2                   - RCMP TSSIT OPS-II
                          random / prng / stream - PRNG Stream
                          zero / quick           - Overwrite with zeros
                          verify                 - Verifies disk is zero filled

  -l, --logfile=FILE      Filename to log to. Default is STDOUT

  -p, --prng=METHOD       PRNG option (mersenne|twister|isaac)

  -r, --rounds=NUM        Number of times to wipe the device using the selected
                          method (default: 1)

      --noblank           Do not blank disk after wipe
                          (default is to complete a final blank pass)

      --nowait            Do not wait for a key before exiting
                          (default is to wait)

      --nosignals         Do not allow signals to interrupt a wipe
                          (default is to allow)

      --nogui             Do not show the GUI interface. Automatically invokes
                          the nowait option. Must be used with the --autonuke
                          option. Send SIGUSR1 to log current stats

      --nousb             Do show or wipe any USB devices whether in GUI
                          mode, --nogui or --autonuke modes.

  -e, --exclude=DEVICES   Up to ten comma separated devices to be excluded
                          --exclude=/dev/sdc
                          --exclude=/dev/sdc,/dev/sdd
                          --exclude=/dev/sdc,/dev/sdd,/dev/mapper/cryptswap1

[PartialVolume]

I just noticed HMG5 is missing from the --help list. I'll do a PR to nwipe to update that.

[PartialVolume]

Nwipe launch options and keyboard mapping can now be configured and saved between reboot by editing grub.cfg in /boot/grub/ and EFI/BOOT/ on the USB stick. For further details see How to change the default nwipe options so the change persists between reboots and How to make a persistent change to keyboard maps

Implemented in this release v2020.05.006_x86-64_0.30.001

[elipsius]

Awesome! I'll be looking at it in the next week. These changes will be nice!

[hameau]

Nwipe launch options and keyboard mapping can now be configured

Great work – thanks.

Works fine in iPXE with the boot options for nwipe and keyboard layout, BIOS and UEFI boot.

[elipsius]

@PartialVolume sorry for the late response, just wanted to say it worked like a charm! I was able to integrate this into my destruct package and have it as a grub line option and working for both my efi and legacy boot systems. So much faster boot time to shred than Dban!

[aToO57]

@hameau @elipsius Can you consider to share you pxe config file ?

I would like to deploy like you a pxe server with this shredos with --autonuke to clean around 700 computer :)

[PartialVolume]

@PartialVolume sorry for the late response, just wanted to say it worked like a charm! I was able to integrate this into my destruct package and have it as a grub line option and working for both my efi and legacy boot systems. So much faster boot time to shred than Dban!

That's great! Glad it's useful. 👍

[livestrong91]

@hameau @elipsius @aToO57 Would it be possible to share your ipxe config files? I tried a lot of different configs with ipxe + efi + shredos. BIOS is running well, but I with efi I ended up in the grub shell..

[elipsius]

@livestrong91

I don't use it with PXE but probably plan on adding it as an option to wipe disks on systems, but the processes is about the same. I actually wrap my stuff into an rpm and have it as a clean / system destruct option in the grub menu.

Here is what I did to get things to boot:

• I had to mount the provided img file, then extract the contents.
  • I had to calculate the bite offset of the image to correctly mount it.
• (I need to make a copy of this outside of my private work repo at some point when I get a moment of time)
• example (shredOS image is in /tmp):

  
  fdisk -lu /tmp/shredos-2020.05.006_x86_64-0.30.001_20210115.img

... this will provide image details.

in this example the block size is 512 and the start is 1263

calculate the byte offset by calculating (block size) * (start block)

512 * 1263 = 646656

mkdir -p /tmp/shredos

or /media/shredos

mount -o loop, offset=646656 /tmp/shredos

mount -o loop, offset=646656 /tmp/shredos-2020.05.006_x86_64-0.30.001_20210115.img /tmp/shredos

> cd /tmp/shredos

> ls -la

EFI boot ....

* The content then provides the boot image you can use with grub and efi booting related to PXE etc.

* My grub (grub2) menu looks like this: 

ShredOS Destruct

Random Data Write 1 pass - quick wipe

menuentry 'destruct' --class shredOS --class destruct --class os --id destruct --unrestricted { load_video linux /shredos console=tty3 loglevel=3 nwipe_options="--autonuke --method=random --nosignals --autopoweroff --nowait" }

* note if using efi boot `linux` needs to be change to `linuxefi`

* I place the `shredos` boot image (from extracted image file) in `/boot/` and/or `/boot/efi`  depending if legacy or efi booted
  * (but you can place the correct images in the PXE / tftpboot structure etc)

Hopefully this helps some, and provides some info on how to get things to boot.

[jeff89179]

For anyone still looking for examples, here is mine. I'm certain it can be improved somehow but for what I need it for, it works.

I'm using SYSLINUX/PXELINUX 3.86 on a Windows server using WDS. I wanted to boot ShredOS via PXE/WDS. Found that I didn't add memdisk initially, so I added that and added the following config to C:\RemoteInstall\Boot\x64\pxeLinux.cfg\default

---

LABEL ShredOS x64 MENU LABEL ShredOS x64 MENU DEFAULT KERNEL memdisk || read void APPEND memdisk initrd=Images/ShredOS/shredos-0.30.001.img

---