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

backing up kernel and initramfs for future rescue use with upslug2



I'm very pleased with the progress of the debian arm port.  My NSLU2
is running fine, and i'm looking forward to seeing it become an
official stable release with the etch transition.

I'd like to try to upgrade to the new kernel
(linux-image-2.6.18-3-ixp4xx), but i want to make sure i can recover
properly if something goes wrong.

In particular, i'd like to be sure that i can reflash the onboard
flash with its current (functional) contents, should i need to do
that.

i'm not sure what approach to take:

 0) Can i just copy the existing flash contents to a file, and back it
    up on another machine?  This seems like it would be the easiest
    (and most stable) thing to do, but i'm not sure how to do it.  Can
    i just do something like this:

     [root@igor]# cat /dev/mtdblock{0,1,2,3,4,5} >/var/backups/flashimage.bak
     [root@igor]# scp /var/backups/flashimage.bak backuphost:igor-backups/

    and then flash it with upslug2 from backuphost if something goes
    wrong?  That does seem to add up to the right bytecount...

 1) Alternately, i'd be happy to just backup my kernel and initramfs
    if i was sure that was all i needed, since i can use upslug2 to
    reflash them when the time comes.  But if i'm going to do that, i
    still have questions after reading "man upslug2 slugimage" (i'm
    running upslug2 version 11-1):

   * For specifying the initramfs in upslug2, should i use -r or -R?
     the man page has a FIXME here.

   * My slug uses the first partition of the USB disk for its root
     filesystem.  What should i specify for the rootfs in this case?
     Can i leave it empty?

   * What is the FIS directory?  can i leave that empty as well?

   * Do i need to include the second-stage bootloader (apex-nslu2) in
     an any image to be reflashed by upslug2?  If so, how would i
     specify that?

   * Do i need to specify --extra-version, --firmware-version,
     --product-id, or --protocol-id?  Are they for my own future
     reference?  Or do they have some other meaning which i will make
     me regret tinkering with them?

   * What should i do about endianness if i'm flashing a standard
     NSLU2 running arm (not armel) from a i386 machine?

Thanks for any suggestions or pointers, and thanks especially to the
debian-arm team for this great platform.

	--dkg



Reply to: