> This script does not have any provisions for exiting out of the new environment back into something sane. You will have to reboot when you're done. If you get anything wrong, your machine won't boot. Tough luck.
So then "without rebooting" in the title is inaccurate, no?
I haven't studied TFA carefully. But reinstalling running Linux systems via SSH is pretty routine, no? Using debian-installer with network-console, I mean.
I occasionally reinstall remote servers with LUKS via SSH. I just login, build the installer, and reboot into it. Then I SSH to the installer, and almost complete it. Just before rebooting, I go to single-user mode, and setup dropbear in initramfs. Then I reboot.
So OK, that's two reboots, not one. And if it fails, I just reboot using the control panel. If I've really fucked up, I reinstall and try again.
Maybe kexec-ing into the new kernel would be feasible?
I investigated this many years ago to see if it was, but I found scant information on compatibility requirements when using kexec to hand over execution to an arbitrary kernel.
The problem seems really hard though. One issue that stands out to me is that even if you properly shutdown the old kernel, will all system devices be in a 'good enough' state to be reinitialized properly by the new one? Or do some devices require a reboot for some reason?
I love how the first comment praises it for being "straightforward". For reference, this is how you shrink a file system on Windows:
diskpart
select volume C:
shrink desired=4096
I guess it's nice that the Linux version lets you move the partition as well (or "shrink from behind", so to speak), but damn, "straightforward" is not a word I would have used to describe it.
Not needed anymore since DO supports custom OS images now but I found this script quite interesting, setting up a "blockplan" and applying it from a minimal root FS in RAM to entirely replace a Debian OS with an ArchLinux install unattended and without rebooting (except as a very last step to actually boot into the Arch kernel using the replaced GRUB2)
I forked it to try and convert Debian installs from ext4 to btrfs. Unfortunately while it does work, that's a very bad idea since btrfs-convert produces a fs that fails to operate properly on the long run (IIRC there is - was? - some increasing random space usage that cannot be reclaimed, ever).
BTW, the process to convert to btrfs is excellent, only creating btrfs metadata in unallocated ext3 space, writing the btrfs header at the last minute, and using subvolumes allowing you to keep the ext3 metadata around as long as you want to roll back (obviously losing any subsequent modifications) because barring the header the whole ext filesystem and data is untouched.
I actually implemented something on an embedded linux product once: a busybox initramfs that you could boot into "recovery mode," then along with dropbear, SSH into a completely in-memory system and re-flash the entire system image without having to pop out an SD card or connect a cable for DFU.
The recovery mode could even be initiated remotely, so you could re-flash a device without ever touching it. Of course you have to be careful, if the re-flash failed you could be SOL :) Apparently I need to go back and improve it so we can re-flash without rebooting!
These days you can use things like containers (Balena also looks very cool) to achieve a similar goal in possibly a "safer" way. But the idea of being able to re-flash the entire system while running it felt sort of like changing the engine of a car while driving it down the freeway!
I've implemented something very similar for upgrading headless Linux mobile robots. One nice property of this approach is that the in-memory installer environment and associated scripts can be common between USB-based install media and a remotely-triggerable kexec type installer.
At first, it surprised me there wasn't more standard tooling out there for this kind of thing, but as I got more into it, I realised how specific to our particular needs my solution had become, and I could see how it would be hard to offer something generic that would be a good fit for a wide range of use-cases without being super-bloated.
We upgraded a whole fleet of AWS / Digitalocean instances without floating IPs from Ubuntu Precise to Xenial based on this method back in the summer of 2017. While obviously not having to do crazy stuff like this would be better, it's nice to know that it is possible if you really need it.
Recently we ran into another use-case for this in production actually, we needed to wipe a lot of servers in our datacenter remotely and we figured one of the options would be to install some OS in memory with the relevant wiping tools, pivot_root to that, unmount all disks and then perform the wipe. In the end we went a different route and opted for a custom PXE-boot image instead that the servers would boot into that scripted the whole thing.
The first step is to update the kernel from an i386 one, so that it could run both i386 and amd64 binaries, but then you essentially overwrite every package with the version from the new architecture, and hope like hell it doesn't mess up.
At the time I had a pair of servers, a mail-host, and a web-host, and I managed to successfully upgrade both, although it was a little scary. At least I had console access if things did get horribly screwed up.
You could first chroot to a minimal stable system then update everything without having to rely on hope so much (but yeah big updates are always "exciting" and yum/apt/etc never get it completely right)
[+] [-] mirimir|7 years ago|reply
So then "without rebooting" in the title is inaccurate, no?
I haven't studied TFA carefully. But reinstalling running Linux systems via SSH is pretty routine, no? Using debian-installer with network-console, I mean.
I occasionally reinstall remote servers with LUKS via SSH. I just login, build the installer, and reboot into it. Then I SSH to the installer, and almost complete it. Just before rebooting, I go to single-user mode, and setup dropbear in initramfs. Then I reboot.
So OK, that's two reboots, not one. And if it fails, I just reboot using the control panel. If I've really fucked up, I reinstall and try again.
[+] [-] zamadatix|7 years ago|reply
[+] [-] cliffy|7 years ago|reply
I investigated this many years ago to see if it was, but I found scant information on compatibility requirements when using kexec to hand over execution to an arbitrary kernel.
The problem seems really hard though. One issue that stands out to me is that even if you properly shutdown the old kernel, will all system devices be in a 'good enough' state to be reinitialized properly by the new one? Or do some devices require a reboot for some reason?
[+] [-] arminiusreturns|7 years ago|reply
[+] [-] saagarjha|7 years ago|reply
[+] [-] mehrdadn|7 years ago|reply
[+] [-] zcid|7 years ago|reply
[+] [-] lloeki|7 years ago|reply
https://github.com/gh2o/digitalocean-debian-to-arch#how-it-w...
I forked it to try and convert Debian installs from ext4 to btrfs. Unfortunately while it does work, that's a very bad idea since btrfs-convert produces a fs that fails to operate properly on the long run (IIRC there is - was? - some increasing random space usage that cannot be reclaimed, ever).
https://github.com/lloeki/digitalocean-ext4-to-btrfs/blob/ma...
BTW, the process to convert to btrfs is excellent, only creating btrfs metadata in unallocated ext3 space, writing the btrfs header at the last minute, and using subvolumes allowing you to keep the ext3 metadata around as long as you want to roll back (obviously losing any subsequent modifications) because barring the header the whole ext filesystem and data is untouched.
https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
I suppose Apple did something similar to convert from HFS+ to APFS so swiftly and so reliably.
[+] [-] thom_nic|7 years ago|reply
The recovery mode could even be initiated remotely, so you could re-flash a device without ever touching it. Of course you have to be careful, if the re-flash failed you could be SOL :) Apparently I need to go back and improve it so we can re-flash without rebooting!
These days you can use things like containers (Balena also looks very cool) to achieve a similar goal in possibly a "safer" way. But the idea of being able to re-flash the entire system while running it felt sort of like changing the engine of a car while driving it down the freeway!
[+] [-] mikepurvis|7 years ago|reply
At first, it surprised me there wasn't more standard tooling out there for this kind of thing, but as I got more into it, I realised how specific to our particular needs my solution had become, and I could see how it would be hard to offer something generic that would be a good fit for a wide range of use-cases without being super-bloated.
[+] [-] vdloo|7 years ago|reply
https://www.reddit.com/r/programming/comments/6o7i8p/dont_ru...
Recently we ran into another use-case for this in production actually, we needed to wipe a lot of servers in our datacenter remotely and we figured one of the options would be to install some OS in memory with the relevant wiping tools, pivot_root to that, unmount all disks and then perform the wipe. In the end we went a different route and opted for a custom PXE-boot image instead that the servers would boot into that scripted the whole thing.
[+] [-] stevekemp|7 years ago|reply
https://wiki.debian.org/CrossGrading
The first step is to update the kernel from an i386 one, so that it could run both i386 and amd64 binaries, but then you essentially overwrite every package with the version from the new architecture, and hope like hell it doesn't mess up.
At the time I had a pair of servers, a mail-host, and a web-host, and I managed to successfully upgrade both, although it was a little scary. At least I had console access if things did get horribly screwed up.
[+] [-] raverbashing|7 years ago|reply
[+] [-] simula67|7 years ago|reply
https://news.ycombinator.com/item?id=18741529
https://news.ycombinator.com/item?id=13618378
https://news.ycombinator.com/item?id=13622301
[+] [-] exegete|7 years ago|reply
[+] [-] ratling|7 years ago|reply
AWS everything.
[+] [-] raintrees|7 years ago|reply
[+] [-] Ixiaus|7 years ago|reply