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

Re: backing up kernel and initramfs for future rescue use with upslug2



Hi Daniel

On 11/26/06, Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net> wrote:

OK, good to know.  posting it as a bug as well would be helpful for
those of us who check these things before considering an upgrade.  i
know i'd be interested in the details.

Yeah, I know, but I was discussing the problem via email, so in this
case, apart from the reason you mention above, there was no reason to
file a bug report.

For reference, the problem was that the hooks provided by nslu2-utils
(/usr/share/initramfs-tools/hooks/nslu2 and
/usr/share/initramfs-tools/scripts/local-top/nslu2) that are used to
generate the initramfs were not being installed with execute
permission and therefore not being run.
/usr/share/initramfs-tools/hooks/nslu2 creates /conf/param.conf in the
initramfs which sets the root partition. Without this file, the system
is not able to find and mount the root disk, and therefore drops to an
ash shell before network access is available. If you didn't have a
serial port, you would have no idea what had happened to the system.

right.  As i understand it, filesystem presence of the modules for the
active kernel is probably the most important bit.  The kernel image
itself probably doesn't need to be there, so long as the bootloader
can get to it.

Yup.

ok, i went ahead with the upgrade, after backing up the flash image
with cat.  For whatever reason, my NSLU2 now takes a little less than
1 hour for the network interface to come up.  It used to be on the

Very odd. I have never seen this behaviour. The most similar report
that I have heard of was due to a hung RTC
(http://article.gmane.org/gmane.comp.misc.nslu2.linux/16483). Maybe
the posts in that thread can help (you can read the whole thread using
Yahoo Groups or Gmane).

since i don't have a serial line attached, i can't quite tell what's
making it take so long, unfortunately.  the syslog shows all "Mar 7
09:11:08" (give or take a handful of seconds) until ntpdate finally
kicks in, which of course doesn't happen until the NIC is actually up.

Can you try removing ntpdate (i.e. dpkg --deinstall ntpdate) and see
if the behaviour changes. I don't have ntpdate installed on my slug. I
think that ntpdate is no longer needed if you have the ntp package
installed because ntp now sets the clock initially
(http://packages.debian.org/testing/net/ntpdate).

Gordon

--
Gordon Farquharson



Reply to: