Description of problem: setup-named-chroot.sh[1441]: ls: cannot access /var/lib/named/usr/lib/openssl: No such file or directory setup-named-chroot.sh[1441]: mount: mount point /var/lib/named/usr/lib/openssl does not exist Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. clean install, apply updates 2. urpmi bind 3. journalctl -b | grep setup-named-chroot.sh
Assignee: bugsquad => guillomovitch
32bits-specific path such as /usr/lib/openssl or /usr/lib/bind should not exist on a 64bits system, and the setup-named-chroot.sh should ignore them silently. The opposite is true for 64bits-specific pathes on 32bits system. Your issue you're facing seems to be caused by the existence of /usr/lib/openssl, which is possible if you have both 32buts and 64bits version of openssl libs installed. The script will attempt to this path in the chroot, and will fail because of missing mount point. Either the script should be made slightly more intelligent, and use an arch-specific pathes list. Or it should test also the mount point before attempting to mount something on it.
Status: NEW => ASSIGNED
(In reply to comment #1) > 32bits-specific path such as /usr/lib/openssl or /usr/lib/bind should not exist > on a 64bits system, I hear that. Problem was able to creep in because of the skype rpm which is only released as a 32 bit app and drags in a boat load of 32 bit libs and what not. :( > Either the script should be made slightly more intelligent, and use an > arch-specific pathes list. "use an arch-specific path" sounds like the better choice to me.
Fixed in 9.9.2.P1-2.mga3.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED