Just installed hprofile-2.0_beta2 (using it for dual-booting my native Gentoo install also sometimes in coLinux), set the scripts up and noticed they can't run because of several reasons (among them, the rc script from baselayout, the location of some binaries from coreutlis, findutils and diffutils), one of them being the install location of the hprofile scripts themselves, namely under /usr/sbin. Well, I happen to have a partition layout where "/usr" is a distinct partition, so everything needed at boot time, while filesystem checks are performed and only the root filesystem is accessible, obviously cannot be accessed from anything under /usr. Solved this only with some patching in all involved (mentioned above) packages, will attach my patches (mostly patching the ebuilds) right away.
Created attachment 148986 [details, diff] ebuild patch The patch optionally alters the install location and referneces to the scrtipts to "/sbin", controlled by the USE flag "rootfs".
I no longer maintain hprofile (or use Linux) so I'm unable to help any further. Sorry.
(In reply to comment #2) > I no longer maintain hprofile (or use Linux) so I'm unable to help any further. > Sorry. > No problem Martin, sorry for putting you on CC with this bug and it's blockers (though you might be intereseted, as I also think I've seen recent posts of you in the Gentoo forums). Anyway, I find your hprofile scripts great and managed to use them even if I had to dig a bit, as you see. Just thought others could also possibly benefit of them with current Gentoo, therefore I'm re-opening the bug just for the ebuild maintainer to include my patch, afer all, the ebuild is still in portage and actually useful and working with a little help.
we're not going to bloat / just for hprofile. if hprofile is this limited, then we'll either add a warning about the / and /usr issue, or people shouldnt be putting this before localmount, or we punt the package.
If I wasn't forced to move /usr away on another partition, I wouldn't have noticed these problems now, when I just discovered hprofile to be useful for my need, but I'm open to alternatives, so you guys must be knowing the answer to this: Is there "something" similar to hprofile, allowing to boot a system in different hardware environments (think of booting a native installation also in vmware or colinux, or typical laptop usage in different networks, or docked/undocked) and thus select which services should/should not start in a specific hardware scenario, which kernel modules to load or not, which /etc/conf.d files to use? Is this mighty baselayout2/openrc capable of that?
ive never used hprofile so i cant really make any comments on it baselayout has always support soft runlevels which allow you to create arbitrary profiles of init scripts and settings. the default softlevel is simply "default". that is why `rc-status` shows "Runlevel: default" normally. i use this to create profiles for my laptop. "wired", "wireless", "nonetwork", whatever.
Well, I know about the softlevel kernel command line to select a specific runlevel and its conf.d file (hprofile also uses different runlevels which I manage with the normal rc-update), but what about other files like /etc/fstab, or some files under /etc/X11 ? hprofile can also switch those according to the desired profile, together with selecting the desired runlevel (it creates symlinks to the desired variant of file). Would it be at least possible to extend the feature used in /etc/conf.d to try the /etc/conf.d/*.<softlevel> file first, to a list of files other than under /etc/conf.d, maybe user-specified (at least those I'm interested in, /etc/fstab or a specified list of files under /etc/X11, which can also deal with different hardware profiles?
softlevel only affects init.d scripts, not anything else. it already checks /etc/conf.d/<service>.<softlevel> before /etc/conf.d/<service>. only thing i can think of is a very simple init script that does something like: cp -a /etc/profiles/<softlevel>/* /etc/ during boot ... and then you should just manage the files in /etc/profiles/<softlevel>/ as overlays to /etc/ is that the only thing you're missing from hprofile ?
(In reply to comment #8) > softlevel only affects init.d scripts, not anything else. it already checks > /etc/conf.d/<service>.<softlevel> before /etc/conf.d/<service>. Yes, that's the way ^^ I also understood it, the runlevels and conf.d files themselves are already covered by the current implementation. > only thing i can think of is a very simple init script that does something > like: > cp -a /etc/profiles/<softlevel>/* /etc/ > during boot ... and then you should just manage the files in > /etc/profiles/<softlevel>/ as overlays to /etc/ > > is that the only thing you're missing from hprofile ? Exactly, overlays to files other than the init.d scripts called from softlevels and their corresponding conf.d files. And the description of your proposed script is very similar to what hprofile is doing (which creates symlinks to the desired files in that managed overlay of /etc). It's necessary to be able to call that script after checkroot and before modules, but if baselayout2/openrc will conform to the expected behavior of using depend(), like you said in https://bugs.gentoo.org/show_bug.cgi?id=216720#c3 then yes, that would be what I 'm personally missing. Are you thinking of implementing such kind of script in some next baselayout/openrc? I'd volunteer to upgrade and test then ;-)
yes, i'm pondering writing a simple script for openrc ... but i dont think i want to support all the extraneous pieces (like hook scripts and all that), just the filesystem overlays
Well, that would be sufficient, I think and also an enhancement. Looking forward to it, keep it up!
Created attachment 149515 [details] runprofiles init.d this provides a mechanism for syncing files from /etc/runprofiles/<runlevel>/ to / it also provides for pre/post sync functions to be run by using the existing conf.d system ... just define what you want in conf.d/runprofiles[.<runlevel>]
latest Gentoo policy says you have to make sure /usr is mounted sanely. busybox provides a simple /ginit helper for this. as such, the hprofile behavior is not a bug.
