Re: Bug#433568: VLANs during install are important
On Fri, Jan 29, 2010 at 02:54:58PM +0100, Frans Pop wrote:
> On Friday 29 January 2010, Josef Wolf wrote:
> > But at that time the interface chosen interface is not known. So
> > deducing from chosen interface name (as outlined above) is not possible
> > and this method would only work with preseeding or if additional
> > questions are asked.
>
> No. The sequence should be:
> - if the interfaces are there, hw-setup should install additional needed
> stuff
> - if additional needed stuff is not available, netcfg should not offer
> the interfaces for selection
Umm, I don't think this would work with vlan. See, a vlan is not a piece
of hardware that you can auto detect. All that you get is your normal
network interface (e.g. eth0) which you have anyway. Although this interface
is detected, there is no way to tell whether you want to run vlans on that
interface or whether you want to use it as an ordinary iface. AFAICS, all
you can get from hw-setup is your plain-vanilla interface (e.g. eth0). The
vlan interfaces won't spring into existence until you load the required
kernel modules and create them with commands like
vconfig set_name_type DEV_PLUS_VID_NO_PAD
vconfig eth0 5
This will create eth0.5 (may get a different name, depends on the naming
scheme, which has also to be configured by vconfig, as shown above)
See the chicken+egg problem here? You have to load the modules and execute
vconfig to create the interface. So you can not rely on hw-setup to load
the udebs since there's no way for hw-setup to know that the vlan udebs
need to be loaded in the first place.
This is why my original proposal was to decide from the value of
netcfg/chosen_interface whether to load/configure all the vlan stuff.
If chosen_interface matches one of the vlan naming schemes, then load
and configure the vlan stuff appropriately. AFAICS, hw-setup is too
early to parse chosen_interface and decide whether it matches one of
the vlan naming schemes.
> > > And for e.g. netboot
> > > images the vlan udeb would need to be included in the initrd for
> > > relevant architectures.
> >
> > Oh, I've completely forgotten about netboot. To be honest, I have no
> > clue what this means exactly. Can you point me to some information about
> > that?
>
> Just build the target and use the mini.iso for your development and
> testing. It's by far the easiest way to develop new functionality anyway.
Building the installer is not exactly an everyday-task for me, so please
be patient with me. It may take some time until I get my head around it.
BTW: I could use a little bit hand-holding on this topic ;-)
> See further the document I pointed t earlier, especially the comments about
> localudebs and pkg-lists/local.
Somehow I managed to miss that, and google seems not to have it in its
index (yet?). Can you give me some more pointer?
> > BTW:
> > Actually there are two udebs:
> > - one udeb created from vlan.deb (only the XC-Package-Type line needs
> > to be added to debian/control)
>
> Not needed according to Bastian.
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? 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...
> > - the kernel modules would be created via kernel-wedge
>
> Correct. Only question is whether they should be in a separate udeb, or
> included in one of the existing network-drivers udebs. That depends on:
> - size
> - whether it is generally needed/useful or only for selected arches.
>
> I think a separate udeb is the best option to start with.
The required modules are (size might vary with kernel version...):
8021q.ko 32328 bytes
garp.ko 13460 bytes
stp.ko 4456 bytes
Thats a total of about 50 kbytes.
BTW: I have double-checked now. 8021q won't load without garp. And garp
won't load without stp. So I think the question that appeared earlier
in this thread can be answered now: all three modules are needed.
We would have to talk to the kernel developers to change that.
Reply to: