> An archive of files and directories is in itself not a program.
Okay, but you can make the same argument to say that ELF files aren't programs in and of themselves either. In fact, some ELF files are dynamic libraries without an entrypoint, and therefore not actually executable in any meaningful way unless connected to yet another program.
If you can accept that some ELF files are executables and some aren't, then you can also accept that some CPIOs are executables and some aren't. What's the difference between ld.so unpacking an ELF file into RAM and running its entrypoint, and the Linux kernel unpacking an initramfs into RAM and running its entrypoint?
By that logic, everything is executable. Not entirely wrong, but mostly because of vulnerabilities. Not because of a highly contrived way of using a file format to run a program. You could do the same thing with json or xml.
i agree, its linkers and loaders which parse a file and extract meaning, which might be executed by yet another program that runs in kernel and creates a 'user space' part to run the untrusted code in.
its not as simple as executable file, blap now it runs. they made it like that on the surface so people dont need to bother with the details.
a lot in this article, writes about the abstractions and maybe how they work. not really sure as you i found it hard to read. It doesnt mean its all wrong though, maybe theres more ways to look at a system which has layered abstractions. Each layer can be a different view and be discussed independently in its design.
if you look at what the CPU and kernel code is doing its a messy afair :D hard to talk about (fun tho :D and imho good to understand as you pointed out)
ELF files are an image format which is a format to store things in basically..image being a legacy term.
an elf file is not executable, but depending on what you do, a linker and loader might cause the operating system to execute some or all of its contents at some point.
... I think you're reading a bit much into it. It's less that I couldn't afford to pay that, and more that I didn't want to pay that, and iterating on the solution I used to dodge that led me down a giant rabbit hole of learning more about Linux while solving stupider and stupider problems posed for myself.
I did learn about systemctl switch-root after finishing my kexec solution, but I think if you're at the point of reimaging a server over the network, you probably don't care enough to shut it down correctly :)
Actually you do, bacause you can't re-image safely while kernel is also writing to your target block device via fs driver. And if original server has nything more complex going on, like md/lvm you're in even more trouble.
To be honest, even this has plenty of room to go down. I get the feeling I could have squeezed a couple more MB off if I had actually cut things off of the default Nixpkgs busybox, and possibly also cut a couple of kernel drivers out.
From what it sounds like, because you have a console and therefore aren't dependent on SSHD not getting overwritten, you can just dd the live running system here?
Like I said in the other comment I am not really familiar with the various clouds. I self host. The console is a weird web based thing that isn't the same environment as your VMs (or their hypervisor). It's a barebones shell where you can mount your volumes and such, not actually boot or enter the vm. (Edit: This was incorrect) And if I remember correctly I probably did have to do some mounting there to create device files and such. I didn't really have much use for the console after that either. I will try to find the actual gist I followed.
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!"
Okay, but you can make the same argument to say that ELF files aren't programs in and of themselves either. In fact, some ELF files are dynamic libraries without an entrypoint, and therefore not actually executable in any meaningful way unless connected to yet another program.
If you can accept that some ELF files are executables and some aren't, then you can also accept that some CPIOs are executables and some aren't. What's the difference between ld.so unpacking an ELF file into RAM and running its entrypoint, and the Linux kernel unpacking an initramfs into RAM and running its entrypoint?
reply