Re: request_module: runaway loop modprobe binfmt-464c

Reik Red wrote:
>  Reik Red wrote:
> > Mikkel L. Ellertson wrote:
> >> Reik Red wrote:
> >>> Hello,
> >>>
> >>> The boot sequence of my fedora 7 (x86_32) machine hangs with multiple
> >>> messages that state
> >>>
> >>>  request_module: runaway loop modprobe binfmt-464c
> >>>  request_module: runaway loop modprobe binfmt-464c
> >>>  request_module: runaway loop modprobe binfmt-464c
> >>>
> >>> This happens ONLY when I have plugged in an extra IDE drive which 
> >>> contains
> >>> a copy of fedora 8 (x86_64).
> >>>
> >>> I have gleaned from various web searches that the problem may be that
> >>> f7 is confused about and/or trying to execute some 64bit code from the
> >>> additional hard disk?
> >>>
> >>> Does anyone know how to get around this problem (boot hanging, that 
> >>> is)?
> >>> There is lots of hits on the web but I have not been able to 
> >>> synthesize a
> >>> solution from what I find.
> >>>
> >>> Reik
> >>>
> >> Dumb question - are you using partition labels or LVM? If so, are the 
> >> labels the same on both drives?
> >>
> >> Mikkel
> >>
> >
> > That sounds like a very good question, Mikkel!
> > Short answer is, no LVM, but there may be some partition labels
> > involved,
> >
> > But wouldn't grub (or whoever decides these things) pick partitions
> > from the booted drive instead of some other drive, if they exist?
> >
> > On the other hand, if I insert the offending hard drive into my fedora 8
> > system as a third drive, the system boots without problem.
> >
> > What should I look for? Labels, grub.conf or /etc/fstab?
> >
> > Reik
> >
>  
>  More data:
>  
>  The fc7 machine has the following entries (among others) in /etc/fstab,
>  and /dev/sda has the proper corresponding e2label readings.
>  
>  LABEL=/                 /                       ext3    defaults        1 1
>  LABEL=/boot             /boot                   ext3    defaults        1 2
>  LABEL=/usr              /usr                    ext3    defaults        1 2
>  
>  Presumably /dev/sdc also has some LABEL=/ and so on (I'll check as soon 
>  as I
>  can reboot the f8 system I'm typing on and attach the offending IDE drive).
>  By the way, on the fedora 8 machine that I am currently typing on, I have
>  
>  LABEL=/1                /                       ext3    defaults        1 1
>  LABEL=/usr1             /usr                    ext3    defaults        1 2
>  LABEL=/boot1            /boot                   ext3    defaults        1 2
>  
>  so that would perhaps explain why /dev/sdc does not interfere with the boot
>  here, assuming e2label /dev/sdc1 is "/".
>  
>  But if there are indeed multiple partitions on multiple drives, with the 
>  same label name,
>  why would grub or the kernel pick as first choice a partition from a 
>  *different*
>  drive rather than the drive that the kernel is booting from? That seems 
>  weird to me.
>  
>  Is this a bug or a weakness that ought to be addressed?
>  
>  Reik
>   
Mikkel,

Sorry, our emails crossed. Would it make sense to use "prefer same drive first
match"
instead of "last match" as the default choice in the case of duplicate labels?

To answer your question from the intermediate email: Yes, f8=64bit, so it probably would
have
worked even if it mounted LABEL=/ from /dev/sdc, but as seen from the above, the LABEL=/1
already
saves the situation before it gets that far.

There is even an Anaconda tie-in here, because I recall that Anaconda chose the /usr1 (et
al)
labels because I had another drive attached while installing, and that drive used
LABEL=/usr
already. It gets complicated!

I think "prefer same drive first match" would be the most robust method,
but I'm as you can see far from an expert on this topic.

What is your opinion?

Thanks
Reik