> I couldn't do stage 2 on my laptop because that involves chrooting into the install and unfortunately my laptop isn't powerpc.
For people doing similar projects, you can use qemu in user mode to work around this. I believe the relevant Debian package is qemu-user-static. With it, you can execute binaries from foreign architectures as if they're native, with software translation doing all the hard work for you. Think Rosetta (not Rosetta2) but on Linux and supporting a wide variety of hardware.
Install the package, copy /usr/bin/qemu-<target architecture>-static to the /usr/bin folder in your chroot and you should be able to chroot into the foreign system!
I've used this to analyze some ARM binaries pulled from a router and it works surprisingly effective. Applications may fail because of the version inconsistencies between the daemons running on your OS and the old versions the chroot expects, but for basic tools it should Just Work, really.
How would that work? The problem here is that chroot needs to run using a different CPU instruction set. qemu-user is exactly the right answer here.
According to e.g. https://wiki.gentoo.org/wiki/Systemd-nspawn "no hardware emulation is taking place and unlike QEMU and Virtualbox non-native CPU instruction sets are not directly supported".
systemd-nspawn is still using binfmt which is how Linux tries to read ELF files, and what you really want when executing other architectures is to teach binfmt about qemu.
nspawn doesn't do anything additional here, but might be easier for most new sysadmins (sorry... "devops/platform/cloud engineers").
cd into an OS image built for arm on your x86 dev machine, and type:
`systemd-nspawn -D .`
and it just works. At least it's never failed for me. I believe it pulls in some kind of binfmt/qemu shim to get these binaries working. Probably qemu under the hood, but this is about as plug-n-play as it gets.
This reminds me of back in the day when the US became very worried that the 'level of sophisticated computing power' in the then-recently released PlayStation 2 could be used by Iran or North Korea to power nuclear missile guidance systems, if Linux could be installed on the box. What was especially weird was that Sony then went ahead and released Linux for the PS2 anyway which made no commercial sense anyway!
At the time there were particularly tight restrictions on distribution of PS2, beyond the usual export embargo of any tech to these countries.
I've always heard the PS2 Linux kit was to defeat some higher tariffs on importation of video game consoles versus the lower ones on personal computers. Some editions of the PS2 came with the network module pre-installed so maybe even without the HDD necessary, it could still loosely be defined as a PC since all that is missing is software that could easily be downloaded and installed.
That's a pretty imaginative method for recruitment. If you're nerdy enough to want to install Linux on a games console, maybe you'd like to get paid for it!
Modern XBOX Series X and S has very nice hardware (custom AMD APUs) for a really really discounted price. I wonder when or if they can be bricked enough to be a viable linux computer that can be sold for ~250$ ish with a great performance.
This is use of the word "bricked" which is a novel inverse of my normal understanding. To me a "bricked" device has been corrupted in core boot so bad, even JTAG may not get it back. It's the unusable state.
"rooted" is the more normal description of 'I got to install some code on it which the original vendor did not want me to be able to install' surely?
Or has geek english moved on to invert the greybeard meaning of "bricked" ?
There's consumer boards with xbox one and xbox series SoCs out there with the GPU fused off already. They won't ever be hacked, security is tight and the scene essentially doesn't exist anymore.
I have an Xbox One X that would be nice as a second PC. Even if it was an irreversible process that allowed me to install Windows, it would at least keep it out of the landfill for a little while longer.
I think a modded PS4 fits the shoe quite well, if you ignore the need to run a web browser exploit each time you want to boot Linux (like a "semi-untethered jailbreak" for the iOS nerds)
Moreover, it has GPU that was every cryptominers wanted to get and use. Since it's still not hacked, it seems to extremely
hard to hack. It was $$$ profit for mining farm.
Given the RROD, I don't think its worth putting time into Xbox360. Unless there has been some development on the 360 hardware, I doubt people will be using theirs for too long.
I went through 4 RRODs before the final RROD was in 2019.
I thought that xbox360 was going to be pals with my son at my parents...
The real serious RROD on the 360 was caused by failure of the solder joints between the GPU flip-chip and the substrate due to thermal cycling. Since this linux install won't ever utilize the GPU of the 360 in a way that would get it very hot (or if the number of thermal cycles is just kept very low in total, that failure mode may simply never be an issue.
And this is definitely the type of project someone is doing for fun anyway. Unfortunately even at idle the 360 isn't super power efficient, drawing ~70 watts or more, or else this could actually be a pretty neat project for repurposing a 360 as a NAS or something.
Wow, I forgot about that. I remember there was a last-ditch hack to try and resurrect a RRODed 360 which was to wrap a towel around it to force it to overheat, thus (possibly) re-melting the solder joints. This worked for us once, but only for a short time and subsequent towel-hacks did not bring it back. They did eventually release a new version of the 360 that doesn't RROD, which I eventually bought (realistically MS should have given these out to customers who experienced RRODs for free, but of course they had to scam kids out of whatever little money they had).
Now that I have a series X, the "only" major problem is that microsoft's controllers interfere with every wireless headset I've tried (including Microsoft's own wireless headset) super consistently (yes, everything has updated firmware). I'm sure hardware development isn't easy, but microsoft seems reliably bad at it.
> They did eventually release a new version of the 360 that doesn't RROD, which I eventually bought (realistically MS should have given these out to customers who experienced RRODs for free, but of course they had to scam kids out of whatever little money they had).
They did? They had a very generous policy where you were covered for three years after purchase, in which time they would repair or replace the hardware free of charge. If you RRoD'd in the later span of that, you would almost definitely have received an improved model (rather than them bothering to repair yours).
> They did? They had a very generous policy where you were covered for three years after purchase, in which time they would repair or replace the hardware free of charge. If you RRoD'd in the later span of that, you would almost definitely have received an improved model (rather than them bothering to repair yours).
There were two refreshes of the "Fat" 360 generation trying to resolve the RRoD issue, and as you might guess the first one helped but didn't solve the problem. Unfortunately for early adopters, the first refresh was where HDMI was added and while a non-HDMI version of that board was created for warranty repair use the same never happened for the second refresh. If you bought an early Xbox 360 that didn't have HDMI ports you were never going to get a completely fixed box unless you managed to get support to just replace it entirely with a new one.
If you purchased your 360 on launch day, you would qualify for the Jasper model (65nm CPU/65nm GPU, which is the primary "no RRoD" model) for over two months. Everyone after was in an even better position. In addition, there are many reports of early buyers having their RRoD replacement honored for one or two months outside of the guaranteed window.
Compare that to Sony and their Yellow Light of Death, who didn't offer any replacements or support after their standard warranty period. Compounded by the fact that the vast majority of consoles that suffered it were the full-Backwards Compatibility models, superior to what could be purchased in replacement.
The point isn't "boo hoo, stop crying about RRoDs"; it's that Microsoft is one of the worst companies to try to call out in this case. Their support for an issue caused by a third party manufacturer's chip was unprecedented and probably one of the best examples of a company supporting their product; even if it still doesn't reach your personal standards.
> There were five revisions in the first 36 months of the Xbox 360's life:
Zephyr was pretty much just a Xenon board with HDMI hardware added, and Opus was a Falcon with HDMI hardware removed, so I count Falcon/Opus as the first refresh and Jasper as the second.
> If you purchased your 360 on launch day, you would qualify for the Jasper model (65nm CPU/65nm GPU, which is the primary "no RRoD" model) for over two months.
Opus exists solely for warranty replacements for Xenons. It never shipped to retail. If you had a Xenon fail under warranty you got back another Xenon until mid-2008.
I've personally never seen someone get a Jasper back in exchange for a failed Xenon or Opus. If you didn't have HDMI you were stuck with the older hardware. Not saying it never happened, but if it happened it missed my entire sample size.
> Their support for an issue caused by a third party manufacturer's chip was unprecedented
AFAIK the problem was the combination of RoHS solder plus heat cycling plus a poorly designed retention mechanism. I don't know what if any part of that physical design of the cooling system IBM might have been responsible for but the chip itself wasn't the issue. I definitely would not say this was an issue "caused by a third party manufacturer's chip"
> Given the RROD, I don't think its worth putting time into Xbox360. Unless there has been some development on the 360 hardware, I doubt people will be using theirs for too long.
You're 15 years behind on this one.
While the original "Xenon" Xbox 360s are probably almost all dead by now, as are the first-gen Elites with the "Zephyr" board, the late-2007 "Falcon" revision that brought HDMI to the mass market models was a significant improvement and the late-2008 "Jasper" revision basically solved the problem. RRoDs on "Phat" consoles with the Jasper boards or any of the "Slim" variants are incredibly rare and unrelated to the flaw that impacted older revisions.
My own anecdotal experience matches the internet reports as well. I was deep in the OG Xbox modding world so a lot of my friends are also big Xbox fans and as a result we've owned a lot of Xbox 360s. As far as I'm aware no one I know still has a functioning Xenon or Zephyr. Falcon and Opus are roughly 50/50, and I don't know of a single Jasper or later console that has failed randomly. A few have been taken out through obvious external forces like lightning, children, and/or gravity but nothing like the earlier consoles where you could just be playing a game, it freezes, reboots, and then the lights we all feared come on.
A bunch of those consoles now have succumbed to optical drive failures and most of the rest are getting pickier about what discs they'll load, but that's an entirely different thing common to all sorts of older hardware. All those machines still play any games you want to off the hard drive.
IMHO The point of this project wasn't for practicality; it's for fun in the process.
For a hacker like the author, anything is a good learning practice and thus good time spent.
That being said, you have a good point -- For people really looking for a serious alternative to computers, they shouldn't look too deep into Xbox 360. Thanks for putting the warning about RROD here. You've added a valuable warning sign to the original content.
RROD hasn't really been much of a thing since the older fat models. If you have a slim Xbox 360 you're basically golden.
Corona, Jasper, and Trinity boards are widely considered the most reliable revisions. This coveres late fat and all slim models produced from ~2008 up to 2013. The "E" model introduced in 2013 is also pretty reliable, but some units are not good for modding.
They started becoming less prevalent throughout 2008, as manufacturers got better at working with RoHS-compliant solder and die shrinks meant less heat.
However, the failure rate for the early models was only 25%. An astronomically high number for any consumer electronic and 10x that of the Nintendo Wii, but still a minority of consoles. Plenty of people got "bad" consoles in 2006, 2007 and didn't have a failure until 2009 or 2010. There were also plenty of "refurbished" consoles floating around game stores and ebay for years that would eventually fail again.
There are some near end-of-life Xbox 360 models that are less prone to RROD's, but i'm not sure if you could still install linux/modchips on the newer ones. I think they put more security on those.
I nearly forgot how HD-DVD used to be a thing. I remember back when HD-DVD was surpassed by bluray, they had a whole shelf of those Xbox 360 HD-DVD drives on fire sale at Fry's electronics (RIP) for $10.
Went to fire up my old 360 that was in the basement to play some old kinetic dance game with the kids. RROD. Seemed a waste to throw more good money/time after bad trying to fix it.
Tangential: back in the day, installing a modchip in the original Xbox to boot Linux was a nice way to get a cheap Linux box. 64MB RAM were a bit tight when 256MB were pretty much the norm, but otherwise the machine was quite powerful for its price.
ah, fun times. i remember interviewing the guy behind the project, a very nice person.
also i remember there was a modified boot loader (chromwell, iirc?) and some person had managed to solder an additional 64mb chip to bring the total memory to a whopping 128MB.
I really enjoy concepts like these that scavenge the most value from obsolete items / things you can get (almost) for free. (I used to build really cheap computers for kids who can't afford them.) I also love ideas that makes a special-purpose device available for general computing.
This makes me want to try my hand again at using Nix to build a full Linux disk image for the OG Xbox. I had a whole strategy planned until realizing that the OG Xbox needs an older rev of x86 than we support in nixpkgs...
I've been thinking that linux on an xbox one could be a nice way to reuse all those consoles sitting un-used as people move to Series X/S.
Also made me think that there could be a market for PCs that are inbetween laptop and desktop size. So something Xbox sized that can upgrade RAM and SSD and keep everything else small like a console.
For people doing similar projects, you can use qemu in user mode to work around this. I believe the relevant Debian package is qemu-user-static. With it, you can execute binaries from foreign architectures as if they're native, with software translation doing all the hard work for you. Think Rosetta (not Rosetta2) but on Linux and supporting a wide variety of hardware.
Install the package, copy /usr/bin/qemu-<target architecture>-static to the /usr/bin folder in your chroot and you should be able to chroot into the foreign system!
I've used this to analyze some ARM binaries pulled from a router and it works surprisingly effective. Applications may fail because of the version inconsistencies between the daemons running on your OS and the old versions the chroot expects, but for basic tools it should Just Work, really.