blob: 90b805dc4883e745e664fc897c4fe67380700a18 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
#+TITLE: Feb 14, 2020
#+DATE: <2020-02-14 Fri>
**IMPORTANT!** Carbs-init update to be released on 17th of February
will require manual intervention. I am holding this update back so
people can see it before they update their system (even though the
update will show the same message as this). The rationale for the
update is explained below the intervention.
#+BEGIN_SRC sh
# There is an explanation for each init You only need to follow the instructions
# for your own init-system
## busybox-init
# If you did not edit your inittab simply move inittab.new to inittab
mv /etc/inittab.new /etc/inittab
# If you did edit your inittab you can use a simple sed command to remove the
# necessary lines
sed -i '/getty/d;/runsvdir/d' /etc/inittab
## runit
# same as busybox-init, if you did not edit /etc/runit/2 move 2.new to 2
mv /etc/runit/2.new /etc/runit/2
# else
vim /etc/runit/2
# open your 2 file and remove the for loop containing getty commands. If you are
# using runit, it is recommended to comment out /etc/init/runit.boot
## sinit/minit
# If you did not edit your {sinit-,}launch-services.boot you can simply remove
# it.
rm -f /etc/init/launch-services.boot /etc/init/sinit-launch-services.boot
# This should leave you without any issues, and you can safely reboot.
#+END_SRC
Carbs-init update is to make sure init systems do not clash, and do
not have to use different files. This is a sensible update both for
the user user and for the maintainer side.
To give an example, before this update busybox-init was managing getty
through =inittab=, runit was managing through =/etc/runit/2=, and
minit/sinit were launching from =/etc/init/launch-services.boot=. This
is a configuration nightmare for everyone, and since I am maintaining
and constantly testing those init providers, a huge nightmare for me.
This is a Quality of Life update.
|
