Fix Compilation Errors in armv8a and fix issue with NOS image discovery #459
Conversation
problem : copliation errors like "ERROR: Missing SYSROOT_LIB: ld-2.24.so” when sysroot is prepared. cause : New crosstool-ng, keeps the c libs fo 64 bit architectures (such as armv8a and x86_64) in lib64 folders of cross toolchain installation directory. fix : for 64 bit architectures first lokkup the c Libraries in lib64 and then in lib folder of cross toolchain installation directory. Signed-off-by: Pankaj Bansal <[email protected]>
multiple network interfaces Problem : Onie installation doesnt complete if multiple ethernet interfaces are there and tftpserver connected to 1st valid interface(that is eth0) doesnt have valid Onie installer. Cause : The installer only searches eth0 for NOS images Fix : The installer should search all ethernet interfaces for NOS image Signed-off-by: Pankaj Bansal <[email protected]>
| exit 1; } ; \ | ||
| find $(DEV_SYSROOT)/lib -name $$file | xargs -i \ | ||
| cp -av {} $(SYSROOTDIR)/lib/ || exit 1 ; \ | ||
| if [ "$(ARCH)" == "arm64" ] || [ "$(ARCH)" == "x86_64" ] ; then \ |
There was a problem hiding this comment.
Why is x86_64 included here? x86_64 is currently building fine as it is with the new crosstool-ng.
It seems like this is only an arm64 issue. I'm probably missing something.
| echo "ERROR: Does not look like valid GRUB i386-pc library directory: $GRUB_TARGET_LIB_I386_DIR" | ||
| exit 1 | ||
| } | ||
| fi |
There was a problem hiding this comment.
The onie-mk-iso.sh change looks OK to me. This is orthogonal to the above bit about lib32 / lib64. Let's make this a separate patch.
| @@ -1,6 +1,7 @@ | |||
| #!/bin/sh | |||
There was a problem hiding this comment.
I think this issue needs some more thought. Also this issue should be in a separate pull request from the lib32/lib64 issues as they are unrelated.
Correct me if I'm wrong, but here is my take on what is happening:
The sd_dhcp4() function attempts DHCPv4 on all interfaces, but stops when it gets a reply from one. Let's say you have two interfaces eth0 and eth1, both of which have a DHCP server (possibility different servers, or different configurations) - lets call the DHCP severs dhcp0 and dhcp1 respectively.
The sd_dhcp4() loop will stop after eth0 gets a DHCP reply from dhcp0. eth1 never gets a chance to talk with dhcp1.
In your case the desired DHCP configuration (the tftp server info) is only valid from dhcp1 -- for example the reply from dhcp0 does not contain the tftp server info.
It seems like the ONIE discovery needs to be per interface and the image waterfall driven all the way through before moving on to the next interface. Today the code is not quite right, where it first tries to gather all the DHCP info from all interfaces and then drive the waterfall.
The reason the code stops after the first interface has a valid reply is that what if both dhcp0 and dhcp1 specify a tftp server? Who wins?
All this code needs a bit of a rework and you have done most that here -- thanks!
A few comments:
-
sd_staticandsd_localfsshould only happen once per discovery loop. These should not happen once per network interface. I think once these discoveries are complete we could launchexec_installerjust for them. -
sd_dhcp6,sd_dhcp4,sd_mdns,sd_fallbackandneigh_discoveryhappen once per interface. After all of these network discoveries are complete for an interface, launchexec_installer. This would allow each interface to receive DHCP replies from different servers, with potentially different image URL configuration.
It looks like you have done most of this already. The only change I would make is that the static and local file system discovery only happen once per "discovery loop", instead of once per interface. Otherwise looks pretty reasonable.
| /etc/init.d/syslogd.sh discover | ||
| service_discovery "$i" | ||
| log_debug_msg "onie_disco: $onie_disco" | ||
| neigh_discovery |
There was a problem hiding this comment.
looks like neigh_discovery should be passed $i
No description provided.