Well the 1 SSH session bit was for dramatic meme-effect lol, you can actually connect back without issue (at least it did for me) so worst case if you weren’t working in tmux you’d just have to start dd again
Worst worst case, you’d just end up back where you were probably heading before anyways, KVM/IPMI
Sure, I suppose as long as sshd is up and running in the ramdisk environment (which you mentioned in another comment, along with all other services) you could always reconnect. Very neat and clever!
What happens if the SSH session closes before dd finishes? Sounds pretty badass but I don’t think I would trust this approach in prod lol
Well the 1 SSH session bit was for dramatic meme-effect lol, you can actually connect back without issue (at least it did for me) so worst case if you weren’t working in tmux you’d just have to start dd again
Worst worst case, you’d just end up back where you were probably heading before anyways, KVM/IPMI
Sure, I suppose as long as sshd is up and running in the ramdisk environment (which you mentioned in another comment, along with all other services) you could always reconnect. Very neat and clever!
You could use screen or tmux for a persistent terminal session.
True, but I was more thinking about the issue of reconnecting in general when you just nuked sshd.
As long as you only copy off the disk, you can just reboot and the whole system in RAM vanishes and the normal system boots again for the second try.
Maybe run ssh on 2 different ports?