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