eselect rc supports the ROOT environment variable. However, when calling, eselect rc add, this does not work as expected. The result is that a symlink is created in /etc/runlevels (so not inside $ROOT) pointing to the initscript inside $ROOT. From /usr/share/eselect/modules/rc.eselect:106 ln -sf \ ${ROOT}/etc/init.d/${script} \ ${ROOTi}/etc/runlevels/${runlevel}/${script} \ && write_kv_list_entry ${runlevel} "[done]" \ || write_kv_list_entry ${runlevel} "[failed]" Here we see that $ROOT is applied to both the target and name of the symlink, however, it is misspelled for the name, resulting in the symlink being created outside of $ROOT. Apart from this misspelling, we see that $ROOT is also aplied to the target of the symlink. The resulting symlink will then point to, for example, /somewhere/etc/init.d/somescript. When actually booting into the root fs under $ROOT, /somewhere is obviously not available anymore. The symlink should either point to /etc/init.d/somescript (this is what update-rc does) or to ../init.d/somescript (this is what the default links in baselayout2 have). I've attached a patch that achieves the former solution. It is made against 1.0.10, but 1.0.11 has the same problem and the patch should apply cleanly. It's a trivial patch anyway.
Created attachment 140493 [details, diff] Patch against 1.0.10
I don't see any such problem w/ 1.0.11
I'm still convinced that this bug is present. To show that the bugged code is still present in 1.0.11, run the following two commands. # ebuild /usr/portage/app-admin/eselect/eselect-1.0.11.ebuild unpack # grep -C 2 ROOTi /var/tmp/portage/app-admin/eselect-1.0.11/work/eselect-1.0.11/modules/rc.eselect ln -sf \ ${ROOT}/etc/init.d/${script} \ ${ROOTi}/etc/runlevels/${runlevel}/${script} \ && write_kv_list_entry ${runlevel} "[done]" \ || write_kv_list_entry ${runlevel} "[failed]" To verify, I installed eselect-1.0.11 and got the following. # mkdir -p /somewhere/etc/init.d /somewhere/etc/runlevels/default # cp /etc/init.d/local /somewhere/etc/init.d/ # ROOT=/somewhere eselect rc add local default # ls -l /etc/runlevels/default/local lrwxrwxrwx 1 root root 27 Jan 8 22:33 /etc/runlevels/default/local -> /somewhere/etc/init.d/local # ls -l /somewhere/etc/runlevels/default/ total 0 Clearly, the bug is still in 1.0.11. I'm reopening the bug. Could you please see if the above shows the problem for you as well?
(In reply to comment #3) > I'm still convinced that this bug is present. Well, I apparently fixed that locally... sorry.
Thanks, fixed in svn.
(In reply to comment #5) > Thanks, fixed in svn. > I have just been bitten by this and wasted a good half a day trying to figure out what was going wrong (ok the problem isn't hard to debug - but it took a while to figure out that it was actually happening) Can this get pushed out as a new package ASAP please? (I am surprised that this doesn't bite catalyst and gnap, etc?) Thanks
Can we push a -r2 with this? I see you pushed a -r1 without this patch in March, peper..
(In reply to comment #1) > Created an attachment (id=140493) [edit] > Patch against 1.0.10 Committed to trunk (r425) and 1.0.x branch (r426). This will be in 1.0.12.
Fixed in 1.0.12. Thanks for reporting.
