Discussion
astrid dot tech
M95D: From the article:> The OS may stop you from unmounting /dev/sda1, but it won’t stop you from writing to /dev/sda1 or /dev/sda even if there’s something mounted!Not always true. There's a kernel config option that allows it.
rwmj: Unfortunately it's not safe as the kernel can still write to (what it thinks is) the old filesystem on the device, which will introduce corruption to the new disk image.However a fun fact is that you can (do not actually do this!) boot a qemu VM from /dev/sda. You have to use an overlay (eg. qemu -drive snapshot=on flag) so that qemu won't write through to /dev/sda. I use this trick in supernested, a script I wrote that runs nested within nested within nested VMs ad infinitum until your hypervisor crashes. http://git.annexia.org/?p=supernested.git;a=blob;f=run-super...
matja: > 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.
lloydatkinson: 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!
dizhn: Reminded me of how to install Alpine linux (which isn't available) on Oracle cloud over an ubuntu install. It uses dd and has the advantage of having a console.I had found it in a github gist when I used it but here's a similar blog post.https://alextsang.net/articles/20191006-063049/index.html
Joker_vD: What if we remount the filesystem(s) at /dev/sda as read-only first? Then make a small ramfs with statically-linked curl in it and exec it. Hmm. Ideally, you'd also want to call reboot(2) after it's done...
vidarh: The second part in the series deals with that by mounting it read-only from initrd.
kees99: 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.
codeflo: > 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...
matja: I totally missed part 2/3, thanks for linking!
mbana: Wait hold on, can you not simply just access the underlying volume/block device using an API? The VMs in OCI have a boot volume that is attached, so I reckon it's possible to "mount" this somehow and overwrite it with whatever data you want.
dizhn: I am not sure. Maybe it's a thing about not being able to download the iso (no network on the console?) or not having space for it or something.Made me think though.
akdev1l: in most cases you could just drop back into the initramfs that is included in most distrosOr if you have access to the boot command line you can also usually stop the boot process before pivot_root happens (hence you’ll be left running in the initramfs environment)On Fedora/EL it would be done by putting `rd.break` in the kernel command line
PunchyHamster: > Well, what can we try instead? > write to the mounted disk anyways. fuck youStupid penguin trick I learned: Add a file inside ramdisk (i use /dev/shm) as LVM PV.pvmove off the hard driveBoom, now your OS lives entirely in RAMYou can now even replace the hard disk, put a new one and migrate back.Or migrate to network storage (nbd,iSCSI etc.), re-sequence disks into whatever RAID you need, and migrate backNeed to fix /boot after that tho, and probably make sure to not have power failure in meantime
PunchyHamster: and we've gone full circle, back in the day you installed os on diskettes like that!
astralbijection: All of those things get covered in parts 2, 3, and 4 :)
Joker_vD: There's... no part 2 in the post? And it's the latest blog post on the site, as far as I can see.
astralbijection: It does get linked at the very bottom, though admittedly it could be made clearer. https://astrid.tech/2026/03/24/1/swap-out-the-root-before-bo...
rkeene2: 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.
Joker_vD: Oh, I see, the posts got published in the reversed order.On the topic itself: wow, what a journey. And I personally fully support "come on, you should totally be able to just dump the system image onto your disk and reboot/exec it!"
