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?
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 ...
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?
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.
(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 ?
(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)
(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
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.
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.
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
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.
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
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.
(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
(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.
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)