upgrading to Debian 5.0

Jared list-dell at legroom.net
Thu Feb 26 15:25:25 CST 2009

Thanks for the replies.  I've already performed one upgrade on a server
at my house and had trouble with a bad NIC driver in the new kernel
(which causes an instance kernel crash on load), some openssh/openssl
issue that prevents me from using key-based SSH authentication, and the
complete disappearance of my CD-ROM drive (still haven't figured out
that one).  Fortunately, I had local access to this server, so I was
able to recover, but needless to say it didn't make me to enthusiastic
about upgrading my remote PE 2950.

The biggest thing that worries me based on what I've read so far is the
mdadm/RAID issue.  I have a PERC5/i on a PE 2950.  Is this something
that I should look out for?  I'm using hardware RAID w/ LVM, and I
believe that mdadm only comes into play with software RAIDs, so I think
I should be safe here.  I'd rather be safe than sorry, though.


On 02/26/2009 04:25 AM, Simon Waters wrote:
> Just done all but one of our Debian servers, with most reboots this morning 
> before folks got in.
> This morning I discovered the mdadm feature of lenny.
> The kernel in Lenny does mdadm differently, such that you need 
> a "rootdelay=10" statement on the kernel cmdline, otherwise it doesn't find 
> your root disk (assuming you have root on a mirrored disk - i.e. md0). Hmm -- 
> quite how this didn't get fixed I don't know. Easy to fix once you know what 
> it is - stops at "Attached scsi disk" and eventually times out saying the 
> root disk was not found. Booted the old kernel (which worked fine!), added 
> the option to /boot/grub/menu.lst - and was away again.
> SATA in an SC1425 needed to use UUID in /etc/fstab because we went from 2.4 to 
> 2.6, as the disk name changes from /dev/hda to /dev/sda, also needs to add 
> options for the root parameter in /boot/grub/menu.lst, I set it for newer 
> kernels only. I'm adding switch all fstab's to UUID as a low priority task, 
> as it is more robust if less readable approach to finding your filesystems.
> Couple of my boxes hung for a long time on starting ntp - for the moment I've 
> removed it from the start-up. Problem is something to do with creating lock 
> files - I assume because we have an inconsistent set of NTP packages or some 
> such. I think ntpdate is obseleted, and hadn't been removed or some such. Not 
> a high priority issue for us.
> Not hit any Poweredge specific issues yet.
> General experience was good, although the mdadm issue did surprise me. Seems a 
> poor regression - I have hardware RAID most places but they gave their issues 
> moving from Sarge to Etch.
> Most time (outside our own complex software configurations) was boxes which 
> still had 2.4 kernels. These were 2.4 for Sarge, and I never switched them to 
> 2.6 when Etch came along, but just accepted the default. They all ran happily 
> with the Etch stock 2.6 kernel so they weren't hard just an extra reboot and 
> some fiddling around on the first one understanding what was needed. Just 
> install and boot Etch 2.6 kernel before trying to upgrade to Lenny is 
> simplest.
> Also some of our boxes down have the metapackage for the latest relevant 
> kernel, so that the Lenny upgrade doesn't seem to have given them an 
> appropriately shiny kernel by default.
> I'd suggest the magic step "aptitude install dpkg aptitude" be replaced 
> with "aptitude install dpkg aptitude debian-archive-keyring" as depending on 
> the boxes history it may not have "debian-archive-keyring", and you'll not 
> have the appropriate package signing key for lenny.
> Smile - some poor sap somewhere is updating an SC1425 which is an NTP server 
> with a 2.4 kernel, and an mdadm mirrored root disk (Actually mdadm uses UUID 
> is some revisions so they probably wouldn't hit all these issues, although 
> one of my boxes has the old disk names in the mdadm.conf file?!).
>  Simon

More information about the Linux-PowerEdge mailing list