Re: Bug#433568: VLANs during install are important
On Sat, Jan 30, 2010 at 01:07:04AM +0100, Frans Pop wrote:
> On Saturday 30 January 2010, Josef Wolf wrote:
> > This is why my original proposal was to decide from the value of
> > netcfg/chosen_interface whether to load/configure all the vlan stuff.
>
> So you would *always* show vlan interfaces, even for regular users on
> normal systems? I don't think I like that idea very much.
No, my plan was to not ask any questions at all. The decision whether to
load the vlan stuff would be based on the format of choose_interface. If
the interface name matches one of the vlan naming schemes (e.g. eth0.5 or
vlan5), then load/configure it that way.
> Note that during most installs the dialog to select an interface is not
> even displayed currently (if there's only one) and we certainly wouldn't
> want to change that.
My intention was to not ask any questions at all.
> > Somehow I managed to miss that, and google seems not to have it in its
> > index (yet?). Can you give me some more pointer?
>
> It's also linked in the wiki, but:
> http://d-i.alioth.debian.org/doc/internals/
Ah, I already read that. I was not aware that you talk about this writeup.
> > Would be just a change in a config option, right? So that's not really a
> > big deal and could be done independently of the changes we are
> > discussing in this thread, right?
>
> It would also mean a size increase of the initrd for all architectures...
That's right. But only for netinstall. What about supporting vlan only with
CD installation?
BTW: all the needed bits are on the install CD anyway (in the ordinary
packages). Why not extract them from the ordinary packages instead of
duplicating them by creating special udebs?
> We usually don't do make such changes lightly.
I guess this decision is not up to me. ;-)
> > So, _PLEASE_ consider to activate this
> > option independently from the results on this thread. Then, people would
> > be able to configure vlans manually even if the efforts in this thread
> > would fail for whatever reason...
>
> Please check that it works first and try to implement proper support. If
> that does not work out we can always discuss alternatives.
OK, I'll check that.
Reply to: