On 12/08/2016 19:47, Steve Litt wrote:
Hi Steve
[big snip]
Thanks for your valued thought but I consider the incident "water under
the bridge". All what I wanted is to warn PID 1 'runit' users that the
upgrading is a botched affair. As I said, I was able to recover the
system but belive me, its
Quoting Steve Litt (sl...@troubleshooters.com):
> LOL, you're right. The bootloader or UEFIwhatever starts the kernel.
Everyone who's read your excellent troubleshooters.com artlces about
inits figured out that your fingers were merely on autopilot or
something, but you _definitely_ knew that
On Fri, 12 Aug 2016 20:34:07 +0200
Harald Arnesen wrote:
> Steve Litt [2016-08-12 19:47]:
>
> > I don't understand. Do you perhaps mean that sysvinit is PID1, and
> > you use runit strictly as a process supervisor? The reason I ask
> > this is, whatever acts as PID1 is what
Harald Arnesen wrote:
<<
Steve Litt [2016-08-12 19:47]:
> I don't understand. Do you perhaps mean that sysvinit is PID1, and you
> use runit strictly as a process supervisor? The reason I ask this is,
> whatever acts as PID1 is what boots the kernel.
No. The kernel starts PID1.
>>
Steve Litt
Steve Litt [2016-08-12 19:47]:
> I don't understand. Do you perhaps mean that sysvinit is PID1, and you
> use runit strictly as a process supervisor? The reason I ask this is,
> whatever acts as PID1 is what boots the kernel.
No. The kernel starts PID1.
--
Hilsen Harald
On Fri, 12 Aug 2016 11:32:41 +0200
Fred DC wrote:
> Hi,
>
> My apololgies for sounding a bit emotional about this issue.
The behavior of the poetterists is enough to make anybody indignant.
>
> If, up to now, you have "runit" running as pid 1 and managed to
> maintain
Hi,
My apololgies for sounding a bit emotional about this issue.
If, up to now, you have "runit" running as pid 1 and managed to
maintain the ability to boot from the kernel commandline using
the sysv-init read on.
The latest update to package 'runit' *wipes* out the 2 binaries
/sbin/runit-init