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
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?
On Thu, 2011-11-17 at 16:53 -0500, David Cantrell wrote:
- 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>'.
- 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.
- 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
- 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.
On Fri, 2011-11-18 at 17:05 -0800, John Reiser wrote:
- 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.
I may have been unclear here - what I'm concerned about is whether we need *user-facing* interactive elements.
Diagnosing and debugging problems is a *developer* problem, generally. We can easily have a nice (English) error messages and bash/readline interactive UI for error recovery - with the default (us) keymap[1]. I have no problem with this stuff.
On the other hand, I feel we have a responsibility to properly translate and localize *user-facing* UI elements. Which requires us to have further UI to pick the language and keymap.
Most install cases (CD, DVD, Live USB, etc). will not require any user-facing UI in initramfs - they'll immediately load stage2 and be merrily on their way. PXE and other netboot scenarios should do the same, unless the server is misconfigured[2].
Basically: I understand that you, as a developer, want interactive debuggability. That's cool, I want that too.
But do we really expect normal users to have to deal with unrecoverable errors (e.g. misconfigured netboot servers) *so often* that we should write an entirely new language/keymap picker just for that? I'm not so sure.
-w
[1] This seems to be accepted practice for Linux development - the bootup messages, for instance, are all in English. No translations.
[2] Also note that configuring a PXE server can be done on a system that will have the proper local language/keymap, using translated documentation.
Hi Will,
I may have been unclear here - what I'm concerned about is whether we need *user-facing* interactive elements.
We support manual driver disc selection: You have a hard drive with dd.iso and right now can select disc, partition and file to load.
Or we need to be able to re-initialize after loading the driver > disk. I'm pretty sure that's easy to handle for network drivers.. not sure about storage, but I don't think it's impossible.
To be exact, we have to be able to unload all network and storage drivers and instruct udev to load them again.
Unloading just storage and network supposes we know which modules are network and storage.. that is why we currently save a list of modules loaded before loader and restores to that state (no guessing that way..).
- DD support needs to be in dracut if (and only if) there are
supported install cases where dracut must load a driver disk before it will be able to load install.img.
Network install and new unsupported scsi/cdrom/blade controllers are the main reasons. And PPCs still have the 32MB limit during PXE initrd download.
2) We need a driver disk before loading install.img if (and only
if) there are devices that can hold/fetch the DD, but not install.img.
Sure, DD on usb key is the only thing we can be almost sure works. Install.img on network or new unsupported hardware are common cases and the reason we update drivers that early.
This all are cases I have to solve. Unless we use single image dracut+install.img and the firmware is able to load it. Can we be sure this will always work (100% and no exceptions)? Because if not and we have to use two stages on some obscure machine, the feature would be useless there (too late..).
We are talking about hardware which is yet to be invented and I do not want to limit ourselves. I can simply do much more before install.img starts.
Martin
----- Original Message -----
On Fri, 2011-11-18 at 17:05 -0800, John Reiser wrote:
- 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.
I may have been unclear here - what I'm concerned about is whether we need *user-facing* interactive elements.
Diagnosing and debugging problems is a *developer* problem, generally. We can easily have a nice (English) error messages and bash/readline interactive UI for error recovery - with the default (us) keymap[1]. I have no problem with this stuff.
On the other hand, I feel we have a responsibility to properly translate and localize *user-facing* UI elements. Which requires us to have further UI to pick the language and keymap.
Most install cases (CD, DVD, Live USB, etc). will not require any user-facing UI in initramfs - they'll immediately load stage2 and be merrily on their way. PXE and other netboot scenarios should do the same, unless the server is misconfigured[2].
Basically: I understand that you, as a developer, want interactive debuggability. That's cool, I want that too.
But do we really expect normal users to have to deal with unrecoverable errors (e.g. misconfigured netboot servers) *so often* that we should write an entirely new language/keymap picker just for that? I'm not so sure.
-w
[1] This seems to be accepted practice for Linux development - the bootup messages, for instance, are all in English. No translations.
[2] Also note that configuring a PXE server can be done on a system that will have the proper local language/keymap, using translated documentation.
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Martin Sivak (msivak@redhat.com) said:
Or we need to be able to re-initialize after loading the driver > disk. I'm pretty sure that's easy to handle for network drivers.. not sure about storage, but I don't think it's impossible.
To be exact, we have to be able to unload all network and storage drivers and instruct udev to load them again.
Unloading just storage and network supposes we know which modules are network and storage.. that is why we currently save a list of modules loaded before loader and restores to that state (no guessing that way..).
At what point do we reexamine everything that is done in driver discs in terms of what is absolutely required, versus 'what we have always done'?
For example, the 'feature' of unloading all drivers to then load them in an interactive order seems to mainly be there to preserve the fallacy that storage device names are meaningful. Is that the only reason that it's required? If so, is that feature worth an entirely separate interactive infrastructure? Why does it need to be interactive, when it could theoretically be done via kickstart commands, or commandline operations?
Bill, playing devil's advocate
Hi,
At what point do we reexamine everything that is done in driver discs in terms of what is absolutely required, versus 'what we have always done'?
For example, the 'feature' of unloading all drivers to then load them in an interactive order seems to mainly be there to preserve the fallacy that storage device names are meaningful. Is that the only reason that it's required? If so, is that feature worth an entirely separate interactive infrastructure? Why does it need to be interactive, when it could theoretically be done via kickstart commands, or commandline operations?
This is not part of the driver disc infrastructure as I know it. Driver discs can be noninteractive - with the exception of the features I talked about. Manual driver _disc_ (not single driver) selection and automatically detected driver disc confirmation (and at least the second one is a must).
It is not about what we have always done, but more about what the customers expect to still work. It takes a lot of politics to convince them that they do not need a feature they have always used :)
I see the points in moving it to anaconda directly, but I also see what becomes hard to do in the use cases when dracut is not able to load the whole big image, either because the hw/fw limits it (PPC) or because it is stored somewhere we do not have access to. Those might be uncommon, but this feature was never meant for the common user, it is used by couple of big vendors with exactly this sort of problems.
One use case we ran into was to select one driverdisc from a media to get access to a device with a second one that contained drivers for all hardware the vendor supported. It allowed them to maintain only one big image..
If we can ensure that dracut always gets install.img, regardless on the install method and the novelty of used hardware, then we can move this feature to anaconda. If not, it has to go to dracut (and will probably use question/answer by number system).
Martin
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):
- 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).
- 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.
- 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
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):
- 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).
- 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.
- 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 Cantrelldcantrell@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
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):
- 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).
- 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.
- 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 Cantrelldcantrell@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
- 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.
- 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
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
On Tue, 2011-11-22 at 10:10 -0500, Martin Sivak wrote:
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.
Or we need to be able to re-initialize after loading the driver disk. I'm pretty sure that's easy to handle for network drivers.. not sure about storage, but I don't think it's impossible.
So with install/network sources being handled by dracut, DDs have to go into dracut too..
I'm not sure about this. Here's my reasoning (forgive the formality but I'm trying to think through the logic myself):
1) DD support needs to be in dracut if (and only if) there are supported install cases where dracut must load a driver disk before it will be able to load install.img.
2) We need a driver disk before loading install.img if (and only if) there are devices that can hold/fetch the DD, but not install.img.
Therefore:
We only need DD support in dracut if there are supported devices that can hold/fetch a DD but not install.img.
Floppies and Zip drives are the only things that come to mind that meet this condition, but I'm not sure if we support them. Are there any others?
-w
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
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!
The various lesser known network options like linksleep and nicdelay were all added at customer requests, thus we do need to find a place for them to live or we'll be getting regression bug reports later.
- Chris
anaconda-devel@lists.fedoraproject.org
-
Bill Nottingham -
Chris Lumens -
David Cantrell -
John Reiser -
Martin Sivak -
Will Woods