request_module: runaway loop modprobe binfmt-464c

Mikkel L. Ellertson mikkel at infinity-ltd.com
Mon Jan 28 21:33:07 UTC 2008


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!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080128/4cfd05c7/attachment-0001.sig>


More information about the fedora-list mailing list