Mike Christie [micha...@cs.wisc.edu] wrote:
> If the ibft implementation uses one session, but exports all the targets 
> in the ibft info, then in RHEL 5.3 the installer only picks up the 
> session used for the ibft boot up, but the initrd root-boot code used 
> after the install should log into all the targets in ibft whether they 
> were used for the ibft boot or not. There different behavior is a result 
> of the installer goofing up where is used the wrong api.

It is quite likely that my iBFT implementation uses&exports a single
session.

> This should work, but there are some other issues. For the boot that 
> panics what was the problem? Did the session get logged in or was it a 
> panic in the iscsi code?

The panic is due to not finding any bootable device. Actually the newly
created initrd didn't have any iSCSI code at all! One time, there was
some iSCSI code in the "initrd" image , but the session login failed.
Maybe real network failure that one time as I can't reproduce the latter
problem now.

> There was a bug where mkinitrd would use the current sessoins values 
> then stick them in the initrd and use them. In 5.3, if you were using 
> ibft then the initrd code should use the ibft values. Check out 
> /sbin/mkinitrd:emit_iscsi_device. It should call iscsi_is_ibft and 
> figure out that ibft is used. It is still sort of broken. If you changed 
> the ibft value then ran mkinitrd we would not figure out ibft is being 
> used because it checks this by matching the ibft values with the current 
> sessions.

Yes, the mkinitrd code looks at ibft values and the current session(s).
If the session matches ibft values, it uses ibft. If not, it uses the
session values directly.

But the problem in my case is that as soon as I run "iscsiadm -m node
-l" to login to the second session, it creates a new path /dev/sdb as
expected.  The udev, I believe, also creating a "/dev/disk/by-id/..."
special file for it. LVM displays that "by-id" path as its PV instead of
the regular /dev/sdb2 (or /dev/sda2). mkinitrd passes that "by-id"
symlink to findstoragedriver() in handlelvordev

findstoragedriver() can't handle symlinks and ends up not putting
anything in the "initrd".

I hacked "/sbin/mkinitrd" to fix the above stuff as well as added the
second path. I also modified it to include multipath related changes.
Now I am able to boot RHEL5.3 on a multipath iSCSI device!

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to