On Thu, Jul 15, 2004 at 04:30:23PM +0100, Clive Menzies wrote: > On (15/07/04 15:32), Sven Luther wrote: > > On Thu, Jul 15, 2004 at 01:27:19PM +0100, Clive Menzies wrote: > <snip> > > > It all worked pretty much "out of the box" - thanks for a very > > > smooth installer ;) > > > > > > Installing 2.6.7-powerpc-smp worked seamlessly on the new > > > install and sound, network etc. worked straight away. However, > > > I haven't yet installed all the software that I use on my > > > production box although I did upgrade to sid. The initrd.img is > > > in /boot on this installation and I amended yaboot accordingly. > > > > > > Installing 2.6.7-powerpc-smp on my production system, replacing > > > a custom 2.4.23-ben1.031224 which I'd compiled with HighMem, > > > smp, dma sound etc. produced some interesting results - none > > > insurmountable: > > > The initrd.img is in / on this installation but I amended yaboot > > Strange. How did that happen ? And was the initrd really in /, or just > > its symlink ? > Maybe, I need to be more explict ;) > > On the new install the symlink "initrd.img" is in /boot but on my > production system it is in /. On both sytems, the actual > initrd.img-2.6.7-powerpc-smp is in /boot. So it is the symlink > references in yaboot that need to be different. Not a serious problem > but during the installation, some comment on identifying where the > symlink resides might be helpful.
Check your /etc/kernel-img.conf. In the new install, it was set by debian-installer, while i suppose you have random or no values in it on your upgraded system. Not really d-i's problem though, but something we have to be aware of. > > > assuming that it was in /boot and managed get my production > > > system into an unbootable state. However, mounting the partition > > > in the new install allowed me to find initrd.img, update yaboot, > > > and get my system back ;) I'm in danger of becoming a geek - > > > eek ;) > > > > > > I lost network connectivity because eth0 was taken over by > > > ip1394 but amending /etc/network/interfaces cured the problem. > > > From dmesg: > > > > Yes, this is the module loader problem, where discover, hotplug and > > /etc/modules and the modules loaded by the initrd conflict. only hotplug > > usually loads the firewire before the network, and it is usually called > > after discover. Do you have discover installed ? If yes, which version ? > > And does it work ? > Ah! I don't have discover on my production system which is probably why > they loaded out of sequence. I don't use firewire, so presumably I > could remove this module? Well, you just need to blacklist it in /etc/hotplug/blacklist. Friendly, Sven Luther
