Script to upgrade from Squeeze to Wheezy without buggy 3.2 kernel

I've prepared a script which manages an upgrade from Debian Squeeze ( stable, as installed following http://projects.doozan.com/debian/ ) to Wheezy (testing) reliably, using only apt tools and the debian repositories.

It works at the time of writing this post. It must be run as root of course. Try it at your own risk, but these steps worked on my Pink Pogoplug. Instructions at http://cefn.com/blog/pogoplug_wheezy.html

It does this by manually installing an early version of the 3.x kernel and then holding future kernel upgrades to prevent the installation of kernel 3.2 which has a buggy interaction with uBoot as discussed elsewhere on this forum. It overwrites /etc/apt/sources.list to point to UK Wheezy repositories, binary only, including contrib and non-free. If you want to change this behaviour for a different repo or packages then modify the relevant line. It is intended to be run non-interactively, so it chooses Y to all prompts and causes local config files to be overwritten by those of the package maintainer on upgrade and dist-upgrade. If you want to change this behaviour then edit the APT_OPTS variable to something else. Making APT_OPTS blank means you will have to sit there waiting to handle 5 or 6 keyboard interactions during the update, which can take quite a while, more than half an hour.

If you don't want all of these steps, remix the script for your tastes. Feedback very welcome in this thread.

Just wondering why you choose to upgrade to 3.1.0 instead of 3.3.3 thereby skipping 3.2?

Also wondering... 3.3.2 is fine - no bugs, and 3.4.1 is just around the corner. There _is_ a minor bug in the older U-Boots (not disabling the L2 cache just before decompressing the kernel), and I actually thought it wasn't a bug until I saw that some of the Marvell (OEM) U-Boots did have this L2C disable setting available.

To each their own, though. If it works great for you, more power to you.

=====================================================

• davy's Github Repo's rescue-dg

Thanks for the feedback. I find specifying what I'm doing in this much detail really useful to get people's perspectives on how to do it better, and I'm sure you're right.

Could you suggest a reliable location from which I can get the proper kernel file (linux-image.***.deb) via http, and I'll add that into the script instead.

My main intent, (and I hope this will still be valuable), is to make it idiot-proof to upgrade, compared to some of the more complex sequences steps I've seen on the forum (especially requiring serial connectivity!). I can't find anything in the top level of the site (as there is for lenny or squeeze) to guide someone through these steps.

No doubt many of these sequences are for historical reasons, during the investigation of the problem, but it's hard as a new forum member to work out what is 'old hat' without someone promoting a preferred sequence as 'best practice'.

I thought >= 3.2 was a problem as Wheezy's default latest kernel was broken when I naively followed the /etc/apt/sources.list upgrade path, but if things have moved on beyond then that's great, and I'll be sure to use a later kernel the moment I hear of a reliable source.

And just to clarify, are you saying the sequence of steps to upgrade my uBoot as detailed at http://forum.doozan.com/read.php?3,6965,6965 is no longer necessary if I want to run 3.3.3. Even without following this kind of sequence, you're saying 3.3.3 will just work by running dpkg -i with an appropriate kernel .deb file.

I think I've been misled by statements which appear a lot in these threads (as typified by the thread I linked above) saying that any kernel >= 3.2 into the future will have the same problem, but maybe something got sorted out since.

cefn Wrote:
-------------------------------------------------------
> And just to clarify, are you saying the sequence
> of steps to upgrade my uBoot as detailed at
> http://forum.doozan.com/read.php?3,6965,6965 is no
> longer necessary if I want to run 3.3.3. Even
> without following this kind of sequence, you're
> saying 3.3.3 will just work by running dpkg -i
> with an appropriate kernel .deb file.
>

As far as I know, you either need a custom-configured-and-built kernel, or a U-Boot that disables the L2 Cache while the decompressor stub inflates the uImage.

