Hi,

We need to do something to make iscsi driver which need to be brought up
manually available in rescue mode before we search for a / to rescue.

There are 2 options:

1) Add some text mode UI stuff to do this
2) Make rescue mode graphical, and make rescue mode
go through the filter UI.

I think in the long run we will want to do 2). But I guess that is too late
RHEL-6, so that we need to do 1) there.

Any input / comments is appreciated. I'll try to make some time
to work on 1) (if no-one yells no) in the next few days.

About 2). I think this is the logical and best thing to do in the
long run, given that we are already doing kms even in rescue mode,
we are already making rescue mode dependent on having working graphics,
so I don't see any big blockers here.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On 04/07/2010 11:27 AM, Hans de Goede wrote:
> Hi,
>
> We need to do something to make iscsi driver which need to be brought up
> manually available in rescue mode before we search for a / to rescue.
>
> There are 2 options:
>
> 1) Add some text mode UI stuff to do this
> 2) Make rescue mode graphical, and make rescue mode
> go through the filter UI.
>
> I think in the long run we will want to do 2). But I guess that is too late
> RHEL-6, so that we need to do 1) there.

I don't think that's necessarily true, especially considering how awful #1 is.

> Any input / comments is appreciated. I'll try to make some time
> to work on 1) (if no-one yells no) in the next few days.
>
> About 2). I think this is the logical and best thing to do in the
> long run, given that we are already doing kms even in rescue mode,
> we are already making rescue mode dependent on having working graphics,
> so I don't see any big blockers here.

Absolutely.

--
Peter

Sanity's just a one trick pony anyway. You only get one trick -- rational
thinking -- but when you're good and crazy, the sky's the limit!
-- The Tick

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Hi,

On 04/07/2010 07:27 PM, Peter Jones wrote:

On 04/07/2010 11:27 AM, Hans de Goede wrote:

Hi,

We need to do something to make iscsi driver which need to be brought up
manually available in rescue mode before we search for a / to rescue.

There are 2 options:

1) Add some text mode UI stuff to do this
2) Make rescue mode graphical, and make rescue mode
go through the filter UI.

I think in the long run we will want to do 2). But I guess that is too late
RHEL-6, so that we need to do 1) there.


I don't think that's necessarily true, especially considering how awful #1 is.



I hear you, but still I think 1 is much less invasive then 2, so 1 is the right
thing to do for now. We already have most of the needed code (from back when
we had partitioning support in text mode), and we will need 1) for RHEL-5 anyways.


Any input / comments is appreciated. I'll try to make some time
to work on 1) (if no-one yells no) in the next few days.

About 2). I think this is the logical and best thing to do in the
long run, given that we are already doing kms even in rescue mode,
we are already making rescue mode dependent on having working graphics,
so I don't see any big blockers here.


Absolutely.



I'm glad you agree

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On 04/07/2010 05:27 PM, Hans de Goede wrote:
> We need to do something to make iscsi driver which need to be brought up
> manually available in rescue mode before we search for a / to rescue.
>
> There are 2 options:
>
> 1) Add some text mode UI stuff to do this
> 2) Make rescue mode graphical, and make rescue mode
> go through the filter UI.
>
> I think in the long run we will want to do 2). But I guess that is too late
> RHEL-6, so that we need to do 1) there.
>
> Any input / comments is appreciated. I'll try to make some time
> to work on 1) (if no-one yells no) in the next few days.

Having an "Add zFCP" dialog in text mode would be nice.
Realistically, on s390, we have early DASD activation in linuxrc.s390
and this did work with the latest RHEL6 compose I had access to. We also
have FCP_*="..." boot options. However, they are currently only
activated late in storage/zfcp.py. If that could be triggered for rescue
mode as well, then we would have at least a workaround for all disk
types on s390 and that would be great.

> About 2). I think this is the logical and best thing to do in the
> long run, given that we are already doing kms even in rescue mode,
> we are already making rescue mode dependent on having working graphics,
> so I don't see any big blockers here.

2) won't work if you only have serial lines or even line-mode terminals.
With the last RHEL6 compose I had access to, rescue mode worked fine on
s390 since it does not yet seem to depend on a frame buffer or the like
and I think this dependency should never happen. Otherwise you would
also need to support early network configuration to provide VNC/X11.

Steffen

Linux on System z Development

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Hi,

iSCSI based root device should work with iBFT enabled machine, but the problem is when the machine has local/pxe based kernel and initrd. The initrd is then usually responsible for mounting the drive, but we have no access to the information within.

We have also problem with non-root iSCSI devices. I looked at it yesterday and there is no configuration in /etc/iscsi we could use to initialize storage for mounting drives mentioned in /etc/fstab. So even if we could execute iscsi daemon, there is no info about where to look for the drives... (except in initrd file on /boot drive, which could itself be iSCSI device)

So currently without iBFT we have no automated support for iSCSI in rescue.

Manually adding the devices doesn't seem as the right approach to me, because the admin can always do that by hand in the rescue shell. And unless we get some plugins for firstaidkit, nobody except admins can use rescue anyways...

We could go with allowing the user to manually add root filesystem whereabouts (if the detection fails) and then doing the same we do now (mounting /etc/fstab for example). But we would still have problems with no information about needed iscsi drives.

Martin

----- "Hans de Goede" <hdegoede@redhat.com> wrote:

> Hi,
>
> We need to do something to make iscsi driver which need to be brought
> up
> manually available in rescue mode before we search for a / to rescue.
>
> There are 2 options:
>
> 1) Add some text mode UI stuff to do this
> 2) Make rescue mode graphical, and make rescue mode
> go through the filter UI.
>
> I think in the long run we will want to do 2). But I guess that is too
> late
> RHEL-6, so that we need to do 1) there.
>
> Any input / comments is appreciated. I'll try to make some time
> to work on 1) (if no-one yells no) in the next few days.
>
> About 2). I think this is the logical and best thing to do in the
> long run, given that we are already doing kms even in rescue mode,
> we are already making rescue mode dependent on having working
> graphics,
> so I don't see any big blockers here.
>
> Regards,
>
> Hans
>
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Hi,

On 04/08/2010 12:28 PM, Martin Sivak wrote:

Hi,

iSCSI based root device should work with iBFT enabled machine, but the problem is when the machine has local/pxe based kernel and initrd. The initrd is then usually responsible for mounting the drive, but we have no access to the information within.

We have also problem with non-root iSCSI devices. I looked at it yesterday and there is no configuration in /etc/iscsi we could use to initialize storage for mounting drives mentioned in /etc/fstab. So even if we could execute iscsi daemon, there is no info about where to look for the drives... (except in initrd file on /boot drive, which could itself be iSCSI device)



iscsi info is stored in the iscsi db, which lives under /var/lib/iscsi. But that does not help, as we won't have /var in
the / on iscsi case either.


So currently without iBFT we have no automated support for iSCSI in rescue.



Yes, as we cannot supported automated iscsi support in rescue, just like we cannot do this in a regular install.


Manually adding the devices doesn't seem as the right approach to me, because the admin can always do that by hand in the rescue shell. And unless we get some plugins for firstaidkit, nobody except admins can use rescue anyways...



Manually adding them is the only option, admins are already used to needing to do this from the
regular install path. Duplicating the add advanced target UI in rescue mode is a lot more
userfriendly then asking them to type obscure iscsiadm (and zfcp and fcoe) commands, esp. as
they are already used to the UI.

More over if we don't activate the disks before scanning for /, the user will need to
mount / manually including mounting sub mounts (say /home), /proc, /proc/bus/usb /sys and *bind* mounting
/dev, sure this can be done but is anything but userfriendly.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list