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
