consolefont issues

[Duncan <1i5t5.duncan@cox.net>]

Part of this is downstream/gentoo, but there's some weird interaction, possibly circular dependency, upstream/openrc as well.

What initially focused my attention is the fact that baselayout/openrc treats the absence of runlevel link files as local configuration, but CONFIG_PROTECT doesn't. Namely, the comments in /etc/conf.d/consolefont say to remove it (rc-update delete) if it's unwanted, but while doing so works temporarily, as soon as I update openrc, the boot runlevel link is back again, CONFIG_PROTECT or no CONFIG_PROTECT, since that portage feature doesn't consider the absence of a file a configuration setting to be preserved.

So my next reaction is to create a dummy-service file in /etc/init.d that does nothing, and point the symlink in runlevel/boot at it, reasoning that if a file is there, CONFIG_PROTECT should do its job. The problem then is that no matter what's in the dummy service, whether it's all commented or whether it has start and stop functions that simply return 0, or even when I add a dummy depend function as well ( with before local, which shouldn't change anything since local is last already), it triggers a pidwait: Interrupted <something> error just after init takes over, before the first Openrc booting... output. Thus, since I reason figuring dependencies must be about the first order of business, I'm figuring it may be a dependency resolution error, circular dependency or something, with the interrupt to break it out of its loop and hopefully boot.

Only by removing the file entirely (or reverting to the non-dummy version), can I seem to break the error, but then I get the unwanted service back at the next update once again!

Of course, there are workarounds such as using entirely non-default runlevels, so anything merging can't kill the runlevel config, or using INSTALL_MASK, but one would think, particularly since the instructions say to configure it by deleting it, that the configuration should hold thru updates as normal configurations do on Gentoo.

One hack of a workaround would be to have rc-update (and friends, rc-config, eselect rc...) put an entry in a config file whenever they delete a runlevel entry. Then the various ebuilds that install links to the runlevels (most don't, as they don't activate by default, baselayout/openrc is one exception) can check that file and delete rather than install anything listed therein, as already deleted and thereby configured as NOT to be started in that runlevel by the sysadmin.

Meanwhile, if it's a circular dependency triggering the Waitpid: Interrupted error, the deptree I posted just a bit ago with bug #38 should be of help, tho that's without the dummy service dependencies. However it doesn't seem to matter what dependencies I put in the dummy service, it still triggers that error, so if it's a circular dependency, it would seem to be so without the entries in that service. Or maybe it's not updating the dependencies right when I change the service?

I don't know. I do know it's strange, tho, and frustrating as it triggers a console reset and thereby the loss of my scrollback buffer, which I like to keep around to investigate any kernel issues I might have, without having to resort to the log file at least for the initial look-over. (That BTW is one of the reasons I don't want consolefont in the first place, it too triggers a console reset, and therefore the loss of the scrollback buffer.)

Duncan

[roy]

When you emerge the git ebuild, it always adds the default runlevel links. However, the 0.1 ebuild does not do this. On a box running it, I can rc-update del consolefont boot, re-emerge openrc and consolefont is still missing from the boot runlevel.

As to the rest of the issue, it could be caused be reiserfs, and someone has told me of a reiserfs bug that has now hopefully been fixed in the git repo.

[roy]

Gentoo developers are now automatically adding missing services to the boot runlevel, so I suggest you take this matter up with them now.