There were several problems/changes in 3.2 that were very noticeable to Kirkwood users. Some were inconsequential or at least easily fixable (like a header problem in arch/arm/include/asm/bug.h) minor problems. The big change that actually stopped so many of us from booting a 3.2 (or higher) kernel turned out to not be a bug at all. It was a policy change that _wouldn't_ have been a problem, if it had hadn't been for a latent bug in the older U-Boot. This latent bug was not anyone's fault - it was just that no one had noticed the problem... unforeseen, I guess.

To boot 3.2 (or higher) standard-issue kernels on Kirkwood, you will (almost certainly) need a U-Boot that disables the L2 Cache at initialization. This allows the processor to correctly decompress the kernel (uImage) and boot normally.

It is possible to custom-compile (using non-defconfig settings) a kernel, but that won't work for someone who is trying to debootstrap Wheezy (or into a 3.2 or higher kernel).


> I think I've been misled by statements which
> appear a lot in these threads (as typified by the
> thread I linked above) saying that any kernel >=
> 3.2 into the future will have the same problem,
> but maybe something got sorted out since.

No, I wouldn't say you've been misled. It is my understanding that from 3.2 on out, any standard-issue kernel will expect that the L2 Cache is disabled - once the kernel is done decompressing, it eventually re-enables it. Some of the newer OEM U-Boots (from Marvell's source - production/factory-installed U-Boots) have the L2C disabled at initialization.

Misled? Unless you've seen some notification in the LKML (linux kernel mailing list) that indicates otherwise, what we saw starting in 3.2 is now the default setting/default behavior.

On the other hand, if you've seen some very recent post/article from the kernel-developers community that says otherwise, please post back w/ a link to it.

Personally, I'd be livid if I found out that - "ohhh, it was all just a big mistake, and now we are going back to the pre-3.2 behavior". I posted some of the first bug reports on this and followed the early-middle discussions that said it would _never_ revert to the previous status.

=====================================================

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 05/12/2012 05:49PM by davygravy.

davygravy Wrote:
>
> It is possible to custom-compile (using
> non-defconfig settings) a kernel, but that won't
> work for someone who is trying to debootstrap
> Wheezy (or into a 3.2 or higher kernel).

I can confirm that it's a simple change (3 parameters) in the .config file (that I've learned from some member's post in this forum) did allow me to build Wheezy kernel 3.2.x and boot successfully with Jeff's UBoot. That was while davy was still working on the new UBoot.

These parameters are:

# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_EMBEDDED=y
CONFIG_PHYS_OFFSET=0x0

Don't worry Davygravy, I'm not suggesting uboot+kernels =>3.2 will end up fixed by another route. I'm just trying to get informed.

I think in response to

Quote
astker
Just wondering why you choose to upgrade to 3.1.0 instead of 3.3.3 thereby skipping 3.2?

...and...

Quote
davygravy
Also wondering... 3.3.2 is fine - no bugs, and 3.4.1 is just around the corner.

Because this approach is easy, works, and requires few steps. Is that so surprising? My suspicion is that this is what most users want as a first priority - simple access to Wheezy software, with a later kernel as a nice-to-have and to handle certain very specialist issues.

I personally don't have a clue how to follow instructions such as those provided by Bodhi, as there's a lot of implicit information about where those lines go, and as part of what procedure, which I don't have.

As we explore in this thread the use of kernels 3.3 or 3.4 I fear we're once again approaching the event horizon of 'why don't you just rebuild your uBoot' through these simple manual steps, requiring netconsole, tftp, JTAG and similar. Those insights are really valuable, and the effort you're volunteering is really welcome, for users who are sufficiently keen on a later kernel. I'm relatively indifferent, compared to the value of having a script which (modelled on Jeff's Script) reliably works like...

wget http://cefn.com/blog/files/wheezy-upgrade.sh
chmod +x wheezy-upgrade.sh
./wheezy-upgrade.sh

...and then gets me wheezy software builds straight from the repository.

If anyone can produce an equivalently idiot-proof series of steps which gets our plug computers to Wheezy with a kernel >= 3.2, or can tell me how to modify my script so it does this, either by updating uBoot or selecting a kernel.deb which doesn't reveal this latent issue, then it makes sense to use a later kernel for users with my tastes for simplicity. Otherwise, it doesn't.

Can anyone point me to a http-hosted .deb which gives a later kernel which will work without going through what seem very complex and manual uBoot upgrade instructions? Or is a uBoot upgrade scriptable?

Sorry if I'm sounding like a PITA but I seem to be finding it hard to explain myself, although what I'm doing seems to be straightforward and well-justified in my mind.

cefn Wrote:
-------------------------------------------------------
> Because this approach is easy, works, and requires
> few steps. Is that so surprising? My suspicion is
> that this is what most users want as a first
> priority - simple access to Wheezy software, with
> a later kernel as a nice-to-have and to handle
> certain very specialist issues.

Easy is great. Few steps is great.


> I personally don't have a clue how to follow
> instructions such as those provided by Bodhi, as
> there's a lot of implicit information about where
> those lines go, and as part of what procedure,
> which I don't have.
>
> As we explore in this thread the use of kernels
> 3.3 or 3.4 I fear we're once again approaching the
> event horizon of 'why don't you just rebuild your
> uBoot' through these simple manual steps,
> requiring netconsole, tftp, JTAG and similar.
> Those insights are really valuable, and the effort
> you're volunteering is really welcome, for users
> who are sufficiently keen on a later kernel. I'm
> relatively indifferent, compared to the value of
> having a script which (modelled on Jeff's Script)
> reliably works like...
>

> wget http://cefn.com/blog/files/wheezy-upgrade.sh
> chmod +x wheezy-upgrade.sh
> ./wheezy-upgrade.sh
>

> ...and then gets me wheezy software builds
> straight from the repository.

Eventually the repository will list kernels that are higher... at some point the sub 3.2 kernels will be old-stable and then unsupported.

> If anyone can produce an equivalently idiot-proof
> series of steps which gets our plug computers to
> Wheezy with a kernel >= 3.2, or can tell me how to
> modify my script so it does this, either by
> updating uBoot or selecting a kernel.deb which
> doesn't reveal this latent issue, then it makes
> sense to use a later kernel for users with my
> tastes for simplicity. Otherwise, it doesn't.

Updating U-Boot takes less than 5 minutes. I'm pretty sure there are no more than 6 commands, including the wget, untar and flashing.

> Can anyone point me to a http-hosted .deb which
> gives a later kernel which will work without going
> through what seem very complex and manual uBoot
> upgrade instructions?

Everyone has a different tolerance for the complexity. In my view 6 cut&paste commands is not big deal. I certainly understand anyone who is risk-averse to something unforeseen going wrong though.

> Or is a uBoot upgrade scriptable?

Absolutely. It is a matter of adding some more code to check md5 sums and some testing/decision statements for safeguards. Jeff and I have communicated about this - it is in the planning stages - maybe sometime June or July.

> Sorry if I'm sounding like a PITA but I seem to be
> finding it hard to explain myself, although what
> I'm doing seems to be straightforward and
> well-justified in my mind.

=====================================================

• davy's Github Repo's rescue-dg

I just recently dumped arch and went to debian on my v1 plug and you guys work is awesome! I am looking forward to wheezy on my plug! :)

Eric,

Would love to learn if the script I proposed works for you (search "pogoplug wheezy fix" on google as I have trouble with links here).

So far I've no corroboration beyond my own single test case.

Is there now a scripted sequence to go from a stock Pogoplug to one with an up-to-date wheezy kernel (which scripts the fixed uboot setup or works around it in some way)?

If it exists I'm hoping to provide a link and description from my page as people still arrive there sometimes I think.