[Bug 209110] iSCSI root device name should be dynamic

bugzilla at redhat.com bugzilla at redhat.com
Mon Oct 27 14:23:30 UTC 2008


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=209110


Hans de Goede <hdegoede at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hdegoede at redhat.com




--- Comment #12 from Hans de Goede <hdegoede at redhat.com>  2008-10-27 10:23:27 EDT ---
Hi Mark,

I'm a new anaconda developer currently working on iscsi support in Fedora and
as such looking at open iscsi related bugs.

What you are seeing here are 2 different problems:

1) The device name of iscsi disks is not stable

This is not something which we are going to fix, with things like usb disks,
motherboard with a zillion sata connectors, etc. device names will not be
stable. This is the new dynamic hotplug / udev Linux world.

Solution: use a label or uuid for /

2) mkinitrd resolves a label / uuid to a device name and puts this in the
initrd, given 1) we really should stop doing this. I think we've not stopped
doing this thus far, because the rootdev option to mkrootdev (in the ramdisk
init script) gets ignored when a root= parameter gets passed to the kernel, and
by default (when using grub) we always pass a root= parameter, so the rootdev
parameter in the initscript doesn't matter much in the default case.

I believe thus that this bug should be renamed:
"mkrootdev gets passed /dev/foo as rootdev while root should be found by LABEL
or UUID"

Peter do you agree?

In the mean time you should be able to fix the issue reported here by passing
root=LABEL=somelabel to the kernel when booting.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.




More information about the fedora-triage-list mailing list