You are not logged in.
Relying on an orphaned package to boot your system seems unwise, no?
systemd-shim is used to keep systemd happy enough to provide logind, even though the system is being booted by sysvinit. Not exactly using systemd-shim to boot...?
...and runit-init was always a weird side-alley anyway, right?
But don't think I'm promoting sysvinit at all. I'd be quite happy to go back to systemctl commands in bl-exit, although other users may not be.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
@HoaS sorry to shout, but I do get annoyed sometimes when faced with the implication that I somehow couldn't have had the issue I clearly stated previously that I did.
Yes I may well be in a minority, and I'm glad the process works for you, I've yet to have any success with it, but I haven't tried often.. I might add though, that my original comparison still stands because upgrading W95 > W98 also often worked in fact "worked for most people, more times than not". Given my experience I still have reservations about the process.
The box involved was "Plain ole Debian LXDE" using systemd. The only "foreign" software was the Seamonkey suite, which doesn't so much install as simply un-tar entire into your choice of folder in my case ~/seamonkey and run from there, so I can't really see how that would interfere, since it replaces nothing, and isn't even in my path.
On the subject of sysv-init though, since it came up
http://without-systemd.org/wiki/index.php/Debian_Stretch wrote:Support status
A January 2017 bug report discussion and a February 2017 mailing list thread indicate that Debian developers are continuing to support sysvinit.My own experience is the bl-exit package is not directly installable on a sysv-Helium system "depends libpam-systemd", though if the script is copied in manually it works perfectly as long as you have whatever libpam-* is there + systemd-shim.
As for relying on systemd-shim to boot, method two (variant) at http://without-systemd.org/wiki/index.p … an_Stretch doesn't install it and the system boots just fine, so clearly one isn't relying on it to boot, one needs to revise the suggested pinning and install it to make bl-exit work however.
Had trouble installing using method one, but didn't bother digging into troubleshooting that, though I might later, because I have one very old box which exhibits weird behaviour using systemd, namely the CPU usage is pegged at 100% sitting idle, using sysv that figure alternates between 3% and 4%.
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline
Not exactly using systemd-shim to boot...?
I didn't exactly say "using", I said:
Relying on
The only way Debian would boot with SysVinit as PID1 without systemd-shim would be by using an unsupported hack.
I have one very old box which exhibits weird behaviour using systemd, namely the CPU usage is pegged at 100% sitting idle, using sysv that figure alternates between 3% and 4%.
If that is true then it will never get fixed unless a bug report is filed, the developers are not psychic and probably don't visit these forums (much).
Offline
And, assuming that I took the time and trouble to track the issue down, and isolate exactly what to report, exactly how interested do you think those devs will be in fixing something that only happens to me on a Pentium 2 class machine?
I suspect any such bug would get fixed by revising the minimum system requirements for debian to a pentium 3 or 4 class processor.
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline
I have one very old box which exhibits weird behaviour using systemd, namely the CPU usage is pegged at 100% sitting idle, using sysv that figure alternates between 3% and 4%.
Turns out on further playing, this isn't directly systemd related. since if I do a netinstall and then
sudo apt-get install task-lxqt-desktop
the CPU is NOT so pegged.
It's therefore something that happens specifically with BL-Helium-dev, presumably something runs under systemd which pegs the cpu, and that same thing either fails to run, or uses less CPU under sysvinit.
Just saying, not sure if I'll dig into it, the hardware involved is so old it's not really useable for anything other than a commandline system, or DOS/Win9x gaming.
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline