wraggster
November 1st, 2009, 20:15
Heres an update from the Hackimii Team (http://hackmii.com/2009/11/updates-and-bricking/) courtesy of Bushing and like most newsposts its better to comfrom the coder than some uninformed person posting the news:
I keep getting questions along the lines of “should I update to 4.2? Are you guys going to make a ’safe boot2 updater’?” (The answer is ‘no’, but keep reading.)
Somewhere in the noise about this most recent update the point I was trying to make got lost. Let me recap the facts:
The most recent system update was the largest update ever done — 32 titles were added or updated, and each system downloaded approximately 50MB of data.
A certain firmware graybeard tells me that, on average, 1 in 1000 updates (of any software, on any system) will fail.
The Wii performs updates atomically on a per-title basis. What this means is that the system menu downloads each title from the Nintendo Update Server and feeds the data directly to IOS/ES. As each chunk of data for a given title is downloaded, IOS writes it into /import, and then once the entire title has finished downloading, it renames the files in /import to overwrite the older version of the title (in one step, “atomically”). That rename step probably only takes a second or two for each title.
Contrary to Nintendo’s claims, an update will not start over from the beginning if interrupted. Rather, the updates will be downloaded and installed in this order: boot2, IOS of the new system menu, a new system menu, and then everything else. If the update is interrupted after (for example) the IOS is installed but before the System Menu has finished downloading, the partially downloaded System Menu will be deleted upon the next reboot. You will still be told “an update is available”, and it will restart the update — but since it won’t reinstall the same version of something that’s already there, it will skip over boot2 and the IOS and restart downloading the system menu.
Any failed update on three of those pieces (boot2, system menu, IOS) will cause the system to irreparably brick.
Any failed update on another part of the system (for example, another IOS) could either cause strange behavior (certain games won’t launch) or could cause the system to brick (if it damaged the filesystem in NAND).
As far as updating boot2 goes:
The 1-in-1000 number applies to boot2, although there are some protection mechanisms in place to try to mitigate that risk. There are two separate copies of boot2 stored in flash, and if one is corrupted, it will try to boot the other — this is the only real “safety mechanism” in the entire device.
The boot2 update code is completely separate from any other update code, and has never been used before on any retail Wiis. That does not mean it’s necessarily broken or buggy, just that it has been nearly as well-tested as any of the other updater code.
During the development of BootMii/the HackMii Installer, I ran into a bug where the ECC data was not always written when writing boot2. Let me be clear here — this is not a huge bug. It only applies to the boot2-area blockmap page, and when it happens, the effect is generally harmless — if there is a bit error in that page, it will not be detected or corrected, but there are three copies of that data in that page and boot1 will choose the best 2 out of 3. (The only real indication you will see of this is if you find the message “Ninty forgot to write spare data for page xxx” in your installer.log file after installing BootMii/boot2.) I don’t really think this will cause a system to get bricked, but it’s evidence that the code has not been thoroughly tested.
Our boot2 updater code presumably carries the same 1-in-1000 risk of failure, but a failure there will still allow at least one of the two old copies of boot2 to work. (We do something mildly clever there to avoid overwriting each copy, and to prevent problems with BC/MIOS.)
There is no benefit or pitfall to installing boot2v4, other than the fact that if you don’t install it, it will keep trying to install it whenever you update, and if you had BootMii/boot2 installed, it will overwrite it.
Various employees of Nintendo — from lowly tech support staff and forum moderators to executives — have made the claim that “most of the bricked systems were a result of other modifications to the system.” This is a lie, and I’m disappointed in Nintendo for trying to make this claim. It’s not supported by evidence — how could they possibly get that kind of statistic? (There hasn’t been time for them to get bricked units back and do much analysis, and even in the case where they do have a bricked console in their hands, there’s nothing they can do to see whether it was modified or not.) It’s not supported by logic, either — the reason why this update “kills homebrew” is because it overwrites EVERYTHING, but the same is true for unmodified Wiis. It’s not even supported anecdotally — there were comments on Nintendo’s official Tech Forums from people who had bought a new Wii that day and had it brick the first time they did their connection test and system update.
If we were to write a boot2 installer, there’s no guarantee that it would be any safer than Nintendo’s. We sincerely believe it to be safe — we’ve tested it as much as we possibly can, we have an unreasonable number of safety checks in there, and I have yet to hear of a single case of bricking in somewhere between 10-20,000 installs — but then again, I’m sure Nintendo feels the same way about their code.
The distinction here is a more subtle than “whose code is buggier”. When you run the HackMii installer and install anything we’ve written, you are taking some risk. The difference here is that
For the (say) 20,000 people that run the HackMii installer, each one of them has done so deliberately and with some goal in mind — tinkering with their system, playing homebrew games, whatever. In the case of BootMii/boot2, we even give you a strong defense against bricking your console through updates (oh, the irony). If you run into problems, you can be mad at us, you can be mad at yourselves, but at the end of the day, you took a calculated risk.
For the 55 million people who own Wiis but did not run the HackMii Installer — yet are forced to update anyway — they run the risk of bricking with no tangible benefit to them whatsoever, and no choice in the matter.
If we take this 1-in-1000 statistic of failed updates, and say that 1-in-100 of those failed updates will result in a bricked system, and then extrapolate that over the top two groups — you end up with maybe one or two homebrew-running people with bricked Wiis, and 550 unmodified, bricked Wiis. If you have one of those, go to Nintendo and ask them to fix it for free. If you haven’t updated, there’s no good reason to — other than to stop it nagging at you to update. If you do feel compelled to update, your chances of running into problems are no better and no worse than anyone else’s, and they wouldn’t be much different if we wrote the update code instead of Nintendo.
This is the reason why it’s a big deal when anyone releases a bootloader update — it’s inherently risky, and for most people, it’s not worth the risk.
I keep getting questions along the lines of “should I update to 4.2? Are you guys going to make a ’safe boot2 updater’?” (The answer is ‘no’, but keep reading.)
Somewhere in the noise about this most recent update the point I was trying to make got lost. Let me recap the facts:
The most recent system update was the largest update ever done — 32 titles were added or updated, and each system downloaded approximately 50MB of data.
A certain firmware graybeard tells me that, on average, 1 in 1000 updates (of any software, on any system) will fail.
The Wii performs updates atomically on a per-title basis. What this means is that the system menu downloads each title from the Nintendo Update Server and feeds the data directly to IOS/ES. As each chunk of data for a given title is downloaded, IOS writes it into /import, and then once the entire title has finished downloading, it renames the files in /import to overwrite the older version of the title (in one step, “atomically”). That rename step probably only takes a second or two for each title.
Contrary to Nintendo’s claims, an update will not start over from the beginning if interrupted. Rather, the updates will be downloaded and installed in this order: boot2, IOS of the new system menu, a new system menu, and then everything else. If the update is interrupted after (for example) the IOS is installed but before the System Menu has finished downloading, the partially downloaded System Menu will be deleted upon the next reboot. You will still be told “an update is available”, and it will restart the update — but since it won’t reinstall the same version of something that’s already there, it will skip over boot2 and the IOS and restart downloading the system menu.
Any failed update on three of those pieces (boot2, system menu, IOS) will cause the system to irreparably brick.
Any failed update on another part of the system (for example, another IOS) could either cause strange behavior (certain games won’t launch) or could cause the system to brick (if it damaged the filesystem in NAND).
As far as updating boot2 goes:
The 1-in-1000 number applies to boot2, although there are some protection mechanisms in place to try to mitigate that risk. There are two separate copies of boot2 stored in flash, and if one is corrupted, it will try to boot the other — this is the only real “safety mechanism” in the entire device.
The boot2 update code is completely separate from any other update code, and has never been used before on any retail Wiis. That does not mean it’s necessarily broken or buggy, just that it has been nearly as well-tested as any of the other updater code.
During the development of BootMii/the HackMii Installer, I ran into a bug where the ECC data was not always written when writing boot2. Let me be clear here — this is not a huge bug. It only applies to the boot2-area blockmap page, and when it happens, the effect is generally harmless — if there is a bit error in that page, it will not be detected or corrected, but there are three copies of that data in that page and boot1 will choose the best 2 out of 3. (The only real indication you will see of this is if you find the message “Ninty forgot to write spare data for page xxx” in your installer.log file after installing BootMii/boot2.) I don’t really think this will cause a system to get bricked, but it’s evidence that the code has not been thoroughly tested.
Our boot2 updater code presumably carries the same 1-in-1000 risk of failure, but a failure there will still allow at least one of the two old copies of boot2 to work. (We do something mildly clever there to avoid overwriting each copy, and to prevent problems with BC/MIOS.)
There is no benefit or pitfall to installing boot2v4, other than the fact that if you don’t install it, it will keep trying to install it whenever you update, and if you had BootMii/boot2 installed, it will overwrite it.
Various employees of Nintendo — from lowly tech support staff and forum moderators to executives — have made the claim that “most of the bricked systems were a result of other modifications to the system.” This is a lie, and I’m disappointed in Nintendo for trying to make this claim. It’s not supported by evidence — how could they possibly get that kind of statistic? (There hasn’t been time for them to get bricked units back and do much analysis, and even in the case where they do have a bricked console in their hands, there’s nothing they can do to see whether it was modified or not.) It’s not supported by logic, either — the reason why this update “kills homebrew” is because it overwrites EVERYTHING, but the same is true for unmodified Wiis. It’s not even supported anecdotally — there were comments on Nintendo’s official Tech Forums from people who had bought a new Wii that day and had it brick the first time they did their connection test and system update.
If we were to write a boot2 installer, there’s no guarantee that it would be any safer than Nintendo’s. We sincerely believe it to be safe — we’ve tested it as much as we possibly can, we have an unreasonable number of safety checks in there, and I have yet to hear of a single case of bricking in somewhere between 10-20,000 installs — but then again, I’m sure Nintendo feels the same way about their code.
The distinction here is a more subtle than “whose code is buggier”. When you run the HackMii installer and install anything we’ve written, you are taking some risk. The difference here is that
For the (say) 20,000 people that run the HackMii installer, each one of them has done so deliberately and with some goal in mind — tinkering with their system, playing homebrew games, whatever. In the case of BootMii/boot2, we even give you a strong defense against bricking your console through updates (oh, the irony). If you run into problems, you can be mad at us, you can be mad at yourselves, but at the end of the day, you took a calculated risk.
For the 55 million people who own Wiis but did not run the HackMii Installer — yet are forced to update anyway — they run the risk of bricking with no tangible benefit to them whatsoever, and no choice in the matter.
If we take this 1-in-1000 statistic of failed updates, and say that 1-in-100 of those failed updates will result in a bricked system, and then extrapolate that over the top two groups — you end up with maybe one or two homebrew-running people with bricked Wiis, and 550 unmodified, bricked Wiis. If you have one of those, go to Nintendo and ask them to fix it for free. If you haven’t updated, there’s no good reason to — other than to stop it nagging at you to update. If you do feel compelled to update, your chances of running into problems are no better and no worse than anyone else’s, and they wouldn’t be much different if we wrote the update code instead of Nintendo.
This is the reason why it’s a big deal when anyone releases a bootloader update — it’s inherently risky, and for most people, it’s not worth the risk.