Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

f23: dhclient cannot load /usr/lib64/bind99/libirs-export.so.91 library #772

Closed
gdha opened this issue Feb 12, 2016 · 6 comments
Closed

f23: dhclient cannot load /usr/lib64/bind99/libirs-export.so.91 library #772

gdha opened this issue Feb 12, 2016 · 6 comments
Assignees
@gdha
Labels
bug The code does not do what it is meant to do fixed / solved / done
Milestone
Rear v1.18

Comments

@gdha
Copy link
Member

gdha commented Feb 12, 2016

The rescue image created on fedora23 boots fine, but we do no get an IP address (via dhclient), because dhclient cannot find the shared object file.
The libraries are there, but the /lib64/bind99 path is missing in /etc/ld.so.conf file.
@gdha gdha added the bug The code does not do what it is meant to do label Feb 12, 2016
@gdha gdha self-assigned this Feb 12, 2016
@gdha gdha added this to the Rear v1.18 milestone Feb 12, 2016
@gdha
Copy link
Member Author

gdha commented Feb 12, 2016

In script build/GNU/Linux/39_copy_binaries_libraries.sh there is a call to ldconfig $v -r "$ROOTFS_DIR" >&8 and it goes clearly over the /lib/64/bind99 libs, but did not add it the the /etc/ld/so.conf file.
Perhaps, we should skip this old fashion why of working and use the more standard way with conf files under /etc/ld.so.conf.d/ directory?

gdha added a commit that referenced this issue Feb 15, 2016
@gdha
* modified script build/GNU/Linux/39_copy_binaries_libraries.sh:
d62a555 
  commenting out ldconfig line
* added new script rescue/GNU/Linux/55_copy_ldconfig.sh:
  copy the /etc/ld.so.conf* stuff to ROOTFS
* added new script skel/default/etc/scripts/system-setup.d/01-run-ldconfig.sh:
  run ldconfig -X before dhclient gets started at boot time
Fix for issue #772
@gdha gdha closed this as completed Mar 4, 2016
@jsmeix jsmeix mentioned this issue Sep 18, 2017
Closed
@jsmeix
Copy link
Member

jsmeix commented Sep 18, 2017 •
edited

Since
d62a555
the recovery system could fail to boot, see
#1494

@jsmeix jsmeix reopened this Sep 18, 2017
@jsmeix
Copy link
Member

jsmeix commented Sep 18, 2017

@gdha
we need a better solution which results a clean recovery system.

@jsmeix jsmeix mentioned this issue Sep 19, 2017
Merged
@jsmeix
Copy link
Member

jsmeix commented Sep 19, 2017 •
edited

@gdha
I think - but that is only a guess - that in
d62a555
only the new script
rescue/GNU/Linux/550_copy_ldconfig.sh
that copies the /etc/ld.so.conf* stuff to ROOTFS
could be sufficient to fix this issue here
because with the ldconfig config files in ROOTFS
the 'ldconfig' call at the end of the later
build/GNU/Linux/390_copy_binaries_libraries.sh
should "do the right thing".
I.e. I think moving additionally the 'ldconfig' call from
build/GNU/Linux/390_copy_binaries_libraries.sh
into the init scripts of the recovery system
into another new script
skel/default/etc/scripts/system-setup.d/01-run-ldconfig.sh
is not needed.

Furthermore I wonder why in
skel/default/etc/scripts/system-setup.d/01-run-ldconfig.sh
the 'ldconfig' call is with the '-X' option?
What is the reason behind why ldconfig must not
update links in the recovery system?
What goes wrong if ldconfig also updated links?

jsmeix added a commit that referenced this issue Sep 19, 2017
@jsmeix
Merge pull request #1502 from jsmeix/run_ldconfig_in_non_mandatory_wa…
6afc9a0 
…y_at_the_end_of_copy_binaries_libraries

Run ldconfig non mandatory at the end
of 390_copy_binaries_liraries.sh
to get a consitent libraries configuration
in the recovery system to avoid issues like
#1494
but do not treat a ldconfig failure as fatal
(only report the failure but do not error out)
so that it could still work for special cases as
#772
@jsmeix
Copy link
Member

jsmeix commented Sep 19, 2017

With #1502 merged
issues like #1494
should now be avoided while it could still work for
special cases like this issue here because now
a ldconfig failure is no longer a fatal error, the
failure is only reported but it does not error out.

@jsmeix jsmeix closed this as completed Sep 19, 2017
@jsmeix
Copy link
Member

jsmeix commented Oct 4, 2017

With #1521 merged
the whole binaries and libraries copying code is now
cleaned up and simplified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gdha gdha

Labels
bug The code does not do what it is meant to do fixed / solved / done
Projects
None yet
Milestone
Rear v1.18
Development

No branches or pull requests
2 participants
@gdha @jsmeix