1:01 p.m.
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
1:38 p.m.
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
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
2:06 p.m.
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
2:21 p.m.
Reik Red wrote:
Mikkel L. Ellertson wrote:
>>
> 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?
Nope - Grub uses the BIOS drive number. The kernel uses what is
passed to it as the root file system, but when using labels, and
finding duplicate labels, it normally uses the last one found.
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.
Is your F8 system 32 or 64 bit? Is it using labels or LVM? (The
default install uses LVM.)
What should I look for? Labels, grub.conf or /etc/fstab?
Reik
"parted -l" will show the labels. If the 64 bit disk and the 32 bit
disk are using the same labels, then usually the last label found
will be used. (Partitions from the second drive.) You can also look
at /etc/fstab to see if labels are being used.
Mikkel
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
2:27 p.m.
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
2:43 p.m.
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
3:33 p.m.
Reik Red wrote:
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
Yes, the installer will pick different labels if the default ones
are in use. It would be better is the labels from the boot drive had
preference when duplicates are found. I suspect the current behavior
is because the programmer did not expect to find duplicate labels,
and the ones found later overwrite the earlier ones. But this is
only a guess on my part.
One way out of this would be to re-label the partitions, and then
edit grub.conf and fstab to match. I like descriptive labels.
Something like /-F732, /-F764, boot-F732, boot-F764. Just remember
that when you are dealing with labels, that /boot is not the same as
boot. So if you use a label of boot-F732 then you need to use
LABEL=boot-F732. I only have 32 bit installs, so I use labels like
/-F7 and boot-F7. You may find something like boot-F7-32 works
better for you. You are limited to 16 character labels.
Mikkel
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
5:08 p.m.
Mikkel L. Ellertson wrote:
Reik Red wrote:
>
> 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
>
Yes, the installer will pick different labels if the default ones are in
use. It would be better is the labels from the boot drive had preference
when duplicates are found. I suspect the current behavior is because the
programmer did not expect to find duplicate labels, and the ones found
later overwrite the earlier ones. But this is only a guess on my part.
One way out of this would be to re-label the partitions, and then edit
grub.conf and fstab to match. I like descriptive labels. Something like
/-F732, /-F764, boot-F732, boot-F764. Just remember that when you are
dealing with labels, that /boot is not the same as boot. So if you use a
label of boot-F732 then you need to use LABEL=boot-F732. I only have 32
bit installs, so I use labels like /-F7 and boot-F7. You may find
something like boot-F7-32 works better for you. You are limited to 16
character labels.
Mikkel
Mikkel,
I hacked the labels by attaching sdc post-boot with a usb2ide gizmo,
so now I have a workaround.
Do you have any suggestions on where to shop the idea of
"prefer same drive first match" for the label search?
Reik
5:33 p.m.
Reik Red wrote:
Mikkel,
I hacked the labels by attaching sdc post-boot with a usb2ide gizmo,
so now I have a workaround.
Do you have any suggestions on where to shop the idea of
"prefer same drive first match" for the label search?
Reik
I wish I did. I would think it would be built into the kernel, but
it might be built into the mount command, or one of the libraries it
uses. You can try doing a Google search on "partition labels" and
see if that produces anything that helps.
One problem I can see if you change the current behavior is you may
run into problems when booting the OS on the second disk. I can also
see problems where the system is spread between disks. Something on
the order of /boot on the first drive, and the rest of the file
system on another drive. This is especially true if the root file
system is on a drive the BIOS does not see. If you 2 or 3
partitions, on different drives, all labeled /, what one do you
pick? (I even saw one case where the user had more then one
installation on the same drive, and tried to convert them all to use
labels, but tried to use the same labels for each distribution.)
The way I have fixed it in the past, the few times I have run into
it, has been to boot a live CD, and fix the labels. You can also
change labels on a running system, before you try booting with both
drives. You also have the option of editing /etc/fstab and
/boot/grub/grub.conf on the current system to use device names
instead of labels if you don't what to mess with label names. But
this can cause problems if you move the drive.
Mikkel
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
5942
days inactive
5942
days old
8 comments
2 participants
participants (2)
-
Mikkel -
reikred＠gmail.com