We use openrc for Alpine Linux so this is a bug for openrc itself and not Gentoo. openrc will no longer detect that the booting system is vserver due to the rc_sys_v1() vs rc_sys_v2() change 647df8cfe70a667f011b38a058244528c4a22a40. this results that the alpine linux networking init.d script gets pulled in (but fails due to vserver guest is not supposed to configure network) and since no "net" is provided the other serivces will fail too, like sshd. The solution is ofcource to set rc_sys="vserver" in /etc/rc.conf, but as said, all current boxes has rc.conf="" so current boxes won't boot. Alpine Linux does not even support LXC (yet) so I'll rather handle LXC when that comes. Thanks!
Created attachment 264599 [details, diff] Use rc_sys_v1() when rc_sys variable is defined but empty Suggested fix
(In reply to comment #1) > Created an attachment (id=264599) [details] > Use rc_sys_v1() when rc_sys variable is defined but empty > Suggested fix The rc_sys_v1 code is buggy and deprecated. We are planning on removing it soon. See bug #347583, bug #349389, commit 3d1d4ab and the FEATURE-REMOVAL-SCHEDULE file in the git repository for our reasons for this change. Because of this, your patch can't be used. Do you have any other suggestions for fixing this?
I am waiting for more info from the user on this bug. The issue he is having is that the default rc_sys setting does not allow a vserver guest to boot, and he wants a way to allow this without changing rc.conf. He is suggesting that we keep the autodetection code around for backward compatibility and run it when rc_sys is set to "". I pointed out the concern about /proc not being readable in early boot or under hardened kernels, and I'm waiting for a response before I decide what to do with this bug.
i dont see any problems with merging this patch
(In reply to comment #3) > I am waiting for more info from the user on this bug. > > The issue he is having is that the default rc_sys setting does not > allow a vserver guest to boot, and he wants a way to allow this without > changing rc.conf. > > He is suggesting that we keep the autodetection code around for backward > compatibility and run it when rc_sys is set to "". > > I pointed out the concern about /proc not being readable in early boot > or under hardened kernels, and I'm waiting for a response before I > decide what to do with this bug. > The problem I want to solve is not surprise current vserver guest installs which has rc_sys="" in their /etc/rc.conf. Currently those will fail. The proposed patch makes them boot. It does not try solve unreadable /proc at all. (thos will still need set rc_sys in rc.conf) I'd suggest that old code is kept in sources, maybe with something like: #if defined (ENABLE_RC_SYS_V1) ... #else ... #endif That way will Gentoo be able remove/break the stuff as they want (the openrc ebuild does not need have a use flag for this) while other distros can compile time enable the compat code. That said, it seems like Alpine Linux is trying to go away from openrc so it doesnt really matter. We can always patch openrc manually as long we need it. Thanks!
Created attachment 264751 [details] rc-default.patch Mike, what do you think about doing this this way instead? This would give users a way at build time to set the default value of RC_SYS.
How about an entirely different solution? Specifically, during install of the package, we populate the rc_sys variable for some systems, esp. vserver
(In reply to comment #7) > How about an entirely different solution? > Specifically, during install of the package, we populate the rc_sys variable > for some systems, esp. vserver I'm not sure how that is different from my patch in comment #6. If you apply my patch then do make MKRCSYS=vserver you get a build with the default for RC_SYS set to vserver.
williamh: I'm proposing we set the variable in rc.conf when it's installed, based on the ebuild environment. No changes to the OpenRC code, just changes to the ebuild code.
(In reply to comment #9) > williamh: I'm proposing we set the variable in rc.conf when it's installed, > based on the ebuild environment. No changes to the OpenRC code, just changes to > the ebuild code. That doesn't work because the poster is using alpine linux, which doesn't use ebuilds. This fix needs to go in the openrc code itself.
Created attachment 264781 [details, diff] 20110304-allow-rc_sys_default.patch Attached patch sets the rc_sys variable in the config file based on the contents of MKRCSYS environment during build.
As of commit 3fca6db, we now have a way in openrc to set the default RC_SYS value in rc.conf. In the future, this should make it possible to install openrc on a vserver guest and make it bootable without editing rc.conf. Natanael, does this fix your issue? Thanks, William
(In reply to comment #12) > As of commit 3fca6db, we now have a way in openrc to set the default RC_SYS > value in rc.conf. In the future, this should make it possible to install openrc > on a vserver guest and make it bootable without editing rc.conf. > > Natanael, does this fix your issue? No. This just moves the problem to compile time. Alpine Linux is a binary distro so same compiled binary package is supposed to run everywhere. This means to solve the specific issue at hand, at least the vserver autodetect code *needs* to stay (which always will work since /proc needs to be mounted by "host"). What is the problem with opportunistic auto detect? For systems where it can be autodetected, let it autodetect, all other must set it in rc.conf.
(In reply to comment #13) > (In reply to comment #12) > > As of commit 3fca6db, we now have a way in openrc to set the default RC_SYS > > value in rc.conf. In the future, this should make it possible to install openrc > > on a vserver guest and make it bootable without editing rc.conf. > > > > Natanael, does this fix your issue? > > No. This just moves the problem to compile time. Alpine Linux is a binary > distro so same compiled binary package is supposed to run everywhere. > > This means to solve the specific issue at hand, at least the vserver autodetect > code *needs* to stay (which always will work since /proc needs to be mounted by > "host"). > > What is the problem with opportunistic auto detect? For systems where it can be > autodetected, let it autodetect, all other must set it in rc.conf. > Point is invalid. It is up to you to update your distro to a working state. You are more then welcome to provide an older release for your distro until you all find a way to deal with how YOU ALL want to fix the issue. William I see no point in further rework of the code, as a binary distro they could always populate the variable at build time.
Created attachment 265029 [details, diff] Allow distros who wants be backard compatible keep rc_sys_v1() Please consider this patch.
i really dont think it's invalid at all. it goes against the entire point of src_* vs pkg_* steps. the fact that Gentoo does not officially maintain an up-to-date binary pkg repository is irrelevant. there are people who do maintain binary pkgs and we should not be actively ignoring/breaking them. i still dont see any problem with the original patch, nor do i see any feedback to indicate that causes any problems.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > As of commit 3fca6db, we now have a way in openrc to set the default RC_SYS > > > value in rc.conf. In the future, this should make it possible to install openrc > > > on a vserver guest and make it bootable without editing rc.conf. > > > > > > Natanael, does this fix your issue? > > > > No. This just moves the problem to compile time. Alpine Linux is a binary > > distro so same compiled binary package is supposed to run everywhere. ... > Point is invalid. It is up to you to update your distro to a working state. You > are more then welcome to provide an older release for your distro until you all > find a way to deal with how YOU ALL want to fix the issue. All I'm asking for is to keep rc_sys_v1 source code in there for compatibility reasons. > ... as a binary distro they could always populate the variable at build time. That is not true. If it is, what should variable be set to at build time so same binary runs on both vserver guests and non-vserver without breaking either?
one alternative would be to change the default rc.conf file so that when MKRCSYS is empty, we dont set rc.conf at all. that way when users do set rc_sys="", we know that they want to opt out of all magic. i think that should appease everyone here.
(In reply to comment #18) > one alternative would be to change the default rc.conf file so that when > MKRCSYS is empty, we dont set rc.conf at all. that way when users do set > rc_sys="", we know that they want to opt out of all magic. > > i think that should appease everyone here. I've been following this in the background with concern. It was precisely the automagic that bothered me, especially since looking into /proc which may not be the most reliable way of doing things for various reasons. I like this solution.
(In reply to comment #18) > one alternative would be to change the default rc.conf file so that when > MKRCSYS is empty, we dont set rc.conf at all. that way when users do set > rc_sys="", we know that they want to opt out of all magic. > > i think that should appease everyone here. That works for me.
Created attachment 265525 [details, diff] default rc.conf to #rc_sys="" here's what i'm proposing. seems to work for me.
I like the patch proposed in comment #21, but I would like to set it up a bit differently, as follows: - Comment out the rc_sys= line in rc.conf and expand the comments so users know when they need to set it. - since we are keeping the auto detection code, I think we should combine the rc_sys_v1/v2 functions in rc_sys. Removing it was the only reason for separating the code. - Since we are keeping the autodetection code and commenting more on the rc_sys setting, I'm not sure we need the ability to set rc_sys in the build process, so I'm thinking about removing the MKRCSYS parameter from the Makefile. I will post a patch later today that takes care of this. What does everyone else think?
Created attachment 265805 [details] 0001-update-rc_sys-handling.patch This is my proposal for this issue. This patch makes rc_sys be unset by default as well as updates the documentation for rc_sys in the configuration file to give a better idea of what we can autodetect vs what we can't. What do you think of this patch? William
that patch looks pretty good, but for two things ... the os.mk hunk doesnt handle the case that mine does as the comment describes. namely when someone does `make MKRCSYS=`. yours will use autodetection while mine will use 'rc_sys=""' (which is to say Linux). if you're going to fix the rc.conf files like that, then i guess FEATURE-REMOVAL-SCHEDULE needs removing too.
(In reply to comment #24) > that patch looks pretty good, but for two things ... > the os.mk hunk doesnt handle the case that mine does as the comment describes. > namely when someone does `make MKRCSYS=`. yours will use autodetection while > mine will use 'rc_sys=""' (which is to say Linux). Ok, that makes sense, and I am fine with going with yours. It is now pushed as commit d7e48fe. Do you think we still need to update the documentation in the rc.conf files so that it gives more information about what can/can't be detected? I think we have to keep the autodetection code around, so I want to remove the listing from FEATURE-REMOVAL-SCHEDULE and combine the rc_sys_v2/rc_sys_v1 code into rc_sys. Do you agree?
I have updated the documentation in rc.conf, git commit c991294. This will be in openrc-0.6.8, which will be released shortly.
yes, updated docs look fine. ive dropped the planned removal of these funcs from the FEATURE-REMOVAL-SCHEDULE file now.
