1 |
On Wed, May 29, 2013 at 10:52:49AM +0200, Tom Wijsman wrote |
2 |
> On Wed, 29 May 2013 00:36:58 +0000 (UTC) |
3 |
> Duncan <1i5t5.duncan@×××.net> wrote: |
4 |
> |
5 |
> > 3b) Except... at that point root isn't writable |
6 |
> |
7 |
> Let me stop you here. Does it need to be writable at that point? |
8 |
> |
9 |
> We're reading the path of the init file to boot from a file, we start |
10 |
> the executable at that path; no writes are involved here. |
11 |
> |
12 |
> The only problem left here is that some init systems need a specific |
13 |
> version of the inittab file, although this can likely be changed in |
14 |
> late shutdown as the only exception to this approach. |
15 |
|
16 |
In order for a different init system to come up, some file(s) |
17 |
somewhere *MUST* be different, no ifs/ands/ors/buts. The problem with |
18 |
an eselect approach is that it's like asking a brain surgeon to operate |
19 |
on himself. The proper procedure is to have another brain surgeon |
20 |
operate on him while the patient is under anesthesia. |
21 |
|
22 |
> It sounds very feasible for init systems that are an exception to just |
23 |
> being able to switch init alone or have conflicting files to fix up |
24 |
> whatever is inconsistent; either by scheduling changes till when the |
25 |
> disk is writable, or by doing it on shutdown... |
26 |
> |
27 |
> > But it occurred to me that we actually do have a demonstrated |
28 |
> > workable and long used in actual practice exception to the normal |
29 |
> > boot case as precedent, where such maintenance tasks traditionally |
30 |
> > occur, single user mode. |
31 |
> |
32 |
> Iff nothing else is feasible enough, this makes a lot of sense to me. |
33 |
|
34 |
There are a couple of other possible approaches... |
35 |
|
36 |
1) If the 2 systems can achieve peacefull co-existance (i.e. no |
37 |
identically-named files with different contents) then simply have 2 boot |
38 |
entries in /etc/lilo.conf (or grub equivalant)... |
39 |
|
40 |
append = "init=/etc/foo" |
41 |
append = "init=/etc/bar" |
42 |
|
43 |
...and select whichever one you want from the boot menu. This guarantees |
44 |
a) the system shuts down properly with the old init |
45 |
b) the system starts up properly with the new init |
46 |
c) if the new files are incorrect/unbootable, you can simply reboot to |
47 |
the old version and try to figure out what went wrong |
48 |
|
49 |
> > [initr* SNIP] |
50 |
> |
51 |
> Having an initr* as a requirement for being able to switch init system |
52 |
> is maybe a bit too much to ask; same as above, iff nothing else ... |
53 |
|
54 |
2) We already have such a solution; it's called the Gentoo minimal |
55 |
install ISO. If the 2 init systems conflict over identically-named |
56 |
files, I strongly recommend that the changes be done while booted from a |
57 |
gentoo minimal install ISO. This guarantees |
58 |
a) the system shuts down properly with the old init |
59 |
b) the system starts up properly with the new init |
60 |
c) if the new files are incorrect/unbootable, you can simply chroot into |
61 |
the machine and send pleas for help to the Gentoo user mailing list ;) |
62 |
|
63 |
-- |
64 |
Walter Dnes <waltdnes@××××××××.org> |
65 |
I don't run "desktop environments"; I run useful applications |