You can run
shred directly on the disk's device node from the running system. It'll be unhappy and throw IO errors as the filesystem is still mounted over a disk being filled with random data, but as the
shred binary and any libraries it depends on are fully loaded before the process starts, it should be able to withstand everything else collapsing under the IO errors and still complete the erasing procedure.
Note that there's a small chance of sensitive data being written back to the disk after it's been erased as the filesystem is still mounted read/write and the system might be flushing buffers full of confidential data back to the disk. To mitigate this, remount the filesystem as read-only if you can, though I'm pretty sure you can't easily do that from the root filesystem once the system is running. You could either modify your fstab to mount it using the
ro option and reboot (but make sure your boot process doesn't mind it and at the very least can get far enough to start an SSH server so you can connect), or from a physical console/out of band management device, start the OS with a custom kernel command line
linux /boot/vmlinuz... root=/dev/sdX ro quiet init=/bin/sh that mounts the root filesystem as read-only and starts a bare shell rather than the init process, and from it you should be able to run
shred without any data leaks as the FS is now read only.
Note that if you have any swap partitions set up on the device you're erasing, make sure to "unmount" them with
swapoff /dev/sdXY (or commenting them in the fstab and rebooting) before erasing the disk to ensure the process can complete without issues. While IO errors aren't fatal to a process already loaded, messing with the swap partition may make the system crash completely before the erasing is completed.
Finally another option is the ATA Secure Erase command :
hdparm --security-set-pass verysecure /dev/sdX
hdparm --security-erase verysecure /dev/sdX
Assuming you trust the drive's manufacturer to implement it correctly, this should be enough, but all of the above regarding data leaks and the swap partition still applies.
If you're really paranoid you could use one method, then reboot on some installation media or recovery environment over the network (most hosting providers have them) and do the second method.