Quote from the Archwiki (Installation guide):
Arch Linux should run on any x86_64-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation. A basic installation should take less than 2 GiB of disk space.
Does that mean it is technically possible to get a Windows XP-era device with 512 Mb RAM and install Arch on it by pulling out the hard drive, connecting it to a modern machine via a SATA to usb connector, for example, with the modern machine running the live environment, and then just partitioning and installing on the old computer HDD, then putting the hdd back on the old computer? Is something like that feasible? I don’t have a machine to test it on, but it certainly sounds like a fun experiment. It sort of reminds me of the stories of Gentoo cross-compiling.
Edit: It is a HYPOTHETICAL question. Please focus on the METHOD and IMPLEMENTATION instead of 32-bit compatibility or driver issues.
The requirement for x86_64 eliminates most XP era machines, though I was certainly running XP well into the Vista era on potentially compatible hardware.
How old are you thinking?
There are Arch ports to 32-bit architecture, for example this one
It’s a hypothetical question on the method of implementation, not the practical side of things.
Wouldn’t most of those old computers be 32 bit? I remember trying to throw arch on an old winxp netbook and running into that issue.
It’s a hypothetical question about the method of implementation and that method’s feasibility. Sorry for the confusion.
I think so, yeah.
Though Alpine would be probably easier to get going given the super tiny size.Yes, you can install on one machine, move the drive to a different machine, and it should mostly just work (unless they are different architectures and the packages aren’t compatible). I’ve recently moved an old Arch install into a basically new computer and after changing the microcode it just works fine.
512 m ram dunno, but I had an old 10 yo+ dual core / 4 gb ram laptop on arch working well, except for gaming. Just replaced it with ghostbsd, also fluid.
Not so mich about the device, more about the method of doing it. It’s a hypothetical question pf whether or not this method of installation is possible.
It should be possible. I’ve just recently created a virtual hard disk in virtual box and mapped it to a physical ssd and installed windows on it. just change the settings of the virtual machine to match the target hardware and it should be fine I think.
Way overcomplicating it, sure you could do that, or you could just Install arch using cdrom. it’s worked on Windows 98 PCs it’ll probably work on Windows XP PCs.
though you may need an older ISO to hit the 512mb limit
I don’t know about Arch, because I’ve never used it, and I believe it only installs the drivers for the current hardware. I’ve done it with either Ubuntu or Mint though, and even with Windows XP and 7, though they were harder.
I haven’t done it as a deliberate choice during installation, but I have had a working OS on a drive that I’ve then transferred to another computer. In the Linux cases, I’ve just put an old drive into another computer to see what would happen, as the drive was due to be wiped anyway. It was several years ago, probably over ten years, but for the most part, they just worked. The first boot was slow, presumably while the drivers were sorted out, but I think the most work I had to do was reboot a few times, after it got to the desktop.
With Windows, I had to delete a drivers folder, I think under C:\Windows\System32, and delete a registry entry. It didn’t work every time, but it did work fairly regularly. It may have been down to the Windows version, home vs pro, but I can’t remember.
Hope this helps 👍
So. To answer you “hypothetical” question if we ignore all the factors making it complicated (like 32bit compatibility, drivers, etc.)
Yes it is “feasible” to Install an OS using a modern System and just pull out the HDD and shove it into an old system. Especially since the way BIOS/MBR (aka “Legacy Boot”) is the exact same on all systems you write the “what to start” code in the first few Bytes on the HDD (aka the MBR) and set a bootable flag on the device. Now you can pull it out and plug it into any other machine which will simply “look” for a bootable flag and then run the code in the MBR (usually a bootloader). This bootloader (usually grub for legacy systems) will then execute one of its boot entries and start a kernel. This is probably where a real world example fails because of the problems mentioned by everyone here.
Yes, thank you. I just wanted to make sure that was a thing. Thank you for actually answering my question.
I have a Thinkpad T400 with Arch on it. It came out in 2008 which I believe is the last year XP got a release. But I’m pretty sure it came with Vista.
It runs like shit with a full desktop environment but with i3, it’s decent. I haven’t used it in a little while because I upgraded to a luxurious T440 recently but I have Intellij and Docker running on it. I can do most of my programming things. It’s definitely good enough for browsing the internet or running Libre Office.
“I have this really hard problem. If you disregard all of the hard parts, what are the hard parts?”
As I said, I do not have this problem. It’s an old theoretical thought experiment.
I used to have an USB stick with Ubundu on it, so I see no reason that it shouldn’t be possible. But idk how drivers would work.
Also I would check how much RAM is needed to boot the live ISO (not during the process). If it is low enough, you can use swap.
I don’t have such a device. It’s a hypothetical question on whether this way of doing things is possible.