Re: Installation package - PowerPC sarge d-i tcl1 and upgrade to 2.6.7 smp kernel
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:
> > > 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.