Bug 209110 - iSCSI root device name should be dynamic
iSCSI root device name should be dynamic
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-03 07:00 EDT by Mark McLoughlin
Modified: 2009-02-03 08:09 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-03 08:09:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark McLoughlin 2006-10-03 07:00:22 EDT
The problem I'm seeing is that if I create an initrd for iSCSI root as follows:

  http://fedoraproject.org/wiki/StatelessLinuxiSCSIRoot

Then it works fine so long as the iscsi device name on the machine where you
create the initrd is that same as the iscsi device name on the machine using the
initrd.

In my case, I create the initrd on a machine which already has a SCSI disk so
the iSCSI device is /dev/sdb. If I then try to boot with iSCSI root in a Xen
guest, it fails trying to find /dev/sdb ... the iSCSI device is on /dev/sda


Ideally, the initrd would set up the iSCSI device, figure out the device name
for it and then mount that


Playing around with the iSCSI stuff, the best I can come up with is that we'd
add a mkiscsiroot to nash. This would work as follows:

  - iterate over the subdirs in /sys/class/iscsi_session

  - find the dir which has a targetname which matches the target for which
    the initrd was created

  - From that dir find the device name from device/targetfoo/bar/block:blaa

  - Then create /dev/iscsiroot using the major:minor from /dev/blaa

mkrootdev would then use /dev/iscsiroot


That's a bit ... ugggh, though. Mike, is there any better way to figure out the
device name for the session corresponding to a given target name?
Comment 1 Mark McLoughlin 2006-10-03 07:07:03 EDT
Other ideas:

  - somehow tell iscsistart what you want the device name to be
  - watch for uevents while iscsistart is running ... and somehow figure out 
    which device is the one you want ...
Comment 2 Mike Christie 2006-10-03 14:26:13 EDT
Does udev work in our initramfs?

SUSE and upstream we have iscsi udev rule that has the iscsi target and port and
devices values in the by-path dir. SUSE/upstream's rule is actually broken for
many type of targets, but on the list we figured out how to solve it. We had
just been waiting for someone to send the udev guys a patch to fix it up.

But we do not even need a iscsi specific rule (iscsi people seem to like to name
their devices with the target info for some reason though), could we use
/dev/disk/by-uuid or by-id?
Comment 3 Jeremy Katz 2006-10-03 14:32:56 EDT
udev rules are insane to try to generically support in the initramfs -- kernel
name is the way to go

Mark -- why aren't you using the fs label or uuid to determine the root?  That
should work fine and be independent of what the device actually is named.
Comment 4 Mark McLoughlin 2006-10-05 07:24:04 EDT
(In reply to comment #2)
> Does udev work in our initramfs?

Our initrd doesn't use udev

If it did, though, it'd be nice if we could have a rule like:

  SYSFS{iscsi_target}=="myiscsitarget",SYMLINK+="iscsiroot"

rather than fork a script which would have to grub around in /sys for the target
name

i.e. would it make sense to have the iscsi targetname more closely associated
with the block device in /sys ?
Comment 5 Mark McLoughlin 2006-10-05 07:26:50 EDT
(In reply to comment #3)

> Mark -- why aren't you using the fs label or uuid to determine the root?  That
> should work fine and be independent of what the device actually is named.

Nice idea. I can't get it to work, though

if you pass e.g. --rootdev LABEL=foo, it resolves the label to the device name
and  uses the actual device name in the initrd rather than the label

Is that a bug or is it intended?

(At I have a workaround for this now - boot the client with root=/dev/sda on the
kernel command line)

Comment 6 Jeremy Katz 2006-10-05 10:43:16 EDT
(In reply to comment #5)
> (In reply to comment #3)
> 
> > Mark -- why aren't you using the fs label or uuid to determine the root?  That
> > should work fine and be independent of what the device actually is named.
> 
> Nice idea. I can't get it to work, though

Hrmm... it should.  That's definitely the intent (and it matches how a "real"
system works in that the fstab specifies LABEL= and we then use that to boot. 
The root= is intended to be an override and we were planning on dropping the
specification of it, just didn't get to it for FC6)

> if you pass e.g. --rootdev LABEL=foo, it resolves the label to the device name
> and  uses the actual device name in the initrd rather than the label
> 
> Is that a bug or is it intended?

Seems like a bug to me

> (At I have a workaround for this now - boot the client with root=/dev/sda on
the kernel command line)

root=LABEL= should also work, fwiw
Comment 7 Mark McLoughlin 2006-10-05 11:27:01 EDT
Okay, filed bug #209473

Probably should just close this as WONTFIX if we fix LABEL=foo - looking up the
device name from the target name and using that would be a lot of hassle.
Comment 8 Bug Zapper 2008-04-03 14:25:13 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 9 Bug Zapper 2008-05-06 20:55:17 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp
Comment 10 Mark McLoughlin 2008-05-07 04:05:23 EDT
Re-opening - I don't see that there's been any change here, the device name of
the iSCSI device is still hard-coded in the initrd by default and it would be
nice if we could automatically figure out the device name after we've set up the
iSCSI device.
Comment 11 Bug Zapper 2008-05-13 22:23:50 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Hans de Goede 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.
Comment 13 Mark McLoughlin 2008-10-28 03:56:42 EDT
(In reply to comment #12)

> What you are seeing here are 2 different problems:
> 
> 1) The device name of iscsi disks is not stable

Nope, that's not what I'm saying. My point is that the target name *is* stable and mkinitrd should be able to map the target name to a device name and map that device.

> Solution: use a label or uuid for /

Yep - that's one way of doing it, but "mount by target name" is a valid feature request too IMHO.

> 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 believe thus that this bug should be renamed:
> "mkrootdev gets passed /dev/foo as rootdev while root should be found by LABEL
> or UUID"

See bug #209473
Comment 14 Hans de Goede 2008-10-28 04:12:08 EDT
(In reply to comment #13)
> (In reply to comment #12)
> 
> > What you are seeing here are 2 different problems:
> > 
> > 1) The device name of iscsi disks is not stable
> 
> Nope, that's not what I'm saying. My point is that the target name *is* stable
> and mkinitrd should be able to map the target name to a device name and map
> that device.
> 
> > Solution: use a label or uuid for /
> 
> Yep - that's one way of doing it, but "mount by target name" is a valid feature
> request too IMHO.
> 

Agreed, but that indeed really is a *feature request*. To make this possible in some sane manner we need a way to ask iscsiadm which device node / number the iscsi subsystem has gotten / given to a certain target. Even better would be a feature where iscsiadm on login would print the device name to stdout once the login completes.

Actually having iscsiadm print the devicename it has gotten for a disk after login would be absolutely great to have for anaconda too. Currently we're going through much pain in anaconda to find a disk after we've logged in to the iscsi target, and even when we've got a disk we do not know which disks corresponds to which iscsi target.

I like the idea of iscsiadm login printing the device node for the disk after login so much I'll file an RFE against iscsi-initiator-utils right away.
Comment 15 Hans de Goede 2009-02-03 08:09:07 EST
Ok,

I've been working a lot on mkinitrd lately and getting to know it better. As such I can now say with certainty that allowing to specify root by targetname is not something which we are going to support.

For cases where the device number may change one can already specify root by UUID or LABEL, and that is the supported solution to handle these situations, as this works independend of the underlying storage technique.

We are not going to add various hacks to allow other ways of specifying the root device which are storage technique dependend.

Closing this as not a bug, since it is not a bug (but a denied RFE)

Note You need to log in before you can comment on or make changes to this bug.