Multiple interfaces support and lots of cmdline parsing
cover Multiple interfaces support and lots of cmdline parsing
Basically dracut has a problem with netroot when booting with multiple nics. If we have multiple interfaces online at the same time, we don't really know which interface to use for default-route or dhcp root-path source.
This series of patches adresses this problem by delegating the real interface configuration to netroot and introducing a new cmdline argument. I'll try to explain to solution with two use cases:
Case 1: Multiple interfaces with ip=dhcp or ip=client-ip... but no <dev>
The problem here is that we can't up just every eth that pops up. Default-route or whatever will get confused.
The solution here is that ifup and/or dhclient script just write the necessary ip statements into /tmp/net.$dev.* and netroot (which is synchronized by a lock) just uses one interface at a time, deconfiguring it if mounting fails.
Case 2: Multiple interfaces with multiple ip= lines
This is a case where the user expects all interfaces to be up before mounting. Think bonding, iscsi multipathing, etc.
The solution here is that the ip cmdline parsers enforces the presence of <dev> for multiple ip= lines and further demands that the new argument bootdev contains the name of the primary interface to be used for routing etc. Configuration is of course again delegated to netroot but in this case netroot takes additional care to "wait" for all required interfaces to be up.
In order to ensure correct ip= lines I've added a lot of cmdline parseing and some mostly minor rewrites of actual netroot handlers.
Thanks for reviewing (or accepting) the stuff,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
When you post this as a git repo, could you please include more descriptive changelogs on each commit?
dracut_install $(ls {/usr,}$LIBDIR/libnfsidmap*.so* 2>/dev/null ) dracut_install $(ls {/usr,}$LIBDIR/libnss*.so 2>/dev/null) -dracut_install grep
instmods nfs sunrpc ipv6
some commits like [3/5] contain unrelated changes that turn out to be good, but they are not explained in the changelog.
Warren Togami
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 12 lines · Warren Togami
When you post this as a git repo, could you please include more descriptive changelogs on each commit?
dracut_install$(ls {/usr,}$LIBDIR/libnfsidmap*.so* 2>/dev/null )dracut_install$(ls {/usr,}$LIBDIR/libnss*.so 2>/dev/null) -dracut_install grepinstmods nfs sunrpc ipv6
some commits like [3/5] contain unrelated changes that turn out to be good, but they are not explained in the changelog.
I'd like to implement the bridging support next, but it would really be good to do so on top of cleaned up patches from Seewer instead of conflicting with these changes.
Warren
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Seewer Philippe
In order to ensure correct ip= lines I've added a lot of cmdline parseing and some mostly minor rewrites of actual netroot handlers.
Thanks for reviewing (or accepting) the stuff,
Philippe
The series broke the NFS and NBD test suites, and I've not looked into why yet. It dies on the first test.
I've started digging in and trying to review some of the changes, but I'm just not going to have time before I leave; perhaps I can sneak away for a bit next week.
Perhaps a theory of operation/design document as to what the flow is expected to be, or what is handled where would help?
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 1244865916.18551.20.camel-1q1vX8mYZiGLUyTwlgNVppKKF0rrzTr+@public.gmane.org
Quoted 9 lines · David Dillow
Quoted 4 lines · Seewer Philippe
In order to ensure correct ip= lines I've added a lot of cmdline parseing and some mostly minor rewrites of actual netroot handlers.
Thanks for reviewing (or accepting) the stuff,
PhilippeThe series broke the NFS and NBD test suites, and I've not looked into why yet. It dies on the first test.
That's ... weird? I wasn't able to run the qemu/kvm test locally (don't ask, please). But I replicated the test arguments and ran them through the scripts. Should work, and nfsroot booted flawlessly Friday afternoon.
What's the die() error message?
Quoted 3 lines
I've started digging in and trying to review some of the changes, but I'm just not going to have time before I leave; perhaps I can sneak away for a bit next week.
Thanks for looking into it!
Quoted 2 lines
Perhaps a theory of operation/design document as to what the flow is expected to be, or what is handled where would help?
Is it really that complex? I'll write down my thoughts and add in a few examples.
Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Seewer Philippe
Quoted 2 lines · David Dillow
The series broke the NFS and NBD test suites, and I've not looked into why yet. It dies on the first test.
That's ... weird? I wasn't able to run the qemu/kvm test locally (don't ask, please). But I replicated the test arguments and ran them through the scripts. Should work, and nfsroot booted flawlessly Friday afternoon.
What's the
die()error message?
The only thing printed for either test was
Warning: No ip= argument(s) provided, defaulting to DHCP
It never made it past the first subtest.
It's possible that I screwed up applying them, but git apply-mbox applied all 6 (5+missing) in order without issue.
Quoted 11 lines
Quoted 3 lines
I've started digging in and trying to review some of the changes, but I'm just not going to have time before I leave; perhaps I can sneak away for a bit next week.
Thanks for looking into it!
Quoted 2 lines
Perhaps a theory of operation/design document as to what the flow is expected to be, or what is handled where would help?
Is it really that complex? I'll write down my thoughts and add in a few examples.
I think part of the problem is that your series does too much in each step. You have style changes, network device handling changes, dhclient.conf changes, and command line parsing changes in the series. Each one of those should be its own patch.
I would suggest getting the dhclient.conf and network device handling changes in first; the dhclient.conf change should be uncontroversial and we need to get the discussion on the handling going -- that is holding back other progress. The command line handling is important, but lower priority at the moment in my opinion.
Also, please try again to get the test suite running locally, and make sure any support you add/drop is reflected in the test suite in the same patch, if at all possible. This will help demonstrate the effect of the changes you are making.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 1244895898.18551.30.camel-1q1vX8mYZiGLUyTwlgNVppKKF0rrzTr+@public.gmane.org
David Dillow wrote:
[snip]
Quoted 9 lines
Quoted 3 lines
Quoted 2 lines
Perhaps a theory of operation/design document as to what the flow is expected to be, or what is handled where would help?
Is it really that complex? I'll write down my thoughts and add in a few examples.
I think part of the problem is that your series does too much in each step. You have style changes, network device handling changes, dhclient.conf changes, and command line parsing changes in the series. Each one of those should be its own patch.
Quoted 5 lines
I would suggest getting the dhclient.conf and network device handling changes in first; the dhclient.conf change should be uncontroversial and we need to get the discussion on the handling going -- that is holding back other progress. The command line handling is important, but lower priority at the moment in my opinion.
Hmmm... yes and no. To me, the command line handling is important as well since at least the ip= parser needs to work for the network handling.
Quoted 4 lines
Also, please try again to get the test suite running locally, and make sure any support you add/drop is reflected in the test suite in the same patch, if at all possible. This will help demonstrate the effect of the changes you are making.
ok, thanks for the great feedback!
Working on getting the test-suite running right now, will try to split my patches later the way you suggested. I guess apologies are in order for the "mess".
Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Seewer Philippe
Working on getting the test-suite running right now, will try to split my patches later the way you suggested. I guess apologies are in order for the "mess".
Hi,
We are still waiting for a git repo to pull from so we can review this patch set. Please split unrelated changes into their own commits and write detailed changelog entries on each.
Warren
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Warren Togami
Quoted 4 lines · Seewer Philippe
Working on getting the test-suite running right now, will try to split my patches later the way you suggested. I guess apologies are in order for the "mess".
Hi,
We are still waiting for a git repo to pull from so we can review this patch set. Please split unrelated changes into their own commits and write detailed changelog entries on each.
There you go
http://github.com/seewer/dracut-seewer/commits/master
Patches are split as atomically as made sense (to me). Except for the ISCSI test-suite which I've ignored, all tests now pass. Accordingly the tree contains some fixes that weren't in the patches last week, this is mainly to fix the test-suites to run with Debian based distros and some enhancments that were discovered while running the test cases.
As for further examples how the multinic stuff should work, I've tried document an example in the two last multinic patches:
http://github.com/seewer/dracut-seewer/commit/db8158439dac10e7462203d3de44fd794bd35e2b
http://github.com/seewer/dracut-seewer/commit/8ecd9d010a46999263b629b16954156e34083244
Apologies it took longer than expected, the only thing I can say there is that Murphy is always right.
Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 31 lines · Seewer Philippe
Quoted 11 lines · Warren Togami
Quoted 4 lines · Seewer Philippe
Working on getting the test-suite running right now, will try to split my patches later the way you suggested. I guess apologies are in order for the "mess".
Hi,
We are still waiting for a git repo to pull from so we can review this patch set. Please split unrelated changes into their own commits and write detailed changelog entries on each.
There you go
http://github.com/seewer/dracut-seewer/commits/master
Patches are split as atomically as made sense (to me). Except for the ISCSI test-suite which I've ignored, all tests now pass. Accordingly the tree contains some fixes that weren't in the patches last week, this is mainly to fix the test-suites to run with Debian based distros and some enhancments that were discovered while running the test cases.
As for further examples how the multinic stuff should work, I've tried document an example in the two last multinic patches:
http://github.com/seewer/dracut-seewer/commit/db8158439dac10e7462203d3de44fd794bd35e2b
http://github.com/seewer/dracut-seewer/commit/8ecd9d010a46999263b629b16954156e34083244
Quoted 6 lines
Apologies it took longer than expected, the only thing I can say there is that Murphy is always right.
Regards,
Philippe
--
Pushed with some additional changes.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html