Hacker News Reader

Comment by rwmj | Hacker News Reader

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...

View on HN

I used to dual-boot windows, but I was too lazy to actually reboot, so naturally I had Virtualbox just boot the physical Windows partition while Linux was running. Which is totally fine!

It's not a real dual boot if you don't boot both partitions at the same time.

As long as you don't install guest VBox drivers, those would make it hang when it boots as the host on physical hardware, since there's no longer someone above to answer the hypercalls.

Yeah. That is a valid use. I mean, this is how I installed Windows to begin with, from Linux via QEMU, onto my other hard drive. I did reboot and test it out, and it worked just fine.

I think Windows refused to do that at some point? So I booted the physical Linux partition from Windows if I needed both at the same time. That's on a laptop that otherwise almost always ran Linux.

It whines about licensing, but I switch between booting my windows installation bare metal and as a VM all the time

> I had Virtualbox just boot the physical Windows partition while Linux was running. Which is totally fine!

I had no idea that this was possible, and I learned something new today. Thank you!

That script sounds extremely unhinged, and I mean it as a compliment :)

Without spoiling too much, the command at the very end of the series does something adjacent to this.

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...

in most cases you could just drop back into the initramfs that is included in most distros

Or 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

All of those things get covered in parts 2, 3, and 4 :)

There's... no part 2 in the post? And it's the latest blog post on the site, as far as I can see.

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...

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!"

You also don't want to do this under any kind of memory pressure, because the kernel will happily drop read-only pages from memory if it thinks they can be re-read from disk when needed.

One bit of magic you may be interested in is pivot_root, which allows another filesystem to take the place of the root filesystem (e.g. / and /mnt become /old and /). It's usually used during startup, to allow the "real" root filesystem to take the place of the initrd, but could have other uses.

Last time I tried to use it though I just could not get it to let go of the main filesystem even after repeatedly killing the processes I could and restarting the rest.

Taking control at the initrd stage, as in the second page of the article, is significantly more reliable.

But have busybox in your initrd so you don't have to suffer. It takes up 0.5% of the size of my initrd file.

The second part in the series deals with that by mounting it read-only from initrd.

Could xfs_freeze help with this?

[0]: https://www.man7.org/linux/man-pages/man8/xfs_freeze.8.html

depending on the size of your disk image and your uefi+boot partitions it's still possible to safely pull off.

unmount the efi and boot partitions, write your image to the head of the disk, power cycle, then grow the last filesystem from the image to cover the rest of the disk.

you might get lucky and have all three of uefi/boot/swap to work with.

of course with the advent of uefi, you could instead just drop an installer image directly into the efi parition and boot that.

Reply on news.ycombinator.com