thirdwheel

Ok, this seems like a bizarre design choice. Seems users need full admin rights in order to change their own password. I'm evaluating Estimate as an alternative to a big, bulky, expensive estimating system that is causing users grief and causing the boss to pull his hair out at his inability to get the vendor to see any sort of sense. However, this is a deal breaker. And giving everyone the same password when creating new users? Asking for trouble. At least allow us to specify a password, it's surely...

Another way, if you wanted to just turn them on and have them do their thing, is to get a laptop, download TFTPD32, and set it up to push out DHCP addresses and DBAN using PXELINUX and TFTP. Then it's a matter of connecting the computers to a switch, set them to boot off the network, and boot.

Probably too late now, but in case you were still wondering... Once it starts booting (after it loads the kernel and initrd), you can remove the USB and move on. It'll only need the USB again to write a log file.

Disregard that patch, did it backwards. Here's the correct patch.

Option to not exclude USB devices for --autonuke?

Hi there I found Rufus worked best for creating bootable USBs for Linuces. Also super for building bootable installers for the Windez. Only thing I've tried that hasn't worked is OpenBSD installer ISOs, but they supply their own bootable USB images, which this tool will happily burn onto a USB for you. https://rufus.akeo.ie Unetbootin, as far as I was aware, was designed with Ubuntu in mind. Can't speak for Etcher, though.

Hi there I found Rufus worked best for creating bootable USBs for Linuces. Also super for building bootable installers for the Windez Only thing I've tried that hasn't worked is OpenBSD installer ISOs, but they supply their own bootable USB images, which this tool will happily burn onto a USB for you. https://rufus.akeo.ie Unetbootin, as far as I was aware, was designed with Ubuntu in mind. Can't speak for Etcher, though.

Hi I see in the latest release that there's a measure to prevent USB drives from being nuked during autonuke. Can we add an option to tell autonuke to also nuke USBs please? I have attached a diff (admittedly untested, but should work) that, unless I'm making a false assumption regarding functionality further down the line, should allow this.