FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 11-22-2011, 03:02 PM
Chris Lumens
 
Default Return of NoLoader

> 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-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-28-2011, 05:39 PM
Will Woods
 
Default Return of NoLoader

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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-28-2011, 11:37 PM
Will Woods
 
Default Return of NoLoader

On Fri, 2011-11-18 at 17:05 -0800, John Reiser wrote:
> >> 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.

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
 
Old 11-29-2011, 12:40 PM
Martin Sivak
 
Default Return of NoLoader

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

> 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.

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:
> > >> 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.
>
> 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
>

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-29-2011, 02:55 PM
Bill Nottingham
 
Default Return of NoLoader

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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-29-2011, 03:14 PM
Martin Sivak
 
Default Return of NoLoader

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


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

Thread Tools




All times are GMT. The time now is 04:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org