Just waiting for the hilarious/terrible moment when someone hooks this up to a script scanning the internet for weak SSH passwords and singlehandedly skyrockets the install base for Arch.
Some modifications would be needed to let this run really unattended.
Yet it would be fun seeing one of the infamous "# curl http:// install.coolstuff.io | bash" install processes :)
Hacker news would be greatly improved, in my opinion, if downvotes were accompanied by an explanation. I seem to be seeing a lot more irritating grey text lately and a lot of it seems to be quite unobjectionable so why does it get downvoted.
Downvotes aren't supposed to mean "I disagree", they are supposed to mean "this doesn't contribute anything useful or insightful or discussion-furthering to the thread"
Saying "I'm doing this this weekend!" doesn't contribute anything, there's no information of value to be gained from it, nothing to learn, nothing to think about. It was a waste of time to post. So it gets downvoted so the rest of us don't have to spend a second reading a useless comment.
All those useless seconds add up. The downvotes make us all better off in the long run.
I've experimented with doing this kind of thing myself, especially with servers where I don't have ready access to the console and where the provider doesn't offer custom ISO support and I wanted a clean (and/or customised) install, perhaps of something not yet supported.
While I did have some success with in-place install shenanigans, I eventually settled on creating a customised install ISO for the distribution I wanted (with a script to have it automatically listening for remote shell connections, and so on), using isohybrid on the ISO (which makes the ISO's first sector also a bootable MBR), and then simply dd if=install.iso of=/dev/sda - right over the top of the partition table and everything.
It's inelegant, to say the very least, but it works just fine! I'm pretty sure I saw that technique used a few times during Twitch Installs Arch Linux, during the more exotic segments when some joker hijacked the effort temporarily by installing Windows 95, and TempleOS, and so on.
> dd if=install.iso of=/dev/sda - right over the top of the partition table and everything.
I do the same thing. Then reboot and use fdisk to delete the main partition and recreate it again, except this time using all the available space of install drive. Then resize2fs to expand the filesystem.
How does something like the Arch Linux installer handle being "overwritten" as it installs? Or do you skip the first ~700mb of the drive when installing?
Interesting approach, skipping the space. But I think it would be simpler to just start with whatever's configured on the install disc. It's a pretty normal archlinux install, just need to change the passwords.
There's no need for an ISO image. Just prepare the system on either bare metal or a virtual machine, then tar the entire disk to a file, transfer and feed that file to dd instead. Of course, make sure you use the same (or smaller, but you'll have to claim unused space later) disk size, and be careful when choosing partition table type and aligning partitions.
> It's inelegant, to say the very least, but it works just fine! I'm pretty sure I saw that technique used a few times during Twitch Installs Arch Linux, during the more exotic segments when some joker hijacked the effort temporarily by installing Windows 95, and TempleOS, and so on.
Don't forget Gentoo! That's precisely how they installed it.
My understanding is that that was initially intended as a local installation option -- if you'd already had a running Linux install on a system, or had booted it under a bootable Linux system -- Knoppix, or any of numerous other systems back in the day (anyone remember lnxrtbt?).
It's been extended in some interesting ways, including unattended remote installations. Debian's inherehent flexability is impressive in this regard.
This is fantastic for e.g. EC2 where Arch Linux AMIs are hard to come by. (where "hard to come by" just means that they're available at https://www.uplinklabs.net/projects/arch-linux-on-ec2/ but I don't know who uplinklabs.net is nor whether I should trust their AMIs)
It really needs to be easier/cheaper to run your own image on EC2. I should try again now I have enough upstream capacity to upload the disk image - but don't you then pay for the AMI hosting forever?
Edit: looks like the scripts / source to create the AMI are available so you could build it yourself if you wanted. Bonus points if you can build it on an EC2 spot instance and deploy it, CI/CD style.
Neato. Just one minor nitpick: I see two points where vim is invoked but no way to tell what edits were made to the files (though it's easy enough to guess from the filenames).
Switch those two out with appropriate sed or echo commands, add a bash shebang at line 1, and baby, you've got a stew going!
Instead of rebooting, it should (in theory) be possible to use the kexec syscall to replace the kernel. I would rather just reboot for various hardware-related reasons though...
I was thinking more from the can you do a manual in system replacement like this on Windows. I guess in some ways doing an upgrade from 7/8 to 10 is similar but it doesn't really feel the same.
This is nuts, I would have never guessed you could swap an entire OS out! I scanned the code, this can be done without rebooting and while preserving "uptime" yes?
Well technically you're already running Arch with a Debian kernel before the reboot. You could install and start services, the guide does so for sshd. Now -- taking off my pedant hat -- clearly you wouldn't want to rely on this chimera, and rather let it settle into one shape through a reboot.
My success rate with such projects is sufficiently low that I only attempt it when I have no other option. And that's for Debian -> Debian bootstrapping. Most of the time I manage to fumble a crucial parameter and the boot fails. I wouldn't even think of doing this remotely except as a challenge.
But that's not to mean you shouldn't try it for the fun of it!
If the Debian kernel supports kexec it could be even more fun.
Is there any actual utility to scripting such a thing? I'm a strange person who enjoys distro-hopping and setting up PXE servers and such, so it seems like something I'd try.
At the start, /dev/xvda2 mounted as /, with Debian installed on it. The goal was to wipe it and install arch on it, all remotely over ssh, since I didn't have access to the console.
This kind of thing should be performed by a well-tested script, not an interactive session. Otherwise you might have an "Oh, what did I just type?" moment.
Linux installs (apart from grub boot blocks and partitioning) are JBOF (just a bunch of files).
Mostly, the non-user parts are /etc /boot /usr and /var (for package management), and things aren't always in the same places and conf files may vary in options because of version/patch differences.
Using symlinks and seperate directories, it's theoretically possible to switch OSes at boot time assuming everything is symlink-agonistic (stow for operating systems)
It's possible and rarely necessary except for personal playgrounds but a production box would follow 12factors standards and lifecycle the entire OS by switching the underlying base image with something like unionfs + hypervisor.
Lots of ways to shoot yourself in the feet, and in box rebuilds it's usually much faster to just start fresh and deploy using configuration management than try to hammer a bank into the shape of plane.
Definitely make verified backups before attempting a lobotomy on anything real.
