Re: Etch-Lenny upgrade gone bad

2009-09-28 Thread Del Merritt
Martin Michlmayr wrote:
 Hi Del,

 * Del Merritt d...@alum.mit.edu [2009-09-23 21:53]:
   
 I mentioned that I have a good Lenny slug.  I'm hoping there's a
 clever way for me to flash its vmlinuz (and anything else from the
 good Lenny install) to the former-Etch slug.
 

 There is, although it remains to be seen whether it will help.
   

Well, as you (implicitly) predicted, that didn't help.  Since the HDD is
still quite mountable, I did an:
%  find bin boot etc initrd lib sbin sys usr -ls
in / on both machines.  I then  whipped up a little script to compare
the results, looking for common (and not) files and, when common, if the
sizes matched.  A daunting number are different or only on one or the
other.  *sigh*

So I'll copy my important files off of the / partition and then try
one of the don't blow away my existing partitions methods of a fresh
lenny install.  I had hoped to avoid this, just 'cuz, but the full
install - once I'm done with all the backups, just in case - is pretty
quick.

And I still need to turbo the beast.  So many projects; so little time.

Thanks for the suggestions, though. 

-Del


 You can make a copy of your good machine with:
 cat /dev/mtdblock?  backup

 and then upload that to your broken machine with:
 upslug2 -U -i backup

   
 I'm open to other suggestions; I haven't tried (yet) plugging my
 etch-lenny disk to the good lenny box; aside from MAC address and
 IP address, is there system-specific information in the flashed
 data?
 

 The IP address is actually stored on disk, not in flash (at least in
 case the Debian).  See /etc/network/interfaces

 The MAC address is not stored in flash either.  However, the udev
 rules will mention the MAC address to ensure it always uses the same
 network name.  So when you plug your disk into the other NSLU2 you'll
 have to adapt /etc/udev/rules.d/70-persistent-net.rules

 Apart from that, it should work fine.

   
 In fact, I happen to have a third slug - still in box - and I'd love
 to have a clever way to clone one of the other two without having to
 go through the full Debian Installer (or the even slower aptitude
 [full|safe]-upgrade process).
 

 It's actually pretty easy to clone a NSLU2:

  - tar up the whole disk and untar it to another disk with the same
disk partition layout.
  - Edit /etc/network/interfaces (in case it has a static IP, rather
than DHCP)
  - Edit /etc/udev/rules.d/70-persistent-net.rules
  - Make a copy of flash (as above) and write it to the other
device (again, as above).

 It's on my TODO list to write a HOWTO describing how to clone a NSLU2
 but I'm not sure when I'll find the time.

   
 Sorry for a long first post here; I've had worry-free slug operation
 in the past, and thought I had the ducks in a row.  Thanks for any
 ideas,
 

 No problem.  I hope you get it working.
   


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Etch-Lenny upgrade gone bad

2009-09-23 Thread Del Merritt
I am hoping for some help with a problem, an aptitude full-upgrade 
gone bad.  The history:


  1. Two NSLU2s (hence slugs, of course), stock (unturboed, unfat)
  2. One runs Lenny, installed from the Debian installer
  3. The other runs Etch, also installed from the Debian installer back
 in the day (I helped diagnose issues with ssh timeouts - see the
 wiki); has an 8GB swap partition (more on this later)
  4. I decide, time to upgrade the Etch slug
  5. Update sources.list to point to Lenny [1]
  6. aptitude update
  7. aptitude full-upgrade
  8. watch the oom-killer whack aptitude, many times, in different and
 terrifying ways; go back to step 6, or sometimes do a dpkg
 --configure -a, if it tells me it needs that
  9. try adding more swap (1GB via dd and mkswap) - problem gets worse
 (for in retrospect obvious reasons [2])
 10. create 256MB swap file; swapon 256MB file, swapoff 8GB partition
 and 1GB file
 11. watch aptitude (and a dpkg --configure -a) smoothly finish the
 upgrade, including:
 :
 Setting up build-essential (11.4) ...
 Processing triggers for initramfs-tools ...
 update-initramfs: Generating /boot/initrd.img-2.6.26-2-ixp4xx
 Flashing kernel: done.
 Flashing initramfs: done.
 sh-3.2#
 12. install locales it hadn't been there, and I'm not sure if it was
 the victim of the oom-killer or wasn't there in etch for some
 reason; my logs are full of:
 Setting up some-module (X.yy) ...
 perl: warning: Setting locale failed.
 perl: warning: Please check that your locale settings:
 LANGUAGE = (unset),
 LC_ALL = (unset),
 LANG = en_US.UTF-8
 are supported and installed on your system.
 perl: warning: Falling back to the standard locale (C).
 locale: Cannot set LC_CTYPE to default locale: No such file or
 directory
 locale: Cannot set LC_MESSAGES to default locale: No such file or
 directory
 locale: Cannot set LC_ALL to default locale: No such file or directory
 13. aptitude update; aptitude  safe-upgrade; - Yay! - it says I don't
 need any more stuff!
 14. check my ethernet config; looks OK
 15. sync; sync; # deep breath
 16. reboot
 17. wait; and wait; nothing; no ping response; lights are on green
 Disk 1 and Ready/System LEDs; except for a brief time at power up,
 no Ethernet LED activity
 18. power down hard; plug disk in to workstation; look at var/log/,
 and nothing is modified since reboot
 19. plug back into slug and try again; after a while, only Disk 1 LED
 is lit

That's a lot of steps.  I'm guessing that I ended up with a bad flash.  
At least I haven't lost the data on the drive (yet).


I mentioned that I have a good Lenny slug.  I'm hoping there's a 
clever way for me to flash its vmlinuz (and anything else from the good 
Lenny install) to the former-Etch slug.  I'm open to other suggestions; 
I haven't tried (yet) plugging my etch-lenny disk to the good lenny 
box; aside from MAC address and IP address, is there system-specific 
information in the flashed data?


In fact, I happen to have a third slug - still in box - and I'd love to 
have a clever way to clone one of the other two without having to go 
through the full Debian Installer (or the even slower aptitude 
[full|safe]-upgrade process).  Seems that if my problem is indeed a bad 
flash, I could use that technique and some judicious disk copying to 
create new versions.  But that's a different topic...


Sorry for a long first post here; I've had worry-free slug operation in 
the past, and thought I had the ducks in a row.  Thanks for any ideas,


-Del

[1] These steps are somewhat abridged, actually.  So there's possibly 
something else I did that didn't help.
[2] Turns out I should have read about swap space and Linux more 
closely; bigger swap puts *more* pressure on low-memory and hastens the 
onset of the oom-killer.  *sigh*



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org