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

Re: newworld g3 trying to get to 2.6.x; problems w/ udev



I have a followup solution to this problem.

On Mon, Apr 24, 2006 at 12:30:59PM -0700, Seth Daniel wrote:
> Hello,
> 
> I have a Blue & White Newworld G3.  I use it as a firewall and it works
> very well.  Currently it is running the 2.4.27-powerpc kernel.  I am
> trying (and failing) to upgrade to 2.6.x (primarily 2.6.16-1-powerpc).  
> 
> Whenever I boot with a >= 2.6.8 kernel udev will hang at "Waiting for
> /dev to be fully populated" and nothing will happen after that point
> (I've waited up to 5 minutes for something to happen).  It doesn't
> appear to be a hard lock.  The keyboard is still responsive but nothing
> ever happens after the above message is printed.  The above message is
> located in /etc/init.d/udev so it would appear to be a udev related
> problem.
> 
> I am wondering a) how/if I can get 2.6.16 working on this machine and b)
> if this problem has anything to do with how the initrd image is being
> built?  The preinst script for 2.6.16-1-powerpc won't let yaird run if
> the preinst script is being run on a kernel < 2.6.8 so I installed
> initramfs-tools and the preinst script doesn't seem to mind that.  I
> mention this because I have seen a number of threads on this list that
> talk about problems with initrd images, particularly when the process
> creating the image is on a 2.4 machine and is trying to create an image
> for a 2.6 kernel.  None of those problems appear to be my problem.


It isn't a symptom of how the initrd image is built at all.  It has
nothing to do with initrd.  Apparently the new kernel (I assume it's the
kernel) maps my hard drives to different /dev names than the 2.4 kernel
did.  2.4 => /dev/hda[1234]   2.6 => /dev/hdc[1234]  (also: the cdrom
drive is now /dev/hda when it used to be /dev/hde.)  This was causing
udev to wait for the root filesystem to be populated, but since the root
device was wrong it would simply wait forever.  This drive mapping may
be an artifact of udev, perhaps?  Or is it the kernel?

I know I saw a thread about this drive mapping issue on this list but I
have been unable to find it over the last hour or so.  

Is this remapping normal and expected?  Is there some way to get the old
mapping back?  Do I really care or need the old mapping to come back?
(my gut reaction is 'no, I don't' since it all seems to work now.)

-- 
seth / @sethdaniel.org
One has to look out for engineers -- they begin with sewing machines
and end up with the atomic bomb.



Reply to: