Return of NoLoader
 

Courtesans and gentlefops! May I direct your attention to:

https://fedoraproject.org/wiki/Anaconda/Features/NoLoader

In particular, please note the Scope section, which might also be titled
the Big Damn List Of Stuff To Do.

The short summary is: Yes, we're really trying to remove loader this
time, for real. And it's gonna take some work. So I'm looking for advice
and assistance in the following areas:

== Boot Option Priorities ==

Some of these things (ks=, lang=, ip=) are obviously important; some of
them are obviously less important (nousb, noprobe), and some of them I'm
just not sure if anyone uses them (gdb=, syslog=, wepkey=).

If you (or someone you know) depends on any of these things, please give
us some information on how and why you use them, so we can make sure
things work as expected - and get your help with testing!

== Porting to Dracut ==

Some of these things will probably end up in upstream dracut (e.g.
network stuff can go in the 40network module), but a lot of things will
end up in our own special dracut module (80anaconda).

I'll need some assistance getting all that done for F17, so if you've
got some bash skill and want to help with dracut development, this is a
perfect place to help make a difference in the quality and stability of
the next release! Let me know if you can help, so I have some idea how
many people may be involved (and set goals/deadlines appropriately).

== General Sanity Checking ==

Does this plan look sound to everyone? Can we all agree that dropping
the stage1 interactive stuff is sane (remember, we'll still have a
text-mode installer in the anaconda runtime - just no more dialogs in
initrd.img)? Is there anything missing, any improvements you could
suggest?


Once we've got a finished plan of attack, I might take this to
devel-list just to be sure they're all aware (and see if we can solicit
further info/assistance).

Thanks,

-w

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

Return of NoLoader
 

On 11/17/2011 01:33 PM, Will Woods wrote:

Courtesans and gentlefops! May I direct your attention to:

https://fedoraproject.org/wiki/Anaconda/Features/NoLoader

In particular, please note the Scope section, which might also be titled
the Big Damn List Of Stuff To Do.

The short summary is: Yes, we're really trying to remove loader this
time, for real. And it's gonna take some work. So I'm looking for advice
and assistance in the following areas:

== Boot Option Priorities ==

Some of these things (ks=, lang=, ip=) are obviously important; some of
them are obviously less important (nousb, noprobe), and some of them I'm
just not sure if anyone uses them (gdb=, syslog=, wepkey=).

If you (or someone you know) depends on any of these things, please give
us some information on how and why you use them, so we can make sure
things work as expected - and get your help with testing!

== Porting to Dracut ==

Some of these things will probably end up in upstream dracut (e.g.
network stuff can go in the 40network module), but a lot of things will
end up in our own special dracut module (80anaconda).

I'll need some assistance getting all that done for F17, so if you've
got some bash skill and want to help with dracut development, this is a
perfect place to help make a difference in the quality and stability of
the next release! Let me know if you can help, so I have some idea how
many people may be involved (and set goals/deadlines appropriately).

== General Sanity Checking ==

Does this plan look sound to everyone? Can we all agree that dropping
the stage1 interactive stuff is sane (remember, we'll still have a
text-mode installer in the anaconda runtime - just no more dialogs in
initrd.img)? Is there anything missing, any improvements you could
suggest?


Once we've got a finished plan of attack, I might take this to
devel-list just to be sure they're all aware (and see if we can solicit
further info/assistance).


Some things that we need to come up with a solution for (where
"solution" means either keeping something on our own still called
/sbin/loader, or a dracut module, or something else that is run inside
the initramfs):


1) Driver update disks require an interactive element at boot time.
Doing that once anaconda is not really possible since we may need that
driver to get anaconda. A dracut module is fine, but we do need to keep
some level of interactive element. NOTE: It does not have to be an
ncurses interface, but something interactive so that users do not have
to pass long boot options (well, we will probably want that, but we
should also have an interactive path).


2) Install method... if we can't find an install source and the user
didn't tell us what to use, we prompt in loader. Are we planning to do
that via the 80anaconda dracut module? I would say this is important as
well.


3) Some sort of minimal interactive network configuration may be
required, again so users are not solely restricted to passing boot
parameters to dracut. Not sure if this is planned or not.


Really, the important one to me is the driver update disk support and
retaining that functionality. It's complex enough that we may even want
a separate dracut module just for the driver update disk support
(79dud?). msivak?


--
David Cantrell <dcantrell@redhat.com>
Supervisor, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT

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

Return of NoLoader
 

On Thu, 2011-11-17 at 16:53 -0500, David Cantrell wrote:
>
> 1) Driver update disks require an interactive element at boot time.
> Doing that once anaconda is not really possible since we may need that
> driver to get anaconda. A dracut module is fine, but we do need to keep
> some level of interactive element. NOTE: It does not have to be an
> ncurses interface, but something interactive so that users do not have
> to pass long boot options (well, we will probably want that, but we
> should also have an interactive path).

Why do they require an interactive element? What input is needed? Device
name? Filename?

Why wouldn't boot args plus default device/filename suffice? e.g.:

If you pass 'dd', we'd look for a file named "drivers.img" on a device
labeled "RHUPDATES".
If you actually need to use different label/filename you could do:
'dd=<device>:<path>'.

> 2) Install method... if we can't find an install source and the user
> didn't tell us what to use, we prompt in loader. Are we planning to do
> that via the 80anaconda dracut module? I would say this is important as
> well.

Possibly? This prompt would only come up if you don't boot from media -
i.e. only on netboot.

If you've already set up the netboot server.. couldn't we just use a
sensible default, again? Like, if nothing is passed for 'repo=' or
'root=', try a few URLs:

http://<server-ip>/<client-ip>/install.img
http://<server-ip>/<product>/<arch>/<version>/os/images/install.img
Maybe even:
http://download.fedoraproject.org/pub/fedora/linux/releases/<version>/Fedora/<arch>/os/images/install.img

It's kind of like PXE - if there's no files for the system to PXE boot,
you don't get a PXE prompt saying "hey what files do you want to load?".
It's already a pretty specialized environment - just set up the server
properly and it'll work fine.

Or, if you want to make things simpler, you can just cram install.img
into the initrd.img. Then you don't need to set up the network etc. to
find it.

> 3) Some sort of minimal interactive network configuration may be
> required, again so users are not solely restricted to passing boot
> parameters to dracut. Not sure if this is planned or not.

Sure, but again, this is only needed if you're doing netboot. All the
simple cases already work (ip={dhcp,dhcp6,auto6}). Most netboot setups
seem to automatically set up the boot commandline anyway.

Is it easier/necessary to have us maintain a super-limited pre-stage2
interactive UI than to have better docs on setting up netboot
environments?

> Really, the important one to me is the driver update disk support and
> retaining that functionality. It's complex enough that we may even want
> a separate dracut module just for the driver update disk support
> (79dud?). msivak?

I can definitely understand that this is Required for some Business Use
Cases, but I don't fully understand the actual requirements. So yeah,
where can we get more info about who uses this, and how, and why, and
what they need?

-w

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

Return of NoLoader
 

>> 1) Driver update disks require an interactive element at boot time.
[snip]

> Why do they require an interactive element? What input is needed? Device
> name? Filename?

For me, the interactive element is for diagnosis and recovery from errors.

First, I want really good error messages: ones that are good enough
to help you _fix_ the problem. For example, not just "No such file or directory"
but "Looking for foobar configuration file; cannot open /path/to/the/missing/file
because directory /path/to/the/missing does not exist."

Then, I want the "last input" loaded into the line editor, with the cursor
positioned appropriately, and so that activating the line re-starts the
part that failed ("Looking for foobar configuration file" with new pathname),
except that <ESC> backs up one step farther, etc.

The convenience of retrying the failing action (or backing up step by step)
without having to start over from the very beginning, and receiving help
such as pre-loading the line editor, is worth a lot for Usability.
Being unable to proceed (except by re-booting) is a symptom of failure
in the UI.

--

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

Return of NoLoader
 

I have three pieces which have to work:

> them are obviously less important (nousb, noprobe)
Look at rhbz#690058, noprobe is very important for a big partner there

And it is related to what David said:
- Driverdiscs have to be supported.
- Networking has to be supported (for install source and for getting the driverdisc).
- Some interactivity has to stay there also for these features to work and be usable..

Syslog arguments are useful for debugging, we use it to start remote logging from anaconda. Also Gdb was used couple of times here in Brno, remote debugging is a nice feature to have (less important if there is no C code in anaconda..).

Martin

----- Original Message -----
> On 11/17/2011 01:33 PM, Will Woods wrote:
> > Courtesans and gentlefops! May I direct your attention to:
> >
> > https://fedoraproject.org/wiki/Anaconda/Features/NoLoader
> >
> > In particular, please note the Scope section, which might also be
> > titled
> > the Big Damn List Of Stuff To Do.
> >
> > The short summary is: Yes, we're really trying to remove loader
> > this
> > time, for real. And it's gonna take some work. So I'm looking for
> > advice
> > and assistance in the following areas:
> >
> > == Boot Option Priorities ==
> >
> > Some of these things (ks=, lang=, ip=) are obviously important;
> > some of
> > them are obviously less important (nousb, noprobe), and some of
> > them I'm
> > just not sure if anyone uses them (gdb=, syslog=, wepkey=).
> >
> > If you (or someone you know) depends on any of these things, please
> > give
> > us some information on how and why you use them, so we can make
> > sure
> > things work as expected - and get your help with testing!
> >
> > == Porting to Dracut ==
> >
> > Some of these things will probably end up in upstream dracut (e.g.
> > network stuff can go in the 40network module), but a lot of things
> > will
> > end up in our own special dracut module (80anaconda).
> >
> > I'll need some assistance getting all that done for F17, so if
> > you've
> > got some bash skill and want to help with dracut development, this
> > is a
> > perfect place to help make a difference in the quality and
> > stability of
> > the next release! Let me know if you can help, so I have some idea
> > how
> > many people may be involved (and set goals/deadlines
> > appropriately).
> >
> > == General Sanity Checking ==
> >
> > Does this plan look sound to everyone? Can we all agree that
> > dropping
> > the stage1 interactive stuff is sane (remember, we'll still have a
> > text-mode installer in the anaconda runtime - just no more dialogs
> > in
> > initrd.img)? Is there anything missing, any improvements you could
> > suggest?
> >
> >
> > Once we've got a finished plan of attack, I might take this to
> > devel-list just to be sure they're all aware (and see if we can
> > solicit
> > further info/assistance).
>
> Some things that we need to come up with a solution for (where
> "solution" means either keeping something on our own still called
> /sbin/loader, or a dracut module, or something else that is run
> inside
> the initramfs):
>
> 1) Driver update disks require an interactive element at boot time.
> Doing that once anaconda is not really possible since we may need
> that
> driver to get anaconda. A dracut module is fine, but we do need to
> keep
> some level of interactive element. NOTE: It does not have to be an
> ncurses interface, but something interactive so that users do not
> have
> to pass long boot options (well, we will probably want that, but we
> should also have an interactive path).
>
> 2) Install method... if we can't find an install source and the user
> didn't tell us what to use, we prompt in loader. Are we planning to
> do
> that via the 80anaconda dracut module? I would say this is important
> as
> well.
>
> 3) Some sort of minimal interactive network configuration may be
> required, again so users are not solely restricted to passing boot
> parameters to dracut. Not sure if this is planned or not.
>
> Really, the important one to me is the driver update disk support and
> retaining that functionality. It's complex enough that we may even
> want
> a separate dracut module just for the driver update disk support
> (79dud?). msivak?
>
> --
> David Cantrell <dcantrell@redhat.com>
> Supervisor, Installer Engineering Team
> Red Hat, Inc. | Westford, MA | EST5EDT
>
> _______________________________________________
> 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

Return of NoLoader
 

On 11/22/2011 06:49 AM, Martin Sivak wrote:

I have three pieces which have to work:


them are obviously less important (nousb, noprobe)

Look at rhbz#690058, noprobe is very important for a big partner there

And it is related to what David said:
- Driverdiscs have to be supported.
- Networking has to be supported (for install source and for getting the driverdisc).
- Some interactivity has to stay there also for these features to work and be usable..


What is the reason we need these elements interactive in loader? The
only thing I can remember is that some vendors ship internal USB flash
drives with drivers embedded, and users may or may not want to install
those drivers at install time. So looking for and automatically loading
all found drivers on driver disks is not ideal in that case.


msivak, can you expand on why we need these elements interactive?


Syslog arguments are useful for debugging, we use it to start remote logging from anaconda. Also Gdb was used couple of times here in Brno, remote debugging is a nice feature to have (less important if there is no C code in anaconda..).

Martin

----- Original Message -----

On 11/17/2011 01:33 PM, Will Woods wrote:

Courtesans and gentlefops! May I direct your attention to:

https://fedoraproject.org/wiki/Anaconda/Features/NoLoader

In particular, please note the Scope section, which might also be
titled
the Big Damn List Of Stuff To Do.

The short summary is: Yes, we're really trying to remove loader
this
time, for real. And it's gonna take some work. So I'm looking for
advice
and assistance in the following areas:

== Boot Option Priorities ==

Some of these things (ks=, lang=, ip=) are obviously important;
some of
them are obviously less important (nousb, noprobe), and some of
them I'm
just not sure if anyone uses them (gdb=, syslog=, wepkey=).

If you (or someone you know) depends on any of these things, please
give
us some information on how and why you use them, so we can make
sure
things work as expected - and get your help with testing!

== Porting to Dracut ==

Some of these things will probably end up in upstream dracut (e.g.
network stuff can go in the 40network module), but a lot of things
will
end up in our own special dracut module (80anaconda).

I'll need some assistance getting all that done for F17, so if
you've
got some bash skill and want to help with dracut development, this
is a
perfect place to help make a difference in the quality and
stability of
the next release! Let me know if you can help, so I have some idea
how
many people may be involved (and set goals/deadlines
appropriately).

== General Sanity Checking ==

Does this plan look sound to everyone? Can we all agree that
dropping
the stage1 interactive stuff is sane (remember, we'll still have a
text-mode installer in the anaconda runtime - just no more dialogs
in
initrd.img)? Is there anything missing, any improvements you could
suggest?


Once we've got a finished plan of attack, I might take this to
devel-list just to be sure they're all aware (and see if we can
solicit
further info/assistance).


Some things that we need to come up with a solution for (where
"solution" means either keeping something on our own still called
/sbin/loader, or a dracut module, or something else that is run
inside
the initramfs):

1) Driver update disks require an interactive element at boot time.
Doing that once anaconda is not really possible since we may need
that
driver to get anaconda. A dracut module is fine, but we do need to
keep
some level of interactive element. NOTE: It does not have to be an
ncurses interface, but something interactive so that users do not
have
to pass long boot options (well, we will probably want that, but we
should also have an interactive path).

2) Install method... if we can't find an install source and the user
didn't tell us what to use, we prompt in loader. Are we planning to
do
that via the 80anaconda dracut module? I would say this is important
as
well.

3) Some sort of minimal interactive network configuration may be
required, again so users are not solely restricted to passing boot
parameters to dracut. Not sure if this is planned or not.

Really, the important one to me is the driver update disk support and
retaining that functionality. It's complex enough that we may even
want
a separate dracut module just for the driver update disk support
(79dud?). msivak?

--
David Cantrell<dcantrell@redhat.com>
Supervisor, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT

_______________________________________________
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




--
David Cantrell <dcantrell@redhat.com>
Supervisor, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT

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

Return of NoLoader
 

> Does this plan look sound to everyone? Can we all agree that dropping
> the stage1 interactive stuff is sane (remember, we'll still have a
> text-mode installer in the anaconda runtime - just no more dialogs in
> initrd.img)? Is there anything missing, any improvements you could
> suggest?

Yes, getting rid of everything interactive and therefore eliminating
loader does sound sane. It's a noble goal and one that I have hoped to
be able to do for a very long time now.

I'll comment on specifics elsewhere.

- Chris

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

Return of NoLoader
 

Hi,

> msivak, can you expand on why we need these elements interactive?

Well,

- automatically detected driver discs have to be confirmed before loading (#570053)
- we support network method for getting driver discs, so we might need something to let the user set the network up
- right now we allow the user to manually select driver update disc or it's image to load. Sources include USB, hard drives, ...

That requires some kind of interactivity.

Martin


----- Original Message -----
> On 11/22/2011 06:49 AM, Martin Sivak wrote:
> > I have three pieces which have to work:
> >
> >> them are obviously less important (nousb, noprobe)
> > Look at rhbz#690058, noprobe is very important for a big partner
> > there
> >
> > And it is related to what David said:
> > - Driverdiscs have to be supported.
> > - Networking has to be supported (for install source and for
> > getting the driverdisc).
> > - Some interactivity has to stay there also for these features to
> > work and be usable..
>
> What is the reason we need these elements interactive in loader? The
> only thing I can remember is that some vendors ship internal USB
> flash
> drives with drivers embedded, and users may or may not want to
> install
> those drivers at install time. So looking for and automatically
> loading
> all found drivers on driver disks is not ideal in that case.
>
> msivak, can you expand on why we need these elements interactive?
>
> > Syslog arguments are useful for debugging, we use it to start
> > remote logging from anaconda. Also Gdb was used couple of times
> > here in Brno, remote debugging is a nice feature to have (less
> > important if there is no C code in anaconda..).
> >
> > Martin
> >
> > ----- Original Message -----
> >> On 11/17/2011 01:33 PM, Will Woods wrote:
> >>> Courtesans and gentlefops! May I direct your attention to:
> >>>
> >>> https://fedoraproject.org/wiki/Anaconda/Features/NoLoader
> >>>
> >>> In particular, please note the Scope section, which might also be
> >>> titled
> >>> the Big Damn List Of Stuff To Do.
> >>>
> >>> The short summary is: Yes, we're really trying to remove loader
> >>> this
> >>> time, for real. And it's gonna take some work. So I'm looking for
> >>> advice
> >>> and assistance in the following areas:
> >>>
> >>> == Boot Option Priorities ==
> >>>
> >>> Some of these things (ks=, lang=, ip=) are obviously important;
> >>> some of
> >>> them are obviously less important (nousb, noprobe), and some of
> >>> them I'm
> >>> just not sure if anyone uses them (gdb=, syslog=, wepkey=).
> >>>
> >>> If you (or someone you know) depends on any of these things,
> >>> please
> >>> give
> >>> us some information on how and why you use them, so we can make
> >>> sure
> >>> things work as expected - and get your help with testing!
> >>>
> >>> == Porting to Dracut ==
> >>>
> >>> Some of these things will probably end up in upstream dracut
> >>> (e.g.
> >>> network stuff can go in the 40network module), but a lot of
> >>> things
> >>> will
> >>> end up in our own special dracut module (80anaconda).
> >>>
> >>> I'll need some assistance getting all that done for F17, so if
> >>> you've
> >>> got some bash skill and want to help with dracut development,
> >>> this
> >>> is a
> >>> perfect place to help make a difference in the quality and
> >>> stability of
> >>> the next release! Let me know if you can help, so I have some
> >>> idea
> >>> how
> >>> many people may be involved (and set goals/deadlines
> >>> appropriately).
> >>>
> >>> == General Sanity Checking ==
> >>>
> >>> Does this plan look sound to everyone? Can we all agree that
> >>> dropping
> >>> the stage1 interactive stuff is sane (remember, we'll still have
> >>> a
> >>> text-mode installer in the anaconda runtime - just no more
> >>> dialogs
> >>> in
> >>> initrd.img)? Is there anything missing, any improvements you
> >>> could
> >>> suggest?
> >>>
> >>>
> >>> Once we've got a finished plan of attack, I might take this to
> >>> devel-list just to be sure they're all aware (and see if we can
> >>> solicit
> >>> further info/assistance).
> >>
> >> Some things that we need to come up with a solution for (where
> >> "solution" means either keeping something on our own still called
> >> /sbin/loader, or a dracut module, or something else that is run
> >> inside
> >> the initramfs):
> >>
> >> 1) Driver update disks require an interactive element at boot
> >> time.
> >> Doing that once anaconda is not really possible since we may need
> >> that
> >> driver to get anaconda. A dracut module is fine, but we do need
> >> to
> >> keep
> >> some level of interactive element. NOTE: It does not have to be
> >> an
> >> ncurses interface, but something interactive so that users do not
> >> have
> >> to pass long boot options (well, we will probably want that, but
> >> we
> >> should also have an interactive path).
> >>
> >> 2) Install method... if we can't find an install source and the
> >> user
> >> didn't tell us what to use, we prompt in loader. Are we planning
> >> to
> >> do
> >> that via the 80anaconda dracut module? I would say this is
> >> important
> >> as
> >> well.
> >>
> >> 3) Some sort of minimal interactive network configuration may be
> >> required, again so users are not solely restricted to passing boot
> >> parameters to dracut. Not sure if this is planned or not.
> >>
> >> Really, the important one to me is the driver update disk support
> >> and
> >> retaining that functionality. It's complex enough that we may
> >> even
> >> want
> >> a separate dracut module just for the driver update disk support
> >> (79dud?). msivak?
> >>
> >> --
> >> David Cantrell<dcantrell@redhat.com>
> >> Supervisor, Installer Engineering Team
> >> Red Hat, Inc. | Westford, MA | EST5EDT
> >>
> >> _______________________________________________
> >> 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
>
>
>
> --
> David Cantrell <dcantrell@redhat.com>
> Supervisor, Installer Engineering Team
> Red Hat, Inc. | Westford, MA | EST5EDT
>
> _______________________________________________
> 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

Return of NoLoader
 

> 1) Driver update disks require an interactive element at boot time.
> Doing that once anaconda is not really possible since we may need
> that driver to get anaconda. A dracut module is fine, but we do
> need to keep some level of interactive element. NOTE: It does not
> have to be an ncurses interface, but something interactive so that
> users do not have to pass long boot options (well, we will probably
> want that, but we should also have an interactive path).

Driver disks may require an interactive element, but can't that just be
another screen in anaconda proper? We're already going to have network
bring up UI there (as well as cmdline handling in dracut), as well as
language and keyboard. It seems to me that we could just toss in
another screen at an appropriate place in the UI. Note - likely not an
F17 thing.

> 2) Install method... if we can't find an install source and the user
> didn't tell us what to use, we prompt in loader. Are we planning to
> do that via the 80anaconda dracut module? I would say this is
> important as well.

Right now, if we can't find an install source and the user didn't tell
us anything, we hit the Fedora mirror list and use the first out of
there. askmethod-like functionality is probably required, but should be
done in the UI as well.

- Chris

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

Return of NoLoader
 

Hi,

> Driver disks may require an interactive element, but can't that just
> be
> another screen in anaconda proper? We're already going to have
> network
> bring up UI there (as well as cmdline handling in dracut), as well as
> language and keyboard. It seems to me that we could just toss in
> another screen at an appropriate place in the UI. Note - likely not
> an
> F17 thing.

This has to be done before we initialize network and all of storage. So with install/network sources being handled by dracut, DDs have to go into dracut too..

Martin

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