[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Fwd: Upgrading kernel on Sheevaplug requires SD card to be removed and re-inserted]



A follow up on an old problem.

I have resisted upgrading my Sheevaplug to 2.6.32-2 because of the
problem recorded below - I didn't want to do it until I knew I could
spare the time.

Last weekend my Sheevaplug died (broken PSU apparently).  I've bought a
new one and transferred the system over.  Whilst I was at it I thought I
should finally do that kernel upgrade.

Exactly the same problem again - the new kernel won't boot with the boot
loader complaining about "Bad Magic Number".  This time however the
renaming trick didn't work.  I've gone backwards and forwards a few
times but it just won't boot with the new 2.6.32-2 uImage and uInitrd.
I've had to rename them out of the way and put the 2.6.30-2 ones back.

Note that this is a completely new Sheevaplug and it exhibits exactly
the same symptoms as its predecessor.

John


-------- Original Message --------
Subject: Upgrading kernel on Sheevaplug requires SD card to be removed
and re-inserted
Date: Sun, 15 Nov 2009 07:46:41 +0000
From: John Winters <john@sinodun.org.uk>
To: debian-arm@lists.debian.org

I reported earlier problems when I first upgraded the kernel on my
Sheevaplug (running from an 8G SDHC card).  After the new kernel had
been installed (and flash-kernel run manually) the plug wouldn't boot.

That time I moved the card to a different machine, renamed back to the
old kernel and booted successfully.  The odd thing was, when I reversed
the process (again removing the card) I found I could boot the new
kernel too.

I've just upgraded to the latest 2.6.30-2 and again, the machine
wouldn't boot the new kernel.  I'm trying to cut down the recovery
process to a minimum.  What I did this time was:

Move card to laptop
Rename to old kernel
Card back to plug
Boot old kernel (2.6.30-1)
Rename back to new kernel
Re-boot and all is hunky

It seems to be something to do with either needing the card to be
physically removed from the box before it will boot a new kernel
(firmware caching part of the kernel image?) or the need for a rename.

John


Reply to: