> How do you unmount your OS’s disk while keeping the OS running to be able to overwrite itself?

I went down a similar rabbit-hole myself, with the goal of safely replacing the Linux installation on a disk that a machine is already running from (e.g. replace a VPS's setup image with one of your own) without needing a KVM-style remote access tool to the console.

The problem there is if you directly modify the disk when a filesystem is mounted on that disk then all bets are off in terms of corruption of the filesystem that's already on there and also the filesystem(s) you're writing over the top.

My solution was to kexec into a new kernel+initramfs which has a DHCP client and cURL in it - that effectively stops any filesystem access while the image is being written over the disk, then to just reboot.

> My solution was to kexec into a new kernel+initramfs which has a DHCP client and cURL in it - that effectively stops any filesystem access while the image is being written over the disk, then to just reboot.

That's what I was expecting from the article.

Update: It's not obvious, but it turns out that this is a multipart article, and kexec is reserved for part 3: https://astrid.tech/2026/03/24/2/how-to-pass-secrets-between...

Keeping with the YOLO spirit of the article, one can be even lazier, and do emergency R/O remount using this little thing:

https://www.kernel.org/doc/html/latest/admin-guide/sysrq.htm...

It's technically not an unmount, but still a pretty strong guarantee OS will not corrupt the image being written.

When done, reboot has to be done from the same sysrq handler, of course.

I usually just move all the files to a new directory (/oldroot) and pivot_root -- any open files reference the new paths. Then install into the newly empty root directory of the filesystem, reboot and delete the /oldroot.

The gymnastics VPS providers force people to go through just so they can have some dumb "wizard" with a limited number of OS choices is maddening. Just allow people to upload an ISO!